如何建立以业务为核心的云原生体系？（中）
上一篇，我们讲了阶段一的很多问题，归根结底就一个字——散。系统散，数据散，流程散，组织散。在当前的市场竞争条件下，业务创新要争分夺秒。因而要将这些系统，数据，流程，组织重新组合，形成公司的“腰部力量”，强调能力的沉淀，强调融合与复用。只有有了“腰部力量”，才能灵活应对业务的快速变化。
这就是我们常说的中台。中台这个词很火，有的人觉得很好，有的人觉得太虚，但是名字无所谓，其实就是构建公司的可复用能力。
一、云原生体系演进阶段二：构建中台体系，加速业务创新
1、中台的定义
这里给中台下一个相对完整而准确的定义。
这个概念需要解读一下。中台是为了体现IT技术，IT系统，IT部门的业务价值而诞生的概念。在传统企业，过去往往重业务而轻技术，重硬件而轻软件。当低成本人口红利的野蛮生长阶段过去后，老板们发现差异化客户体验驱动产品创新的阶段已经到来，于是开始设立CIO这个职责。在传统企业能够体现业务价值非常重要，这是中台的核心，也即定义中的“面向业务场景”以及“支撑业务快速迭代”所强调的，CIO要让CEO，业务部门理解IT部门和IT系统的价值。
2、中台的五大误区
误区一：中台构建的太早。中台是企业已有系统积淀，解决了业务温饱问题，要进一步解决业务创新问题时候用的。如果是一家创业公司，解决温饱问题，确定业务模式最为重要，没必要花大量时间建设中台。
误区二：对中台期望太高。中台有时被当成万金油，似乎什么都能解决。例如中台能使业务创新，就属于期待过高。中台其实就是可复用能力，只能“支撑”业务创新，但替代不了业务能力。如果业务方能想出约50种创新的方法，但不知道哪个正确时，中台的可复用能力就帮上忙了。
误区三：觉得中台太简单。以为中台就是现有系统的接口组合，以为通过ESB将服务编排一下就解决了。将ERP，CRM等后台系统通过ESB暴露出去不是中台。
误区四：觉得中台太复杂。很多传统企业认为中台太复杂，不应该参与，其实中台的构建有封装式和重构式。传统企业往往害怕的是重构式，其实中台建设有渐进的过程，可以保留原来的系统，通过逐渐的封装，构建自己的中台。
误区五：觉得中台太技术。有些企业预算充足，认为只要买一个一线互联网公司的大平台就搞定了中台。但因为企业没有自己的架构师团队和中台团队，没有自己的流程和规范，没有自己沉淀可复用能力的方法论，还是无法应对业务的快速迭代。
3、中台建设的两种方式
一、封装式
传统企业由于采购大量传统服务，可采用封装式构建中台。
前台APP或者门户一旦需求改变，后台采购系统或核心稳态系统不可能随之改变，所以中间封装中台服务层。传统服务多使用SOAP协议暴露接口，可通过ESB或者API网关转换为RESTFul接口对上暴露。服务层采用最新微服务架构进行开发，适应前台快速迭代。
二、重构式
互联网公司历史包袱轻，大型银行，运营商等由于技术力量充足，可对于部分系统进行全方位的重构为微服务架构，并以此为底座构建中台。可全面实现自主可控，和快速大迭代。
二、中台如何解决第一阶段的问题
接下来，我们来看中台如何解决第一阶段的问题，还是从企业架构的五个方面逐个分析。
1、业务架构：架构服务化，侧重变化多和复用性，领域拆分与解耦
Q1 上一节，我们讲了影响快速迭代的问题是架构腐化问题，那如何解决呢？
通过服务化的方式，将不同的业务领域拆分到不同的工程里。
第一，增加可理解性。工程更加简洁，每个工程只做一个领域的事情，职责单一，这样既容易修改，也容易Review。
第二，增加可测试性。测试覆盖率是验证架构有没有腐化的指标，拆分后的服务测试更加容易展开，覆盖率变高，有利于及时制止和修复腐化。
第三，最重要的是可观测性。服务化之后，一般要有服务统一的注册发现和接口管理平台，通过这个平台，服务之间的调用关系以及接口的设计和文档，领导和架构委员会都能看到。
如此就实现了架构始终保持在轻债务的阶段，这样开发敢改，同事容易Review，QA容易测试，领导和架构委员会也看得到的效果。而且服务化拆分后，会将很多内部的功能，暴露成接口对外提供服务，并且接口经过Review和设计，而且文档和调用方式都在注册中心上，非常方便其他服务调用，实现可复用性。从而最终实现快速迭代。
Q2 你可能会问，你说了半天服务化，和前面的中台啥关系呢？
中台这个词其实是给业务方听的，具体到技术手段，就是服务化。
Q3 服务化应该从哪里开始呢？
很多技术人员都会犯的错误是，从数据库出发，看数据库结构如何设计的，按照数据库最容易拆分的方式进行拆分。这样是不对的，没有站在业务角度去考虑问题。应该借鉴领域驱动设计的思路，从业务流程的梳理和业务领域的划分出发，来划分不同的服务。虽然最后映射到数据库可能会拆分得比较难受，但是方向是对的，才能适应未来业务的快速变化，起到中台应该起到的作用。
Q4 领域划分后，如何拆分出服务，进行服务化呢？
比较落地的方法是随着新需求的不断到来，渐进拆分。变化多，复用性是两大考虑要素。
2、技术架构：基础设施云化，统一接口，抽象概念，租户自助
服务化的过程，工具链很重要，技术架构就是解决这个问题的。
经过业务层的服务化，也对运维组造成了压力。随着服务的拆分，不同的业务开发组会接到不同的需求，并行开发功能增多，发布频繁，造成测试环境，生产环境更加频繁的部署。而频繁的部署，就需要频繁创建和删除虚拟机。如果还是采用过去审批的模式，运维部就会成为瓶颈。这就需要进行运维模式的改变，也即基础设施层云化。
虚拟化到云化有什么不一样呢？
首先是接口统一。例如基于OpenStack实现，大部分部署工具支持其接口，可基于开源工具实现发布的工具化和平台化。
其次是概念的抽象。原来使用的物理网络，问题在于它是所有部门共享的，无法交给一个业务部门*配置和使用。因而要有VPC虚拟网络的概念，VPC屏蔽物理网络复杂性，冲突问题和安全问题，使得租户可自行配置网络。
其三是租户自助。即租户自助的管理，机器自动的调度，自动的配置。云提供租户概念，有账号子账号体系，有quota，可以让租户在管理员许可的范围内自助操作，加快环境部署速度。
3、数据架构：统一指标体系，建设数据仓库，支撑管理决策
服务化之后，各个系统的业务数据格式统一，制定了统一标准，并且上游系统设计时会考虑下游的使用，下游系统设计时，会考虑和上游兼容，统一的客户ID，订单ID等能够将整个业务流程串起来，有利于建设统一的指标体系。有了这个基础，就可以建设统一的数据仓库。数据仓库的构建不能像第一阶段那样在数据库里面，或者业务系统里面直接进行分析，需要通过数据接入，将数据抽取出来，经过一定的处理，放到数据仓库里。
前面讨论服务化时，梳理了业务领域的划分以及业务流程，这在数仓建设中是很有用的。如下图所示，里面有商品域，采购域，物流域，交易域，这些都是和服务相对应的。建设数仓时，里面的指标设计也是按照业务流程来的，这也是和服务相对应的。
当基于业务领域划分和业务流程梳理，总结出来的数据仓库及指标，是能够反映业务的运行过程的，在此之上，建设BI报表，和领导驾驶舱，可以将原来以周为单位的经营情况反馈过程，缩短到天甚至小时。
这里面有一个制造业的例子，就是经过数仓的建设和指标的梳理，已经可以很好的做业务运营监控了。
4、研发流程：发布模式平台化，构建持续集成流程，质量和绩效看板
云平台的建设提供了统一的接口，使得发布模式可以更容易地对接资源，实现平台化，并基于平台构建持续集成流程。
因为如果云计算不管应用，一旦出现扩容，或者自动部署的需求，云平台创建出来的虚拟机还是空的，需要运维手动上去部署，根本忙不过来。因而云平台，也一定要管理应用。基于云计算OpenStack的虚拟机分层镜像发布和回滚机制，构建发布平台，可实现大规模批量部署和弹性伸缩。
基于虚拟机的PaaS托管中间件，简化租户创建，运维，调优中间件的难度。云平台的PaaS负责创建的中间件的稳定，保证SLA，当出现问题的时候，会自动修复，从而业务方不用管PaaS中间件的部署和SLA了。发布平台提供基于虚拟机镜像+PaaS中间件，做完整的应用部署和上线，称为编排。基于编排，就可以进行很好的持续集成，例如每天晚上，自动部署一套环境，进行回归测试，从而保证修改的正确性。
要求业务对于高可用性设计要在应用层完成，而不能完全依赖于基础设施层的能力了。每一个服务都有实现良好的无状态化处理，幂等服务接口设计。每个服务都要设计有效探活接口，以便健康检查感知到服务状态。通过制定良好的代码检查规范和静态扫描工具，最大化限制因为代码问题造成的系统不可用。
5、组织架构：成立中台组/架构师组，衔接研发和运维
中台是为了能够集团军作战，协调各种力量为业务快速迭代服务，要建设腰部力量，除了上面所说的各种系统，人当然是最重要的。所以运维组和开发组不能隔离，要成立架构师组或者架构委员会，来横向协调各种资源，并且挂在CIO下面，有一定的话语权。
建立独立的前端组，统一前端框架，界面一致，所有人掌握统一的前端开发能力，积累前端代码，在有新的需求的时候，能够快速的进行开发。建立中间件组，这部分人不用贴近业务开发，每天的任务就是研究如何使用这些中间件，如何调优，遇到问题如何Debug，形成知识积累。如果有统一的一帮人专注中间件，就可以根据自身的情况，选择有限几个中间件集中研究，限定业务组只使用这些中间件，可保证选型的一致性，如果中间件被这个组统一维护，也可以提供可靠的SLA给业务方。将业务开发组分出一部分来，建立中台组，将可以复用的能力和代码，交由这几个组开发出服务来，给业务组使用，这样数据模型会统一，业务开发的时候，首先先看看有哪些现成的服务可以使用，不用全部从零开发，也会提高开发效率。
三、阶段二的问题
能够做到架构服务化，基础设施云化的公司已经是传统行业在信息化领域的佼佼者了。那什么情况下才会觉得阶段二有问题呢？当传统行业不再满足于在本行业的领先地位，希望对接互联网业务时，上面的模式才会出现新的痛点。对接互联网所面临的最大的问题，就是巨大的用户量所带来的请求量和数据量，会是原来的N倍，能不能撑得住，大家都心里没底。
例如有的企业推出互联网理财秒杀抢购，原来的架构无法承载近百倍的瞬间流量。
有的企业对接了互联网支付，甚至对接了国内最大的外卖平台，而原来的ESB总线，就算扩容到最大规模(13个节点)，也可能撑不住。
有的企业发现，一旦到了互联网大促级别，Oracle数据库是肯定扛不住的，需要从Oracle迁移到DDB分布式数据库，可是怎么个迁移法，如何平滑过渡，心里没底。
当出现这些问题的时候，才应该考虑进入第三个阶段，微服务化。下一节，我们来看阶段三如何解决这些问题。
（本文整理自：分布式实验室）
●往期推荐 ●
Nebulogy 品牌介绍
Nebulogy致力于通过云原生理念，帮助企业构建PaaS平台，提高开发资源利用率，满足应用快速上线和迭代需求，助力企业实现真正应用云化、业务互联网化。
电话：400-105-0300