以业务为核心的云原生体系建设（上）

本文转载自【刘超的通俗云计算】公众号，作者刘超，网易杭州研究院云计算架构师

要做好整个企业的云原生体系建设，需要有个总体的视角，不谋全局者，不足以谋一域。我们将企业的架构进行全方面的梳理，并给出云原生体系建设总图，这个图当然不是一蹴而就就能建设完毕的，而是根据业务需求不断迭代演进出来的，但是我们要知道目标在哪里。

1、企业架构的五个方面

企业架构不仅仅是技术问题，还有流程问题和组织问题，总得来说分为五个方面，业务架构、技术架构、数据架构、研发流程和组织架构。

 第一个是业务架构，里面承载了企业所从事的业务的核心逻辑。目前大部分企业因为系统多是外采的，或者因为原来对于IT投入不够重视，处于单体架构的阶段。也有部分比较先进的企业，为了应对市场的快速变化，而采用了服务化的架构，构建了中台体系。而互联网公司因为要应对高并发流量，已经将服务拆分得更加细，实现了微服务架构。

第二个是技术架构，为了支撑业务代码的运行而建设的IT基础实施。最初企业多会采购物理机的方式运行业务代码，因为资源使用效率和灵活度的问题，很多企业采用了虚拟化平台。从虚拟化平台到云平台的变化不在于技术，而在于使用模式，主要是三点，统一接口，抽象概念，租户自助，说白了就是让业务方不需要特别专业的底层技术能力，就能实现应用的部署，同时将运维人员从应对越来越多的业务方的噩梦中解放出来。这一点很多企业出现了问题，一些采购了公有云或者OpenStack，仍然将所有的操作权限都放在运维那里，把云当成了虚拟化软件在用。容器进一步让应用从代码到运行无缝的连接起来，并且可以实现跨云的迁移。Service Mesh将微服务的治理放到统一的平台上来做，进一步解放业务方。

第三个是数据架构，在业务运行的过程中，会积累很多的数据。最初企业的系统多只做数据记录的作用，并没有发挥太多的价值，数据是散落在各个系统的数据库之中的，如果想进行分析，查看当前业务的运行情况，需要一个分析师将数据导出来，做成表格和报告，给领导看，这样时效性就会很差。后来很多企业开始做数据的梳理，建设数据仓库，并且建设BI大屏，领导驾驶舱，支撑战略决策。当然这种方式没有办法和业务直接结合，于是才有的后来的数据运营驱动业务创新，我们在电商和社交APP上感受到的千人千面，智能推荐，都是例子。

第四个是研发流程，也即代码是如何发布上线的。最初企业的发布上线都是手工化的，后来随着服务数目增多，开始脚本化。脚本难以维护，容易出错，后来就有了统一的发布平台，和云平台相结合，进行自动化的发布流程管理。有了容器之后，发布模式有了一定的改变，强调开发和运维合作保障在线业务的SLA，而非仅仅运维保障，从而发布平台也要DevOps化。

第五个是组织架构，根据康威定律，组织架构和技术架构往往是相互影响的，如果仅仅调整技术架构，不调整组织架构，则不能发挥新技术的优势。最初企业往往是开发和运维完全隔离的，甚至是两个老大进行领导，因而不能融合，迭代速度慢，线上高可用无法保证。要改变这种方式，除了配备上面的技术平台之外，还需要成立中台组或者架构师组，来衔接开发和运维，最终实现开发和运维的融合，共同基于DevOps平台保障线上系统的可用性。

2、云原生体系建设总图

根据上面的梳理，我们会发现，云原生体系建设还是非常复杂的，最终会建成一个什么样呢？需要有一个目标的总体架构，只有有了目标，就可以根据业务的发展阶段，逐步向这个方向进行靠拢。

所以我这里画了一张云原生体系建设总图。       这张图左面是组织架构的部分，右面是技术架构的部分。左面和右面相同颜色的部分，就是相应的团队负责相应的技术架构的部分。

我们先看右面技术架构的部分。

最底层是数据中心的物理网络，对于数据中心的基本原理，《趣谈网络协议》中有一节专门描述。但是这里的数据中心是云数据中心，所以其设计会要求更高，在这个课程会更加详细的描述。

在物理网络之上是虚拟网络，最好整个数据中心有一个统一的SDN控制器，可以方便不同的环境之间的网络打通，例如物理机，Vmware虚拟机，OpenStack虚拟机，容器网络，都可以被统一的管理。SDN可以是使用硬件的，也可以使用软件的。

接着是OpenStack云平台，可以纳管物理机，Vmware虚拟机，KVM虚拟机，向上提供统一的接口。当然也可以不基于OpenStack创建云平台，而用云管平台。OpenStack的好处就是接口统一，业内和他配合的工具链比较丰富，有很多的运维工具可以直接基于OpenStack接口创建虚拟机，因而持续集成平台和OpenStack对接会轻松很多，实现基于云接口的应用编排。无论是用OpenStack或者其他的云管平台，作为“云”，除了统一接口之外，还要有相应的租户管理体系，租户和用户要分层分权限，让平台管理员可以分配给业务方一定的权限，例如Quota，QoS等，可以让业务方对于应用部署有一定的自助能力。另外云还要提供一层对于底层技术的抽象，例如flavor作为CPU和内存的抽象，VPC作为网络的抽象，安全组作为防火墙的抽象等，这样业务不需要特别懂底层技术，就能有应用的部署能力。

基于OpenStack云平台，可以实现基于虚拟机镜像的运行环境，容器有镜像，虚拟机也有，在有容器之前，我们就可以对接持续集成平台，基于虚拟机的镜像实现应用的编排，将主流的运行环境全部打成镜像，并可以基于虚拟机镜像实现弹性伸缩。

基于OpenStack云平台以及虚拟机镜像，可以构建基于虚拟机的PaaS平台，也即数据库，消息队列，缓存等，都可以变成托管服务，让业务方点即可得，不用自己搭建，也不用考虑高可用如何配置，主备如何切换，PaaS如何扩容等等，这些全部由虚拟机镜像中的脚本自动化搞定。

在此之上是Kubernetes容器平台，他作为统一的编排层，可以将Vmware创建出来的虚拟机，KVM创建出来的虚拟机，以及物理机统一的纳管进来，还可以通过多Kubernetes管理，纳管公有云上的资源。Kubernetes里面的概念更贴近应用层，所以可以看成从资源层到应用层过渡的桥梁，将底层不同的资源全部屏蔽起来，对上提供统一的应用编排。Kubernetes的编排能力比OpenStack强很多，对概念的抽象也更加对应用友好，因而持续集成平台可以从对接OpenStack，慢慢切换称为对接Kubernetes，可以实现跨云编排，迁移，与弹性伸缩。

有了Kubernetes，就不用使用虚拟机镜像做应用运行环境了，Docker镜像就是天然的运行环境，而且更加的标准化，可以跨云迁移。另外有了Kubernetes Operator，可以基于容器实现PaaS平台，也即数据库，缓存，消息队列的编排。

在网上就是应用层了，这里以电商业务为例子，业务层已经实现了微服务化，封为两层，下层为中台层，也即可复用的能力，强调资源整合和能力沉淀，包括第三方商家，供应链，决策，用户，商品，社交，交易等基础服务。上层为业务应用，强调贴近用户，快速应对市场变化，包含的系统非常多。当然不是任何一个业务都是要一下子拆这么细的，而是逐渐拆分的，如何逐步拆分成这样，也是本课程的重点。

为了支撑如此复杂的微服务架构，需要配备相应的工具链，例如API网关，微服务管理与治理平台，APM性能管理平台，日志中心，配置中心，分布式事务等。当然这些工具链也不是一下子都用起来，也是随着微服务的不断拆分，逐渐的使用。

这些工具的采用都多少对于应用有侵入性，如果想让微服务的治理能力下层到基础设施层，Service Mesh是一个好的选择。

另外还要有端到端统一的监控中心，要下能够监控基础设施，上能够监控应用的运行，这样在定位问题的时候，才能够互相印证。

我们再来看左面的组织架构。

为了讲右面的技术架构运行起来，要改变原来CIO下面一个技术总监，一个运维总监的情况。由于整个技术体系比较复杂，需要整个团队基于统一的流程和规范，才能方便管理，而如何保证整个系统的运行符合这个流程和规范，仅仅CIO一个人的精力不够，需要有一个架构委员会，这里面有专职的架构师，包括云的，运维的，微服务的，QA的，项目管理的，另外架构委员会里面还应该有各个组架构师代表。架构委员会对于整个架构的运行，流程和规范的落地负责，并像CIO汇报。而且架构委员会会融合各个角色，不会出现开发和运维隔离的情况。架构委员会制定流程和规范，并要求各个开发和运维组执行。

开发组分成业务开发和中台开发组，业务开发组用于快速响应客户的需求，中台开发组不直接面向客户，每天想的事情就是能力如何复用，如何锻炼腰部力量，只有有一拨人专门考虑这个问题，才有可能积累称为中台。

业务开发和中台开发到底是否执行架构委员会制定的流程和规范，需要有一定的工具链的配合，因而就需要技术底座组，包括云，大数据，容器，微服务，已经相应的流程管理，规范管理，绩效看板等，可以让架构委员会通过工具链，实时审核架构当前的运行情况，并对不符合流程和规范的接口，测试，文档等及时纠正，并计入绩效看板。

看完了这些，你可能觉得，哇，云原生如此的复杂，直接放弃吧。

其实不是的，从来没有一种说法是一下子就达到这个状态，而且也不可能通过采购一个大平台，公司一下子就形成了云原生架构，这都需要迭代的进行，这正是要解决的问题。

接下来，我会逐层剖丝剥茧的解析这个迭代过程，主要的思路为：

• 遇到什么样的问题？

• 应该采取什么样的技术解决这个问题？如何解决这个问题的？

• 这个技术的实现有很多种，应该如何选型？

• 使用这个技术有没有最佳实践，能不能形成企业的相关规范？

3、云原生体系演进阶段一：拉通信息系统，重塑组织协同

我们来看第一个阶段，拉通信息系统，重塑组织协同。

我们分别从企业架构的五个方面依次阐述。

3.1、阶段一的现状

3.1.1、业务架构：单体应用，企业消息总线集成

我们还是从业务架构入手分析，大部分企业的信息系统并没有做到这一点——拉通信息系统，重塑组织协同，因为大部分系统都是外部采购，或者外包公司开发，由不同的团队进行维护，这些都是烟囱系统，信息零散，格式不一致，无法拉通，无法协同。

以制造业为例子，如图所示，企业外采了CRM，MES，ERP，HR，PLM，SCM等系统，但是各自独立，各有各数据库，各有各的权限管理。

这样的架构使得企业的各个部门无法协同，例如公司生产两种工业品A和B，其中A需要原材料A1和A2，B需要原材料B1和B2，突然有一天，销售人员发现市场情况有所变化，原来客户喜欢A和B是1:1的比例，现在突然B的需求量大了起来，变成了1:2的关系，这些信息，销售人员都将一个个客户的需求登记到CRM里面，可是工厂并不知道这件事情，于是还是按照1:1的来生产，这样A就会滞销，B就会脱销，这就需要销售部门的老大根据报告，看到这种情况，给生产部门老大说，改变生产的比例，但是这又牵扯到原料，如果A1和A2，B1和B2还按照原来的数量采购，那没有原料，A和B也生产不出来，所以生产部门的老大要同供应链的老大去说。另外还有不同车间的人员比例，明显生产B所需要的人才要多了，而且生产B的人要配备相应的绩效，这些HR都不知道，所以要有人告诉HR。另外市场发生变化之后，对于公司的收入和利润有什么影响，这也是两眼一抹黑。等这些都理清楚，那几个月都过去了，市场可能又发生变化了。

为了解决这个问题，在多年之前，很多企业就采购了企业服务总线ESB和数据交换工具，将不同的流程打通，做到信息拉通，数据集成，协同管理。       企业消息总线可以实现不同系统之间不同接口的调用，哪怕这些接口格式，协议都不一样，有的是SOAP，有的是Restful，有的是RPC，有的是私有协议，他可以做协议的转换。使得一个系统发生的事情，另一个系统可以通过接口调用得到结果。也有的功能没有暴露接口，那可以通过数据交换工具，将一个系统的数据库里面的数据定时的导出来，放到另一个系统里面去，也实现了数据的拉通。

虽然这个体系结构比较原来的架构有了改进，但是仍然有问题，就是无法支撑业务快速创新。

3.1.2、技术架构：物理机及虚拟化

             

             

在第一阶段，在传统架构下，基础设施层往往采取物理机或者虚拟化进行部署，为了不同的应用之间方便相互访问，多采取桥接扁平二层机房网络，也即所有的机器的IP地址都是可以相互访问的，不想互相访问的，多采用防火墙进行隔离。

无论是使用物理机，还是虚拟化，配置是相对复杂的，不是做过多年运维的人员，难以独立的创建一台机器，而且网络规划也需要非常小心，分配给不同业务部门的机器，网段不能冲突。例如使用Vmware，可能需要考一个特别有含金量的证书，才能很好的配置他。所有这一切，都需要运维部门统一进行管理，一般的IT人员或者开发人员既没有专业性，也不可能给他们权限进行操作，要申请机器怎么办，走个工单，审批一下，过一段时间，机器就能创建出来。

传统架构数据库层，由于系统由外包公司独立开发，或者不同开发部门独立开发，不同业务使用不同的数据库，有用Oracle的，有用SQL Server的，有用Mysql的，有用MongoDB的，各不相同。

传统架构的中间件层，每个团队独立选型中间件，可能会多种多样。

• 文件：NFS，FTP，Ceph，S3

• 缓存：Redis Cluster，主备，Sentinel, Memcached

• 分布式框架：Spring Cloud，Dubbo，Restful or RPC不同的部门自己选型

• 分库分表：Sharding-jdbc，Mycat

• 消息队列：RabbitMQ, Kafka

• 注册中心：Zk，Euraka，consul

3.1.3、数据架构：数据抽取与统计分析

这个阶段没有所谓的数据架构，由于业务是离散的，业务数据库里面的数据也是离散的，没有统一标准，虽然有了数据交换工具，会使得同一个数据很多份，各自分析。当然公司的领导和部门的领导都想看到当前企业的运行情况的，往往会有一个分析师的团队，从业务系统里面导出数据来，形成excel，然后利用自己对于流程和行业的理解进行分析，做出各种表格，图形，变成报告，交给公司领导或者部门领导看，领导肯定会根据报告进行讨论，然后根据运行情况调整战略和策略。

研发流程：测试与发布手工化及脚本化

在物理机上部署，由于机器数目比较小，可以使用手动测试和发布的方法。无非是丢上去一个安装包，然后重启一下Tomcat，发布就结束了。

后来上了虚拟化，机器的数目多了起来，服务数目也多了，再手动的一个个部署，工作量就比较大了，这个时候多采取脚本化的部署方法，写shell，或者写Ansible脚本等，进行自动化的发布与上线。

当然脚本比较难维护，专业性强，所以上线还是由写脚本的运维统一完成。

3.1.4、组织架构：研发与运维隔离

组织状态相对简单。

运维部和开放部是天然分开的，谁也不想管对方，两边的老大也是评级的，本相安无事。

统一的运维组，管理物理机，物理网络，Vmware虚拟化等资源，同时部署上线由运维部负责。

开发组每个业务都是独立的，负责写代码，不同的业务沟通不多，开发除了做自己的系统外，还需要维护外包公司开发的系统，由于不同的外包公司技术选型差异较大，因而处于烟囱式的架构状态。

机房当然只能运维人员能碰，这里面有安全的问题，专业性的问题，线上系统严肃的问题。如果交给没有那么专业的开发去部署环境，一旦系统由漏洞，谁能担责任，一旦线上系统挂了，又是谁的责任，这个问题问出来，能够让任何争论鸦雀无声。

3.2、阶段一的问题

阶段一有问题吗？这要从业务角度出发，其实也本没有什么问题。

中间件，服务层，前端，全部由外包商或者乙方搞定，端到端维护，要改什么招手即来，而且每个系统都是完整的一套，部署方便，运维方便。

数据库无论使用Oracle, DB2，还是SQL Server都没有问题，只要公司有足够的预算，而且性能也的确杠杠的，里面存储了大量存储过程，会使得应用开发简单很多，而且有专业的乙方帮忙运维，数据库如此关键，如果替换称为Mysql，一旦抗不出挂了，或者开源的没人维护，线上出了事情，谁来负责？

如果一起安好，其实没有任何问题，这个时候上容器或者上微服务，的确自找麻烦。

那什么时候，才会觉得阶段一有问题呢？还是从业务角度出发。当你的系统需要灵活的响应业务变化的时候，才会感觉到痛。

例如本来你经营着一家超市，原来主要通过线下进行销售，此次冠状病毒突然使得大家都不能逛超市了，这个时候就需要能够线上下单，线上销售，但是由于疫情事发突然，你外采的供应链管理，ERP等系统根本没办法修改，加入自己的业务逻辑，你让外包公司开发的系统，也不能随便修改，因为这需要重新招标，瀑布式的开发，交付，上线。你根本来不及。

再如你是一个汽车厂商，原来主要通过4S店进行销售，突然国家出台了一项激励新能源车的政策，使得你想借此机会促进一下销售，但是你发现外采的和外包的系统同样不能修改，等你改完了，风口早就过去了。

没有办法快速迭代上线，是阶段一的主要问题，我们还是分别从企业架构的五个方面依次阐述。

3.2.1、业务架构：架构耦合问题，架构腐化问题，技术债务问题

外采的程序和外包的程序，为了交付方便，往往开发成为单体应用。你可能会说，如果变成我自己开发和维护，是不是就能够解决这个问题了？而且我有企业服务总线，可以灵活的对于多个单体应用接口做集成。那是不是也能够解决，快速迭代上线的问题呢？

自然，自己开发和维护，灵活性确实要强的多。但是如果你依然采取单体的架构，你将来仍然会存在因为耦合问题导致无法快速响应业务变化情况。

因为任何混合在一起的架构，都会不断地腐化，即便你花时间和精力重构了一遍，还会再腐化，再重构，再腐化。这是架构的天然宿命，也是人性而导致的。他不能避免，但是可以不断地修正。所以架构设计并不能避免架构腐化的问题，但是能够解决及时发现及时修正的问题。

如果你不相信这一点，那我们就举一个例子，看是不是天天发生在你的身边。

             就像图中显示的一样，左边是你的领导认为一个单体应用的内部架构，里面的几个模块，界限清楚，调用分明。而右面可能是实际的内部架构，界限已经十分模糊，很多逻辑都糅合在了一起。        为什么会出现这种现象呢？第一个原因就是没时间搞。对单体应用内部的界限是不可观测的。我们都知道，领导都非常重视功能和bug，因为功能和bug都是可以观测的，而且是会影响用户的体验的。而架构往往不受重视，是因为单体运用内部的架构，领导是看不到的。他看不到，他就不会给你留时间，在开发功能的时候，不断的去调整架构。第二个原因，就是没动力搞。一旦代码的很多逻辑糅合在一起，那代码的可理解性就会非常的差。这个时候重构往往就更加的费时间。而领导又不肯留时间，那这时候开发人员就会想，反正领导也不重视，代码可理解性差呢，Code Review也Review不出啥来，那索性就头痛医头脚痛医脚好了。第三个原因。就是没胆量搞。哪怕这时候有一个有技术洁癖技术理想的人想搞这个事情，但是他会发现，代码复杂，耦合性强，越是核心的逻辑，越是不敢动，因为线上出了问题，谁改谁负责，所以，只好层层封装。

以上的三点。都是不可避免的人性。作为管理者和架构设计者不能要求我们的程序员是圣人，也不能不考虑人性去解决这些问题。

所以由于以上三点，我们就观察到了非常常见的两个现象。第一个就是迭代速度慢。因为架构的耦合，往往A上线，明明不关B的事情，需要B配合，B上线明明不关C的事情，需要C配合，最后问了一圈，只好10个功能一起弄完一起上线，那上线周期以月为周期。第二个就是可复用性差，如果你是一个领导，你会经常问这样的问题，明明你记得某个模块里面有某个功能，当另外一个模块需要的时候，拿不出来，需要另外开发。

最终就形成了技术债务，就像咱们借P2P，借了一万，一个月后发现要还两万。同理，当领导一年前问你某个功能开发需要多长时间，你半天就搞定了，一年后，你说要一个星期，领导很困惑，以为你开始学会偷懒了，变成老油条了，其实领导已经不知道单体应用里面已经一团浆糊了。

3.2.2、技术架构：资源申请慢，复用性差，高可用性差

从技术架构的角度来看，基于虚拟机技术，资源申请非常的慢。因为虚拟机大量地依赖于人工的调度，需要运维人员非常清楚，要部署在什么地方，往往需要通过excel进行维护。另外VMware还有一个问题，它使用共享存储，会限制整个集群的规模，因为此时的应用不多，这个程度的规模还可以接受。

另外网络、虚拟化、存储等基础设施，没有抽象化的概念，复杂度非常高，开发接不了这个工作，必须依赖运维，就要审批。由统一的一帮人来做，而且他们要考证书，比如，网络要有思科的证书，虚拟化要有VMware的证书，要特别专业才能做这件事情，因此会极大地降低迭代速度。业务方无论做什么事，都要走审批，运维部的人根本忙不过来，就会降低资源的申请速度。

所以我们经常观察到这样的现象，业务部门要部署应用，本来需要80台机器，却要申请100台，因为流程比较慢，万一不够，就要重新申请，一旦申请的，就不愿意归还运维部，因为说不定什么时候要用上，这样资源利用率大大降低。另外部署应用的时候，如果基于脚本部署，应该是环境越干净越一致，脚本部署的越顺畅，所以本来应该每次部署都是新创建的虚拟机，而且一旦一个系统被安装坏了，不必修复这个系统，重新创建一个虚拟机是最方便的。本来挺好的虚拟机的特性，被审批流程给破坏了，业务部门发现虚拟机坏了，想想重新申请太慢了，于是就忍忍，自己在虚拟机里面进行修复，十分浪费时间。

多种多样的中间件，每个团队独立选型中间件，没有统一的维护，没有统一的知识积累，无法统一保障SLA。一旦使用的消息队列，缓存，框架出了问题，整个团队没有人能够搞定这个事情，因为大家都忙于业务开发，没人有时间深入的去研究这些中间件的背后原理，常见的问题，如何调优等等。

3.2.3、数据架构：数据分散质量差，单一维度统计分析，人为报告反馈链长

这个时候的数据是非常分散的，不同的数据存在不同的业务系统中，如上面说的单体应用客户管理系统、生产系统、销售系统、采购系统、订单系统、仓储系统和财务系统等，或者同一个业务系统但由不同的机器在采集，这都导致了数据没有统一的标准，而是以割裂的形态存在，也就是数据孤岛。

但是业务的领导和部门的主管想了解业务的运行情况，就需要有人统计分析，这就是分析师，但是分析师因为生产流程太多了，数据太分散了，设备、系统、测量数据一堆，每个特性最少N个数据，一方面需要到处找人，一方面N多数据接口、N多数据格式，各自为战，数据对接不上。所以报告一般以周为单位给出，然后层层汇报，领导根据汇报，才能调整策略，然后再根据运行情况，再出报告，这个反馈链太长，要以月为单位了，不能适应市场的快速变化。

3.2.4、研发流程：上线依赖人，部署风险高，脚本难维护

上线依赖于人工和脚本，人是最不靠谱的，很容易犯错误，造成发布事故。而发布脚本、逻辑相对复杂，时间长了以后，逻辑是难以掌握的。而且，如果你想把一个脚本交给另外一个人，也很难交代清楚。

另外，并且脚本多样，不成体系，难以维护。线上系统会有Bug，其实发布脚本也会有Bug。

所以如果你上线的时候，发现运维人员对着一百项配置和Checklist，看半天，或者对着发布脚本多次审核，都不敢运行他，就说明出了问题。

3.2.5、组织架构：研发运维标准不一，难保障端到端高可用

线上的高可用性，业务层的开发人员不会做任何事情，他认为是线上一旦出事，应该由运维集中处理，迫使运维服务的发布人员依赖虚拟化机制，来提供高可用机制。我们都知道VMware有非常著名的简化运维的高可用机制，比如FT、HA、DR等类似的机制。如果我们是从IT层来做高可用，有一个缺点，作为基础设施层来讲，它看上层没有任何的区别，所以没有办法区分业务优先级。比如说FT的模式，跑CPU指令，它不知道这是最核心支付的指令、还是日志的指令，再如数据中心之间的同步，存储层是无法区分交易数据和日志数据的。这样就会造成一方面该同步的没有同步，不该同步的同步了很多，使得线上业务SLA降低了。另一方面浪费了存储和带宽的资源。而且一个服务到底是不是正常，需要应用层开放一个health接口来返回，如果应用层不做这件事情，基础设施只能通过看进程是否存在，端口是否监听等判断，很可能出现进程在，但是服务不可用的情况，也会降低SLA。

至此，我们看到了阶段一的问题，那应该如何解决这些问题呢？我们下一节详细解读。

未完待续

 

作者简介：刘超，网易杭州研究院云计算技术部首席架构师，出版《Lucene应用开发解密》，极客时间专栏《趣谈网络协议》《趣谈Linux操作系统》，毕业于上海交通大学，曾经就职于EMC，CCTV证券资讯频道，HP，华为等，目前在网易从事容器，Kubernetes和微服务的架构工作。长期致力于云计算开源技术的分享，布道和落地，将网易内部最佳实践服务客户与行业。个人公众号《刘超的通俗云计算》发表OpenStack, Kubernetes, 微服务类技术文章107篇，其中《终于有人把云计算，大数据，人工智能讲明白了》累积10万+。