如何建立以业务为核心的云原生体系？（上）

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

一、企业架构的五个方面

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

01 业务架构

里面承载了企业所从事业务的核心逻辑。

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

02 技术架构

为了支撑业务代码的运行而建设的IT基础实施。

最初企业大多采购物理机的方式运行业务代码，由于资源使用效率和灵活度的问题，很多企业采用了虚拟化平台。从虚拟化平台到云平台的变化主要是三点：统一接口，抽象概念，租户自助。容器进一步让应用从代码到运行无缝连接起来，并且可以实现跨云的迁移。Service Mesh将微服务的治理放到统一的平台上来做，进一步解放业务方。

03 数据架构

在业务运行的过程中，会积累很多的数据。

过去业务运行的数据散落在各个系统中，如果想分析当前业务的运行情况，需要分析师导出数据做成报告，时效性很差。之后很多企业开始建设数据仓库，BI大屏，领导驾驶舱，支撑战略决策。这种方式无法和业务直接结合，于是产生了数据运营驱动业务创新，我们在电商和社交APP上感受到的智能推荐就是例子。

04 研发流程

即代码是如何发布上线。

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

05 组织架构

根据康威定律，组织架构和技术架构往往是相互影响的。

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

二、云原生体系建设总图

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

这里画了一张云原生体系建设总图。

看完了这张图，你可能觉得，哇，云原生如此的复杂，直接放弃吧。其实不是的，这个状态不是一蹴而就的，而且企业不可能通过采购一个大平台，一下子就形成了云原生架构，这都需要迭代的进行，这正是要解决的问题。

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

• 遇到什么样的问题？
• 应该采取什么样的技术解决这个问题？如何解决这个问题的？
• 这个技术的实现有很多种，应该如何选型？
• 使用这个技术有没有最佳实践，能不能形成企业的相关规范？

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

我们分别从企业架构的五个方面，依次阐述该阶段企业所面临的现状和问题。

1、业务架构

现状：单体应用，企业消息总线集成

大部分企业的信息系统是外部采购或外包公司开发，所以由不同的团队进行维护，这些烟囱系统信息零散，格式不一致，无法拉通，无法协同。

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

这种架构使得企业的各个部门无法协同，为了解决这个问题，很多企业多年前采购了企业服务总线ESB和数据交换工具，将不同的流程打通，做到信息拉通，数据集成，协同管理。

虽然这个体系结构较原来的架构有了改进，但当企业系统需要灵活地响应业务变化时，却发现无法支撑业务快速创新，快速迭代上线。

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

任何混合在一起的架构，都会不断地腐化，即便花时间和精力重构了一遍，还会再腐化，再重构，再腐化。所以架构设计并不能避免架构腐化的问题，但是能够解决及时发现及时修正的问题。

我们举一个例子，看是不是天天发生在你的身边。

就像图中显示的一样，左边是你的领导认为一个单体应用的内部架构，里面的几个模块，界限清楚，调用分明。而右面可能是实际的内部架构，界限已经十分模糊，很多逻辑都糅合在了一起。

为什么会出现这种现象呢？

原因1：没时间。领导都重视功能和bug，因为它们是可观测的，且会影响用户体验。而架构因其不可观测往往不被重视，所以领导不会留足够时间，让员工在开发功能的时候不断调整架构。
原因2：没动力。一旦代码的很多逻辑糅合在一起，那代码的可理解性就会非常差，这时重构往往就更加费时间。
原因3：没胆量。代码复杂，耦合性强，越是核心的逻辑，越是不敢动，因为线上出了问题，谁改谁负责，所以，只好层层封装。

基于以上三点，可以观察到两个非常常见的现象。

第一个是迭代速度慢。因为架构的耦合，往往A上线，明明不关B的事情，需要B配合，B上线明明不关C的事情，需要C配合，最后问了一圈，只好10个功能一起弄完一起上线，所以上线以月为周期。

第二个是可复用性差。如果你是一个领导，你会经常问这样的问题，明明你记得某个模块里面有某个功能，当另外一个模块需要的时候，拿不出来，需要另外开发。

最终就形成了技术债务。当领导一年前问你某个功能开发需要多长时间，你半天就搞定了，一年后，你说要一个星期，其实领导已经不知道单体应用里面已经一团浆糊了。

2、技术架构

现状：物理机及虚拟化

传统架构下，基础设施层往往采用物理机或者虚拟化进行部署。无论是使用物理机还是虚拟化，配置相对复杂，不是做过多年运维的人员，难以独立创建一台机器，而且网络规划也需要非常小心，分配给不同业务部门的机器，网段不能冲突。

传统架构数据库层，由于系统由外包公司独立开发，或者不同开发部门独立开发，不同业务使用不同的数据库，有用Oracle，SQL Server，Mysql，MongoDB等。传统架构的中间件层，每个团队独立选型也会多种多样。

问题：资源申请慢，复用性差，高可用性差

虚拟机技术资源申请非常慢，因为虚拟机大量地依赖于人工的调度。另外网络、虚拟化、存储等基础设施，没有抽象化概念，复杂度非常高，必须依赖运维人员。所以业务方无论做什么事都要走审批，运维部忙不过来，就会降低资源的申请速度。

每个团队独立选型中间件，没有统一的维护和知识积累，无法统一保障SLA。由于大家都忙于业务开发，一旦使用的消息队列，缓存，框架出了问题，整个团队没有人能够及时解决。

三、数据架构

现状：数据抽取与统计分析

该阶段没有所谓的数据架构，由于业务和数据库里的数据没有统一标准。当公司和部门领导想看当前企业的运行情况时，往往会有一个分析师团队，从业务系统导出数据形成excel，然后分析做出各种表格，图形，变成报告，领导再根据报告调整战略和策略。

问题：数据分散，人为报告反馈链长

不同的数据存在不同的业务系统中，或者同一个业务系统但由不同的机器在采集，这都导致了数据以割裂的形态存在，也就是数据孤岛。各自为战的数据孤岛，导致分析师的报告一般以周为单位给出，然后层层汇报，领导根据汇报调整策略，然后分析师再根据运行情况出报告，无法适应市场的快速变化。

四、研发流程

现状：测试与发布手工化及脚本化

企业最初在物理机上部署，机器数目较小，可以手动测试和发布。后来上了虚拟化，机器和服务数目增多，此时多采取脚本化的部署方法，进行自动化的发布与上线。当然脚本比较难维护，专业性强，所以上线还是由写脚本的运维统一完成。

问题：上线依赖人，部署风险高，脚本难维护

上线依赖于人工和脚本，很容易犯错造成发布事故。发布脚本逻辑相对复杂，如果想把一个脚本交给另外一个人，很难交代清楚。另外，脚本多样不成体系，发布也会有Bug。所以如果上线时，发现运维人员对着一百项配置和Checklist看半天，或者对着发布脚本多次审核，都不敢运行，就说明出了问题。

五、组织架构

现状：研发与运维隔离

运维部和开发部是天然分开的，两边的老大也是平级，本相安无事。统一的运维组，管理物理机，物理网络，VMware虚拟化等资源，同时部署上线由运维部负责。开发组每个业务都是独立的，负责写代码。开发除了做自己的系统外，还需要维护外包公司开发的系统。

问题：研发运维标准不统一，难保障端到端高可用

线上的高可用性，业务层的开发人员不会做任何事情，他认为线上一旦出事，应该由运维集中处理，迫使运维服务的发布人员依赖虚拟化机制，来提供高可用机制。

我们都知道VMware有非常著名的简化运维的高可用机制，比如FT、HA、DR等类似的机制。如果我们从IT层来做高可用有一个缺点，作为基础设施层来讲，它看上层没有任何的区别，所以没有办法区分业务优先级。另一方面浪费了存储和带宽的资源。而且一个服务到底是不是正常，需要应用层开放一个health接口来返回，如果应用层不做这件事情，基础设施只能通过看进程是否存在，端口是否监听等判断，很可能出现进程在，但是服务不可用的情况，也会降低SLA。

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

本文转载自【刘超的通俗云计算】公众号，作者刘超

Nebulogy 品牌介绍

Nebulogy致力于通过云原生理念，帮助企业构建PaaS平台，提高开发资源利用率，满足应用快速上线和迭代需求，助力企业实现真正应用云化、业务互联网化。