金融企业应用容器化改造四大难点
金融企业应用容器化改造四大难点

一、应用容器化改造四大难点


应用容器化改造难点1:容器化后核心系统和非核心系统如何共存在同一主机,兼顾成本和安全性?

容器的隔离性没有虚拟机强,他们共享同一主机内核,如果一个核心系统和非核心系统共存在一台主机运行,可能非核心服务因为某种缘故导致内核crash,所在主机所有的服务都回收到影响,我们也不可能一个物理机只跑一个核心服务,那样的话成本太高。

@gxcornflakes:

首先,对于银行业,容器技术适用于敏态业务(互联网业务),虚机技术适用于稳态业务,容器技术不是一概而论的。

1、首先关于运行的系统进行讨论,无论是核心还是非核心系统,都是分布式的,都是多个节点的,理论上,一台物理机可以跑多个容器,即运行一个核心或者非核心的系统的多个服务实例(1个系统对应M个服务,1个服务运行N个实例)。

2、计算节点(物理机),无论是容器还是虚拟机都是运行在多个计算节点(冗余高可用),单个计算节点宕机,容器或虚机均会自动漂移至新计算节点,提供服务;而虚机内核crash,并不会漂移,而产生当然虚机的服务不可用,需手动重启。

3、根据上述描述,1)隔离性方面,一个核心系统和非核心系统共存在一台主机运行,存在相互影响的情况,但是容器会自动漂移重新提供服务。2)成本方面,如需进行隔离,则可采用核心业务非核心业务分计算集群的方式运行,而一个计算节点可以跑多个核心服务,一个计算节点发生crash时可以漂移至另一个计算节点,漂移过程中出现轻微服务波动的情况。

4、如果考虑核心业务的高SLA,那还是建议核心业务使用虚机或者物理机,而非核心业务使用容器技术,容器应用从非核心业务进行试点推广。

@yaoyaozdl:

一般来说容器部署,底层物理设备都是多台X86服务器,很少有单点的。如果的确有这种需求,可以先把底层物理设备先进行虚拟化,再在虚拟机上面部署容器,通过虚拟化层面实现故障隔离,资源配额。

@Steven99:

个人觉得首先考虑应用和资源的分层问题。应用只是使用资源,资源统一由基础设施资源平台来管理,需要什么资源分配什么资源。

不要尝试直接用docker或k8s cmd去管理应用,否则自己会玩死自己。应用管理平台要考虑产品化。

容器的优点在于弹性,云计算的优点在于体量,没有大量的需求,不会节约成本,反而造成浪费。

安全性需要通过产品化和不同层次的安全措施实现。

@dean25:

目前我们的做法是核心业务和非核心业务承载在不同的K8S集群上。同一集群内的应用可以共享宿主机。为了避免因为单个节点故障影响应用,要求所有的应用必须至少部署2个副本,分布在不同的宿主机上,同时对于核心业务,要求应用必须双活部署,也即部署在双活数据中心的两个独立K8S集群上,前端通过负载均衡或者自动发现机制引流,这样即使某个数据中心发生了全局性故障,也不会影响应用。


应用容器化改造难点2:怎样实现应用的高可用,需要考虑哪些方面?

@liufengyi:

1.无状态,或者存储状态在应用本地的转移到第三方服务上(如本地会话转移到redis等,本地存储转移到分布式存储上)

2.配置管理,配置接入配置中心,最好有应用实现配置治理

3.服务最好不依赖ip,hostname等本地标识

4.调度亲和性,反亲和性(不在一个机架或者主机上)

5.应用健康检查

6.优雅启停

@dean25

总结起来,有以下几点:

1. 应用无状态,多副本部署,副本分布到不同节点

2. 使用PVC的话,尽量不要使用共享PVC

3. 使用独占PVC,要确保没有外部应用程序去访问

4. liveness/readiness机制要尽可能覆盖完善

5. 应用跨集群容灾双活部署

6. 服务间有启动顺序依赖的话,需要做好对所依赖服务的探活和重连机制


应用容器化改造难点3:如何选择对外发布服务的方式,Nodeport、Ingress和LoadBalance如何选择?

@lligao:

也可以直接与负载均衡厂商(如F5)进行集成,不需要另外开发。既能满足容器对灵活性的要求,也能保留F5的传统优势。

F5的解决方案包含2个组件,VE(Virtual Edition)和CC(Container Connector)。VE是F5LTM的软件化产品,可以安装在虚拟机上,其功能与硬件设备完全一致。CC是F5的一个开源组件,它以容器的形式部署在Kubernetes集群中,通过读取Kubernetes API获取集群内的服务资源并将其转化为VE上的配置。管理员可以为每一个租户部署一组CC,每组CC独立控制VE上的一个对象配置隔离区域(partition),该partition下的资源完全由该组CC独立控制。兼顾了稳定性、灵活性与安全性。该方案中,负载均衡策略的定义提供多种方式,可以使用Ingress,也可以使用ConfigMap。

采用CC+VE技术,利用CC与Kubernetes通过API进行联动,完全适应容器平台对灵活性的要求;另外,配置上采用ConfigMap定义负载均衡策略,架构上采用VE直接对集群中的POD进行负载分发,减少网络层次,提升负载均衡性能;同时,通过将Kubernetes的Namespace与VE的partition一一对应,实现不同容器租户服务资源的隔离。

@liufengyi:

nodeport 四层协议的适用 中小规模的时候可以使用(ipvs目前不是特别的稳定,个人认为还没到生产可用,我们经常遇见服务没有及时更新的问题,但是是未来的方向)

ingress 七层http和https协议适用 有多种ingress类型

loadbalance 需要自己去开发对接了。

@Steven99:

K8s发布服务有4种方式,ClusterIp, Nodeport, loadbalancer, externalName
ClusterIp是对容器内部服务调用。

Nodeport是提供对外的调用方式,但Ip:port的方式通常不够友好。

Loadbalancer是需要k8s 外部负载均衡工具的支持。

基于Ingress机制可以实现负载均衡,比如用Nginx实现Ingress负载均衡。通常可以使用Ingress机制,辅以DNS实现域名访问。不过需要优化的工作不少。

ExternalName没有详细研究。

@Garyy:

Openshift产品推荐通过NodePort类型的Service为某个应用对外暴露一个服务端口。NodePort类型的Service会在集群中的所有节点上监听一个特定的端口,访问任意一个计算机节点的端口,即可访问内部容器中的服务。在集群的所有节点的这个端口都会预留给该应用所用。

• 在F5 VS的Pool Member中配置所有节点,通过Keepalived来实现HA

• 应用系统和用户不用改变现有的访问方式。

@dean25:

从我们实际使用情况看,三种方式适用于不同场景。Nodeport适用于需要将服务端口注册到服务注册中心,不需要负载均衡的应用,典型的如使用了Spring Cloud服务治理架构的应用,应用和应用之间通过注册到服务中心的IP+端口通信。Ingress适合于对外的微服务较多,需要收敛到统一对外服务入口的应用,比如有20个微服务,都通过NodePort或者Loadbalance对外服务并不现实,通过Ingress对外提供统一服务入口就变得很有必要了。LoadBalance适用于除上述两种类型应用的其它场景。

@lihaoyu:

Nodeport方式在某些场景上还是存在一些问题的,NodePort的实现方式是通过直接访问计算节点的端口,通过计算节点的iptables来转发请求至pod,而iptables只能基于源IP地址做会话保持,不能基于cookie等信息。另外,如果F5在没有开启X-Forwarded-For的情况下,由于计算节点接收到请求的源IP都为F5的地址,所以基于iptables的源地址会话保持机制,会将访问的所有流量都转发到一个pod中,导致在有多个pod的情况,只有一个pod有业务访问流量,其他pod没有负载(实际情况下,其他pod也有流量,但是流量非常少),不能做到流量负载均衡;

Ingress方式适合的场景会更多,可以通过Nginx或者HAProxy实现负载均衡,不过这种方式可能会带来一些额外的工作。如果现有环境中,系统间的接口调用方式不是域名方式的话,就需要接口调用方及提供方更改接口地址为域名地址,同时还需要引入DNS配合。


应用容器化改造难点4:容器化后日志存储该如何改造,如何兼顾本地存储和远程ELK存储?

@liufengyi:

第一种做法是用分布式存储,使用stateful资源对象模型来编排应用,外部对接elk(日志打印标准输出和本地),这样日志本地和远程都兼顾,但是要注意日志需要定时归档,删除。

第二种做法是用hostpath或者emptyDir,使用deployment资源对象模型来编排应用,注意不要把磁盘文件系统空间写满,外部对接elk。

@Garyy:

应对分布式环境下日志分散的解决办法是收集日志,将其集中到一个地方。收集到的海量日志需要经过结构化处理,进而交给需要的人员分析,挖掘日志的价值信息。同时不同的人员对日志的需求是不一样的,运营人员关注访问日志,运维人员关注系统日志,开发人员关注应用日志。这样就需要有一种足够开放、灵活的方法让所有关心日志的人在日志收集过程中对其定义、分割、过滤、索引、查询。

OpenShift使用EFK来实现日志管理平台。该管理平台具备以下能力:

■ 日志采集,将日志集中在一起

■ 索引日志内容,快速返回查询结果

■ 具有伸缩性,在各个环节都能够扩容

■ 强大的图形查询工具、报表产出工具

@dean25:

如果采用集中式的日志收集Agent,也就是在应用容器之外单独由一个日志收集程序从PVC收集日志并发往ELK,会很容易导致应用容器切换到新节点时失败,原因是日志收集程序会hold住PVC,如果PVC是独占类型的,就会锁住PVC,导致PVC无法释放,相应的应用Pod在新节点上由于不能加载PVC,就无法启动。为了解决这个问题,我们的做法是给这种需求的应用容器旁挂一个日志收集容器,两个容器在一个Pod里,这样应用Pod退出时,会完全释放PVC,应用Pod也可以在新的节点正常启动。


二、更多相关问题


1、在灰度发布功能方面,容器云能提供哪些帮助?如何设计并实现基于容器云的灰度发布功能?

@Steven99:

灰度发布通常是互联网类应用,快速迭代,以新版本逐步发布替换旧版本,以验证新版本是否存在重大缺陷,在新版本有问题的情况下可以快速回滚。

实现方式有多种,容器云平台层就是用同一个服务对应多个不同的容器实例,在发布新版本时,这些容器实例可以实现逐步的替换(服务名不变),就实现了灰度发布功能。

还有一种方法是通过流量负载分发,这种方式可以部署服务为多个版本,每个版本引流部分流量,需要有路由负载分发组件支持。

或者可以直接在容器云平台外部署API网关,在网关层实现路由分发,支持更多选择。

@dean25:

我们目前并没有用istio来做灰度发布,主要是对于istio在生产环境使用还有一些顾虑。目前灰度发布的流量切换还是通过F5负载均衡实现。K8S层面可以申请两个命名空间,其中一个用于灰度版本的发布。一旦验证通过,在F5上做流量切换即可。F5的member添加和删除已经完全自动化,所以流量切换或者回切都会很方便。

@liufengyi:

灰度发布功能,服务网格能做,不过可能对现有的技术体系和服务管控有比较大的冲击,而且服务网格还不是真正的很成熟。

容器云能很快的创建应用的新版本服务实例,剩下的结合负载均衡器结合业务做流量分发管理就能实现灰度发布。

1.创建新的应用版本集群,老的应用版本并存,这样资源的使用要多不少,逐步扩大新版本的分发流量比例,并且逐步减少老应用版本实例数。

2.采用滚动升级的方法,比如运行一个新应用版本实例,删除老的应用版本实例。逐步替换。

另外灰度发布是一个很复杂的体系工程,除了流量管理外,还涉及新旧版本存储数据如何平滑迁移以及如何回滚

@mtming333:

istio k8的方案很完备。

mesos的话可以通过拆分成两个应用实现灰度版本,通过服务发现和服务注册组件配合istio实现引流。


2、银行企业应用如何做无状态化?

【问题描述】对于有状态应用,容器需要额外技术负担去保证容器不漂移或者存储数据不丢失,对于运维和技术要求很高,所以银行企业应用如何做无状态化就显得很重要。

@gxcornflakes:

1、应用(主要介绍java应用)无状态化分为两个部分,session无状态化和存储无状态化。

2、一般银行应用均采用F5作为负载均衡,并采用session粘滞模式,如应用容器化则需实现session无状态化,如果采用springboot技术,添加@EnableRedisHttpSession来开启spring session支持,同时在application.properties中配置redis服务器信息;如果传统应用采用非springboot技术,容器采用tomcat,可以采用tomcat-redis-session-manager组件。以上redis建议采用高可用模式(如哨兵或集群),并强烈建议redis开启密码认证等安全配置。

3、有少部分应用需要挂载NAS存储,如应用容器化则需有两种方案,一种方案是宿主机和容器都挂载NAS存储,但这样会加强运维复杂度以及存储管理难度,不建议;第二种方案是存储无状态化,需采用分布式对象存储代替传统NAS存储,同时应用需改造采用S3接口,银行引入新技术分布式对象存储的可用性有待进一步验证,形成风险点。

4、建议挂载NAS存储的应用暂不上容器,规避技术复杂性,而敏态业务(互联网)应用改造上容器。

5、建立《容器平台应用适云规范》。

@liufengyi:

这个问题应该是问怎么样去做有状态应用。

我先回答一下如何做无状态应用,应用部署包的组成主要为代码,配置文件,初始化脚本,启停脚本,各类依赖管理。

无状态应用,我们要显式声明应用依赖管理,配置文件应该外部化,或环境变量,或配置中心管理,我们build出的镜像应该能在各种环境下使用。日志输出应该对接elk,要对日志输出格式进行改造,适配集中式日志系统规范。

有状态应用,我们除了要对接共享存储之外,还要注意有状态应用的扩缩容,比如如何弹性扩容三主三从redis集群,读写分离mysql,这些都是共享存储之外需要做的。

对于共享存储,对于强监管的银行应用,我们要做好存储的生命周期管理,审计,权限控管,配额管理,qos,故障追踪,平滑扩容等等一系列共享存储本身技术之外的东西。

@Steven99:

个人觉得应用是需要考虑分层实现的,不是一个容器就运行一个应用。基于这样的考虑,其实可以实现容器层的无状态,可以利用容器的弹性等优点。

一个应用有一到多个服务,每个服务部署一到多个服务实例。配置由配置中心统一管控。实例、服务配置可以相同也可以不同,做到按需配置。

日志、监控等实现统一接口,应用服务不需要关注,通过配置就可以实现不同日志、监控平台的接入

数据可以通过messaging等方式实现和底层存储的松耦合,可以存储于数据库、大数据平台等

中间可以按需加入缓存、数据处理等逻辑

不妨基于这样的考虑尝试下

@聂奎甲:

容器云环境下,应用和基础环境资源是解耦的,应用的扩缩容不需要涉及基础环境资源的扩缩容,仅仅需要修改应用部署模板文件中的副本数,然后在容器云平台执行即可。容器云平台会根据副本数来自动创建或者删除副本,使得最终的副本数是部署模板文件中定义的副本数。整个扩容或缩容流程可以在数秒到数十秒内完成。这样当应用面临突发业务量增长,需要紧急扩容的时候,就可以非常快的完成,实现了真正意义上的弹性扩容。

@Garyy:

无状态应用:Stateless Application 是指并不会在会话中保存下次会话中去要的客户端数据。每一个会话都像首次执行一样,不会依赖之前的数据进行响应。

有状态的应用: Stateful Application 是指会在会话中保存客户端的数据,并在客户端下一次的请求中来使用那些数据。

在无状态应用中,会话数据将会被存储在客户端或者透传给需要的这些数据的服务。在开发离线应用时,这是一个非常重要的的因素。通过这种方式来开发,会话数据将会被存储在终端用户的设备上,例如:当网络不可用时,用户将数据存储在自己的设备上,当网络重新连接时,会话数据将被上传并复制到云中。

在分布式系统中,无状态应用使实现了分布式水平扩展成为可能。当分布式系统中的一个组建是无状态时,能够在出现故障时轻松的重新部署,也能够自由的水平扩展来适应负载。组建之间也能够方便的使用API来进行通信。

@dean25:

银行业的很多应用,特别是一些核心应用很难做到完全的无状态化,典型的比如需要根据应用容器(或所在宿主机)生成交易流水号的应用。交易流水号很重要,通过它可以知道一笔交易在内部都经过了哪些处理环节,要明确到是哪个容器处理在这个处理环节里。这种情况下就很难做到无状态化。此外,很多核心应用还需要本地保存日志,需要每个容器将自己的日志写入独立的PVC。这种情况下也无法做到无状态化。好在K8S通过StatefulSet提供了对有状态应用的支持,运维难度其实和无状态的差别并不大。


3、同一套应用系统节点分别部署在虚拟机和容器环境,是否可行?有具体生产落地实践吗?

【问题描述】针对某一套具体应用系统,比如8节点,4个节点以虚拟机方式部署和运行,4个以容器方式部署和运行,前端通过负载均衡进行流量控制,这种方式是否有银行生产落地实践?有哪些需要注意的技术难点?

@gxcornflakes:

分别部署虚机/物理机和容器环境,可行!

1、目标:对于业务连续性要求,防范新技术(容器技术)应用的技术风险,重要系统可以同时部署在两种环境,形成“本地双活”,当容器平台发生风险时,无业务中断风险,但是此技术会增加配置复杂性、架构复杂性和操作复杂性。待容器技术成熟后,可切至容器平台,也可认为是一种技术过渡性方案。

2、应用节点部署,1)虚机/物理机部署,可采用自动化部署(使用Jenkin、ansible等自动化技术),或者手动部署;2)容器部署,采用镜像进行一键部署。

3、负载均衡,最前端采用F5,1)双负载均衡架构,前端一个总VS,下挂分别挂两个VS:A、虚机/物理机单独再配置一个VS(虚机物理机IP),B、容器部署也配置一个VS(容器软负载IP);2)单负载均衡架构,前端一个VS,下挂混合虚机/物理机IP以及容器软负载IP。

4、上述两种负载均衡根据各数据中心情况和需求进行相应调整。

@liufengyi:

这种方案是银行过渡到容器云阶段的必经之路。

1.接入层使用负载均衡来流量分发到虚拟机或者容器集群,虚拟机部署的应用服务endport基本可认为是固定的,负载均衡可以手工配置,但是容器集群的应用容器是动态ip(除非做ip固定),这样就要求负载均衡要有服务自动注册的能力。

2.容器化到一定阶段后,上下游应用混合跑在异构环境中,要注意容器集群和虚拟机集群的互联互通,虚拟机要能访问到容器集群的服务实例,容器集群也要能访问到虚拟机集群里面的关联服务。

3.要注意规划采用哪种容器网络方案,不同的网络方案会有不同的问题。(三层路由或者隧道模式,或者放弃网络隔离性,采用宿主机网络)

4.注意关联服务是否有ip白名单的安全管理要求。

@lihaoyu :

肯定是可行的。

传统企业在进行老系统容器化改造的过程中,应该都会面临这个问题:切割上线的时候,是一刀切,还是先并行(或称之为灰度发布)?

虽然在容器环境生产上线前都会经过各种各样测试,但是很难保证一刀切(将业务系统的访问流量从虚拟化环境全部切换至容器环境)之后不会出现异常。所以,比较稳妥的方式,就是将同一系统在原有环境中与容器环境中同时并行运行。以F5负载均衡为例,将”容器节点“作为新的pool member加入到原有的VS中。需要注意的是,这种方式需要考虑容器环境的外部访问模式,如果是NodePort访问方式,则需要把node+port加入到VS中,如果是域名访问方式,需要把Router加入到VS中。


4、集团容器云如何建设?产品选型及标准上有哪些建议?

【问题描述】我们集团是一家大型中央企业,属下业务板块众多,既有金融板块(银行、证券、保险等)、地产板块、交通物流板块、工业板块等。金融板块IT比较独立。集团今年在落实数字化转型中,提出两平台一体系的建设:云平台、大数据平台、数据治理体系。云平台建设是基础,是集团数字化转型的底座,云平台建设重点是PAAS平台。按照集团信息化的特点及现状,总部综合管控系统、下属公司业务系统等基本采用购置第三方的成熟产品套件,这块完全云化,不太现实,需要第三方厂家产品支持。

关于容器云建设,这个在传统行业也刚刚起步,在容器云建设大家认识不统一:

第一、完全自研不太现实,资源配置不足;

第二采用容器云平台,行业的软件提供商在支持容器开发上产品不多。

基于这样的场景,集团容器云如何建设?采用K8s+docker是否能够满足未来的云化需求?行业内的PASS平台缺乏统一标准,各厂家产品的组件化提供方式不太成熟(组件化输出为能力,移植到自有的PASS平台)。在产品选型及标准上有什么好的建议?传统的应用是否有必要向容器云分拆成微服务?

@gxcornflakes:

1、云平台,从一个维度上讲包括IaaS、PaaS和SaaS,从另一个维度上讲包括计算云、存储云和网络云。首先贵公司确定建设目标,是基于容器技术的PaaS云平台,所以围绕这个目标进行建设。

2、容器技术,目前技术路线已经非常清晰,由原来的三足鼎立(k8s、mesos、swarm)演变为一枝独秀k8s,大家可以紧追k8s路线,且k8s经历了大版本的变更已逐步稳定、国内外生产案例具有大规模集群案例,基于k8s的方案已逐步走向成熟,k8s生态也逐步建立起来,当然相关组件还需进一步生产实践;

3、云管平台,所有功能基于UI化,以便操作用户和管理员用户进行操作,同时API化,以便各平台调用;同时运维方面,包括资源管理、组件管理、健康、日志、监控、应急、容量、部署、镜像、弹性扩缩、网络、存储、负载均衡等管理,运营方面,包括各应用系统的资源概览、容量分配情况、资源使用等情况;多数据中心管理,数据中心多集群管理、多数据中心集群管理、多数据中心镜像管理、资源统一调度、同城数据中心双活、异地数据中心灾备、灾备演练、灾备一键切换等功能;客户化,由于公司流程复杂、数据中心平台繁多,容器产品需要进行很多客户化开发,并进行各种流程系统对接。

4、容器平台建设,第一阶段采用厂商(建议专业做容器技术的厂商)合作模式,引入产品,由厂商支持底层组件等运维,有条件的情况下逐步过渡到以我为主(规划需求设计)、厂商为辅(开发测试运维),同时建设自主研发团队纳管云管平台建设。

5、团队方面:容器技术本身较难,需要技术研发团队进行新技术的调研、二开、应用的开源治理工作,同时运维支持进行问题排查工作;同时由ITIL流程逐步转换为较为轻量级的DevOps流程来适配容器云平台建设和应用,这需要从制度流程上和团队思维上进行逐步改变;

6、应用方面,应用包括稳态和敏态,容器适合敏态业务的应用(或者互联网应用)。传统应用根据整体规划逐步向微服务演进,一般的传统应用进行无状态改造后可直接上容器;非常厚重的应用需逐步改造为微服务,微服务拆分可按照业务进行拆分。一方面摸着石头过河,一方面最重要的是在改造过程中建设微服务规范和应用适云规范,逐步推广,这是一个长远建设的过程,需要加强技术人员支持。

@dean25:

目前来看,K8S+Docker已经是大势所趋,可以作为容器云平台的核心。当然,一个完善的容器云平台不能只是K8S+Docker,还需要一个统一的自服务管理平台,需要配套的应用日志处理系统、监控系统、DevOps流程和工具体系、资源申请和管理体系、应用容器化改造规范等。这些方面,涉及大量的定制化,市面上不一定能找到合适的产品,如果具备自研能力,可以自己自主设计开发。如果不具备,可以考虑采购一些产品,快速形成能力,并要求厂商支持定制化开发。

容器天生是要求微服务的,所以做应用容器改造实际上就是一个应用微服务化的过程。传统应用里,如果以前都是按照模块化方式开发的,改造起来相对容器,只需要把模块改造成微服务,通信方式从IPC换成RPC,并对日志输出方式做一定改造。如果不是模块化的,改造难度会比较大,可以尽量做一些拆分,让单个容器不要承担太多的功能和压力。

@Steven99:

云平台不只是容器云,容器云可以是其中的一部分。集团考虑云计算平台作为数字化转型底座,可以考虑构建统一的基础设施平台,包括IaaS和PaaS,技术实现有很多种,容器云只是其中一部分。

考虑资源管理和应用管理分离,通过租户机制实现使用资源满足应用运营管理需求。

需要构建企业级PaaS平台,支持多集群、多数据中心部署

选型容器云,需要自身具备自主控制能力,否则不建议实施容器云。

采用容器云可能需要同步考虑微服务架构,实现业务应用的改造,能够发挥容器的特性

@liufengyi:

1.首先需要统一认识,使用容器需要解决什么问题。

2.公司需要有对容器比较熟悉的人牵头建设,或者与容器厂商共建

3.k8s和docker基本能满足大部分的需求,不过容器化建设的难点还在于存储,网络还有与基础设施整合,流程制度等等一切

4.先试点非关键应用,需要频繁变更应用或者需要快速扩缩容的应用,或者是敏捷性应用。

本文文字及图片,版权归原作者所有
如需联系斑鸠,请电洽:0592-5922595