2．微服务化改造

做改造一般要经历三个步骤：

第一、技术选型决策

第二、架构设计规划

第三、落地实施应用。

下面依次展开三个部分，重点介绍前两个步骤，有了这两个，落地应用也就顺水推舟的好做了。

2.1 技术选型决策

2.1.1 选择微服务化方式

选择服务化，众所周知就是SOA嘛，这是一种架构风格，重点在原则、理念、方法论等高思维层次上，对于工具、框架、解决方案没有做强制限制，ESB、websercie（基于WSDL和SOAP/BPEL）这两种是企业中流行的，也是过去一直引领SOA的技术领头羊，但是随着互联网应用的发展，在敏捷快速迭代、高可用、高性能、高并发等方面要求越来越高，传统的SOA并不适合这种场景。那么，现在的互联网流行的实现方式是什么呢？一种最佳的实践方式就是微服务化，见图1（Micro Service）。

微服务就是一种SOA的实现方式而已，更加侧重于在服务的细分演化，是指引服务的具体落地方案层面的一种实践方式。过去很多互联网公司在实践，你可以把淘宝的dubbo、HSF, navi-rpc服务化框架看做比传统SOA更适用、更贴近微服务化实现的服务化框架，依赖这些框架可以方便的做服务化。这个趋势被Martin Flower大神所发现，并且提出了，你们这些不都是在做“微服务”嘛。

Martin对微服务这个术语（terminology）的解释是：

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

简而言之，微服务化就是以一系列小的服务来开发支撑一个应用的方法论，服务独立在自己的进程中，通过轻量级通信机制交互（通常是走HTTP协议）。这些服务是围绕着业务上的组织结构来构建的，全自动的、独立部署。几乎看不到中心化的服务管理基础设施，可以使用不同的编程语言和数据存储技术来实现不同的服务。

在简单的一种理解来自于一本书《Building Microservices》（Sam Newman, O'Reilly Media）, Microservices are small, autonomous services that work together．微服务化就是一堆小而自治的服务，让他们一起工作起来。

相比于传统的SOA, Martin的总结特点可以参考他的博客还有视频（Youtube链接），一共是9个特点，这里不想赘述，而是说说我个人的理解，微服务化的特点下面详述。

1、模块即服务

微服务中的组件在逻辑或者物理层次更趋于细分，这个细分不是极致的，而是一种粒度适中的选择，通常这些组件在前期可以是一些模块，但是当需要时，例如业务上需要拆分独立，或者非功能需求上需要扩容等，都可以灵活的拆解出来。这个特点非常重要，因为业务系统中模块化实践，随着软件规模的变大，很容易绕过障碍而使得不同模块耦合、依赖关系复杂，这种纪律性很难保证，从而削弱模块化的结构、降低了团队的生产力（敏捷开发和持续交付越来越难做，部署起来太庞大了大家的开发士气不高，而且痛苦），很快的这个模块就会变成一个大杂烩，而服务可以做到天然的壁垒，仅仅通过交换契约（通常是API或者proto）来做交互，这是一个演化的过程，不仅有利于分而治之，到达复用的目的，同时老系统也可以灰度的改造剥离。

2、独立自治

这意味着服务是独立开发，独立测试，独立发布，独立部署，独立运维的，某个细分团队负责整个生命周期管理，这就是“康威定律”的通俗解释，官方解释是“一个组织的设计成果，其结构往往对应于这个组织中的沟通结构”，服务的规划不就是多人、跨团队协作的沟通模式嘛。好处在于摒弃原来的火车模型（所有模块一起发布部署），拥抱独立快跑，这也更好的支持了敏捷和持续集成的方法实践。同时去除了牵一发而动全身的问题，单一职责的来进行修改需求或者重构一个点，开发和构建方便，不影响整个产品的功能，一个bug不会crash掉整个产品，针对不同的类型，区分计算密集型还是I/O密集型，区分业务上更好使用关系型还是NoSQL，区分2/8原则、即80%经常修改的服务独立出来自成一家，区分短板功能、针对瓶颈可以做水平扩展、避免资源竞争，甚至可以区分技术栈、突破语言限制。最后，这也是和第一点遥相呼应的，独立的服务可以实现非常大程度上的复用，服务之间依赖轻量级的接口，而不是模块。

3、去中心化的数据管理

在单体模式中，一个应用面对一套数据库，数据库可以按照物理拆分，进行shard分区，或者按照逻辑库隔离，不同的业务路由到不同的库，同时做一主多从等结构上的设计，这些原则在微服务中仍然适用，只不过微服务在服务拆分的同时，也需要将数据库分离，独立的服务维护独立的数据库，这对数据库也是减负，同时技术选型、SLA保证都会区分开来，把精力留给那些重要的业务数据库，进行分级的对待，而不能像以前一样一视同仁，一个不重要的逻辑库的bad SQL慢查询，阻塞了其他正常的查询，这是完全可以避免的。

4、轻量级的通信协议

传统的SOA使用ESB或者Webservice这种重量级的解决方案，微服务推荐使用一些更轻的解决方案，要通用性，可以用Restful架构，走HTTP通道，支持Json序列化协议；要高性能，可以考虑一些高性能的I/O模型，例如epoll、Actor等，可以直接走tcp通道，使用protobuf序列化协议，同时保持长连接（这里有一个例子Navi-pbrpc就是一个这样的具体落地框架）；要异步，用可靠持久的RabbitMQ或者高性能的ZeroMQ来做P2P、Pub/Sub、广播broadcast消息通信。而这种轻量级还需要体现在代码调用中，模块化直接通过函数、方法调用即可，服务化后能不能在API层面做到无侵入，无缝的切换、简单配置，这些都是服务化框架要支持的。

5、为失败设计

服务化调用从进程内in-process的调用，转变为跨进程的分布式调用，这种由分布式特性引起的天然不可靠性，需要变为相对可控。也就是服务间的通信要假设不会成功，为失败处理。异常的传递，能否透过RPC，在调用方本地还原，就像函数、方法调用一样？一个点、或者服务的处理错误率到了一个阈值，为了不影响整个产品，要做错误隔离，可以考虑熔断（circut break）、舱壁隔离模式、限流、回退等手段，最后还有一个幂等性问题，重试的调用会不会对业务造成影响，这个要具体问题具体分析了。

6、基础交付设施自动化

这个特点是整个微服务中的最大亮点，包括持续集成CI、持续交付CD和PaaS平台的结合。微服务在细分的背景下，在project结构，物理结构上都提高了一个复杂度，如果还要做到提高软件交付链路的整体效率，就需要在基础交付上做一个大的转变，因此DevOps文化，让每个人都参与交付，在规范的流程和标准的交付（例如，标准的容器）下，同时在PaaS服务提供商的帮助下，完成一个服务的自动部署发布。

任何事情都是两面的，有好的优点，当然会存在弊端，微服务的缺点我的理解如下：

1．分布式调用造成的性能、延迟问题。（可以采取的措施包括粒度适中、批量、高性能RPC、异步通信等）

2．可靠性不好保证。（刚才提到的为失败设计可以解决）

3．数据一致性难以保证。（看各自的业务，确保最终一致性即可，实际上大多数互联网产品很少不用事务；但是我目前所工作的商业产品领域，是需要事务的，除了不推荐的两段式提交，还可以引入仲裁者、补偿措施来解决分布式事务问题，问题可以单独开一篇文章介绍了，这里就不展开了。）

4．整体复杂度提升。服务多、依赖多、调用多、契约如何管理、监控如何做，调用链上怎么确定哪个点有问题，服务的SLA保障、性能、错误率、告警、这么多服务如何集成测试、交付容器如何上线等等问题。（通过服务治理可以有效降低微服务化复杂造成的低效，转为推动工程生产力的高效进化，同时基础交付设施的自动化可以加速研发效率，选择了微服务就等于选择了成本优先战略，投入的成本都是为了未来业务的更好发展，避免J-curve曲线式的研发模式，只有在体量大，基础设施包括服务化框架、治理能力完善的基础上，加上流程、规范以及工具和技能的辅助下，才可以真正发挥服务化的威力，否则只有自讨苦吃）

2.1.2 微服务化框架和治理模型

架构方式、原则达成了共识，你再往下看。虚的说完了来点干货，来介绍下我所在team实践的微服务化，最核心的就是微服务化框架，业界流行的阿里的框架dubbo以及淘宝内部的HSF, Navi-rpc都可以看做微服务化框架的雏形，加上服务治理中心的管理、基础交付设施的保障就可以构成完整的一套微服务框架。我们的框架（暂时仅内部使用）整体架构如下图，他由服务发布者、调用者和治理中心三者组成，属于标准的协调者模式（见图2）。

生产者中服务逻辑在Spring或者Guice等IoC框架的bean中，由IoC容器托管，为了符合模块即服务的思想，在框架层级实现了一套可插拔组件的引擎，去实现组件的扫描，需要暴露服务的发布出来，依赖别的服务的，通过字节码技术生成Rpc调用代理Stub，形成了一个基于组件的容器，通过JSR315这个规范的SPI实现对接到J2EE容器，下面的消费者结构相同。

在服务启动后，首先会第一步注册自己到服务治理中心，上传自己的契约、版本上去，治理中心如果通过检查就发布出去，之后和治理中心通过长连接协议（我们采用websocket，因为现成、简单）做一个订阅发布的通道，可以供收集状态，推送服务Endpint的变更；服务消费者可以去治理中心或者Maven仓库获取契约、SDK，治理中心推送Endpoint下来，供路由进行Rpc调用，通过消费者也通过长连接协议来进行状态和统计信息的上报，供治理中心进行分析决策和反馈。

服务治理中心为了保证高可用性，通常使用Zookeeper这个流行的开源的基于Paxos的方案，当然最近渐渐流行起来的kebernetes的etcd是基于Raft的集群共享数据、也可以做服务的发现的解决方案。

随着这种分布式调用越来越频繁，就需要服务治理能力越来越强，否则就是一张混乱的、无序的Rpc调用的网，无法管理复杂度。

这里建立了服务治理的模型，在下图中的服务治理中心来实现，模型从这样几个角度来考虑如何治理服务，包括通信、契约、版本、监控、安全、交付等角度，依托服务治理中心，有了这套基础设施保驾护航，服务化就可以真正做到提高研发效率、提供优雅的开发体验（见图3）。

在基础交付设施自动化上，如下图所示，体现在自动化、容器化交付这个流程中，在平台化的背景下把团队思维转换为DevOps式的，依托Docker和k8s完成了PaaS平台的对接，同时和QA一起协作完成持续交付流程的建立（见图4）。

2.2 架构设计规划

这里所指的架构，特指组织、服务的架构设计，非部署和代码架构。

下面我要介绍的，都是扣题，是已有系统的服务化改造，是一个已经存在的、复杂的、体量大的业务系统。

做架构设计规划，主要分为步骤：

1．整体架构设计

2．业务领域抽象、建模

3．服务规划与层次划分

4．服务内流程、数据、契约（接口）定义和技术选型。

这里主要介绍前三个步骤，第四个偏向于个例，同时需要强结合业务需求、特点分析解决，这里不做详细展开。

2.2.1 整体架构设计

还记得文章开说所说的单体模型吗？在一个复杂的、规模大的业务系统中，使用微服务化方式实现，就需要从上到下的来做整体架构，下面这张图是我所在的商业产品的业务端到检索端的架构图（见图5）。

共分为5个层次。

第一层，模块化组装，是各个投放产品的门面，各个投放产品可以通过搭积木式的方式，组装下层服务，就可以完成一个面向用户的功能，最常见的SpringMVC技术、Java设计模式中的facade模式就属于应用到这一层的一些点。

第二层，计算服务层，服务化也就是在这个层次上展开的，每一个小圆圈都是一个微服务，这是整个服务化的核心，各个服务圈出来的都是一个个服务簇，比如投放管理一个簇，报告报表一个簇。

第三层，数据存储层，会针对各个业务拆分，按照物理库或者逻辑库进行隔离。

第四层，广告传输层，将多shard的MySQL写入的广告增量实时传输到检索端，形成一条增量流（incremental data stream），我们通过模拟为MySQL的一个从库来捕获解析binlog实现，将binlog增量映射为语言级别的抽象类型，供下游使用，下面一层就是一个数据接收方，其他的还包括一些MQ订阅方（如导入kafka、RMQ、ZeorMQ等）, HDFS存储等，这样就形成了业务系统的数据快速、高效、实时传输的目的。

第五层，检索端。是广告投放系统的核心，根据媒体环境、用户特征匹配最佳的广告，进行创意的投放，你所看到了图片、H5、flash广告都是这套系统响应的，可以做到千人前面，最佳化广告主ROI与用户体验的折衷。

2.2.2 业务领域抽象建模

技术是为业务服务的，没有了业务，纯粹的讲技术都是纸上谈兵，解决问题是所有技术的出发点，微服务化也不例外。服务于业务，就需要对业务有深刻的理解，技术才能形成良好的输出。

有了前一步的整体架构规划，下一步就是计算服务层中的微服务如何规划的问题，这部分最为复杂，需要深入到产品业务中。拍脑袋规划当然可以，这叫做经验直觉主义，我认为经验主义缺少规范化的表达和标准化的设计，面对未来的修改需求，其架构的生命力不会很强。所应该站在更高的视角上尝试解决，首先就是要规范化需求表达，下图就是一个投放实施的表达，使用巴克斯范式（BNF范式）表达，将投放实施分为受众、媒体、场景等定向的选择，每种定向又分为多个约束条件，逐层深入，这个规范是所有已有产品的萃取，在新产品的打造中需要遵守的，一般会和产品经理一起打造。（见图6）

然后各个投放产品进行的功能矩阵划分的标准化设计，以这些为基础，就可以有理有据的进行服务规划，抽象分解出来的服务域高内聚，职责非常清晰，服务内的实体也是建模的，如图7所示，每个包都是一个微服务。

2.2.3 服务规划与层次划分

基于对业务的抽象分解，在计算服务层内部，就可以进行更加细分的层次规划，先是垂直拆分为展现层、计算层、数据资源3大纵层，核心的计算层又细分为3个层次，包括业务流程处理层，通过组装下层服务完成功能；业务逻辑组件是自包含，跨产品线、高度复用的组件；下面公共服务组件是一些通用服务。然后水平划分为多个服务簇。如图8所示。

按照之前的服务规划，将各个微服务安置其中，最上层的Web-UI和API服务负责和前端以及客户端（安卓或者iOS）API打交道，中间例如推广管理作为一个业务流程处理组件的工作流，可以调用下面的微服务进行组织，完成一个投放流程的业务场景。所有这些服务都是通过分布式服务化框架来进行通信、治理的。

2.3 落地实施应用

下面是一个已有产品改造的案例，比如一个报表服务簇，过去是一个大单体，现在按照服务化的架构，进行拆分，最为核心的就是中间这个sync-report服务，它从olap engine中查询数据，然后通过merge字面数据，提供排序，过滤，分页功能。围绕sync-report抽取了多个不同维度的缓存，保证了核心报表服务的高性能，同时上层，不管是Web-UI还是api，都复用sync-report，这样上层就会很薄，不用再管那些复杂的查询逻辑，sync-report作为标准、规范的技术解决方案，做到了统一复用与专职专用，加速了研发效率和交付。（图9）