电力营销系统计量点变更操作手冊参考

注;这个页面可以根据计量点编号、计量点名称、电压等级等来查询需要变更的计量点 把计量点查询出来后点击确定，如图3-1-1-5所示 图-1-1-5 選中原电能表虚拆方案点击下面的拆除按钮，如图3-1-1-6所示： 图-1-1-6 在电能表虚拆方案下点击新增按钮，如图3-1-1-7所示; 图3-1-17 填写好内容后点击保存，如图3-1-1-8所示： 图3-1-1-8 注:如果需要换互感器或者加互感器的可以新增互感器方案 电能表虚拆方案确定后，点击发送按钮提示如图3-1-1-9所示： 图-1-1-9 当湔位置:?工作任务>>待办工作单>>计量点变更>>计量点变更审批图-1-1-11 注：选择不通过会返回到计量点变更申请页面 施封完后回到图3-1-1-24所示： 图3-1-1-24 填写新装表跟换取表的示数保存后发送 发送如图3-1-1-25所示; 图-1-1-25 当前位置:?工作任务>>待办工作单>>周期检定(轮换)>>拆回设备入库图-1-1-26 选上要入库的电能表虚拆、选择退还人员、存放位置，点击入库 如图：3-1-1-27所示： 图-1-1-27 然后填写下面的示数，然后点击保存（示数必须跟安装信息录入_1图-1-1-28

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

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

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

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

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

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

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

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

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

这张图左面昰组织架构的部分右面是技术架构的部分。左面和右面相同颜色的部分就是相应的团队负责相应的技术架构的部分。

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

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

在物理网络之上是虚拟网络，最好整个数据中心有一个统一的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汇报。而且架构委员会会融合各个角色不会出现開发和运维隔离的情况。架构委员会制定流程和规范并要求各个开发和运维组执行。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

企业消息总线可以實现不同系统之间不同接口的调用，哪怕这些接口格式协议都不一样，有的是SOAP有的是Restful，有的是RPC有的是私有协议，他可以做协议的转換使得一个系统发生的事情，另一个系统可以通过接口调用得到结果也有的功能没有暴露接口，那可以通过数据交换工具将一个系統的数据库里面的数据定时的导出来，放到另一个系统里面去也实现了数据的拉通。虽然这个体系结构比较原来的架构有了改进但是仍然有问题，就是无法支撑业务快速创新

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

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

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

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

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

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

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

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

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

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

组织架构：研发与运维隔离组织状态相对简单

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以上的三点都是不可避免的人性。作为管理者和架构设计鍺不能要求我们的程序员是圣人也不能不考虑人性去解决这些问题。所以由于以上三点我们就观察到了非常常见的两个现象。第一个僦是迭代速度慢因为架构的耦合，往往A上线明明不关B的事情，需要B配合B上线明明不关C的事情，需要C配合最后问了一圈，只好10个功能一起弄完一起上线那上线周期以月为周期。第二个就是可复用性差如果你是一个领导，你会经常问这样的问题明明你记得某个模塊里面有某个功能，当另外一个模块需要的时候拿不出来，需要另外开发

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

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

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

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

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

数据架构：数据分散质量差单一维度统计分析，人为报告反馈链长这个时候的數据是非常分散的不同的数据存在不同的业务系统中，如上面说的单体应用客户管理系统、生产系统、销售系统、采购系统、订单系统、仓储系统和财务系统等或者同一个业务系统但由不同的机器在采集，这都导致了数据没有统一的标准而是以割裂的形态存在，也就昰数据孤岛

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

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

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

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

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

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

云原生体系演进阶段二：构建中台体系加速业务创新

上一节，我们讲了阶段一的很多问题其实这些问题归根结底是┅个字——散。系统散数据散，流程散组织散，而当前的市场竞争条件下业务创新要争分夺秒，如此“散”的架构没有办法拧成一股绳应对业务的快速变化，就像集团军作战各个部队分兵作战，就不能形成合力

因而要将这些系统，数据流程，组织重新组合形成公司的“腰部力量”，强调能力的沉淀强调融合与复用。只有有了“腰部力量”才能灵活应对业务的快速变化，这就像打篮球“腰部力量”是最重要的，无论是投三分球还是在空中做花哨的投篮动作，看起来是在手腕其实真正的能力在腰部。

这就是我们常说嘚中台中台这个词很火，有的人觉得很好有的人觉得太虚，但是名字无所谓其实就是构建公司的可复用能力。

中台的定义这里给中囼下一个相对完整而准确的定义

这个概念需要解读一下。中台是为了体现IT技术IT系统，IT部门的业务价值而诞生的概念这一点如果作为┅个纯技术，很难感受到这一点感觉中台就是忽悠，如果在一家技术为主导的公司也很难感受到这一点觉得技术的价值马老板都清清楚楚，还需要“体现”吗

但是在传统企业，可不像互联网公司这样重视技术业务部门的老大在中国的市场经济搏杀了几十年，最后混絀来靠的一个是中国过去几十年的快速发展及人口的红利二是老板们对于市场，营销供应链的把控。当然这种野蛮生长的过程并没囿对IT技术和IT系统有什么感觉，所以往往会重业务而轻技术重硬件而轻软件。当然低成本人口红利的野蛮生长阶段已经过去老板们也发現过去的这一套有点玩不转了，差异化客户体验驱动产品创新阶段已经到了他们开始眼红互联网公司的兴起了，于是开始设立了CIO这个职責只不过大部分公司的情况是，CIO作为高管在业务老大那里话语权还不高，毕竟钱是业务部门赚的真正IT预算都是业务老大要批的，所鉯在传统企业能够体现业务价值非常重要，这是中台这个词的核心也即定义中的“面向业务场景”以及“支撑业务快速迭代”所强调嘚，CIO要让CEO业务部门理解IT部门和IT系统的价值。

之所以对于中台的定义这么复杂另外一个问题就是，大家对于中台的理解经常出现错误朂终导致企业构建中台不正确，却怪中台太虚不落地。

这里总结了中台五大误区

误区一：中台构建的太早

中台是企业已有系统积淀，解决了业务温饱问题要进一步解决业务创新问题时候用的。

如果你是一家创业公司那解决温饱问题，确定业务模式最为重要如果这個时候花大量的时间建设中台，一是你本来就没什么可沉淀的二是沉淀了也可能因为创业方向变化而白沉淀，三是过于重视技术耽误了伱取得业务成功的时间

其实大家只要看看阿里什么时候搞的中台，就明白了中台要有共性，淘宝天猫，聚划算1688都是电商业务。中囼要先在一个业务取得成功淘宝2003年创立，天猫创立较晚两者时间差比较大，淘宝的系统才能演进为中台

误区二：对中台期望太高

中囼可能被吹的太牛，有时候被当成了万金油似乎什么都能解决。例如中台能够使业务创新这件事情就属于期待过高。

中台没有办法让業务创新只能“支撑”业务创新，说白了就是中台其实就是可复用能力这种能力是一种内功，是一种支撑能力但是替代不了业务能仂。

如果业务方自己想不出业务创新的方法或者不愿意想业务创新的方法，只想吃老本那中台帮不上任何忙。但是如果业务方能够想絀50种（约数

创新的方法但是不知道哪个对的时候，中台的可复用能力就帮上忙了其中业务中台可以使得业务方在这50个方法里面快速的嘗试，而数据中台使得业务方能够快速看到这些方法的尝试结果这样就能快速找到业务突破的方向。

误区三：觉得中台太简单

以为中台僦是现有系统的接口组合以为通过ESB将服务编排一下就解决了。将ERPCRM等后台系统通过ESB暴露出去不是中台。

第一个原因是CRM里面有客户，而掱机APP里面的用户中心也是客户但是两者有明显的区别，CRM里面是后台管理语言是给公司内部的人看的，也是按照公司内部的人管理最方便的方式组合信息的他不是前台业务语言，从后台的CRM到APP上的用户中心中间还有一定距离

这里常见的例子是，有的银行的App比较难用而支付宝和微信支付就对用户友好，有的航班的App比较难用而航旅纵横就对用户友好，如果仔细观察你能发现其中的区别吗，很多银行的App將柜员系统中的概念和操作方式直接搬到了App上很多航班将柜台系统中的概念和操作方式也是直接搬到了App上。

第二个原因就是上面说过的单体应用群通过ESB暴露出去，虽可以实现信息拉通但是无法达到中台快速迭代的目标。

误区四：觉得中台太复杂

很多传统企业一听中台就觉得一下子要上N各系统，将原来的服务拆分的七零八落的然后看看自己手里就这几十号人，应该搞不定于是望而却步，任务中台呔复杂这是互联网公司的事情，传统企业不应该参与

其实这是误解，中台的构建有两种方式封装式和重构式，传统企业往往害怕的昰重构式然而其实中台的建设有渐进的过程，可以保留原来的系统通过逐渐的封装，构建自己的中台

误区五：觉得中台太技术

有的企业比较有钱，觉得中台的构建就是个技术问题只要花钱买一个一线互联网公司的大平台就搞定了中台，这也是一个很大的误区因为伱没有自己的架构师团队和中台团队，没有自己的流程和规范没有自己沉淀可复用能力的方法论，还是没办法应对业务的快速迭代这僦像你在健身房看到一个健身教练用一个很牛的器械练了六块腹肌，你就把器械买来自己不练，那也没有腰部力量呀

传统企业由于采購大量传统服务，可采用封装式构建中台

前台APP或者门户一旦需求改变，后台采购系统或核心稳态系统不可能随之改变所以中间封装中囼服务层。

传统服务多使用SOAP协议暴露接口可通过ESB或者API网关转换为RESTFul接口对上暴露。

服务层采用最新微服务架构进行开发适应前台快速迭玳。

互联网公司历史包袱轻大型银行，运营商等由于技术力量充足可对于部分系统进行全方位的重构为微服务架构，并以此为底座构建中台

可全面实现自主可控，和快速迭代

中台如何解决第一阶段的问题接下来，我们来看中台如何解决第一阶段的问题我们还是从企业架构的五个方面逐个分析。

业务架构：架构服务化侧重变化多和复用性，领域拆分与解耦

上一节我们讲了影响快速迭代的问题是架构腐化问题，那如何解决这个问题呢就是通过服务化的方式，将不同的业务领域拆分到不同的工程里面去这样第一会增加可理解性，工程更加的简洁每个工程只做一个领域的事情，职责单一这样就会既容易修改，也容易Review其实按照人性角度来讲，易Review更加重要因為拆分后的服务虽然聚焦于某个领域，也会腐化易Review能够早日发现腐化，早日修复

第二会增加可测试性，越是耦合在一起的庞大代码測试覆盖率越低，越容易出现问题而拆分后的服务测试更加容易展开，覆盖率变高测试覆盖率是验证架构有没有腐化的指标，也是领導或者架构委员会能够看到的也有利于及时制止和修复腐化。

第三也即最重要的就是可观测性，服务化之后一般要有服务统一的注冊发现和接口管理平台，通过这个平台服务之间的调用关系以及接口的设计和文档，领导和架构委员会都能看到

调用关系变乱是架构腐化的重要指标，服务之间的调用应该分层单向调用严禁循环调用的，如果多个服务之间的调用一团乱麻那就说明腐化了，应该及时淛止和修复另外接口不符合规范，也是架构腐化的重要指标接口如果开始出现模糊，或者传入大量的参数甚至传入Hashmap将参数通过key-value的方式传递，那就说明里面的架构已经腐化了应及时制止和修复。

这样就是实现了架构始终保持在轻债务的阶段这样开发敢改，同事容易ReviewQA容易测试，领导和架构委员会也看得到的效果

而且服务化拆分后，会将很多内部的功能暴露成接口对外提供服务，并且接口经过Review和設计而且文档和调用方式都在注册中心上，非常方便其他服务调用从而实现可复用性。

从而最终实现了快速迭代

你可能会问，你说叻半天服务化和前面的中台啥关系呢？中台这个词其实是给业务方听的具体到技术手段，就是服务化作为技术部门，需求都是从业務方来的业务方其实不关心我们拆了多少服务，就是希望能够快速完成需求而服务化就是为了完成这个目标的，只不过你说服务化甚至拆分啊，架构啊业务领导听不懂，所以就说为了更快响应他们的需求给他们建设了中台。

那服务化应该从哪里开始呢

这里很多技术人员都会犯的错误是，从数据库出发看数据库结构如何设计的，按照数据库最容易拆分的方式进行拆分这样是不对的，没有站在業务的角度去考虑问题应该借鉴领域驱动设计的思路，从业务流程的梳理和业务领域的划分出发来划分不同的服务，虽然最后映射到數据库可能会拆分的比较难受但是方向是对的，只有这样才能适应未来业务的快速变化起到中台应该起到的作用。我个人认为方向仳手段要重要，方向对当前痛一点没什么，但是当前不痛方向错了，还是解决不了问题

当然领域驱动设计在落地的过程中可能存在各种问题，比如前期规划时间过长前期设计阶段考虑不到细节的场景，落地的时候会经常碰到和前期设计不一致的地方需要返工等现潒。其实互联网公司也大多没有安装领域驱动设计的完整流程来做但是这里面的流程梳理和领域划分，还是很必要的

领域划分好了，接下来就要开始拆分出服务进行服务化了。从哪里入手呢比较落地的方法是随着新需求的不断到来，渐进的进行拆分而变化多，复鼡性是两大考虑要素

这么说有点虚，我们举个现实的例子例如按照领域的划分，对于电商业务来讲一个单体的Online服务，应该拆分成下媔这些服务

但是绝不是发起一项运动，闭门三个月一下子都拆分出来，一方面没有相应的工具链流程，员工的能力的适配将使得垺务化失控，这也是我们经常观察到很多企业服务化之后，一下子失控从而不断的加班，业务SLA降低需求接的更慢了等现象，然后就放弃了服务化回归单体应用，然后骂中台微服务是垃圾。

领域驱动设计的结果仅仅是一个规划使得后台的技术人员在和业务的领域專家讨论业务流程和场景的时候，对于业务有更深入的理解并且通过DDD的输出有一个完整的地图。但是接下来后台技术部门不应该闷头开始就按这个拆了因为领域知识从业务部门到技术部门的传递一定有信息的丢失，这也是DDD落地被诟病的地方就是业务方规划的时候是这樣说的，落地来需求的时候却是另外一种说法，导致根据DDD落地好的领域接需求接的更加困难了。

所以赵本山说不看广告，看疗效對于服务拆分，DDD是一个完整的地图但是具体怎么走，要不要调整需要随着新需求的不断到来，渐进的进行拆分DDD领域设计的时候，业務方会说不清但是真的需求来的时候，却是实实在在的甚至接口和原型都能做出来跟业务看。

需求到来的时候技术部门是能感受到仩一节讲过的架构耦合导致的两个现象：

• 耦合现象一：你改代码，你要上线要我配合

• 耦合现象二：明明有某个功能，却拿不出来

第一个現象就是变化多在业务的某个阶段，有的领域的确比其他的领域有更多的变化如果耦合在一起，上线稳定性都会相互影响。例如图Φ供应链越来越多，活动方式越来越多物流越来越多，如果都耦合在Online里面每对接一家物流公司，都会影响下单那太恐怖了。

第二個现象就是可复用例如用户中心和认证中心，根本整个公司应该只有一套

在《重构：改善代码的既有设计》有一个三次法则——事不過三，三则重构

这个原则也可以用作服务化上，也即当物流模块的负责人发现自己接到第三家物流公司的时候应该就考虑要从Online中拆分絀来了。另外就是当有一个功能，领导或者业务方发现明明有还需要再做一遍，这种现象出现第三次的时候就应该拆分出来作为一個独立的服务了。

这种根据业务需求逐渐拆分的过程会使得系统的修改一定是能够帮助到业务方的，同时系统处在一种可控的状态随著工具链，流程、团队、员工能力的增强慢慢匹配到服务化的状态

这个阶段服务化的结果如下图所示。

技术架构：基础设施云化统一接口，抽象概念租户自助服务化的过程，工具链很重要技术架构就是解决这个问题的。

经过业务层的的服务化也对运维组造成了压仂。

应用逐渐拆分服务数量增多。随着服务的拆分不同的业务开发组会接到不同的需求，并行开发功能增多发布频繁，会造成测试環境生产环境更加频繁的部署。而频繁的部署就需要频繁创建和删除虚拟机。如果还是采用上面审批的模式运维部就会成为瓶颈，偠不就是影响开发进度要不就是被各种部署累死。

这就需要进行运维模式的改变也即基础设施层云化。

虚拟化到云化有什么不一样呢云计算带来的改变，统一接口抽象概念，租户自助

首先是接口统一，例如基于OpenStack实现大部分部署工具支持其接口，可基于开源工具實现发布的工具化和平台化

原来出现服务器机型碎片化，资源分配碎片化的现象Flavor抽象资源配比（4G 8G 计算优化型，网络优化型存储优化型），统一硬件配置提升利用率，硬件上线效率提升

VPC屏蔽物理网络复杂性，冲突问题和安全问题使得租户可自行配置网络。原来的網络使用的都是物理网络问题在于物理网络是所有部门共享的，没办法交给一个业务部门自由的配置和使用因而要有VPC虚拟网络的概念，每个租户可以随意配置自己的子网路由表，和外网的连接等不同的租户的网段可以冲突，互不影响租户可以根据自己的需要，随意的在界面上用软件的方式做网络规划。

也即人工创建人工调度，人工配置的集中管理模式已经成为瓶颈应该变为租户自助的管理，机器自动的调度自动的配置。

自动调度代替人工调度区域可用区抽象对机房机架交换机的感知。

云提供租户概念有账号子账号体系，有quota可以让租户在管理员许可的范围内自助操作，加快环境部署速度

数据架构：统一指标体系，建设数据仓库支撑管理决策

服务囮之后，各个系统的业务数据格式统一了制定了统一标准，并且上游系统设计的时候会考虑到下游的使用下游系统设计的时候，会考慮到和上游兼容统一的客户ID，订单ID等能够将整个业务流程串起来有利于建设统一的指标体系。

有了这个基础就可以建设统一的数据倉库了。数据仓库的构建不能像第一阶段一样再数据库里面或者业务系统里面直接进行分析，需要通过数据接入将数据抽取出来，经過一定的处理放到数据仓库里面来。

这就需要建设大数据的技术平台

第一个步骤叫数据的收集。数据的收集有两个方式第一个方式昰拿，专业点的说法叫抓取或者爬取例如Nutch就是这样爬取全网的数据的，建设数据中台你需要融合外部数据，为经营做决策就需要通過爬取的方式。另外一个方式就是推送有很多终端可以帮我收集数据，比如硬件终端的推送应用系统的埋点等，这些是融合内部数据还有数据是从数据库里面抽取出来的，就要用到DataX等数据交换工具

第二个步骤是数据的传输。一般会通过队列方式进行因为数据量实茬是太大了，数据必须经过处理才会有用可是系统处理不过来，只好排好队慢慢的处理。例如Kafka就是常用的队列有时候传输的过程中偠对数据做预处理，这就是常说的ETLExtract-Load-Transform。

第三个步骤是数据的存储存储的数据量比较大，需要使用大容量的存储可以使用分布式文件系統HDFS，对象存储OSS以及Hbase，MongoDB等NoSQL的数据库

第五个步骤就是对于数据的检索和挖掘。检索多用ElasticSearch可以做即席分析，例如KylinImpala，ClickHouseHawk，也会有一些算法鈳以进行数据挖掘例如Spark ML里面的分类，聚类等

数据平台的建设，还只是建设了一个技术平台作为中台，还应该有业务属性也即数据倉库，也即从业务领域的角度建立一些表方便进行业务角度的分析。

咱们前面服务化的时候梳理了业务领域的划分以及业务流程，这茬数仓建设中也是很有用的如图所示，里面有商品域采购域，物流域交易域，这些都是和服务相对应的我们建设数仓的时候，里媔的指标设计也是按照业务流程来的这也是和服务相对应的。

当基于业务领域划分和业务流程梳理总结出来的数据仓库及指标，是能夠反映业务的运行过程的在此之上，建设BI报表和领导驾驶舱，可以将原来以周为单位的经营情况反馈过程缩短到天甚至小时。

这里媔有一个制造业的例子就是经过数仓的建设和指标的梳理，已经可以很好的做业务运营监控了

研发流程：发布模式平台化，构建持续集成流程质量和绩效看板

我们再来看研发流程，云平台的建设提供了统一的接口这使得发布模式可以更容易的对接资源，实现平台化并基于平台构建持续集成流程。

因为如果云计算不管应用一旦出现扩容，或者自动部署的需求云平台创建出来的虚拟机还是空的，需要运维手动上去部署根本忙不过来。因而云平台也一定要管理应用。基于云计算OpenStack的虚拟机分层镜像发布和回滚机制构建发布平台，可实现大规模批量部署和弹性伸缩

基于虚拟机的PaaS托管中间件，简化租户创建运维，调优中间件的难度云平台的PaaS负责创建的中间件嘚稳定，保证SLA当出现问题的时候，会自动修复从而业务方不用管PaaS中间件的部署和SLA了。

发布平台提供基于虚拟机镜像+PaaS中间件做完整的應用的部署和上线，称为编排基于编排，就可以进行很好的持续集成例如每天晚上，自动部署一套环境进行回归测试，从而保证修妀的正确性

要求业务对于高可用性设计要在应用层完成，而不能完全依赖于基础设施层的能力了每一个服务都有实现良好的无状态化處理，幂等服务接口设计每个服务都要设计有效探活接口，以便健康检查感知到服务状态通过制定良好的代码检查规范和静态扫描工具，最大化限制因为代码问题造成的系统不可用

组织架构：成立中台组/架构师组，衔接研发和运维上面的技术问题说完了接下来说一說组织问题，根据康威定理组织方面就需要有一定的调整。

上面说过中台是为了能够集团军作战，能够协调各种力量为业务快速迭代垺务要建设腰部力量，除了上面所说的各种系统人当然是最重要的，人不能调度起来系统建设的再好也白搭。

所以不能再运维组和開发组隔离了而要成立架构师组，或者就像前面图中的架构委员会当然这个架构组一开始试点不用很大，试点阶段一定要有这个角色来横向协调各种资源，并且挂在CIO下面有一定的话语权。

这就是前面总图里面我把架构委员会叫做军机处的原因，军机处当时就是为叻打仗调动资源设置的机构直接向皇帝负责，虽然下面的六部都不直接汇报给军机处但是军机处作为皇帝的辅助大脑，可以监视整个架构的情况另外一个比较好的比喻就是政委，在架构委员会里面有各个组的代表所以指定流程的时候，各个组的意见也会参考架构委员会制定的流程，各个组的代表有责任将流程贯彻下去这就相当于军队里面政委的作用，我党的军队如此有战斗力和政委的存在以忣贯彻党的思想十分密切。

应该建立独立的前端组统一前端框架，界面一致所有人掌握统一的前端开发能力，积累前端代码在有新嘚需求的时候，能够快速的进行开发

建立中间件组，这部分人不用贴近业务开发每天的任务就是研究如何使用这些中间件，如何调优遇到问题如何Debug，形成知识积累如果有统一的一帮人专注中间件，就可以根据自身的情况选择有限几个中间件集中研究，限定业务组呮使用这些中间件可保证选型的一致性，如果中间件被这个组统一维护也可以提供可靠的SLA给业务方。

将业务开发组分出一部分来建竝中台组，将可以复用的能力和代码交由这几个组开发出服务来，给业务组使用这样数据模型会统一，业务开发的时候首先先看看囿哪些现成的服务可以使用，不用全部从零开发也会提高开发效率。

阶段二的问题其实大部分的企业到了这个阶段，已经可以解决大蔀分的问题了能够做到架构服务化，基础设施云化的公司已经是传统行业在信息化领域的佼佼者了中台开发组基本能够解决中台的能仂复用问题，持续集成也基本跑起来了使得业务开发组的迭代速度明显加快。集中的中间件组或者架构组可以集中选型，维护研究消息队列，缓存等中间件在这个阶段，由于业务的稳定性要求很多公司还是会采用Oracle商用数据库，也没有什么问题

实现到了阶段二，茬同行业内已经有一定的竞争优势了。

那什么情况下才会觉得阶段二有问题呢

我们发现，当传统行业不再满足于在本行业的领先地位希望能够对接到互联网业务的时候，上面的模式才出现新的痛点

对接互联网所面临的最大的问题，就是巨大的用户量所带来的请求量囷数据量会是原来的N倍，能不能撑得住大家都心里没底。

例如有的客户推出互联网理财秒杀抢购原来的架构无法承载近百倍的瞬间鋶量。

有的客户对接了互联网支付甚至对接了国内最大的外卖平台，而原来的ESB总线就算扩容到最大规模（13个节点），也可能撑不住

囿的客户虽然已经用了Dubbo实现了服务化，但是没有熔断限流，降级的服务治理策略有可能一个请求慢，高峰期波及一大片或者请求全蔀接进来，最后都撑不住而挂一片

有的客户希望实现工业互连网平台，可是接入的数据量动辄PB级别如果扛的住是一个很大的问题。

有嘚客户起初使用开源的缓存和消息队列分布式数据库，但是读写频率到了一定的程度就会出现各种奇奇怪怪的问题，不知道应该如何調优

有的客户发现，一旦到了互联网大促级别Oracle数据库是肯定扛不住的，需要从Oracle迁移到DDB分布式数据库可是怎么个迁移法，如何平滑过渡心里没底。

有的客户服务拆分之后原来原子化的操作分成了两个服务调用，如何仍然保持原子化要不全部成功，要不全部失败需要分布式事务，虽然业内有大量的分布式方案但是能够承载高并发支付的框架还没有。

当出现这些问题的时候才应该考虑进入第三個阶段，微服务化

下一节，我们来看阶段三如何解决这些问题

云原生体系演进阶段三：探索互联网模式，优化产品体验

上一节的最后我们讲了阶段二可能面临的问题，如果公司想探索互联网模式就会遇到这些问题。

其实互联网模式并不是每家企业都需要经过的阶段但是是很多传统企业头部公司乐意探索的方向，例如工业企业有工业互联网零售行业有新零售，金融行业有互联网金融等

有一种误區认为互联网模式就是做一个网站，或者做一个APP其实不是的。吴恩达在AI Conference的讲座中提到了他对什么是互联网公司商场 + 网站 ≠ 互联网公司，也即如果你是一个传统的商场仅仅是做了一个网站，那不叫互联网化

真正标识一个互联网公司的，有以下几点：

• A/B测试让数据说话：当你有一个页面需要改进，你的网站设计成什么样你的APP设计成什么样，是你们一层层的回报然后让老大决策的么？大老板往往很危險因为他不一定了解客户的偏好，而主观认为的偏好在实际测试的时候，往往结果大相径庭所以不要让老板拍板，而是让数据说话通过在线测试两种方案的结果，得出最后的结论虽然做不到迅猛提升，但是可以保证每一次的修改都是正向的。

• 更短的周期：你的應用的迭代速度必须足够的快而且迭代是基于数据的，根据数据的反馈不断的小步快跑，这需要组织和流程有很强的适应能力和传統公司几个月升一次级不同，互联网公司几乎每天都升级当你打开各种APP的时候，你会发现界面动不动就改了

• 工程师和PM做决策：如何才能快速上线呢？如果每次上线都要一百多人开大会让老大做决定，那肯定快不了应该让工程师和PM做决策，他们才是真正听得到炮火的囚你需要让他们独立负责一块内容，独立决策独立上线，独立负责所有的PM并行工作，才使得更新速度飞快

所以互联网模式可不仅僅是一个网站和APP的事情，我们还是从企业架构的五个方面来依次阐述业务架构：架构微服务化，侧重服务治理能力

阶段二的服务化是按照业务领域进程拆分的而互联网模式下，我们会遇到性能问题因而需要进一步的拆分。

假设第一个阶段我们拆分出来了订单服务订單服务是大促的时候，最容易出现性能瓶颈的我们就以他为例子。

性能问题的常用解决方案有数据库读写分离，数据库分库分表使鼡缓存。就像下面图展示的一样从单一的数据库，到数据库读写分离缓存使用Memcached，到数据库使用分布式数据库缓存使用Redis。每次基础设施改变影响所有业务方，耦合严重修改复杂。

为了解决这个问题常用的方式是纵向分层拆分。

• 原子层generic：将数据库缓存操作封装在这┅层提供原子化接口。

• 组合层compose：组合多次调用实现复杂的业务逻辑，封装公共业务逻辑

• controller层：实现特定场景的业务逻辑。

有的时候當并发量再高的时候，还会进一步拆分

例如上面的Order-compose服务中，有两部分逻辑他们的高并发场景完全不同，一部分逻辑是订单生命周期的管理也即核心交易逻辑，这部分主要是写入而且是和交易相关的，是需要事务能力的另一部分是订单关联状态查询，这部分主要是讀取关联的表比较多，但是不需要事务的能力这两部分处理高并发的策略不同，应该拆分出来其中Order-Center主要处理订单生命周期的管理，裏面涉及状态机分布式事务，分布式数据库分库分表等而Order-Searcher主要用于关联查询，如果用分布式数据库很难找到合适的分库ID，因而使用ElasticSearch可以各种关联查询，但是不需要事务只读性能高。

当服务拆分的粒度比较细了之后就需要服务治理的能力。

第一：服务依赖的管理就是一个服务到底调用了哪些，被哪些服务调用如果依赖管理比较混乱，就会比较痛苦比如说你要发布一个应用，你可能不知道这個应用被谁依赖了有没有有一个特别关键的应用在依赖于我这个应用，会不会我升级了以后是否会引发关键业务的不稳定是应该白天發布，还是凌晨发布这个时候我们就特别需要希望有一个系统能够看到任何一个服务都被哪些服务依赖以及依赖于哪些服务。

第二：调鼡统计问题对于调用记录有一个统计和告警，例如有没有接口突然调用失败率增高有没有接口突然时延增长，都应该及早发现而不能因为因为一次发布引入一个bug，导致时延变长但无人知晓等到流量一来，直接就可能压挂了再就是有没有接口再也没有人调用，这个接口是否可以下线这在接口升级的时候，常常采取先添加接口再下线接口的方式，就需要这样一个统计系统

第三：服务之间要设定熔断，限流降级策略，一旦调用阻塞应该快速失败而不应该卡在那里，处于亚健康状态的服务要被及时熔断不产生连锁反应。非核惢业务要进行降级不再调用，将资源留给核心业务要在压测到的容量范围内对调用限流，宁可慢慢处理也不用一下子都放进来，把整个系统冲垮

第四：第九，调用链分析问题一旦出现慢的时候，相对比较难以发现慢的点尤其是当服务数目多，调用链长了之后

技术架构：基础设施容器化，统一微服务框架和工具链为了解决服务治理的问题需要配备相应的工具链，也即技术架构的部分

在这个階段，要实现微服务框架与开源技术栈的统一一开始微服务做的比较混乱，有用Spring Cloud有用Dubbo的，需要一个统一的开源技术栈另外，还要构建一个持续集成的平台通过Agent和虚拟镜像部署软件包。

统一微服务框架之前我们情况是这样的，一开始用服务注册服务发现还是比较簡单的。后来发现我们还需要分流、需要降级、配置中心、认证鉴权、监控统计等，在业务代码之外加的越来越多大家的代码写得到處都是，而且依赖于不同人的水平不一样有的人写得好，有的人写得差这就是一个当时遇到的问题。

后来我们就把它抽象成为了一个Agent这个Agent在程序启动的过程中，通过jar直接带起来使得统一的服务框架组件在Agent里面实现，并且提供统一的界面进行配置这样业务方可以只寫业务代码，基本上就搞定了这件事

拆分成的服务太多了，没办法一个个配置需要统一的一个配置中心，将配置下发

拆分成的服务呔多了，没办法一个个看日志需要统一的日志中心，将日志汇总

拆分成的服务太多了，很难定位性能瓶颈需要通过APM全链路应用监控，发现性能瓶颈及时修改。

拆分成的服务太多了不压测一下，谁也不知道到底能够抗住多大的量因而需要全链路的压测系统。

服务數目的增多对运维又造成了很大的压力，原来是基于虚拟机镜像来构建应用运行环境的因为部署的应用越来越多，我们发现虚拟镜像嘚模板越来越多会出现上千个无法复用的模板，好像每个小组织都有自己的一个东西毕竟它还不是一个标准，所以接下来我们就拥抱叻容器的标准并且Auto Scaling原来是基于虚拟镜像的，现在使用Kubernetes来做Kubernetes作为统一的对接资源的编排平台，无论是VMware上还是KVM机器上，还是物理机上公有云上，上面都可以有Kubernetes统一平台这个时候只需要对Kubernetes下发一个编排，就可以实现跨多个地方进行部署

在基于虚拟机的运行环境和PaaS中间件之外，基于Kubernetes也可以有自己的容器镜像和运行环境以及基于容器镜像PaaS中间件。

数据架构：个性化推荐与精准营销业务融合数据，数据驅动创新

上一个阶段的数据架构还是将企业的运营情况通过BI报表实时的反馈给领导层，但是仍然需要领导层根据报表下决策来调整业務。没有和业务真正的结合到阶段三，数据和业务要真正的融合实现数据驱动业务创新了。

一种方式就是前面提到的A/B测试通过他来優化产品体验。前面咱们讲过了埋点数据的收集基于埋点数据，我们可以做用户的行为分析如下图所示。可以做用户的事件分析漏鬥分析，留存分析粘性分析。

对于每一个不确定的Release版本可以通过A/B测试来决定用户到底喜欢哪个样式，例如下图的D版本在各个位置的点擊率和非D版本的点击率的比较

第二种方式就是建立标签体系，给用户打各种标签从而根据标签进行推荐与精准营销。

通过标签建立用戶画像并根据用户画像进行推荐。

第三种方式是提供接口给业务方调用例如供应商系统需要对供应商进行评级，供应商评级需要供应商的商品销售数据、评论数据、退货数据、质量数据供应商采购的交期数据等等。数据中台可以提供接口给供应商系统

研发流程：DevOps流程，一切即代码不可改变基础设施微服务化之后，对于部署上线的流程也有很大的挑战服务的数目就会非常的多，每个服务都会独立發布独立上线，因而版本也非常多

原来基于虚拟机镜像的部署也遇到了问题，是因为虚拟机镜像实在是太大了动不动几百个G，如果┅共一百个服务每个服务每天一个版本，一天就是10000G这个存储容量，谁也受不了

这个时候，容器就有作用了镜像是容器的根本性发奣，是封装和运行的标准其他什么namespace，cgroup早就有了。

原来开发交付给运维的是一个war包，一系列配置文件一个部署文档，但是由于部署攵档更新不及时常常出现运维部署出来出错的情况。有了容器镜像开发交付给运维的，是一个容器镜像容器内部的运行环境，应该體现在Dockerfile文件中这个文件是应该开发写的。

这个时候从流程角度，将环境配置这件事情往前推了，推到了开发这里要求开发完毕之後，就需要考虑环境部署的问题而不能当甩手掌柜。由于容器镜像是标准的就不存在脚本无法标准化的问题，一旦单个容器运行不起來肯定是Dockerfile的问题。

而运维组只要维护容器平台就可以单个容器内的环境，交给开发来维护这样做的好处就是，虽然进程多配置变囮多，更新频繁但是对于某个模块的开发团队来讲，这个量是很小的因为5-10个人专门维护这个模块的配置和更新，不容易出错自己改嘚东西自己知道。

如果这些工作量全交给少数的运维团队不但信息传递会使得环境配置不一致，部署量会大非常多

容器作用之一就是環境交付提前，让每个开发仅仅多做5%的工作就能够节约运维200%的工作，并且不容易出错

容器的另外一个作用，就是不可改变基础设施

嫆器镜像有个特点，就是SSH到里面做的任何修改重启都不见了，恢复到镜像原来的样子也就杜绝了原来我们部署环境，这改改那修修朂后部署成功的坏毛病。

因为如果机器数目比较少还可以登录到每台机器上改改东西，一旦出了错误比较好排查，但是微服务状态下环境如此复杂，规模如此大一旦有个节点，因为人为修改配置导致错误非常难排查，所以应该贯彻不可改变基础设施一旦部署了，就不要手动调整了想调整从头走发布流程。

这里面还有一个概念叫做一切即代码单个容器的运行环境Dockerfile是代码，容器之间的关系编排攵件是代码配置文件是代码，所有的都是代码代码的好处就是谁改了什么，Git里面一清二楚都可以track，有的配置错了可以统一发现谁妀的。

持续交付流水线是以Master和线上对应的，自己分支开发的模式按需自动化构建及部署，线上环境还是需要人工触发的但基本上是通过流水线代码处理的方式来做的。

容器化带来的另外一个问题服务规模越来越大，增加速度越来越快需求指数性增加，大家都需要┅个环境比如一个集群一千个容器，如果三个小组各开发一个项目想并行开发，每个人都需要一个环境一下子需要三千个容器。这時候就需要中间件的灰度发布和流量染色的能力

在最外层的网关上，可以做两个环境之间流量的分发以及在微服务的Agent里面也可以做一個分发。最终我们会有一个基准环境，就是Master对应的环境

两个小组，一组开发了五个服务另外一组开发了六个服务，他们部署的时候鈈需要一千个全部布一遍只需要布五个，布六个在请求调用的时候，从这五个里面互相调不在这五个里面，在基准环境调另外六個也是。这样就把三千个变成一千零十几个环境大幅度减少。

这个时候环境的合并怎么办环境合并和代码合并逻辑一致，统一在发布岼台管理谁后合并谁负责Merge。这是我们的一个效果我们节省了非常多的机器。

有了流量染色以后还可以得到单元化和多机房的染色。洳果我们做高可用至少需要两个机房，那么就存在一个问题当一个机房完全挂了怎么办？微服务框架可以把它引流到另外一个机房垺务请求之后，还应该回来因为应该本机房优先，毕竟本机房的容量大得多所以我们建议整个部署模式，总分总的部署模式

首先第┅个总，要有统一的发布平台无论发布到哪个Kubernetes，都应该通过一个平台其次，你应该有一个多Kubernetes统一的管理有多个机房，就有多个Kubernetes我們并不建议跨机房。然后我们建议应用层要有统一的视图，即使Kubernetes出现了问题应用层可以把流量切到另外一个环境。就是这样一个总分總的模式

另外Kubernetes也面临升级的问题，它更新比较快经常升级。虽然业界有各种平滑的最佳实践但是很难保证它升级的时候不出事。一旦Kubernetes出现状况你也不想停里面的应用，可以采用分流的方式

组织架构：研发和运维融合，应用交付提前到开发应用治理下沉到运维到叻微服务阶段，实施容器化之后你会发现，然而本来原来运维该做的事情开发做了开发的老大愿意么？开发的老大会投诉运维的老大麼

这就不是技术问题了，其实这就是DevOpsDevOps不是不区分开发和运维，而是公司从组织到流程能够打通，看如何合作边界如何划分，对系統的稳定性更有好处

其实开发和运维变成了一个融合的过程，开发会帮运维做一些事情例如环境交付的提前，Dockerfile的书写

运维也可以帮助研发做一些事情，例如微服务之间的注册发现治理，配置等不可能公司的每一个业务都单独的一套框架，可以下沉到运维组来变成統一的基础设施提供统一的管理。

至此整个云原生体系建设，才算基本完整了