【架构师训练营第 1 期 10 周】 作业

【架构师训练营第 1 期 10 周】 作业



1.根据微服务框架 Dubbo 的架构图，画出 Dubbo 进行一次微服务调用的时序图。







2.关于微服务架构（中台架构、领域驱动设计、组件设计原则），你有什么样的思考和认识？



我最大的感觉是：服务划分一定要干净利落，不要服务之间有太多数据关联。



公司内部从2018年开始使用微服务架构进行开发，按不同的功能分为用户服务、订单服务、商品服务、营销服务和报表服务。在前期还是比较容易添加功能的，但是当业务创新超过了当时系统设计的范围时，扩展起来就比较臃肿。没有按业务领域去划分添加功能，当然也有一个原因是业务也不知道实验性的功能到底有没有效。所以到了后期，新的实验功能如果是两个服务相关联的话，就看哪个服务的开发同学有工时开发，就放在哪个服务中。这样就会导致功能划分更加不清晰，后期功能迭代更加混乱，日积月累旧的代码不敢改动，新的代码不断往上加，变成类似传统单体应用的困境。

于是2019年开始安排部分服务重构，当然大家都懂的，业务部门很难抽出一段时间不进行业务开发，单纯进行重构。所以只能逐个服务进行重构，在一段时间段内这个服务不接收新的需求，单独进行重构。但是在重构商品服务的时候，想改造数据格式的时候发现不可以。因为订单服务保存的商品服务的数据格式，营销服务里面优惠券和特价商品配置的时候也保存了商品的数据格式，一旦改动商品服务，订单和营销服务都会受到影响，前者会导致订单商品信息无法显示，后者会导致线上优惠券和特价菜无法使用。在人力有限的情况下只能沿用现有数据格式，做有限的优化。

从那时候就觉得在微服务架构开发设计中，除了领域划分外，各个服务如果关联其它服务的数据，尽量只使用id或者尽量少关联，不然后续如果需要更改数据模型也会“牵一发动全身”。服务隔离得不够干脆的话，后续迭代容易回到混乱状态。