致传统企业朋友：不够痛就别微服务，有坑

1、微服务落地是一个复杂问题，牵扯到IT架构，应用架构，组织架构多个方面

在多家传统行业的企业走访和落地了微服务以后，发现落地微服务是一个很是复杂的问题，甚至都不彻底是技术问题。

当时想微服务既然是改造应用，作微服务治理，相似注册，发现，熔断，限流，降级等，固然应该从应用开发组切入，通常一开始聊的会比较开心，从单体架构，到SOA，再到微服务架构，从Dubbo聊到SpringCloud，可是必然会涉及到微服务的发布和运维问题，涉及到DevOps和容器层，这些都不在开发组的控制范围内，一旦拉进运维组，对于容器的接受程度就成了一个问题，和传统物理机，虚拟机的差异，会带来什么风险等等等等，尤为是容器绝对不是轻量级的虚拟化这件事情，就不是一时半会儿能说的明白的。更况且就算说明白了，还有线上应用容器，一旦出了事情，谁背锅的问题，容器每每会致使应用层和基础设施层界限模糊，这使得背锅双方都会犹豫不决。

有的企业的微服务化是运维部门发起的，运维部门已经意识到了各类各样不统一的应用给运维带来的苦，也乐意接受容器的运维模式，这就涉及到容器直接的服务发现是否应该运维在容器层搞定，仍是应用应该本身搞定的问题，还涉及Dockerfile究竟是开发写仍是运维写的问题。一旦容器化的过程当中，开发不配合，运维单方面去作这个事情，是徒增烦恼却收益有限的。

下图是微服务实施的过程当中涉及到的层次，具体的描述参考文章云架构师进阶攻略

在一些相对先进的企业，会在运维组和开发组之间，有个中间件组，或者叫作架构组，来负责推进微服务化改造的事情，架构组就既须要负责劝说业务开发实施微服务化，也要劝说运维组实施容器化，若是架构组的权威性不足，推进每每也会比较困难。

因此微服务，容器，DevOps的推进，不仅仅是一个技术问题，更是一个组织问题，在推进微服务的过程当中，更加可以感受到康威定律的做用，须要更高层次技术总监或者CIO的介入，方可以推进微服务的落地。

然而到了CIO层，在不少企业又体会不到技术层面的痛点了，而更加关注业务的层面了，只要业务能赚钱，架构的痛，中间件的痛，运维的痛，高层不是很是可以感知，也就体会不到微服务，容器化的技术优点了，而微服务和容器化对于业务的优点，不少厂家在说，可以说到表面，说不到内心。

于是微服务和容器化的改造，更加容易发生在一个扁平化的组织里面，由一个可以体会到基层技术细节的痛的CIO，高瞻远瞩的推进这件事情。这也是为何微服务的落地通常率先落地在互联网公司，由于互联网公司的组织架构实在太平台，哪怕是高层，也离一线很是的近，了解一线的痛。

然而在传统行业就没有那么幸运了，层级每每会比较多，这个时候就须要技术上的痛足够痛，可以痛到影响业务，可以痛到影响收入，可以痛到被竞争对手甩在后面，才能上达天听。

咱们接下来就梳理一下，在这个过程当中的那些痛。

2、阶段一：单体架构群，多个开发组，统一运维组

2.1. 阶段一的组织状态

组织状态相对简单。

统一的运维组，管理物理机，物理网络，Vmware虚拟化等资源，同时部署上线由运维部负责。
开发组每一个业务都是独立的，负责写代码，不一样的业务沟通很少，开发除了作本身的系统外，还须要维护外包公司开发的系统，因为不一样的外包公司技术选型差别较大，于是处于烟囱式的架构状态。

传统烟囱式架构以下图所示

2.2. 阶段一的运维模式

在传统架构下，基础设施层每每采起物理机或者虚拟化进行部署，为了避免同的应用之间方便相互访问，多采起桥接扁平二层机房网络，也即全部的机器的IP地址都是能够相互访问的，不想互相访问的，多采用防火墙进行隔离。

不管是使用物理机，仍是虚拟化，配置是相对复杂的，不是作过多年运维的人员，难以独立的建立一台机器，并且网络规划也须要很是当心，分配给不一样业务部门的机器，网段不能冲突。全部这一切，都须要运维部门统一进行管理，通常的IT人员或者开发人员既没有专业性，也不可能给他们权限进行操做，要申请机器怎么办，走个工单，审批一下，过一段时间，机器就能建立出来。

2.3. 阶段一的应用架构

传统架构数据库层，因为外包公司独立开发，或者不一样开发部门独立开发，不一样业务使用不一样的数据库，有用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
  传统架构的服务层，系统或者由外包公司开发，或者由独立团队开发。

传统架构前端，各自开发各自的前端。

2.4. 阶段一有什么问题吗？

其实阶段一没有任何问题，咱们甚至能找出一万个理由说明这种模式的好处。

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

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

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

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

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

2.5. 什么状况下才会以为阶段一有问题？

固然最初的痛点应该在业务层面，当用户的需求开始变的多种多样，业务方时不时的就要上一个新功能，作一个新系统的时候，你会发现外包公司不是能彻底搞定全部的事情，他们是瀑布模型的开发，并且开发出来的系统很难变动，至少很难快速变动。

因而你开始想本身招聘一些开发，开发本身可以把控的系统，至少可以将外包公司开发的系统接管过来，这个时候，应对业务部门的需求，就会灵活的多。

可是本身开发和维护就带来了新的问题，多种多样的数据库，根本不可能招聘到如此多样的DBA，人都很是的贵，并且随着系统的增多，这些数据库的lisense也很是的贵。

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

前端框架也有相同的问题，技术栈不一致，界面风格不一致，根本没法自动作UI测试。

当维护了多套系统以后，你会发现，这些系统各个层次都有不少的共同点，不少能力是能够复用的，不少数据是能够打通的。一样一套逻辑，这里也有，那里也有，一样类型的数据，这里一份，那里一份，可是信息是隔离的，数据模型不统一，根本没法打通。

当出现这些问题的时候，才是您考虑进入第二个阶段。

3、阶段二：组织服务化，架构SOA化，基础设施云化

3.1. 阶段二的组织形态

怎么解决上面的问题呢？

根据康威定理，组织方面就须要有必定的调整，整个公司仍是分运维组和开发组。

因为痛点是从业务层面发生的，开始调整的应该是开发组。

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

创建中间件组，或者架构师组，这部分人不用贴近业务开发，天天的任务就是研究如何使用这些中间件，如何调优，遇到问题如何Debug，造成知识积累。若是有统一的一帮人专一中间件，就能够根据自身的状况，选择有限几个中间件集中研究，限定业务组只使用这些中间件，可保证选型的一致性，若是中间件被这个组统一维护，也能够提供可靠的SLA给业务方。

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

3.2. 阶段二的应用架构

要创建中台，变成服务为其余业务使用，就须要使用SOA架构，将能够复用的组件服务化，注册到服务的注册中心。

对于有钱的企业，可能会采购商用的ESB总线，也有使用Dubbo本身封装称为服务注册中心。

接下来就是要考虑，哪些应该拆出来？ 最后考虑的是如何拆出来？

这两个题目的答案，不一样的企业不一样，其实分为两个阶段，第一个阶段是尝试阶段，也即整个公司对于服务化拆分没有任何经验，固然不敢拿核心业务上手，每每选取一个边角的业务，先拆拆看，这个时候拆自己是重要的，实际上是为了拆而拆，拆的比较理想化，符合领域驱动设计的最好，如何拆呢？固然是弄一个两个月，核心员工你们闭门开发，进行拆分和组合，来积累经验。不少企业目前处于这个阶段。

可是其实这个阶段的拆法也只能用来积累经验，由于我们最初要拆分，是为了快速响应业务请求，而这个边角的模块，每每不是最痛的核心业务。原本业务就边角，拆不拆收益不大，并且也没办法很好的作能力复用。复用固然都想复用核心能力。

因此其实最重要的是第二个阶段，业务真正的服务化的阶段。固然要拿业务需求最多的核心业务逻辑下手，才能起到快速响应业务请求，复用能力的做用。

例如考拉最初也是一个使用Oracle，对外只有一个online业务的单体应用，而真正的拆分，就是围绕核心的下单业务逻辑进行的。

那核心业务逻辑中，哪些应该拆出来呢？不少企业会问咱们，其实企业本身的开发最清楚。

这个时候常常犯的错误是，先将核心业务逻辑从单体应用中拆分出来。例如将下单逻辑造成下单服务，从online服务中拆分出来。

固然不该该这样，例如两军打仗，当炊事班的烟熏着战士了，是将中军大营搬出去，仍是讲炊事班搬出去呢？固然是炊事班了。

另一点是，可以造成复用的组件，每每不是核心业务逻辑。这个很好理解，两个不一样的业务，固然是核心业务逻辑不一样(要不就成一种业务了)，核心业务逻辑每每是组合逻辑，虽然复杂，可是每每不具有复用性，就算是下单，不一样的电商也是不同的，这家推出了什么什么豆，那家推出了什么什么券，另外一家有个什么什么活动，都是核心业务逻辑的不一样，会常常变。可以复用的，每每是用户中心，支付中心，仓储中心，库存中心等等核心业务的周边逻辑。

因此拆分，应该将这些核心业务的周边逻辑，从核心业务里面拆出来，最终Online就剩下下单的核心路径了，就能够改为下单服务了。当业务方忽然有了需求推出一个抢购活动，就能够复用刚才的周边逻辑了。抢购就成了另外一个应用的核心逻辑，其实核心逻辑是传真引线的，周边逻辑是保存数据，提供原子化接口的。

那哪些周边逻辑应该先拆出来呢？问本身的开发吧，那些战战兢兢，本身修改后生怕把核心逻辑搞挂了的组，是本身有动力从核心逻辑中拆分出来的，这个不须要技术总监和架构师去督促，他们有本身的原有动力，是一个很天然的过程。

这里的原有动力，一个是开发独立，一个是上线独立，就像考拉的online系统里面，仓库组就想本身独立出去，由于他们要对接各类各样的仓储系统，全球这么多的仓库，系统都很传统，接口不同，没新对接一个，开发的时候，都担忧把下单核心逻辑搞挂了，形成线上事故，其实仓储系统能够定义本身的重试和容灾机制，没有下单那么严重。物流组也想独立出去，由于对接的物流公司太多了，也要常常上线，也不想把下单搞挂。

您也能够梳理一下贵公司的业务逻辑，也会有自行愿意拆分的业务，造成中台服务。

当周边的逻辑拆分以后，一些核心的逻辑，互相怕影响，也能够拆分出去，例以下单和支付，支付对接多个支付方的时候，也不想影响下单，也能够独立出去。

而后咱们再看，如何拆分的问题？

关于拆分的前提，时机，方法，规范等，参考文章微服务化之服务拆分与服务发现

首先要作的，就是原有工程代码的标准化，咱们常称为“任何人接手任何一个模块都能看到熟悉的面孔”

例如打开一个java工程，应该有如下的package：

• API接口包：全部的接口定义都在这里，对于内部的调用，也要实现接口，这样一旦要拆分出去，对于本地的接口调用，就能够变为远程的接口调用
• 访问外部服务包：若是这个进程要访问其余进程，对于外部访问的封装都在这里，对于单元测试来说，对于这部分的Mock，可使得不用依赖第三方，就能进行功能测试。对于服务拆分，调用其余的服务，也是在这里。
• 数据库DTO：若是要访问数据库，在这里定义原子的数据结构
• 访问数据库包：访问数据库的逻辑所有在这个包里面
• 服务与商务逻辑：这里实现主要的商业逻辑，拆分也是从这里拆分出来。
• 外部服务：对外提供服务的逻辑在这里，对于接口的提供方，要实如今这里。

另外是测试文件夹，每一个类都应该有单元测试，要审核单元测试覆盖率，模块内部应该经过Mock的方法实现集成测试。

接下来是配置文件夹，配置profile，配置分为几类：

• 内部配置项(启动后不变，改变须要重启)
• 集中配置项(配置中心，可动态下发)
• 外部配置项(外部依赖，和环境相关)

当一个工程的结构很是标准化以后，接下来在原有服务中，先独立功能模块 ，规范输入输出，造成服务内部的分离。在分离出新的进程以前，先分离出新的jar，只要可以分离出新的jar，基本也就实现了松耦合。

接下来，应该新建工程，新启动一个进程，尽早的注册到注册中心，开始提供服务，这个时候，新的工程中的代码逻辑能够先没有，只是转调用原来的进程接口。

为何要越早独立越好呢？哪怕还没实现逻辑先独立呢？由于服务拆分的过程是渐进的，伴随着新功能的开发，新需求的引入，这个时候，对于原来的接口，也会有新的需求进行修改，若是你想把业务逻辑独立出来，独立了一半，新需求来了，改旧的，改新的都不合适，新的还没独立提供服务，旧的若是改了，会形成从旧工程迁移到新工程，边迁移边改变，合并更加困难。若是尽早独立，全部的新需求都进入新的工程，全部调用方更新的时候，都改成调用新的进程，对于老进程的调用会愈来愈少，最终新进程将老进程所有代理。

接下来就能够将老工程中的逻辑逐渐迁移到新工程，因为代码迁移不能保证逻辑的彻底正确，于是须要持续集成，灰度发布，微服务框架可以在新老接口之间切换。

最终当新工程稳定运行，而且在调用监控中，已经没有对于老工程的调用的时候，就能够将老工程下线了。

3.3. 阶段二的运维模式

通过业务层的的服务化，也对运维组形成了压力。

应用逐渐拆分，服务数量增多。

在服务拆分的最佳实践中，有一条就是，拆分过程须要进行持续集成，保证功能一致。

而持续集成的流程，每每须要频繁的部署测试环境。

随着服务的拆分，不一样的业务开发组会接到不一样的需求，并行开发功能增多，发布频繁，会形成测试环境，生产环境更加频繁的部署。

而频繁的部署，就须要频繁建立和删除虚拟机。

若是仍是采用上面审批的模式，运维部就会成为瓶颈，要不就是影响开发进度，要不就是被各类部署累死。

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

虚拟化到云化有什么不同呢？

首先要有良好的租户管理，从运维集中管理到租户自助使用模式的转换。

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

其次，要实现基于Quota和QoS的资源控制。

也即对于租户建立的资源的控制，不用精细化到运维手动管理一切，只要给这个客户分配了租户，分配了Quota，设置了Qos，租户就能够在运维限定的范围内，自由随意的建立，使用，删除虚拟机，无需通知运维，这样迭代速度就会加快。

再次，要实现基于虚拟网络，VPC，SDN的网络规划。

原来的网络使用的都是物理网络，问题在于物理网络是全部部门共享的，没办法交给一个业务部门自由的配置和使用。于是要有VPC虚拟网络的概念，每一个租户能够随意配置本身的子网，路由表，和外网的链接等，不一样的租户的网段能够冲突，互不影响，租户能够根据本身的须要，随意的在界面上，用软件的方式作网络规划。

除了基础设施云化以外，运维部门还应该将应用的部署自动化。

由于若是云计算无论应用，一旦出现扩容，或者自动部署的需求，云平台建立出来的虚拟机仍是空的，须要运维手动上去部署，根本忙不过来。于是云平台，也必定要管理应用。

云计算如何管理应用呢？咱们将应用分红两种，一种称为通用的应用，通常指一些复杂性比较高，但你们都在用的，例如数据库。几乎全部的应用都会用数据库，但数据库软件是标准的，虽然安装和维护比较复杂，但不管谁安装都是同样。这样的应用能够变成标准的PaaS层的应用放在云平台的界面上。当用户须要一个数据库时，一点就出来了，用户就能够直接用了。

因此对于运维模式的第二个改变是，通用软件PaaS化。
前面说过了，在开发部门有中间件组负责这些通用的应用，运维也自动部署这些应用，两个组的界限是什么样的呢？

通常的实践方式是，云平台的PaaS负责建立的中间件的稳定，保证SLA，当出现问题的时候，会自动修复。

而开发部门的中间件组，主要研究如何正确的使用这些PaaS，配置什么样的参数，使用的正确姿式等等，这个和业务相关。

除了通用的应用，还有个性化的应用，应该经过脚本进行部署，例如工具Puppet, Chef, Ansible, SaltStack等。

这里有一个实践是，不建议使用裸机部署，由于这样部署很是的慢，推荐基于虚拟机镜像的自动部署。在云平台上，任何虚拟机的建立都是基于镜像的，咱们能够在镜像里面，将要部署的环境大部分部署好，只须要作少许的定制化，这些由部署工具完成。

下图是OpenStack基于Heat的虚拟机编排，除了调用OpenStack API基于镜像建立虚拟机以外，还要调用SaltStack的master，将定制化的指令下发给虚拟机里面的agent。

基于虚拟机镜像和脚本下发，能够构建自动化部署平台NDP

这样能够基于虚拟机镜像，作完整的应用的部署和上线，称为编排。基于编排，就能够进行很好的持续集成，例如天天晚上，自动部署一套环境，进行回归测试，从而保证修改的正确性。

进行完第二阶段以后，整个状态如上图所示。

这里运维部门的职能有了必定的改变，除了最基本的资源建立，还要提供自助的操做平台，PaaS化的中间件，基于镜像和脚本的自动部署。

开发部门的职能也有了必定的改变，拆分称为前端组，业务开发组，中台组，中间件组，其中中间件组合运维部门的联系最紧密。

3.4. 阶段二有什么问题吗？

其实大部分的企业，到了这个阶段，已经能够解决大部分的问题了。

可以作到架构SOA化，基础设施云化的公司已是传统行业在信息化领域的佼佼者了。

中台开发组基本可以解决中台的能力复用问题，持续集成也基本跑起来了，使得业务开发组的迭代速度明显加快。

集中的中间件组或者架构组，能够集中选型，维护，研究消息队列，缓存等中间件。

在这个阶段，因为业务的稳定性要求，不少公司仍是会采用Oracle商用数据库，也没有什么问题。

实现到了阶段二，在同行业内，已经有必定的竞争优点了。

3.5. 什么状况下才会以为阶段二有问题？

咱们发现，当传统行业再也不知足于在本行业的领先地位，但愿可以对接到互联网业务的时候，上面的模式才出现新的痛点。

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

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

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

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

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

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

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

有的客户服务拆分以后，原来原子化的操做分红了两个服务调用，如何仍然保持原子化，要不所有成功，要不所有失败，须要分布式事务，虽然业内有大量的分布式方案，可是可以承载高并发支付的框架尚未。

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

4、阶段三：组织DevOps化，架构微服务化，基础设施容器化

4.1. 阶段三的应用架构

从SOA到微服务化这一步很是关键，复杂度也比较高，上手须要谨慎。

为了可以承载互联网高并发，业务每每须要拆分的粒度很是的细，细到什么程度呢？咱们来看下面的图。

在这些知名的使用微服务的互联网公司中，微服务之间的相互调用已经密密麻麻相互关联成为一个网状，几乎都看不出条理来。

为何要拆分到这个粒度呢？主要是高并发的需求。

可是高并发不是没有成本的，拆分红这个粒度会有什么问题呢？你会发现等拆完了，下面的这些措施一个都不能少。

• 拆分如何保证功能不变，不引入Bug——持续集成，参考微服务化的基石——持续集成
• 静态资源要拆分出来，缓存到接入层或者CDN，将大部分流量拦截在离用户近的边缘节点或者接入层缓存，参考微服务的接入层设计与动静资源隔离
• 应用的状态要从业务逻辑中拆分出来，使得业务无状态，能够基于容器进行横向扩展，参考微服务化之无状态化与容器化
• 核心业务和非核心业务要拆分，方便核心业务的扩展以及非核心业务的降级，参考微服务化之服务拆分与服务发现
• 数据库要读写分离，要分库分表，才能在超大数据量的状况下，数据库具备横向扩展的能力，不成为瓶颈，参考微服务化的数据库设计与读写分离
• 要层层缓存，只有少数的流量到达中军大营数据库，参考微服务化之缓存的设计
• 要使用消息队列，将原来连续调用的多个服务异步化为监听消息队列，从而缩短核心逻辑
• 服务之间要设定熔断，限流，降级策略，一旦调用阻塞应该快速失败，而不该该卡在那里，处于亚健康状态的服务要被及时熔断，不产生连锁反应。非核心业务要进行降级，再也不调用，将资源留给核心业务。要在压测到的容量范围内对调用限流，宁肯慢慢处理，也不用一会儿都放进来，把整个系统冲垮。
• 拆分红的服务太多了，没办法一个个配置，须要统一的一个配置中心，将配置下发
• 拆分红的服务太多了，没办法一个个看日志，须要统一的日志中心，将日志汇总
• 拆分红的服务太多了，很难定位性能瓶颈，须要经过APM全链路应用监控，发现性能瓶颈，及时修改
• 拆分红的服务太多了，不压测一下，谁也不知道到底可以抗住多大的量，于是须要全链路的压测系统。
  

应用层须要处理这十二个问题，最后一个都不能少，实施微服务，你作好准备了吗？你真以为攒一攒springcloud，就可以作好这些吗？

4.2. 阶段三的运维模式

业务的微服务化改造以后，对于运维的模式是有冲击的。

若是业务拆成了如此网状的细粒度，服务的数目就会很是的多，每一个服务都会独立发布，独立上线，于是版本也很是多。

这样环境就会很是的多，手工部署已经不可能，必须实施自动部署。好在在上一个阶段，咱们已经实施了自动部署，或者基于脚本的，或者基于镜像的，可是到了微服务阶段都有问题。

若是基于脚本的部署，脚本原来多由运维写，因为服务太多，变化也多，脚本确定要不断的更新，而每家公司的开发人员都远远多于运维人员，运维根原本不及维护自动部署的脚本。那脚本能不能由开发写呢？通常是不可行的，开发对于运行环境了解有限，并且脚本没有一个标准，运维没法把控开发写的脚本的质量。

基于虚拟机镜像的就会好不少，由于须要脚本作的事情比较少，大部分对于应用的配置都打在镜像里面了。若是基于虚拟机镜像进行交付，也能起到标准交付的效果。并且一旦上线有问题，也能够基于虚拟机镜像的版本进行回滚。

可是虚拟机镜像实在是太大了，动不动几百个G，若是一共一百个服务，每一个服务天天一个版本，一天就是10000G，这个存储容量，谁也受不了。

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

原来开发交付给运维的，是一个war包，一系列配置文件，一个部署文档，可是因为部署文档更新不及时，经常出现运维部署出来出错的状况。有了容器镜像，开发交付给运维的，是一个容器镜像，容器内部的运行环境，应该体如今Dockerfile文件中，这个文件是应该开发写的。

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

而运维组只要维护容器平台就能够，单个容器内的环境，交给开发来维护。这样作的好处就是，虽然进程多，配置变化多，更新频繁，可是对于某个模块的开发团队来说，这个量是很小的，由于5-10我的专门维护这个模块的配置和更新，不容易出错。本身改的东西本身知道。

若是这些工做量全交给少数的运维团队，不但信息传递会使得环境配置不一致，部署量会大很是多。

容器做用之一就是环境交付提早，让每一个开发仅仅多作5%的工做，就可以节约运维200%的工做，而且不容易出错。

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

容器镜像有个特色，就是ssh到里面作的任何修改，重启都不见了，恢复到镜像原来的样子，也就杜绝了原来咱们部署环境，这改改，那修修最后部署成功的坏毛病。

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

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

4.3. 阶段三的组织形态

到了微服务阶段，实施容器化以后，你会发现，然而原本原来运维该作的事情开发作了，开发的老大愿意么？开发的老大会投诉运维的老大么？

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

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

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

实施容器，微服务，DevOps后，整个分工界面就变成了下面的样子。

在网易就是这个模式，杭州研究院做为公共技术服务部门，有运维部门管理机房，上面是云平台组，基于OpenStack开发了租户可自助操做的云平台。PaaS组件也是云平台的一部分，点击可得，提供SLA保障。容器平台也是云平台的一部分，而且基于容器提供持续集成，持续部署的工具链。

微服务的管理和治理也是云平台的一部分，业务部门可使用这个平台进行微服务的开发。

业务部门的中间件组或者架构组合云平台组沟通密切，主要是如何以正确的姿式使用云平台组件。

业务部门分前端组，业务开发组，中台开发组。

5、如何实施微服务，容器化，DevOps

实施微服务，容器化，DevOps有不少的技术选型。

其中容器化的部分，Kubernetes当之无愧的选择。可是Kubernetes可不只仅志在容器，他是为微服务而设计的。对于实施微服务各方面都有涉及。

详细分析参加为何 kubernetes 自然适合微服务

可是Kubernetes对于容器的运行时生命周期管理比较完善，可是对于服务治理方面还不够强大。

于是对于微服务的治理方面，多选择使用Dubbo或者SpringCloud。使用Dubbo的存量应用比较多，相对于Dubbo来说，SpringCloud比较新，组件也比较丰富。可是SpringCloud的组件都不到开箱即用的程度，须要比较高的学习曲线。

于是基于Kubernetes和SpringCloud，就有了下面这个微服务，容器，DevOps的综合管理平台。包含基于Kubernetes的容器平台，持续集成平台，测试平台，API网关，微服务框架，APM应用性能管理。

主要为了解决从阶段一到阶段二，或者阶段二到阶段三的改进中的痛点。

下面咱们列举几个场景。

场景一：架构SOA拆分时，如何保证回归测试功能集不变

前面说过，服务拆分后，最怕的是拆完了引入一大堆的bug，经过理智确定不能保证拆分后功能集是不变的，于是须要有回归测试集合保证，只要测试集合经过了，功能就没有太大的问题。

回归测试最好是基于接口的，由于基于UI的很危险，有的接口是有的，可是UI上不能点，这个接口若是有Bug，就被暂时隐藏掉了，当后面有了新的需求，当开发发现有个接口可以调用的时候，一调用就挂了。

有了基于Restful API的接口测试以后，能够组成场景测试，将多个API调用组合成为一个场景，例以下单，扣优惠券，减库存，就是一个组合场景。

另外能够造成测试集合，例如冒烟测试集合，当开发将功能交付给测试的时候，执行一下。再如平常测试集合，天天晚上跑一遍，看看当天提交的代码有没有引入新的bug。再如回归测试集合，上线以前跑一遍，保证大部分的功能是正确的。

场景二：架构SOA化的时候，如何统一管理并提供中台服务

当业务要提供中台服务的时候，中台服务首先但愿可以注册到一个地方，当业务组开发业务逻辑的时候，可以在这个地方找到中台的接口如何调用的文档，当业务组的业务注册上来的时候，能够进行调用。

在微服务框架普通的注册发现功能以外，还提供知识库的功能，使得接口和文档统一维护，文档和运行时一致，从而调用方看着文档就能够进行调用。

另外提供注册，发现，调用期间的鉴权功能，不是谁看到中台服务都能调用，须要中台管理员受权才能够。

为了防止中台服务被恶意调用，提供帐户审计功能，记录操做。

场景三：服务SOA化的时候，如何保证关键服务的调用安全

有的服务很是关键，例如支付服务，和资金相关，不是谁想调用就能调用的，一旦被非法调用了，后果严重。

在服务治理里面有路由功能，除了可以配置灵活的路由功能以外，还能够配置黑白名单，能够基于IP地址，也能够基于服务名称，配置只有哪些应用能够调用，能够配合云平台的VPC功能，限制调用方。

场景四：架构SOA化后，对外提供API服务，构建开放平台

架构SOA化以后，除了对内提供中台服务，不少能力也能够开放给外部的合做伙伴，造成开放平台。例如你是一家物流企业，除了在你的页面上下单寄快递以外，其余的电商也能够调用你的API来寄快递，这就须要有一个API网关来管理API，对接你的电商只要登陆到这个API网关，就能看到API以及如何调用，API网关上面的文档管理就是这个做用。

另外API网关提供接口的统一认证鉴权，也提供API接口的定时开关功能，灵活控制API的生命周期。

场景五：互联网场景下的灰度发布和A/B测试

接下来咱们切换到互联网业务场景，常常会作A/B测试，这就须要API网关的流量分发功能。

例如咱们作互联网业务，当上一个新功能的 时候，不清楚客户是否喜欢，因而能够先开放给山东的客户，当HTTP头里面有来自山东的字段，则访问B系统，其余客户仍是访问A系统，这个时候能够看山东的客户是否都喜欢，若是都喜欢，就推向全国，若是不喜欢，就撤下来。

场景六：互联网场景下的预发测试

这个也是互联网场景下常常遇到的预发测试，虽然咱们在测试环境里面测试了不少轮，可是因为线上场景更加复杂，有时候须要使用线上真实数据进行测试，这个时候能够在线上的正式环境旁边部署一套预发环境，使用API网关将真实的请求流量，镜像一部分到预发环境，若是预发环境可以正确处理真实流量，再上线就放心多了。

场景七：互联网场景下的性能压测

互联网场景下要作线上真实的性能压测，才能知道整个系统真正的瓶颈点。可是性能压测的数据不能进真实的数据库，于是须要进入影子库，性能压测的流量，也须要有特殊的标记放在HTTP头里面，让通过的业务系统知道这是压测数据，不进入真实的数据库。

这个特殊的标记要在API网关上添加，可是因为不一样的压测系统要求不同，于是须要API网关有定制路由插件功能，能够随意添加本身的字段到HTTP头里面，和压测系统配合。

场景八：微服务场景下的熔断，限流，降级

微服务场景下，大促的时候，须要进行熔断，限流，降级。这个在API网关上能够作，将超过压测值的流量，经过限流，拦在系统外面，从而保证尽可能的流量，可以下单成功。

在服务之间，也能够经过微服务框架，进行熔断，限流，降级。Dubbo对于服务的控制在接口层面，SpringCloud对于服务的管理在实例层面，这两个粒度不一样的客户选择不同，都用Dubbo粒度太细，都用SpringCloud粒度太粗，因此须要能够灵活配置。

场景九：微服务场景下的精细化流量管理。

在互联网场景下，常常须要对于流量进行精细化的管理，能够根据HTTP Header里面的参数进行分流，例如VIP用户访问一个服务，非VIP用户访问另外一个服务，这样能够对高收入的用户推荐更加精品的产品，增长连带率。