1. 篇首语

业务系统是任何一个用户产品的必须组成，充当着一个门面的角色，用户的输入就是这个系统需要维护的，数据存取是整个系统的核心。例如，广告业务系统的输入是广告主的投放约束、定向条件，微博业务系统的输入是短文字、图片等。

 

在应用发展初期或者规模不大的情况下，有非常简单的实现方案，LNMP、JSP、PyWeb都是你能随口说出来的词，如果用某种架构方式来描述，那就可以称做单体模式（Monolithic，Martin Flower大神所提出的，后面还会介绍），而这些技术都是单体模式的成熟解决方案，它们可以使你工作在“应用层”的最顶端，各种中间件、框架能让你省心地干好业务，开发人员可以通过“模块化”的手段来管理业务系统的复杂度，使他们之间解耦、复用。简单来说，这个单体就是如下这种层次划分。

 

JAVA代码

表示层       前端（HTML+CSS+JS）                        

  |                   |

逻辑层     业务系统（PHP、Java、Python是常用的语言）         

  |                   |                               

数据层      数据库（MySQL）

 

看起来很简单，对吧。诚然，业务系统在这里面还需要做很多，比如缓存、SQL优化、数据分区、系统安全工作，当然还有对于代码的维护和重构。这种工作方式可以很好的工作几年、甚至十年，但是如果业务发展非常快，在系统复杂度、业务规模、参与人数、代码腐化程度都不断上升的情况下，你会发现整个项目正陷于泥潭，PM/RD/QA/OP经常抱怨：

 

---

"改个小功能，怎么要拉这么多模块？"

"拉模块也就罢了，改的地方多，编译太慢了。"

"慢也就算了，关键不知道怎么改，这代码太丑陋了，算了，为了满足PM的排期需要，凑合来吧。"

"凑合来了，QA发现bug，返工再返工，延期再延期。"

"上线了，oh my god，报case了，性能有问题，原来是依赖的模块访问数据库用了for循环select。"

---

 

透过现象看本质，我总结了来看就这三点问题：

 

1）业务逻辑复杂耦合，开发维护成本高。

系统复杂度、规模、参与人数都和腐化程度成正比，单纯的靠模块化，后期来看会存在个别模块成为”大怪物“，臃肿不堪，粒度过粗，难以复用。

 

2）交付效率和质量低。

在敏捷和持续集成方法论、实践大行其道的现今，迭代的按期交付率、单测覆盖率都不尽如人意，线上问题频发。

 

3）非功能需求不达标。

非功能需求指标特指性能、可用性、可扩展性等方面，代码的腐化和缺少维护、重构，以及没有代码洁癖的人污染下，必然导致性能逐渐下降，甚至出现不同资源竞争的短板效应，造成整个系统crash，同时一个大怪物的伸缩性较差，不能随意横向扩展某个细分功能点。

 

我想任何人做架构都需要秉承“业务需求决定技术演化路线”的思路，那么这些暴露出来的现状和问题都驱动系统去转型，在系统和人之间找到一种最佳的合作模式，匹配已有的生产力和生成关系。正如软件开发学泰斗Kent Beck所说的：

“Design is there to enable you to keep changing the software easily in the long term” ，即“变化发生时设计被破坏的程度”

 

放眼业界，面对复杂的、大规模的、多人协作完成的业务系统，如何管理好这个复杂度，有很多方法，模块化、OSGI、传统服务化SOA等等，当今最佳实践的趋势还是服务化。而微服务是最近火热起来的概念，有些人肯定觉得这不就是炒作嘛，但是不管黑猫白猫能抓耗子就是好猫，所以解决问题是重点，不要刻意去批评一些名字，那么本文要重点介绍的就是——如何做微服务化转型和改造。

 

在接下来讲之前，要重点声明，本文并不是推崇服务化，不鼓励单体模式，相反而是相当肯定和支持单体模式，它模块依赖简单、一个发布包、部署于一个容器都使得构建应用非常的简单，在体量还不大的情况下，首先应该解决的是搭建好一套绝对稳定的基于模块化的平台，待体量逐渐长大，再去根据实际需要进行拆分，团队也随之变化（facebook的单体持续了非常长的时间，一是人员素质高，二就是基础平台建设的非常好）。再下个阶段体量大到饱受单体模式之苦，也应该先建设平台化服务，建设好之后，先按照大的粒度进行拆分，逐步再微服务化，否则，直接上服务化、甚至下面要说的微服务都是非常危险的，鲜有成功案例。

 

2. 微服务化改造

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

第一、技术选型决策

第二、架构设计规划

第三、落地实施应用。

 

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

 

2.1 技术选型决策

 

2.1.1 选择微服务化方式

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

微服务就是一种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、独立自治

这意味着服务是独立开发，独立测试，独立发布，独立部署，独立运维的。某个细分团队负责整个生命周期管理，这就是”康威定律（Conway’s law）”的通俗解释，官方解释是“一个组织的设计成果，其结构往往对应于这个组织中的沟通结构”，服务的规划不就是多人、跨团队协作的沟通模式嘛。好处在于摒弃原来的火车模型（所有模块一起发布部署），拥抱独立快跑，这也更好的支持了敏捷和持续集成的方法实践。同时去除了牵一发而动全身的问题，单一职责的来进行修改需求或者重构一个点，开发和构建方便，不影响整个产品的功能，一个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服务负责和前端js以及客户端（安卓或者iOS）API打交道，中间例如推广管理作为一个业务流程处理组件的workflow，可以调用下面的微服务进行组织，完成一个投放流程的业务场景。所有这些服务都是通过分布式服务化框架来进行通信、治理的。

 

2.3 落地实施应用

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

3. 篇后语

本文所提倡的微服务，是结合作者所在team自身业务特点来说的，适合自身的场景，是建立在团队人员素质到了，有成熟的基础设施和框架、中间件辅助，流程也规范，包括CI、敏捷等，团队都做好了准确去做这个转变，有足够的能力来实施，微服务化也就是水到渠成的事了。相反，小团队在前期或者野蛮生长时期，不宜选择微服务，不但影响效率还带来额外的复杂度。成长型或者大公司，有成熟的流程、规范、基础设施、平台等，要想在整条交付链路上加速，就需要投入更多的资源保障微服务化，一切自动化了，能治理了，回头看来这一切就都是值得的，远期收益非常可观。

 

最后要说的是，架构只是标准、骨骼，对微服务的讨论不应该让我们忘记了更重要的问题，驱动软件项目成功和失败的重要因素。软因素如团队中人的素质，以及他们如何彼此合作、沟通，这都会对是否使用微服务有很大的影响。在纯技术层面上来讲，应该把重点放在干净的代码、完善到位的测试，并持续关注架构的演化进步，这才是一个软件工程师的根本职责。

——本文摘自infoQ《架构师》期刊201606期中《谈谈后端业务系统的微服务化改造》一文，作者：张旭。