DDD指导微服务架构升级演进之路

男娘i 2022-09-05 01:42 243阅读 0赞

上周组内针对楼盘词典的架构和演进方向做了一次内部头脑风暴，目前楼盘词典还是单体服务，随着业务的快速发展和数据资产的不断累积，单体服务很难在未来支撑更复杂的业务场景，同时也会在排查问题方面更加困难。针对这个痛点考虑将楼盘词典做微服务拆分，那么如何做好微服务的拆分、如何把控好微服务拆分的粒度，如何解决数据一致性问题以及在最小影响范围内进行架构升级等则是我们面临的难题。

### 楼盘词典目前的架构![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdjaGVuZ21pbmcx_size_16_color_FFFFFF_t_70] ###

从上面的这张图我们可以清洗的看到楼盘词典目前有三个核心的功能，分别是：

*  空间服务：用来保存空间信息，比如城市、楼盘、分期、楼栋、单元、房间号等基础信息
 *  楼盘划分：当楼盘、分期等信息划分到所属门店和所属经纪人下才具备查看的权限，保证了作业的范围
 *  业主档案：通过批量上传、C4同步业主信息和新增业主档案等功能来保存和维护业主的信息，并定期进行跟进

当然除此之外，楼盘词典还具备更多功能，这里暂时不一一描述。那么有经验的小伙伴就会发现这么多功能都耦合在一起会让架构职责弱化，每个核心功能都会融合在一块，比如业主档案是在房间的维度上建立的，一个房间只能有一个当前业主档案，那么如果想看业主档案必须要先经过楼盘划分才可以，楼盘划分的前提是需要提前维护好空间信息。并且所有的功能都耦合在一个单体服务里维护也不是很好维护，一旦某一个点出现了问题，排查问题的成本变高了，并且还需要把整个服务进行重启恢复。

### 微服务拆分 ###

带着刚才的疑问，我们是不是可以思考将一个单体服务拆分成多个微服务呢？答案是可以的。常见微服务拆分的维度有水平拆分和垂直拆分。

*  垂直拆分：垂直拆分是从业务功能的角度进行纵向的拆分，以电商网站为例，可以把常态购买看作一个服务模块，把特卖看看作一个服务模块，把拼团看作一个服务模块，把海外购看作一个服务模块，然后根据与相应模块关联的密切程度将对应的业务逻辑划分到具体的微服务中
 *  水平拆分：水平拆分是从公用且功能独立的角度进行横向的拆分，还是以电商网站为例，上述所有服务模块都会用到用户、商品、交易这些公共功能，我们可以把这些模块也拆分为独立的微服务

很显然我们目前的应用场景应该采用垂直拆分，将单体服务的多个核心功能进行拆分，保证每一个微服务的原子性。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdjaGVuZ21pbmcx_size_16_color_FFFFFF_t_70 1]  
或者我们参考DDD进行领域拆分，而不是拆分成三个独立的微服务  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdjaGVuZ21pbmcx_size_16_color_FFFFFF_t_70 2]  
无论使用那种方案，我们从上面图中都可以看到，我们做出如下架构的调整：

*  去掉wyzs-public-api层
 *  鉴权任务全部交由网关处理
 *  从业务角度进行垂直拆分为三个独立的微服务(或者领域)

### 如何解决联表问题 ###

应用垂直拆分后面临的首要问题是实现表关联查询，比如业主档案中包含了房间信息、房源状态信息，以前在单体服务中我们可以通过连表查询，现在拆分之后肯定行不通了，那么我们怎么做呢？我这里列了几种思路。

##### 第一种方案：使用实时查询 #####

服务化后，为了解决这个问题最容易想到的方法就是冗余非当前服务（或者领域）的主键ID。比如我们的业主档案列表需要实时动态的展示房间信息、业主信息以及房源状态等信息，那么我们可以在业主档案表冗余一个房间ID和房源主键ID。然后将获取两个服务的数据并编排到一起，显然这个工作应该放到应用层，并尽可能使用异步的方式获取数据并聚合到一起。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdjaGVuZ21pbmcx_size_16_color_FFFFFF_t_70 3]  
同时，这种调用也需要进行熔断和回退。当房源服务不可用时，应该即使中断连接，并依然将可用的数据返回给前端，界面上的表现是业主档案数据显示完整，仅仅是房源数据暂无法获取，对用户来说应用基本可用。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdjaGVuZ21pbmcx_size_16_color_FFFFFF_t_70 4]

##### 第二种方案：使用数据副本冗余 #####

产生这个问题，实际上是受到数据库关系理论影响太深了，数据库关系理论可以有效解决数据一致性和冗余，但在分布式系统下不再适用。那么我们是不是可以考虑和这种传统思想"背道而驰"呢？答案是：可以在适当的场景下做出改变。还是以业主档案为例，我们可以在业主档案服务中冗余一些空间信息服务以及其他别的服务的数据，我们使用数据冗余和服务间同步的这种方式来解决服务间的数据关联问题。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdjaGVuZ21pbmcx_size_16_color_FFFFFF_t_70 5]  
这种方案有一些明显的优势：

1.  查询性能高，不需要跨服务查询，缓存策略简单
2.  不需要熔断，没有雪崩效应
3.  便于业务统计分析，数据统计的成本低

当然，并不是所有的业务都能满足条件去实现这种设计，需要具备一些条件：

1.  业务天然具有分离性，典型的就是商品快照、收货地址、发票、单据
2.  业务上不完全分离，但能接受一定程度的延迟，对实时性要求不高，可以通过最终一致性同步过来。例如商品服务和供应链服务

##### 第三种方案：使用搜索引擎解决复杂查询 #####

解决两个服务的问题，有时候可以引入第三个服务来解决。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdjaGVuZ21pbmcx_size_16_color_FFFFFF_t_70 6]  
开源成熟的搜索引擎 Elastic Search 在互联网公司广泛应用，用于解决服务垂直拆分后的查询问题非常实用。通过创建多个 Elastic Search 的索引，可以满足各种不同的查询需求。

使用搜索引擎会造成项目的运维成本上升，带来好处同时也需要考虑成本。另外真实项目中，服务间数据同步失败，最终一致性丢失这种问题始终存在。**搜索引擎应该只拿来做搜索，不应该获取搜索引擎中的数据直接应用于交易业务**。用户从搜索引擎获取的列表，然后根据该条目操作退款等业务，即使条目中含有相关数据，也应根据关联字段实时访问服务获取最新数据，保证强一致性。

总之解决表关联问题还是需要转换关系型数据理论和分布式系统下的两种思维方式，灵活应用。跨库联表等技术显得非常不自然，同时在性能、业务规则上都面临挑战。

### 服务化所带来的的其他挑战 ###

当然任何解决方案都是有利有弊，我们应该尽量发挥它的优势，但是也不能够忽略它的劣势。微服务架构中，还可能要面临的一些问题是分库之后分布式数据库的访问和事务一致性，分布式缓存的设计和访问，以及公共配置中心的访问和设置，还有微服务拆分后部署和运维的复杂性增加，该如何解决等，这些都是我们在做微服务拆分的时候需要考虑到的。

1.  完善的服务治理体系

随着微服务拆分的越细那么微服务的职责也就越单一，服务治理的就显得格外重要。服务治理需要包含注册中心、维护服务之间的关系、统一的流量调度、同城多活、异地多活等，说白了这些各种技术手段都是为了保证服务的稳定性。

1.  健全的监控体系以及链路追踪

服务化之后，面对众多的服务，精细化的监控和方便的运维必不可少。这点很多开发者在开发的时候察觉不到，到你真正上线开始运行维护的时候，如果没有良好的监控措施和快速的运维手段，到时候就是睁眼瞎、手足无措！  
![在这里插入图片描述][84f2491711574b10bcf2a8d364eb4cf1.png]

1.  容器化

单体应用拆分成多个微服务后，能够实现快速开发迭代，但随之带来的问题是测试和运维部署的成本的提升，尤其是机器资源的浪费，这是开发成本中占比很大一部分。不同的微服务的软件配置依赖不同，比如 Java 服务依赖了 JDK，就需要在 ECS 上安装 JDK，而且可能不同的微服务依赖的 JDK 版本也不相同，一般情况下新的业务可能依赖的版本比较新比如 JDK 8，而有些旧的业务可能依赖的版本还是 JDK 6，为此服务部署的初始化工作十分繁琐。所以我们就迫切的需要容器化部署，做好资源隔离，提高资源的利用率。

1.  完善的DevOps

单体应用中在测试和运维的时候，只需要把 Web 应用打成一个大的 JAR 包，部署到 Tomcat 中去就行了。后来拆分成多个微服务之后，有的业务需求需要同时修改多个微服务的代码，这时候就有多个微服务都需要打包、测试和上线发布，一个业务需求就需要同时测试多个微服务接口的功能，上线发布多个系统，给测试和运维的工作量增加了很多。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdjaGVuZ21pbmcx_size_16_color_FFFFFF_t_70 7]所以我们需要借助CI/CD来实践DevOps，我们可以借助GitLab+Jenkins来实现持续集成、持续交付和持续部署这个过程。

1.  分布式事务

服务化之后不同的业务表全都分散开来了，所以也就演变成了分布式事务，那么就要对应的解决方案来处理，常见的TCC、2PC来解决。但是目前咱们的场景不涉及交易，所以采用保证最终一致性就可以了。

1.  唯一ID

服务化之后我们就不能再使用数据库自增ID，因为非常容易发生ID重复的问题。业内常见的解决方案有：UUID、雪花算法等。

1.  老数据兼容和迁移

通常来说架构升级改造完成之后，新来的数据可以直接写入新的数据来源，而旧的数据可以通过DBA团队来帮忙处理，一点一点的清洗数据，最终同步到新的数据源。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdjaGVuZ21pbmcx_size_16_color_FFFFFF_t_70]: /images/20220829/67f546f4b1134172afa140c21322bf79.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdjaGVuZ21pbmcx_size_16_color_FFFFFF_t_70 1]: /images/20220829/b57aaf9e63694837abeeeb792c0ae215.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdjaGVuZ21pbmcx_size_16_color_FFFFFF_t_70 2]: /images/20220829/bd4c9764781a40398465643b89eb5abc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdjaGVuZ21pbmcx_size_16_color_FFFFFF_t_70 3]: /images/20220829/96cc191cc5cd436aab262c32a1a31e3d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdjaGVuZ21pbmcx_size_16_color_FFFFFF_t_70 4]: /images/20220829/b40b81200766442992d09e18543cf57e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdjaGVuZ21pbmcx_size_16_color_FFFFFF_t_70 5]: /images/20220829/f8b49a9b174146d1bbc0389967639fe5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdjaGVuZ21pbmcx_size_16_color_FFFFFF_t_70 6]: /images/20220829/40b0802478754f24a13dd63e725534c1.png
[84f2491711574b10bcf2a8d364eb4cf1.png]: /images/20220829/545daa9a27b14023852b361a4c0d3c9b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdjaGVuZ21pbmcx_size_16_color_FFFFFF_t_70 7]: /images/20220829/0590b3a9884348f1a6d715fc22c758f7.png