技改之路：从单块应用到微服务,我的血泪总结

第一篇：技改之路：从单块应用到微服务,我的血泪总结

技改之路：从单块应用到微服务，我的血泪总结

2016-05-23张辉清技改是技术改造的简称，是技术的蜕变。本文指的是在公司技术发展的某个瓶颈阶段，按原有开发和组织方式已经无法玩下去，这时公司希望引进架构师或技术牛人，来破解当前困局。技术改造，对于公司和技术人员而言都非常难得，参与者多，主导者少。我有幸前后主导过3次OTA系统的技改，规模有大有小，每次环境和问题虽不一样，但还是有套路可循。《技改之路》少讲技术多讲路，我们不过多的关注技术细节和中间件的实现，而重点讲述技术改造的过程和思考，以下是本次分享的Topic： 系统背景 前期工作 技改实施 总结

一、系统背景 







1、技术规模 公司

 国内领先的B2B机票分销平台 资本原始积累，财务良好，一直盈利 系统规模 

 200+应用  100+库，1万+表 研发规模

 开发人员200人左右 服务器有200台左右

此案例是一个中等规模的电子商务公司，老板白手起家，资本原始积累，现在赚钱的互联网公司很少哦。公司从2006年的几个研发人员，到技改前的200个左右研发人员，业务发展良好，是国内领先的B2B机票分销平台，互联网名声虽不大，但处于闷声发大财的状态。

公司之前尝试过2次系统重建，请了一批批的牛人，前后经历过4年。公司消耗大，但都以失败告终。此案例是我本人的第2次技改，效果不错，整体进展顺利，团队技术水平也有1~2个档次的提升，算是比较成功的实践。另外，因为案例过于真实，有些UML会打上马赛克，请多谅解。

2、单块应用

3、主要问题 

 单块应用，该合并的没有合并，该拆开的没有拆开，单个体量不合理，主平台体量太大，其它又过小；

技术过旧：使用7年以前的技术，主平台采用单块应用，且体量过大，无法整体更新维护；   多版本共存：版本混乱，只敢添加，不敢修改； 整个系统非常脆弱，问题多，访问量一大就挂；

管理问题：发布困难、测试困难、修改困难、排错困难。

二、前期工作 



1、架构部组建 成立架构部：

内招几名老程序员，外招几个架构师 培养：

内部走出去，提高眼界；外部牛人请进来，落地了解历史和业务 制度：

项目管理+知识分享： JIRA+WIKI 团队建设、技术分享、工程师文化

2、总体规划

架构是演化出来的还是设计出来的？对于创业场景，创业本身就是在未知中寻找机会，将不清楚变为清楚，系统的架构自然是演化出来的，而对于技术改造或Google搜索等复杂工程场景，系统的架构当然要精心策划。





 公司电商系统总体架构，我们整整花了1个多月的时间，对项目做了总体的规划，然后对内宣讲推广，让每一个参与者了解自已的目标和价值。不手握地图，你怎知站对了位置！、中间件构建 我们构建的中间件有：

job/redis/center Log/业务监控metrics/dashboad/调试工具windbg/rabbitMQ/ORM工具dapper/MongoDB/jetermclient/公共类库jFX/zookeeper/openTSDB/HBase/searcher工具solr/元数据管理DDM/DLL管理nuget/自动发布Jenkins/微服务架构JSOA/ 中间件是应用系统的基础设施，是应用的装备和工具。农村建住房是一块砖一块砖的往上垒，城市建大house则是先打地基，然后再建主框架，最后才是垒砖，所以中间件的建设是大中型系统建设的前提。

以上中件间的构建过程贯穿于整个技改的生命周期，每一个中间件可能需要花1~2个月，它们大部分都基于开源。请关注上面的顺序，直面当前的问题，按需快速构建和推动。虽然使用开源，但中件间的引进和改造有自已的一套流程：调查 =>试用 =>选型 =>深入研究 => demo => wiki =>分享推广 =>业务系统试用 =>改进完善 =>大规模推广。

中间件的构建和增加，不仅对当前业务系统影响较小，还可以解决一部分业务难题，减轻数据库的压力。同时它还有利于建立技术氛围和分享机制。一支有激情、爱技术的研发团队，对技改的具体实施是非常重要的。

三、技改实施

1、数据库改造

当面对100个多库时，我认为系统架构师关注到数据库级别即可，建库拆库。数据库按模块整体迁移，其实并没有想象中那么难，理想情况下只需修改数据库的链接，而对于表和字段的优化，可由应用架构师或技术主管，以SOA收口或应用重构来实现。

数据库如何做到可伸缩，可大可小方便拆分呢，思考如下：

1.上图从内往外看，一个框即可以是一个库，也可以是一个模块，还可以是一个表，根据当前业务规模和系统复杂度来实现；

2.我们的大实体关系图具体为：产品、用户、订单、结算、基础设施。它们早期可以是一个库，里面有5个模块，中期可以分为5个库，后期则可以更底级别分为更多的库；

3.命名规范：数据库名：业务线缩写+库名；模块名：参考大E-R图+专业词汇缩写；表名：模块缩写+表名；自增编号：表名+ID； 4.模块内可多表联接，模块间减少联接，数据库间不允许联接；

5.每一个数据库有且仅有一个Owner组，原则上只允许一个团队才能Create，其它团队访问需要分级控制，L1为接口，L2为只读库，L3为直接读写“写库”。数据库规划

数据库是整个信息系统中生命周期最长、最难修改的部分。所以让时间来解决时间的问题，要加强设计，具体实施过程如下：

1.在地图即总体架构文档推广后，我们就新建立了一批库，这在早期还遭到DBA的抱怨；

2.新增相关库后，新表按新规则创建，特殊情况走特珠审批； 3.去SP去关联，让数据库减少计算，回归存储本质； 4.数据库拆分，改表改字段，采用模块整体迁移或应用重构；

5.一年后，再去看数据库，发现在没有特别立项和驱动的情况下，已接近一半的表在新库中。数据变迁

状态图是数据的变迁，是数据与行为的互动，数据的变化会引起行为的变化，行为的变化会产生数据的不同。上图是国内的订单状态变迁图，它的价值不仅属于数据库层，还在于SOA服务化和核心业务流程。

2、服务改造

服务是动词，是行为或活动的抽象，它的价值在于业务逻辑或行为的重用，具体实施过程如下：

1.服务列表和服务协议，在设计阶段使用Excel表格； 2.统一Request/Response规范； 3.服务实现，因没有直接可见的业务价值输出，最好以工单或项目来落地； 4.服务治理，早期没有工具时，使用WIKI做简单管理，后期使用专业的服务治理工具。领域模型

没有领域图的架构设计都是耍流氓，我们画领域图的架构师是2位老员工，没有多少高大上，甚至于他们之前没有画过UML，但我们的状态图和领域模型都是出自他们之手。其实画领域图的关键是懂事物本身，并知道它们的关系。我们的领域图与业务模型中的5大业务流程一一对应，包括：预订流程，订单处理流程，产品供应流程，财务结算流程，账户管理流程。微服务

我们的微服务JSOA V2.0是基于ServiceStack当时最新的版本号4.0.50实现的，它本身支持轻量级协议和Metadata，以及Swagger，是微服务的一种架构实现。另外，它还可以再扩展以API Gateway的方式实现Open API。

微服务MSA与我们之前的SOA、ESB有什么区别呢？ ESB有总线和聪明的管道管理能力；

SOA弱化了中间的管道和总线，强化了两端；

微服务MSA使用通用的轻量级协议和更加web化（RESTFUL）。





3、应用架构改造

系统是什么？系统=元素+关系。应用架构是什么？应用架构=应用+架构。应用就是系统的最小单元，应用分级和应用编号则构成了应用关系即应用的架构，它有利于应用的管理、交互和追踪。应用分为产品线，子系统和应用3级，每一级编号为2位，如100206。应用要从用户的视角出发，先有用户，然后有应用功能，这样才是以用户为中心去构建系统。

4、组织架构微调

组织架构没有最佳实践，只有适合于自已当前的选择，以下是组织架构与技术架构对齐方面的思考： 1.艺术与工程相关分离：UED； 2.软件开发与硬件相分离：运维； 3.技术研发与业务研发相分离：架构部；

4.需求，实施，验收相分离：每业务线分产品组、开发组、测试组； 5.开发按业务职责相分离：预订组、产品组、订单组；

6.专业技术委员会制：测试、产品、开发、轮流主持，设委员长；

四、总结

1、过程总结

第一步总体规划：手握地图，明确路线； 第二步数据库：建库拆库，去join去SP； 第三步中间件：按需构建，先增加常用； 第四步服务：技改=工单，有业务价值输出； 第五步应用：拆应用，建门户Portal，重构应用；

第六步组织架构微调：组架技术与组织架构对齐，技改之后调整； 第七步固化：框架化，自动化，管理过程工具化如DevOps。

2、经验感悟

 从服务入手是错的，从数据库或中间件入手是正确的。服务属于高级阶段，方便行为的重用，是深层次优化，但太慢了；

从当前问题或故障入手，要先灭火，逆向分析dump工具很重要； 历史要尊重，早期不可做大的改动，不能过多地影响现有业务。建议只做加法，建新库和新中间件，这样就不会有太多阻力和负担；

一般不能全部重建，除非系统较小，系统规模大时只能拆分后分步重构； 技术并不是技改过程中最复杂的，人和事及关系才是麻烦的部分，历史问题的后面是人；

每次环境和问题都不一样，要有准备脱一层皮的心态。

3、通盘无妙招

技改是大折腾，于公司于个人而言都是，小改怡情，大改伤身，我们应该避免大的技术改造，但此现象又比较常见，特别是业务发展快的创业公司。







 所以真正高手下棋，应该是通盘无妙招，让正确的事情很容易发生，基于自然的演化来实现技术的演进。

怎样才能通盘无妙招，系统良性长久的发展？我们需要两个力量，一个是技术，一个是业务，如果只重视业务，而很容易在技术上积劳成疾，如果完全技术驱动，则又容易忘记业务目标。所以它们应该相伴相生，共同发展，在大的技术改造实施之后，在框架和流程相对固化后，小的技术重构项目应该长期存在，这样才能良性循环，让系统进入自然演进的状态。

互动问答

问题：请问张老师如果再来一次技改你会怎么做？在你做过的技改过程中你觉得你最大的收获是什么？觉得做的不好的又是什么？

这个问题非常好，为了更好回答您的问题，我简单介绍一下本人的3次技改经历。我的第1次技改是重建，项目从10月份到第二年8月，历史10个月，可以说是技术成功项目失败。第2次技改是重构，只管技术，少管人和业务，整体效果好，可以归结为成功。第3次技改还是重构，既管技术又管人，且业务处于高速发展期，资源少，可以总结为技术与业务相伴相生，技术效果一般。

如果以后还有机会，自已就不再直接负责了，实在是太累，从内外各招几个架构师，并按上面的工作流程和方式，然后把握好技术与业务的关系和资源占用即可。回到具体问题：

如果再来一次，我会多参考第2次技改经验，即PPT分享的过程总结； 技改后的收获是脱胎换骨，技术和管理都有很大提升；    不好的地方：要更多的关注业务，以及平衡好业务与技术的关系。问题：单块应用向微服务迁移时，平滑过渡有什么技巧？如何解决分布式事务一致性呢？还有关于微服务持续交付、测试、监控（语义监控）方面有落地工具吗？

1.平滑过渡的技术：直面当前系统的问题，不断有价值输出，然后参考上面的过程总结，先规划，然后中间件和数据库，最后是服务和应用； 2.分布式事务一致性：使用替代方案，如最终一致； 3.落地工具：MSA与SOA的治理没有本质差别，还是DevOps/Trace/Metrics/，我们使用的是ServiceStack/JMetrics/CenterLog/Jenkins/。

问题：如果旧有模块关联复杂，又影响现有系统性能，相关开发人员流失，不好梳理，改造有风险，重写老板不答应，该如何取舍呢?

 旧有模块关联复杂，又影响现有系统性能：先灭火解决当前故障, 逆向分析dump工具；

相关开发人员流失：引进中件间，建立分享机制和学习型团队，讲技改总体规划，让每个人了解自已的价值和目标；

不好梳理，改造有风险：内招几个老员工成为应用架构师；

重写老板不答应：有业务价值输入，技改==工单或项目，借助业务项目来实现技改。

嘉宾介绍 



 张辉清，中青易游CTO，曾先后就职于广之旅、携程商旅架构、古大集团，在古大集团主导了从单块应用到微服务的技术改造，任首席架构师和高级技术总监，目前就职于中青实业下属公司中青易游，任职CTO。国家系统分析师和高级项目管理师，12年的互联网分布式系统研发和架构经验，10年的OTA旅游行业经历，是一枚技术爱好者和旅游爱好者。

你可以在这里找到作者

张辉清将在InfoQ组织的CNUTCon全球容器技术大会上详细剖析整个技改之路上的几个关键点，如果你的公司也在考虑从单体应用向微服务迁移，那一定不要错过。下面是CNUTCon微服务专题的介绍。

容器与微服务架构是近几年来开发者社区的技术热点，在与容器结合使用后，微服务架构的优点得到了进一步的放大。有很多的文章都在讨论微服务和单体式架构的区别，到现在，整个社区也开始理性起来，单体式架构和微服务架构并非相互替代的关系，单体式的架构更适合轻量级的简单应用，微服务架构相对复杂，对比起来，并不容易落地。

本专题不谈概念，只讲实践。比如企业如何使用Spring Boot框架构建微服务应用，从SOA转型微服务，有哪些难点和痛点，在此之前应该做好哪些准备等。简单来说，在内容策划上，微服务专题希望能和参会者分享微服务架构应该如何落地，更加偏重案例分享。点击阅读原文，了解详情。

第二篇：《从单体应用到微服务》读后感

《从单体应用到微服务》读后感

目标：共同学习、共同进步、告别码农，成为受人敬仰的、有态度的程序猿。拒绝不知其所以然的复制粘贴、拒绝人云亦云。用最严谨的态度、最专业的方法、最可靠的知识来源，探究技术内幕，死磕到底！！

内容简介

原书名字是《Monolith To Microservices》，是大神Sam Newman的新书，目前还没有中文版本。原本是想写一个简短的读后感的，但是写着写着，发现书中的内容真的是太经典了，浅尝辄止的描述完全不能体现本书的价值。于是就改成了用我自己的语言对书中每一章的内容进行了精炼。因此这个读后感也可以作为原书的精简版来看，只不过用的是我自己的语言总结的。也是由于这个原因，这篇文章越写字数越多，最后接近三万字，花费的时间也很多。为了便于阅读，分成4部分来发。

注：本文中的图片截自原书

第一章、微服务介绍

什么是微服务应用?

微服务是围绕一个业务领域建模的可独立部署的服务。通过网络彼此交互。微服务是一种SOA架构，并且它是技术不可知论的，即：微服务并不要求使用特定的技术。这点需要重点强强调下，因为很多人采用微服务都是技术驱动的，这种认识不是非常合适。微服务通过网络端点互相访问，这让微服务具有分布式系统的特点。下面罗列一些微服务的核心思想：

独立可部署性

这本书认为微服务最重要的特性就是独立可部署性。这要求微服务在部署自身的时候，不依赖任何其它服务。为了保证独立可部署性，因此需要服务之间松耦合、服务之间使用稳定的协议交互数据。

围绕一个业务领域建模

传统的单体应用中，我们最常用的架构是分层架构，如将系统分为展示层、业务层和数据层。根据康威定律：任何设计系统的组织，都会产生这样一个设计，即该设计的结构与该组织的沟通结构相一致。因此在分层架构中，不同技术角色的人员被分配在一起工作，如前端组、后端组和DBA组等。这是一种以技术视角设计的架构。在微服务中，则是围绕业务领域的，将一个大的业务领域划分成若干尽可能独立的子域，每个子域自己可以是分层架构的。根据康威逆定律，这样的架构势必也会影响到组织的沟通方式的变化。

拥有自己数据的所有权

微服务的核心思想之一是不使用共享的数据库，每个服务唯一的拥有自身数据的控制权。这可以让服务决定公开哪些数据和隐藏哪些数据。这进一步要求了微服务之间需要维护稳定的接口协议。对数据的控制会促进服务做到高内聚，而通过隐藏自身数据又可以促进服务间的松耦合。

微服务带来的优势

微服务带来的优势很多。天生的可独立部署性可以促进系统的伸缩性和鲁棒性，并且可以混合使用多种技术。通过服务和团队的划分，每个服务都是独立演进的，也就是说，所有的服务都可以并行开发，服务的开发团队也将专注于一个特定的业务领域，不受其它业务领域的影响。

虽然微服务带来了很多优势，但是这并不代表可以免费的使用微服务。另一方面，微服务的优势中，针对某个方面可能还有其它替代方面，而并非只能使用微服务来获得。因此在应用微服务架构时，非常重要的一点是需要明确自身想从微服务中获得哪些好处。

微服务带来的问题

计算机的价格越来越低，这让SOA架构广泛的被应用。使用SOA可以将系统分布在多台计算机上。但这带来的挑战是服务之间的网络通信问题。网络连接是不稳定的，尤其是考虑延迟的时候，延迟会让整个系统变得不可预测，除此之外，还需要额外处理网络错误的情况。分布式的部署结构会让一切变得复杂起来。某种意义上说，单体应用也存在一些分布式的场景，例如：数据库在一台服务器上，另一台服务器上的程序从数据库服务器读取数据，而客户端使用一台电脑访问程序获取数据。在这个场景中已经出现了3台电脑间的网络通信。单体应用和微服务在分布式上的差别主要在分布的程度上，微服务会使用更多的主机、更多的网络通信。开始的时候，微服务的规模较小，问题可能看起来并不十分严重，但随着微服务规模的逐渐增多，出现问题的频率和难度也会逐步上升。为了解决微服务带来的分布式问题，将会花费很多的真金白银。这也是在打算使用微服务架构时需要考虑的一点：是否值得?

用户界面

使用微服务架构的一个误区是只对服务端程序进行微服务架构，而依然采用单体应用来作为展示层提供UI访问。单体的展示层使得从用户视角来看，服务无法独立的发布，这是不正确的。根据上面围绕业务领域建模中讲述的，每个微服务都应该负责自身业务领域的所有分层，包括：UI层、业务层和数据层。因此在用户界面上也应和微服务的拆分保持一致。这可能需要一些专门的技术来实现，如：微前端。

技术

微服务是一个技术不可知论的架构，因此，如何实现微服务并没有技术上的要求。只要服务间基于网络可以互相通信就可以了，不必使用K8S、Docker、公有云等也可以实现微服务。在编程语言上也可以使用任何一种语言进行实现。但是微服务是非常复杂的，主要是因为它带来的分布式问题，这些问题可能是之前使用单体应用从来没遇到过的问题。因此，不应盲目的跟风新技术，应该使用自己最熟悉的技术来实现微服务应用。

大小

微服务应该有多大，这应该是最常被讨论的问题。要解答这个问题，首先需要定义大小的衡量标准。常用的衡量标准如代码行数，但这在微服务中是没有意义的，因为微服务是技术不可知论的，而使用不同的编程语言实现同样的逻辑，代码行数差别是非常大的。书中引述了一位微服务专家对微服务大小的建议是：“尽可能小的接口”。实际上，微服务的大小在不同的上下文和人群中的感受是不一样的，因此不必过于纠结微服务大小的问题。在考虑大小的时候，最应该考虑的是以下两个问题：1）你可以处理多少个服务。随着服务的增多，系统也会变得更加复杂，需要团队学习更多的知识来应对；2）服务的边界如何定义。不合适的边界划分最终可能会导致恐怖的耦合混乱。

所有权

传统的IT企业采用职能型的组织架构，软件的生命周期分别由不同的部门负责，如需求部门负责采集用户需求，开发部门收到需求部门输出的需求文档后进行软件开发。这种方式如下图所示：

图片

现在越来越多的企业将组织方式调整为矩阵型，提高沟通效率，加快开发速度。而微服务架构是围绕业务领域建模的，这非常适合矩阵型组织的沟通方式。组织可以使用微服务所代表的业务领域对组织进行划分，根据微服务的特性，团队之间也会减少跨团队的共享、最小化发布时的竞争。如下图所示：

单体应用

什么是单体应用呢?单体应用的特征是系统的所有功能共同组成一个唯一的部署单元。通常单体应用分为三类：

单进程单体应用

模块化的单体应用

分布式的单体应用：分布式的单体应用由多个服务组成，但是这些服务必须同时部署。这种方式拥有分布式系统和单体系统的所有缺点，并且对于单纯的分布式系统和单体系统而言没有任何优势。所有的服务都混乱的耦合在一起。一个服务的变更就可能导致系统不可用。

第三方黑盒系统：我们可以将第三方的系统都视为单体应用。

单体系统的挑战

单体应用由于实现和部署耦合，更加的脆弱。如果有很多人在一起工作，可能会引发混乱。一些开发人员可能同时修改同一段代码，团队之间的工作互相依赖。微服务提供的概念边界会更加容易地解决这些问题。

单体系统的优势

单体应用的部署拓扑比分布式系统简单的多，这样会让开发流程更加简单；并且在监控、排错和系统测试方面也要简单许多；单体系统内部的代码可以更简单的复用，这在微服务中，可能意味着代码拷贝或者共享代码等权衡。很多人将单体系统视作老土的架构，视为应该被抛弃的架构，这是绝对是不正确的观点。

内聚和耦合内聚的目的是将相关的代码放在一起，一起应对变更；而耦合则表示对一个部分的修改会对其它部分造成影响。高内聚、低耦合会让架构保持稳定。单体应用通常是高耦合、低内聚的，各种不相关的代码都耦合在一起。当需要代码调整的时候，通常很困难。同时，松耦合在单体应用中实际并不存在，因为任何变动都需要将整个应用一起打包部署。在微服务中，如果要想做的松耦合，一方面是保证自身的修改不需要改变其它部分，另一方面是保证接口的稳定。

我们需要谨慎的考虑系统中的耦合，耦合可分为以下4类：

实现耦合：这是一种危害最大的耦合类型，但通常比较容易处理。例如A服务的实现依赖于B服务如何实现，当B服务需要修改时，A服务需要同时修改。典型的例子是共享数据库，当A和B共享同一个数据库时，A对数据库的变更会直接影响B。

临时耦合：这种耦合发生在运行时，一般发生在分布式环境中的同步调用时。例如A服务要同步地调用B服务获取信息，而B服务此时又需要同步地调用C服务，这就构成一个临时耦合。这里问题是，请求若要成功，这三个服务必须都正常运行并且可以相互调用。解决时可以考虑使用缓存或者异步消息。

部署耦合：不管代码是不是模块化的，如果在发布的时候需要打成一个包统一部署，这时就是部署耦合。部署耦合带来的问题一方面是需要协调各个团队的发布计划，另一方面，每次部署都会有风险，越大的部署范围风险也会越大。并且少量的代码更容易实现自动发布。

领域耦合：每个微服务都处在一个领域限界上下文中，当它们之间的概念有交互时，就形成了领域耦合。例如服务A中需要理解服务B中的一个领域概念。实际上，服务A中所需要的概念可能与服务B中的不一样，例如仓库服务需要访问订单服务中的订单信息，实际上仓库服务需要的订单信息可能只是订单编号，它不需要理解订单服务中订单信息的全部业务概念。因此，仓库服务应该维护一个在自己限界上下文内的订单信息实体。

领域驱动设计

前面介绍了我们为什么要围绕业务领域建模。那么具体如何做呢?这就是领域驱动设计（DDD）解决的问题。DDD介绍了一系列的思想来在程序中表示问题域。设计微服务的重要概念有：

聚合：聚合是一个自包含的单元，表达了一个实际的业务概念。通常聚合拥有一个生命周期，这会让聚合的实现类似一个状态机。我们需要保证一个业务概念的状态转移完全被包含在一个聚合之中。一个微服务会处理一个或多个聚合的生命周期和数据存储。将一个系统划分成聚合可能需要考虑众多因素，例如：性能问题、实现的难易程度等。这也意味着聚合可能会对聚合进行重新划分。在实际中，事件风暴非常有用。

限界上下文：限界上下文通常代表了组织中的一个较大范围的边界。这个边界内有单一的职责。从实现角度来看，一个限界上下文中有一个或多个聚合。这些聚合中的一些可能会对外暴露，另一些则被内部隐藏。

将聚合和限界上下文映射成服务

聚合和限界上下文都提供了高内聚的单元，并且提供设计良好的接口。聚合涉及一个单一领域概念的自包含状态机，而限界上下文则代表一组相关的聚合。聚合和限界上下文都可以作为微服务的边界。考虑到初期尽量减少服务的数量，建议使用范围更大的限界上下文来作为微服务边界，熟悉后，可以进一步使用聚合拆分。

第二章、规划迁移

是否应该使用微服务?

微服务不应作为一个目标，使用微服务也不会让你获得胜利。采用微服务的决定一定是经过深思熟虑的。从单体应用迁移到微服务应用应该有充分的理由，例如获得当前单体应用不具备的能力。在考虑想微服务架构迁移之前，需要明确三个问题：

你希望从微服务中获得什么?

除了微服务，还有什么其它的解决方案?

你怎么衡量微服务带来的成效?

微服务不是免费的，它可能会引起组织系统性的变化，需要引入更多的运维组件，改变现有的开发方式等等。因此需要充分考虑ROI，以判断一个迁移是否值得。

微服务带来的好处主要有以下几点，但请注意，带来的这些好处大部分都可以通过其它方式获得。

提升团队自治性

非常多的企业证明了团队自治带来的好处。自治的团队通常不会很大，确保团队内成员彼此都非常熟悉，自治团队在一个较小的范围内工作。业界有一些关于团队规模的范例，如亚马逊的“两个披萨”模型。如果正确使用团队自治性，会激发团队成员成长并提升效率。当团队拥有微服务的全部控制权，就会提升团队在整个组织中的自治性。

自治性不是微服务独有的，有很多方式可以获得自治。团队的自治主要涉及分配给团队的职责，而与使用什么样的架构关系不大。比如可以通过将代码仓库中的一部分授权给一个团队来促进团队的自治。

加快上市时间

将变更的执行和部署聚焦到各自独立的微服务中，可以做到不用和其它服务协调发布时间，同时多个团队可以并行的处理待办任务列表，这让功能面世的时间大幅度加快。

当然，不使用微服务也可以做到加快上市时间。如“优化上线流程”等也会起到一定的效果。通过对现有上线流程的分析，判断是否可以通过调整任务执行的顺序，或者采用并行的方式来加快流程执行的速度。

为负载更有效的扩缩

每个微服务都可以独立的进行扩缩，这样会更加有效。因为我们只需要扩展对处理当前复杂有瓶颈的部分。当负载降低，可以对这部分再进行缩容。

如果不使用微服务，有很多方法可以应对负载升高的情况。最简单的就是使用配置更高的机器。另外，传统的通过多个单体应用的拷贝来进行水平扩展的方案也是非常有效的，虽然它对于数据库的瓶颈没有帮助。

提升鲁棒性

例如多租户的SaaS系统，这类系统对可用性的要求很高，一旦出现宕机，影响范围将会非常广泛。通过使用微服务，将一个系统根据功能解耦成若干个独立的服务，也就是说，当一个功能出现问题时，不会影响其它服务的功能。这里需要注意的是，微服务提供的鲁棒性不是免费的，并且由于服务部署在不同的机器上，这也会增加调用失败的风险。

如果不使用微服务，通过拷贝多个单体应用进行负载均衡也可以有效的提升系统的鲁棒性。另一方面，系统的不稳定通常都是人为的，如果系统存在很多人工的操作，则使用自动化的手段在很大程度上解决问题。

扩展开发人员的数量

《人月神话》中提到，只有将工作分割成互不影响的小块，才能够通过增加人数来加快发布进度。微服务通过明确的边界，限制了其自身的范围和对其它服务的依赖。因此可以支持大量的开发人员。仅仅使用微服务通常是不够的，还需要结合团队自治和服务所有权。

另一种不使用微服务的方法是实现模块化的单体应用，不同的团队拥有单体中的不同模块。只要它们对外暴露的接口是稳定的，那么就可以独自的演化。

拥抱新技术

单体应用限制了新技术的使用，因为通常它只使用一种开发语言，使用特定的部署平台、运维系统和一种数据库。而微服务中的每一个独立的服务都可以根据自身的特点进行技术选型。成熟的微服务组织通常会限制可使用的技术栈。

在这一点上，单体应用没有太好的办法。

什么时候不应该使用微服务?

在一些场景中是不适合使用微服务的，如下：

不了解的领域：服务边界如果划分有误，则带来的代价可能是非常高昂的，可能会导致服务间的高度耦合，则要比单体应用更加糟糕。如果对业务领域尚不了解，不应盲目的进行服务拆分，而是应该先学习领域知识。

初创系统：很多企业在系统初始阶段就会考虑使用微服务架构，但在实际实现时，都会先采用单体应用。微服务对于扩张来说是一个很好的选择，但在初始阶段，功能尚处于试验阶段，会根据用户的需求不断调整。一些功能可能会重写，另一些功能可能会删掉。另一方面，初始阶段的资金有限，应该将关注点放在产品本身上，单体应用易于开发和测试，部署拓扑也非常简单，相比微服务不需要花费太多的资源和精力。通常来说，一个已经存在的“棕域”系统相比一个新的“绿域”系统来说，更加容易拆分。

客户自己安装和管理的软件：如果软件打包后分发给客户自行安装和管理，那么不应该使用微服务。因为微服务的安装和运维非常复杂，客户可能没有安装和管理微服务架构应用的能力。

没有充分理由的情况下：这个前面也提到过，微服务作为一个分布式系统，使用起来将会面临非常多的挑战，因此，一定是在经过深思熟虑后，确定微服务带来的优点大于缺点时，才可以使用。

如何开始微服务?

要在组织中推广微服务，首先要做的是让其他人清楚的明白你希望从微服务中获得什么，当他们认同之后，要做的就是探讨如何实现。通常需要先引入一些成熟的模型来帮助组织变革。下面介绍John Kotter的“组织变革八步法”，整个过程如下图所示：

创建变革的紧迫感：组织中的好主意有很多，微服务可能只是其中之一。因此需要让大家明白现在就是实现微服务的最佳时机，要做到这点的最佳实践是结合当前组织中的实际场景，结合当前的痛点，而不是干巴巴的说：“我们要使用微服务”，任何时候，微服务都不是目标。

创建一个有足够力量的引导联盟：要推动一个变革，一个人是远远不够的。需要在组织中分辨哪些人可以帮助你，这些人可能是同事、领导或者其它部门的相关方，让这些人加入到你的队伍中，让他们成为推动变革的一份子。这可能涉及到包含IT岗位的任何岗位。

创建一个愿景和实现策略：愿景说明了你想从变更中获得什么，而策略则说明了你将如何实现变革。策略可能会不断调整，因此微服务不一定是唯一的方式。

推广变革愿景：宏大的愿景看起来很棒，但是在推广的时候没人会相信。因此可以在开始的时候分享一个小的愿景。在推广方式上，建议使用面对面的方式，其它方式可以结合使用。

赋予员工广泛的行动权力：当你完成了愿景的推广，大家都满怀激动的心情后，接下来会怎样呢?大家可能继续忙各自的工作。在使用微服务的时候围绕已存在的基础设施的流程可能是一个非常实际的问题。例如你需要发布一个新的服务，但是硬件采购的流程非常长。因此需要赋能员工，帮助他们扫清障碍，做他们该做的事情。

创建短期成效：如果实现的周期太长，人们可能会丧失对愿景的信心，因此需要将整个周期拆分成很多小的胜利。当使用微服务对功能解耦后，这可能更加容易实现。

巩固收益并产生更多变化：当取得一些小胜利后，要趁热打铁。对流程和策略进行继续的优化，寻找如何能够驱动变革继续进行。例如在微服务拆分后，接下来可能意味着对数据库的解耦。

将新方式融入文化：随着变革的深入，以及不断对成功或失败经验进行分享，团队会越来越熟悉新的工作方式，最终会形成组织特有的文化沉淀下来。

逐步迁移的重要性

逐步的迁移有助于在过程中学习微服务，当出现问题的时候，影响的范围也是有限的。把迁移分为多个小步骤，也可以帮助分析每一步的成果，总结每一步的经验教训。也有助于实现上文提到的快速的小胜利。当确定使用微服务的时候，可以先挑选一到两个业务领域，用微服务实现它们，并将它们发布到生产环境，然后观察它工作的怎样。这里列出一些逐步迁移的好处：

只有生产环境才算数：只有将拆分好的微服务发布到生产环境在表示这个服务实现完成。因为微服务解耦后会带来很多问题，如：排错、调用链、延迟、级联错误等。很多问题只有在生产环境中才能发现。如果做错了，逐步迁移会使你能够快速定位问题和回滚。

变更成本：在向微服务迁移时，会犯很多错误，逐步迁移不会减少犯错误的可能性，但是当错误发生，其造成的成本损失是可控的。

可逆和不可逆的决策：有些决策是不可逆的，这意味着一旦它开始执行，就再也无法回到起点了。这类决策需要非常谨慎的评估，运用方法论，长时间的论证。而另一类决策在执行后，如果发现不合适，可以回到初始的地方重新来过，这类决策可以快速指定，并且可以授权给个人或者小的团体。

更容易进行实验：调整代码的成本较低，有很多工具可以使用，但是调整数据库的成本就会非常高。高成本的变更的风险也会是很高的，因此最好的办法是进行一些小的实验来观察可能发生的问题，逐步迁移会让这些实验的影响范围是可控的。

领域驱动设计

接下来我们将讨论如何进行微服务的拆分，使用的思想是领域驱动设计。在使用领域驱动设计建立领域模型后，这个模型可以帮助我们定义服务边界，以及引导我们分辨实现服务的优先级。通过限界上下文之间的依赖关系，对其它限界上下文依赖越少的服务在实现的时候就会越容易，这些也是我们有限选择实现的。实际上，有一些方法可以帮助我们决策，如下：

打算走多远?

开始的时候，一下子要对系统的整体领域模型都进行分析，往往不知道如何入手，也会让人心生畏惧。其实，在将单体应用解耦的时候，只需要了解足够的关于从什么地方开始解耦的信息就够了。缺少全局的理解确实会带来一些风险，但是开始的时候并不是非常重要，因为开始的时候只需要获取如何进行下一步的信息就可以了，在解耦过程中需要不断结合新的领域只是对领域模型进行重新定义。

事件风暴

事件风暴可以帮助技术相关方和非技术相关方共同定义一个共享的领域模型。事件风暴是自下而上的，首先参与者一起定义领域事件——系统中真实发生的事件。然后用这些事件组成聚合，再将聚合组成限界上下文。事件风暴的输出不仅仅是领域模型，最终要的是对领域模型的一致性理解。因此需要相关方在一起工作，这是使用这个方法最大的挑战。

使用模型排序优先级

通过分析上下游服务的依赖关系，就可以明白哪些服务相对容易拆分，哪些会更加困难。这可以作为服务实现顺序的排序因素。但需要注意的是，领域模型表达了系统的逻辑概念，虽然从逻辑上看没有依赖，但可能在物理层面存在关系，因此仍然需要在进一步的从实现代码中分析是否存在依赖。另一个决定优先级的因素是业务本身，因为我们需要实现快速的成功，所以需要选择能够实现这个目标的恰当的业务。

模型分组

在实际选择要实现的服务时，大部分人可能会选择最容易解耦的部分，但我们的另一个关注点是取得快速的成功，这意味着我们应该选择能够为系统带来立竿见影效果的部分，而这些部分通常都是核心业务，可能并不容易拆分。这时我们可以按照难易程度和效果将候选服务进行分组，如下图所示：

X轴表示效果，越向右效果越明显。Y轴表示实现的难度，越向上越容易。显然，我们最终应该选择位于图的右上方的候选服务。有时候我们在实现的时候会发现，原本以为简单的服务实际实现起来很困难，反之亦然。这是很正常的，这也意味着需要重新对服务进行排序后选择新的服务进行实现。

重新组织团队

使架构和组织保持一致是充分发挥微服务架构优势的关键，但这在组织中通常并不容易。下面提出一些对此有帮助的想法：

转变结构

传统上，IT组织的结构是围绕核心能力的。例如Java开发人员在一起，测试人员在一起，DBA和其它DBA在一起。在开发系统的时候，每个只能团队中的人只完成系统生命周期中的一部分任务。这也导致过程中需要各个部门之间相互协调。在微服务的架构中，每个服务涉及多个软件层次，也会涉及多个职能。因此当今的组织开始向DevOps转变，测试人员不再是一个单独的部门，而是作为发布团队中的一员，和开发团队更紧密的合作。通过将不同职能的人员放在一个发布团队中，授予他们足够的权限，这可以促进他们为服务的发布提供各种帮助。

没有范式

组织方式没有一个范式可以适合所有企业，它会收到企业环境、工作文化以及具体的人的影响。因此，盲目拷贝别的企业的组织方式是很危险的。其它企业的成功经验可以用来参考，但是要清楚它可能不会在你的场景中成功。

做出一个改变

如果你不能拷贝其它企业的组织结构，那应该怎么做呢?首先可以先罗列日常涉及的工作和流程，然后将它们和当前企业的组织结构映射起来。然后分析哪些职能需要跨越组织结构来工作，结合愿景重新绘制一个理想的结构图。将两个图进行对比，然后规划迁移方案。

改变技能

从单体向微服务迁移，需要对组织中原有的能力进行更新。一个有效的方法是，首先罗列出所有需要的能力，然后让员工对自己进行评价，评估自己当前的能力。这里需要重点强调的是，自我评价是非公开的，只是用于他们的导师了解每个人的特点。然后根据员工的兴趣爱好针对性的进行培训。改变现有人员的技能只是一个方面，如果追求短期成效，可以在团队中增加拥有该技能的专业人员。

怎么衡量迁移是否成功?

如果没有衡量成功的标准，那么迁移将永无止境。在向微服务迁移时，即便做好完全的准备，也会犯错。那么怎么才能知道迁移工作起作用了呢?基于希望获得的成效，应该指定一些可追踪的指标来回答这个问题。然后设置一些检查点，每到达一个检查点，就检视一下方向是否正确，使用指标衡量是否起到预期的作用，并且分析是否应该尝试其它方式。下面是一些建议：

设置定期的检查点

任何一个迁移，都需要设置定期的检查点，在迁移过程中停下来看看是否正确实现。检查点可以是正式的也可以是非正式的，内容包括：1）重申希望从微服务中获得什么；2）审查定量的指标；3）接受定性的反馈——大家是否觉得做了正确的事情；4）确定今后的改进方向。

定量衡量

定量的指标可以直观的反映出迁移的情况。例如：部署的次数、失败率等。但是要注意数据的时效性，过期的数据可能会造成错误的决策。一些指标可能在短期内没有变化，甚至会变得更糟，这更加需要逐步的实施迁移。

定性衡量

无论定量分析的数据如何，都应该关注于当事人的感受，他们是否享受这个过程是非常重要的。如果大家的感受是负面的，应该立即做出调整。

避免沉没成本谬误

沉默成本谬误发生在，当人们为之前的方法投入了非常多后，即使已经有证据显示这个方法行不通，但因为已经投入了很多，仍然继续执行。有时情况可能因为坚持而最终得到改善，但另一些时候只是在浪费资源。通常，下注越大，越难以回头。这又是一个逐步迁移的好处。

开启新的方式

在迁移的时候，有多种选项和路径。对每一种方式而言，都不会完全平滑，因此可能会在使用一个方式后发现这种方式并不是最好的，然后更换另一个方式实现。建议尝试将这种变化融入到文化之中，采用这种不断进取的文化，敢于尝试新的东西，那么在需要更改方向的时候会变得更加自然。

总结

这一章介绍了为什么需要使用微服务架构，以及哪些因素可以用来对实现顺序进行排序。当企业在决策是否需要向微服务迁移时，需要回答三个问题：

希望从微服务中获得什么?

是否考虑过微服务之外的其它替代方案?

怎么衡量迁移起到了成效?

迁移过程可能会花费很长的时间，但实际工作中，客户不会给我们这么多的时间。迁移只有在发布到生产环境后才能表示一个阶段的结束。这就需要一系列的技术手段来让微服务应用和单体应用协同工作。接下来的内容就会对这些技术进行介绍。