如何把单体式应用拆解成微服务？【下】

热评博文：《如何设计出优美的Web API？》，现阅读量超 2300，小伙伴们不要错过哦！

 

紧接昨天的上篇《如何把单体式应用拆解成微服务？【上】》，今天咱们一块儿来看看具体的拆解场景：

• 场景1：数据库表外键引用关系

若是单体式应用中两个功能模块存在数据引用关系，那咱们在拆解微服务时如何消除这种外键引用关系呢？首先，停⽌外键引⽤；而后，改为经过RESTful HTTP API⽅式获取原先外键关联的信息。以下图，改造前Payment数据库表中的记录经过外键引用Order，代码层面一般会借助对象关系映射（ORM）框架创建数据对象的关联，改造后代码层面就不能经过ORM框架作关联了。在Payment数据库表的记录中会保存Order的主键值，除此以外还会保存Order的关键属性信息，这样能够避免频繁的跨进程调用，从而能够提升系统的总体效率表现。

下图是改造前的状况：

下图是改造后的状况：

• 场景2：共享静态数据关系

若是单体式应用中两个功能模块彼此共享静态数据，那咱们在拆解微服务时如何消除这种共享关系呢？静态数据一般存储在数据库当中，例如：商品类目代号。若是这些静态数据须要更新，那咱们就须要频繁地发布系统，这样会致使多个服务的中断。

为了不这个问题，咱们也能够将这些静态数据拷贝多份，分别⽤于每一个服务，但维护多份数据拷⻉的一致性是个问题。另外，咱们也能够将这些静态数据存⼊每一个服务的配置文件，下降更新数据的难度。统一配置中心，微服务架构中的必选组件，咱们能够经过它来管理这些静态数据，这样在维护更新上会带来极大的便利。

• 场景3：共享基础数据关系

若是单体式应用中两个功能模块共享某类基础数据，那咱们在拆解微服务时如何消除这种共享关系呢？多个服务共享某类基础数据，例如：用户数据、物流公司数据等等，那咱们要为这类数据提炼出专门的领域模型，将它封装成微服务，而后经过该服务来访问这些共享的基础数据。服务化带来的好处就是彼此之间仅仅依赖服务契约，双方具体采用什么技术和方案都是自由的。只要服务契约没有改变，那彼此的升级改造就不会影响。

下图是改造前的状况：

下图是改造后的状况：

• 场景4：共享数据库表格

若是单体式应用中两个功能模块共享一张数据表格，那咱们在拆解微服务时如何消除这种共享关系呢？多个服务各自引⽤的数据被合并存储在一张数据库表当中，代码层面借助ORM框架实现多态，这种状况咱们须要将每一个服务所关注的数据剥离出来，分别存到不一样的表格当中。

下图是改造前的状况：

下图是改造后的状况：

• 场景5：共享数据库

在拆解微服务过程当中，咱们该如何拆分数据库呢？最稳妥的方案就是分阶段重构数据库，数据是最宝贵的资源，咱们不要贪图一步到位。

下图是改造前的状况：

• 第一步，按照业务上下文先将一个数据库拆解成两个数据库，但应用仍然是单体式应用，经过多数据源相关技术应用能够同时访问两个数据库，以下图所示：

• 第二步，将单体式应用拆解成微服务，每一个微服务都有各自独立的数据库，以下图所示：

• 旧模块微服务改造优先级原则

从单体式应用中划分出有界的上下文，做为剥离微服务的候选，而后开始依次重构每一个功能模块。那如何判断哪些模块应该优先被剥离成微服务呢？从模块剥离难度看，咱们能够遵循先易后难的原则，逐步积累重构经验，这适用于在微服务构建方面经验不太丰富的团队；从需求变化频率看，优先剥离那些变动频繁的模块，总体收益会更大一些，这对于人力资源较为紧张的团队不失为一个好的判断准则；从资源消耗类型看，那些计算或内存密集的模块适合优先剥离，这样有利于弹性伸缩时提高资源利用效率，这对系统规模较大的场景效果最明显；从服务边界粒度看，粒度越粗越好剥离。具体按哪一个规则来安排微服务的改造顺序，这就要根据每一个团队的具体状况来具体分析了。

咱们在支持不一样系统实施微服务改造的过程当中，上述优先级原则都被采用过，优先级存在的缘由就是资源不够。微服务改造不是一蹴而就的事情，这个过程会持续很长时间，可能跨度几年，在不一样阶段须要考虑的问题也就不一样，最核心的原则就是按照适合本身的节奏有条不紊地开展工做，在确保线上业务稳定的前提下适当地追求速度。

• 微服务改造是否结束判断标准

那何时才算完成微服务改造呢？判断标准就是旧系统中所有有界上下文都被剥离成微服务，此时反腐层就能够被废除了；或者遗留的单体式应用相对较稳定，再也不发生变化，重构的投入产出比再也不划算；或者遗留的单体式应用关联业务已经退出市场了，系统下线了。

• 微服务架构新挑战与解决方案

当单体式应用被拆解成多个微服务以后，原先在一个事务边界内的操做如今要跨多个事务边界了，咱们如何保证事务的一致性呢？下面是一些分布式事务机制：

• 再次尝试，最终一致：将每一个操做步骤放⼊队列排队，后续再次尝试，确保最后执行成功，状态达成⼀致。
• 撤销所有操做：补偿事务机制，原事务操做失败以后，启动一个新的事务去撤销以前的操做。若是补偿事务也失败了，那系统须要提供手动或自动再次运⾏补偿事务的功能。
• 分布式事务：经过一个全局事务管理器来协调各个事务得以成功执行。对于短时间事务，一般采用两阶段提交（Two-Phase Commit），第一阶段是投票阶段，分布式事务的参与者告诉事务管理器，判断本地事务是否能够顺利执行。若是事务管理器收集到全部投票结果都是YES，那就开始提交事务执行。

分布式事务机制自己不算太复杂，咱们借鉴业界的一些开源产品自研了一套分布式事务框架，跟微服务框架结合起来，应用开发者只须要按照框架的约定实现特定的接口，经过一些注解就能够发起分布式事务，相关细节能够参考阿里的全局事务服务GTS。

当单体式应用被拆解成多个微服务以后，原先集中存储的数据也被分开存储了，报表生成将会遇到新的挑战。在单体式应⽤状况下，一般有一个用于生成报表的从库，从主库同步数据，仅⽤于查询等读操做，避免⽣成报表过程影响主库的读写效率。在微服务状况下，咱们将要经过服务调用来获取数据，设计适合报表统计的批量接口，以及增长缓存用于提高数据获取效率。

• 数据抽取：经过服务调⽤来获取报表所需数据，这会形成很是⼤的负载，以及专⻔为报表设计的API。为了弥补上述不足，咱们能够将数据抽取程序独立出来，专门从业务数据库中抽取数据到报表数据库。
• 事件驱动数据抽取：基于事件驱动的微服务架构，咱们能够开发特定事件的订阅者，负责将数据同步到报表数据库，这样能够解耦底层数据库系统。

微服务改造是一个长期过程，这个过程会遇到各式各样的问题，方法论能够帮助咱们更好地解决这些问题，而且下降风险。欢迎你们一块儿探讨微服务改造过程当中遇到的任何问题！

今天先分享到这里，若是你以为有价值，麻烦动动手指点下文 「 推荐 」按钮，让更多小伙伴能够看到，我也会更加有动力坚持分享。另外，老兵哥我后续还会分享职业规划、应聘面试、技能提高、影响力打造等经验，欢迎 关注 本专栏或歪信公主号 「 IT老兵哥 」！

关注「 IT老兵哥 」，赋能程序人生！

• 软技能-热点文章：

1. “花式”裁人套路深，你知道吗？
2. 遭遇裁人，如何渡过心理危机？
3. 如何在寒冬中找到好工做？
4. 2C 仍是 2B，跟找工做有什么关系？
5. 大公司 vs 小公司，你会选哪一个？
6. 记住这一点，不怕找不到好工做！
7. 跳槽，跳仍是不跳，该怎么跳？
8. 程序员“求包养”攻略揭秘
9. 很努力了，为何我还在原地踏步？

 

• 硬技能-热点文章：

1. 如何设计出优美的Web API？
2. 程序员必须懂的架构入门课
3. 从程序员到架构师，有捷径吗？
4. 图解 Spring：HTTP 请求的处理流程与机制【1】
5. 图解 Spring：HTTP 请求的处理流程与机制【2】
6. 图解 Spring：HTTP 请求的处理流程与机制【3】
7. 图解 Spring：HTTP 请求的处理流程与机制【4】
8. 图解 Spring：HTTP 请求的处理流程与机制【5】
9. 如何正确使用 Spring Cloud？【上】
10. 如何正确使用 Spring Cloud？【中】
11. 如何正确使用 Spring Cloud？【下】
12. Spring 核心技术与产品理念剖析【上】
13. Spring 核心技术与产品理念剖析【下】