概述

系统规模扩张导致单体服务面临一系列问题，从需求，到研发，部署，测试，运行 过大的规模导致系统进化越来越慢，对系统进行服务化拆分用于解决这一系列问题，服务化拆分本身又带来一些棘手的问题要处理，妥善处理这些问题才能发挥好服务化的优势。

微服务是系统功能庞大后的一种管理手段

1：单体服务遇到的问题

本质：规模变大后需要拆分，才能方便更大粒度的组织。

具体问题

1.1 从软件过程看

软件过程：

    需求->研发->打包->测试->测试->部署>运行

1：需求

多个模块都会有变更的需求，落实到项目上就是需求变更更频繁，会出现很多并行的需求，但研发进度及需要对时间点的要求不一，又不能在相同版本上进行。上线又是整体一套程序，版本间必须是串行的，导致进度相互拉扯现象。版本问题很难处理。

2: 研发

代码结构难按模块清晰分离：整个项目在一起，代码的职责就容易存在模糊地带，出现重叠。或跨越层级的调用。

人员职能边界控制：研发人员都看到相同的代码，软性隔离会导致研发人员可能需要了解更多的不需要了解的细节，修改时可能修改到其职能范围外的地方（比如这块逻辑应该是其他人复杂的其他模块的，但被另一个需要的人直接完善或重复写了）



版本多导致代码合并多:

冲突多,bug修复也需要频繁的在多版本合并。

类似高并发的修改，很容易冲突，然后导致进度相互影响。

3: 编译打包

整个项目一起打包，导致打包慢，打包成果文件大，失败率高.

自己负责的部分修改了，统一打包可能是依赖的其他部分有问题导致打包失败。

4:部署与测试

测试：

为防止修改的影响越界，测试的范围也会扩大，测试工作量大。

部署：

单体部署必然是整体的升级,虽然只某一个功能调整，也需要全体升级。升级过程影响全部功能的使用，可能要各个研发线守候防止升级出现问题。

各个模块作为整体一起部署对依赖的资源会很多，包括数据库连接，缓存，硬件基础能力等，部署任何一个节点都需要很重的基础资源。

5：运行

运行时的资源与故障隔离实现困难，可能由于某一个模块的故障导致整体系统不能正常服务。

1.2 从人的角度

1: 出现一些非必要的沟通

或因为进度争抢或因为问题拉扯

2: 人员间职责边界模糊，重叠：

导致效率低下，一个事情负责人的人越多效率越低下

3: 学习熟悉成本高：

在一起导致分离的不够明晰，新人要熟悉的内容就多，入门成本高。

2：服务化解决单体问题

遇到问题的很大原因是规模过大项目挤在一起导致，对系统进行更大一级粒度的拆分，解决过于解耦问题。

比模块更大级别的粒度是独立的运行的程序（服务），因此对单体程序进程服务化拆分解决单体的耦合问题。

2.1 服务拆分方法

拆分的核心原则是解耦，因此拆分前提是程序合理的模块化

1：业务上是分离的，独立发展与变更

      垂直拆分的依据

2：代码上职责分层，对共同的功能依赖做水平拆分，提供公共服务给其他服务使用。避免代码职责重叠

      --服务分层

3：服务的粒度与团队规模匹配，一个服务的维护团队3到5个人可维护，一般不易过大。人的职责容易划分，冲突也少,沟通效率高。

2.2 服务相互调用

将一个程序拆分为多个独立运行程序后，本地的方法调用变为远程调用

1：RPC框架解决远程调用问题

      可以是HTTP或其他网络协议

2：服务注册与负载均衡

      调用的服务在哪里，负载均衡

2.3 服务治理



服务化拆分出现一些原来单体没有的问题

• 数据库事务失效

• 某个操作的处理日志跨越多个服务

• 服务依赖

• 服务版本兼容问题

• 配置分散

• 等

这些都不属于单个业务处理的问题，由统一的框架或平台解决--服务治理。

服务治理主要功能包括：

• 统一Api网关

• 服务注册发现，RPC框架

• 日志监控

• 日志链式追踪

• 服务监控

• 服务故障隔离与限流

• 服务调用重试

• 统一的认证授权

• 版本管理

• 配置中心

• 服务协议转换

2.4 服务的运维

如何管理数量众多的服务，包括打包，部署，扩展，监控等

打包部署与运维-容器与与云原生

打包

拆分为多个服务后，服务数量越多，打包频繁，需要自动化的打包，减少人工重复操作。

服务管理

• 服务依赖的基础环境的管理与隔离。

• 服务的快速部署，扩张-伸缩

• 隔离与重启

基础环境的管理与隔离从虚拟化，到容器化到容器编排。

主流：docker+k8s

 云原生：微服务，容器化，服务编排，服务网格，声明api 等

              可理解为微服务的整个运行工具生态，还未普及。



3：微服务实践

没有统一的方案适用所有组织的系统，根据系统及组织本身的规模，业务特点选择满足自己需要，可以解决问题的方案。解决问题的思想有相通性。

1：服务拆分

服务拆分是实践中难度最高的，也最个性化的，所有系统都要寻找自己的拆分粒度，职责划分的逻辑。同时可能还可能有遗留系统的接入。

先业务逻辑职责分离，后有服务拆分。并且可能随系统变更而调整。

领域驱动设计(DDD) 是比较热的一种服务划分的一种方法。可参考。

2：服务治理框架与RPC框架

服务拆分后服务的远程调用，根据系统现有状态，HTTP协议还是grpc,dubbo等考虑性能与现有系统的接入成本,扩展成本，特殊情况可以做协议转换服务。

服务治理框架：有开源的治理框架提供很多开箱即用的，但也会要求对现有系统做改造。同时服务治理本身会随业务发展要求更多的功能，有些是共性的，有些是自己个性的。

可关注开源上不断涌现的方案，在采用及改造开源方案与自研相结合。

3：容器化与服务编排到云原生

容器化与服务编排已经很普遍也相对成熟了，结合自动打包集成的相关设施，

云原生在服务数更多的时候，或差异比较多的时候可能才有必要。

4：服务网格

成熟度与易用性感觉都还待进一步发展。

如果微服务框架本身越来越复杂后，作为对业务开发人员屏蔽微服务基础组件的一种方案，会有必要。

或者不是全部服务都采用服务网格，而是对服务分层，在层间进行也网格调用隔。

即内聚性高的服务间不采用，而隔离较远的服务间用网格调用。 比服务更大粒度的一种抽象。

5：中台

多个业务线的共性服务或流程的支撑平台

多服务的再组织，避免不同业务线间的重复性工作。