简介

随着项目的不断发展，单体架构可能成为瓶颈。这时，向微服务架构迁移就成为一种必然选择。虽然微服务具有明显的优势，但由于其复杂性和缺乏通用迁移方案，实施过程可能会遇到挑战。

本文旨在分享解决方案架构师在单体架构向微服务迁移过程中的专业经验，并阐述如何在确保项目安全性和可靠性的前提下，成功完成迁移。

单体架构到微服务：迁移路线图

以下五个主要步骤将助你顺利完成单体架构向微服务的迁移：

第一步：技术与商业需求分析

• 评估当前系统的需求
• 制定高效的开发路线图
• 审查技术栈并考虑替代方案

第二步：识别适合迁移到微服务的系统组件

• 确定哪些组件适合作为微服务
• 设计微服务之间的交互方式
• 优先拆分业务逻辑清晰且独立的组件

第三步：单体架构到微服务的拆分策略

• 逐步剥离方法：从单体架构中逐步剥离特定功能，减少对其他组件的依赖性。
• 复制并替换方法：复制所需功能，将其开发为新的微服务，并在测试完成后从单体架构中移除原有功能。

第四步：数据管理策略

• 采用“数据库独享”模式，每个微服务拥有自己的数据库
• 根据数据模式选择不同的数据库和存储方案
• 管理数据的一致性和隔离

第五步：监控、测试和运维

• 建立健全的监控系统，监控微服务的性能和可用性
• 制定全面的测试策略，确保微服务之间的交互
• 设置自动部署和回滚流程，提高运维效率

最佳实践

• 从小的、低风险的组件开始迁移，逐步积累经验
• 采用“敏捷”开发方法，快速迭代和反馈
• 使用编排工具管理微服务的配置和部署
• 自动化测试和部署流程，提高效率和准确性
• 与团队成员建立清晰的沟通和协作机制

结论

单体架构向微服务迁移是一个复杂的过程，但通过遵循上述路线图和最佳实践，企业可以最大程度降低风险，提高迁移成功率。

微服务架构提供了可扩展性、灵活性和其他优势，但最重要的是要根据项目的特定需求和限制因素，对迁移过程进行仔细评估和规划。

架构师年薪，要成为软件架构师，应该看什么书，软件架？

互联网的发展带动了各行各业信息化的趋势，一大批高新企业如雨后春笋般出现在大众的视野中。于是，不同类型的软件项目应运而生。在这些琳琅满目的项目中，有企业管理、电商平台、财务报表、金融银行、医疗器械、智慧城市和大数据分析等类型。项目的层出不穷带来了巨大的利润，让高新企业不断地成长起来，与此同时，也带来了很多相关的就业岗位。

当然，要顺利地完成这些项目，就需要大量的软件工程师。这种硬性的需求又养活了一大批培训机构，从事软件行业的人员当初是凤毛麟角，现在依然是供不应求。那么，如何提高软件工程师的开发技能就成了一个无法回避的问题。诚然，公司可以不定期进行培训，提高开发人员的技能水平，但从更普遍、更直接的意义上来说，提高技能水平的最佳方式还是系统地阅读相关书籍。

计算机语言从机器语言、汇编语言发展到现在的高级语言，这个过程中诞生了很多种语言。有些语言已经逐步退出历史舞台，有些语言仍然在小众化的范围内存在。而Java语言，经历了二十多年的发展，仍然保持着旺盛的生命力，在编程语言排行榜中高居不下，Java程序员的数量也与日俱增，这种现象主要是由Java自身的优势决定的。作为开发人员，需要关注的并不是底层的核心，更多的是Java带给我们的简单、直观、易于使用的平台。因此，程序员不用关心虚拟机复杂的结构和每一步的运行情况，只需要关注项目业务的代码即可。这种易于接受的情形，让更多人把开发当成了一种乐趣。

最近，在业内流行起来的全栈工程师的定位更像是高级程序员，而架构师则需要站在更高的层面思考问题。作为Java架构师，不但要懂得前端插件化的开发理念，为项目选择合适的前端插件，还需要精通后端开发，为项目选择合适的框架，这样才能高效地完成任务。否则，极有可能出现事倍功半的情况。如果说需要弥补架构缺陷，最乐观的情况是通过加班实现，最糟糕的情况是直接导致项目失败。因为项目经理可能并不会深入了解具体的代码，他通常会参考架构师的意见，所以架构师的意见就显得极为重要。

《Spring微服务实战》

[美]约翰卡内尔（JohnCarnell）著

本书详细介绍了微服务架构下Spring体系（Spring->SpringBoot->SpringCloud），帮助Java开发人员快速拆分单体应用，并对微服务的全生命流程进行了封装，大大简化了开发流程。

本书在构建和部署Spring云应用程序的同时，让读者掌握如何进行微服务设计。整本书是一个完整的例子，传授作者多年的宝贵经验。

本书以一个名为EagleEye的项目为主线，介绍云、微服务等概念以及SpringBoot和SpringCloud等诸多Spring项目，并介绍如何将EagleEye项目一步一步地从单体架构重构成微服务架构，最终将这个项目拆分成众多微服务，让它们运行在各自的Docker容器中，实现持续集成/持续部署，并最终自动部署到云环境（Amazon）中。针对在重构过程中遇到的各种微服务开发会面临的典型问题（包括开发、测试和运维等问题），本书介绍了解决这些问题的核心模式，然后在实战中选择特定SpringCloud子项目或其他工具解决这些问题。

《Spring实战（第4版）》

【美】CraigWalls（沃尔斯）著

全球有超过的开发者使用本书来学习Spring

中文版累计销售超10万册，畅销经典Spring技术图书，针对Spring4全新升级作者CraigWalls，SpringSource的软件开发人员，也是一位畅销书作者。第3版译者继续翻译新版，品质保障！

《精通SpringMVC4》

【美】GeoffroyWarin著

SpringMVC属于SpringFrameWork的后续产品，已经融合在SpringWebFlow里面。Spring框架提供了构建Web应用程序的全功能MVC模块。SpringMVC4是当前最新的版本，在众多特性上有了进一步的提升。

在本书中，我们将会从头开始构建一个有用的Web应用。本书共计10章，分别介绍了快速搭建SpringWeb应用、精通MVC结构、URL映射、文件上传与错误处理、创建Restful应用、保护应用、单元测试与验收测试、优化请求、将Web应用部署到云等内容，循序渐进地讲解了SpringMVC4的开发技巧。

《深入理解SpringCloud与微服务构建》

方志朋著

本书共分16章，全面涵盖了SpringCloud构建微服务相关的知识点。第1、2章详细介绍了微服务架构和SpringCloud。第3、4章讲解了用SpringCloud构建微服务的准备工作。第5～12章以案例为切入点，讲解了SpringCloud构建微服务的基础组件，包括Eureka、Ribbon、Feign、Hystrix、Zuul、Config、Sleuth、Admint等组件。第13～15章讲述了使用SpringCloudOAuth2来保护微服务系统的相关知识。第16章用一个综合案例，全面讲解了如何使用SpringCloud构建微服务，可以作为实际开发的样例工程。

《微服务分布式构架开发实战》

龚鹏著

本书语言简洁，内容丰富，适合具备初级Java后端开发能力的开发人员，大中专相关专业师生，网站培训班学员，以前拥有单工程开发经验并且想尝试分布式微服务架构的人员。

《Java架构师指南》

王波著

资深Java专家多年经验总结，全程项目驱动，首本完整介绍Java入门进阶到架构师的编程技术图书。

程序员走向架构师是必经之路，本书基于官方API的完美解读，从架构师的角度来讲解Java知识技能，并且从搭建虚拟机开始，学习常用的Linux命令，力争做到使程序员在较短的时间内成功迈入架构师的殿堂。

《分布式对象存储——原理、架构及Go语言实现》

胡世杰著

云存储专家200分钟视频讲解，掌握云存储理论，动手搭建分布式对象存储架构

本书首先从一个最简单的对象存储服务原型开始，讨论在原型中存在的问题并介绍对象存储服务中一些常见的概念以及设计理念，然后通过改变架构或添加功能的方式解决这些问题。这一迭代步骤将发生多次，最终我们会收获一个足够完善的对象存储服务。

《App架构师实践指南》

SkySeraph潘旭玲著

一本讲解从程序员转变为架构师需要了解的技能和思想，明确地给程序员指引了移动架构师成长的路线，是想成为架构师的程序员实用指南。

全面介绍了在移动应用开发的架构设计和性能优化方面的知识，是架构师的必备书籍。讲述了移动应用架构师需要了解的技能、思想等整体的发展方向，是移动架构师成长的路线图。

《遗留系统重建实战》

[英]克里斯·伯查尔（ChrisBirchall）著

这是一本以经验为主导的指南，能使遗留软件项目脱胎换骨。它涵盖了重构、质量度量学、工具链和工作流、持续集成、基础设施自动化以及组织文化等内容。在技术层面，读者将学习如何给代码模块化引进依赖注入，如何定量地衡量软件质量，以及如何实现基础设施的自动化。

在策略层面，读者将能学到的实践有：软件是应该重写还是应该重构，团队的组织架构应该是什么样的，以及如何让管理层意识到软件质量的重要性。本书的核心议题包括解析和模块化棘手的代码结构、集成和自动化测试、替换过时的构建系统，以及用Vagrant和Ansible之类的工具实现基础设施自动化。

《编写高性能的代码》

[美]Ben，Watson，沃森著

想让自己的代码获得zui佳的性能吗？本书将揭开CLR的神秘面纱，不仅教你如何编写性能优异的代码，还能让你“知其所以然”。作者参与设计并搭建的系统是世界上最大型的高性能系统之一，他在本书中融入了很多的经验教训。

本书不仅讲解了CLR的工作机制，还详细介绍了当前获得zui佳性能的新方法，涉及环境下的优化、对CLR功能的深入剖析、免费的工具和教程推荐、颇有价值的案例轶事、评测并提升性能的具体步骤。

《Docker容器：利用Kubernetes、Flannel、Cockpit和Atomic构建和部署》

克里斯托弗·尼格斯（ChristopherNegus）著

Linux系统或云环境上运行Docker的实用指南！无论是在笔记本上还是在远程云上，Docker都能够改变创建、测试、部署和管理zui关键应用的方式。本书中，作者ChristopherNegus帮助读者从头开始掌握Docker容器化技术。开始的时候读者能够运行一些Ubuntu、Fedora、RHEL、CoreOS或ProjectAtomic的Docker容器镜像，看完本书之后，读者就可以在现代Linux和云环境中部署企业级质量、多容器的Kubernetes。

《OpenStack实战》

[美]V.K.科迪·布姆加德纳（）著

本书提供了真实环境使用案例和如何构建你自己的云平台的一步步的指导。本书能为你提供所需要的物理硬件集群和基础设施服务设计指导。你将会学到如何选择和设置虚拟服务器和物理服务器，如何实现软件定义网络以及在企业内部设计、部署和运营一个OpenStack云的技术细节，还会探索如何针对自己的环境对OpenStack部署做出最佳的定制。最后，你还会学到自己的云是如何提供面向用户的软件和基础设施服务的。

《第一本Docker书（修订版）》

[澳]詹姆斯·特恩布尔（JamesTurnbull）著

本书由Docker公司前服务与支持副总裁JamesTurnbull编写，是Docker开发指南。本书专注于Docker1.9及以上版本，指导读者完成Docker的安装、部署、管理和扩展，带领读者经历从测试到生产的整个开发生命周期，让读者了解Docker适用于什么场景。

为什么DDD是设计微服务的最佳实践

在本人的前一篇文章《不要把微服务做成小单体》中，现在很多的微服务开发团队在设计和实现微服务的时候觉得只要把原来的单体拆小，就是微服务了。但是这不一定是正确的微服务，可能只是一个拆小的小单体。这篇文章让我们从这个话题继续，先看看为什么拆出来的是小单体。

在微服务架构诞生之前，几乎所有的软件系统都是采用单体架构来构建的，因此大部分软件开发者喜欢的开发路径就是单体架构模式。在这样的背景下，根据经济学和心理学的 路径依赖法则 ，当这些开发者基于新的技术想要把原来的大单体拆分成多个部分时，就必然会习惯性地采用自己最擅长的单体架构来设计每个部分。

在现实中我们经常看到这个法则随处都会发生，微信刚出来的时候很多人说这不就是手机上的QQ吗，朋友圈刚出来的时候他们又会说这不就是抄袭微博吗。很多时候当你兴致冲冲给朋友介绍一个新的东东时，朋友一句话就能让你万念俱灰：这不就是XXX吗？之所以这样，是因为人类在接触到新知识新概念的时候，都会下意识的使用以前知道的概念进行套用，这样的思维方式是人类从小到大学习新事物的时候使用的模式，它已经固化成我们大脑操作系统的一部分了。

理解了这个法则，我们就可以很容易的明白，已经在单体架构下开发了多年的软件工程师，当被要求要使用微服务架构来进行设计和开发的时候，本能的反应方式肯定是：这不就是把原来的单体做小了吗？但是这样做出来的“微服务”真的能够给我们带来微服务架构的那些好处吗？真的能提高一个企业的数字化响应力吗？

不断变化的软件需求和经常被视为效率低下的软件开发一直都是这个行业里最难解决的顽疾，从瀑布到敏捷，都是在尝试找到一个解决这个顽疾的方法，领域驱动设计（Domain Driven Design）也是其中一个药方，而且随着十多年的不断实践，我们发现这个药方有它自己的独特之处，下面我们先来介绍一下这个药方。

领域驱动设计这个概念出现在2003年，那个时候的软件还处在从CS到BS转换的时期，敏捷宣言也才发表2年。但是Eric Evans做为在企业级应用工作多年的技术顾问，敏锐的发现了在软件开发业界内（尤其是企业级应用）开始涌现的一股思潮，他把这股思潮成为领域驱动设计，同时还出版了一本书，在书中分享了自己在设计软件项目时采用的建模方法，并为设计决策者提供了一个框架。

但是从那以后DDD并没有和敏捷一样变得更加流行，如果要问原因，我觉得一方面是这套方法里面有很多的新名词新概念，比如说聚合，限界上下文，值对象等等，要理解这些抽象概念本身就比较困难，所以学习和应用DDD的曲线是非常陡峭的。另一方面，做为当时唯一的“官方教材”《领域驱动设计》，阅读这本书是一个非常痛苦的过程，在内容组织上经常会出现跳跃，所以很多人都是刚读了几页就放下了。

虽然入门门槛有些高，但是对于喜欢智力挑战的软件工程师们来说，这就是一个难度稍为有一点高的玩具，所以在小范围群体内，逐渐有一批人开始能够掌控这个玩具，并且可以用它来指导设计能够控制业务复杂性的软件应用出来了。虽然那时候大部分的软件应用都是单体的，但是使用DDD依然可以设计出来容易维护而且快速响应需求变化的单体应用出来。

到了2013年，随着各种分布式的基础设施逐渐成熟，而SOA架构应用在实践中又不是那么顺利，Martin Fowler和James Lewis把当时出现的一种新型分布式架构风潮总结成 微服务架构 。然后微服务这股风就呼呼的吹了起来，这时候软件工程师们发现一个问题，就是虽然指导微服务架构的应用具有什么特征，但是如何把原来的大单体拆分成微服务是完全不知道怎么做了。然后熟悉DDD方法的工程师发现，由于DDD可以有效的从业务视角对软件系统进行拆解，并且DDD特别契合微服务的一个特征：围绕业务能力构建。所以用DDD拆分出来的微服务是比较合理的而且能够实现高内聚低耦合，这样接着微服务DDD迎来了它的第二春。

下面让我们站在软件工程这个大视角看看DDD究竟是在做什么。

从计算机发明以来，人类用过表达世界变化的词有：电子化，信息化，数字化。这些词里面都有一个“化”字，代表着转变，而这些转变就是人类在逐渐的把原来在物理世界中的一个个概念一个个工作，迁移到虚拟的计算机世界。但是在转变的过程中，由于两个世界的底层逻辑以及底层语言不一致，就必须要有一个翻译和设计的过程。这个翻译过程从软件诞生的第一天起就天然存在，而由于有了这个翻译过程，业务和开发之间才总是想两个对立的阶级一样，觉得对方是难以沟通的。

于是乎有些软件工程界的大牛就开始思考，能不能有一种方式来减轻这个翻译过程呢。然后就发明了面向对象语言，开始尝试让计算机世界有物理世界的对象概念。面向对象还不够，这就有了DDD，DDD定义了一些基本概念，然后尝试让业务和开发都能够理解这些概念名词，然后让领域专家使用这些概念名词来描述业务，而由于使用了规定的概念名词，开发就可以很好的理解领域业务，并能够按照领域业务设计的方式进行软件实现。这就是DDD的初衷：让业务架构绑定系统架构。

后来发现这个方法不仅仅可以做好翻译，还可以帮助业务划分领域边界，可以明确哪个领域是自己的核心价值所在，以后应该重点发展哪个领域。甚至可以作为组织进行战略规划的参考。而能够做到这点，其实背后的原因是物理世界和虚拟世界的融合。

上面介绍了使用DDD可以做到绑定业务架构和系统架构，这种绑定对于微服务来说有什么关系呢。所谓的微服务拆分困难，其实根本原因是不知道边界在什么地方。而使用DDD对业务分析的时候，首先会使用聚合这个概念把关联性强的业务概念划分在一个边界下，并限定聚合和聚合之间只能通过聚合根来访问，这是第一层边界。然后在聚合基础之上根据业务相关性，业务变化频率，组织结构等等约束条件来定义限界上下文，这是第二层边界。有了这两层边界作为约束和限制，微服务的边界也就清晰了，拆分微服务也就不再困难了。

而且基于DDD设计的模型中具有边界的最小原子是聚合，聚合和聚合之间由于只通过聚合根进行关联，所以当需要把一个聚合根从一个限界上下文移动到另外一个限界上下文的时候，非常低的移动成本可以很容易地对微服务进行重构，这样我们就不需要再纠结应不应该这样拆分微服务？拆出的微服务太少了以后要再拆分这样的问题了。

所以，经过理论的严密推理和大量实践项目的验证，ThoughtWorks认为DDD是当前软件工程业界设计微服务的最佳实践。虽然学习和使用DDD的成本有点高，但是如果中国的企业想再软件开发这个能力上从冷兵器时代进入热兵器时代，就应该尝试一下DDD了解一下先进的软件工程方法。