传统企业微服务落地大法（4）-真正的微服务化阶段

第三个阶段就是真正的微服务化了，也有三大特征：

(坦白来说，传统企业到这个程度难于登天，不仅仅需要完全独立的IT公司，比较独立的IT文化，还要能走向市场，变成真正的利润中心)

组织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保障。容器平台也是云平台的一部分，并且基于容器提供持续集成，持续部署的工具链。

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

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

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