架构师训练营第十周作业

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



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

微服务架构其实是一种架构风格，即按照领域把关联紧密的一组服务部署为一个应用，对外提供服务。整个系统由多个这样的应用组成。



微服务架构同时也是一种组织风格，正如康威定律里描述的一样：一个组织的系统通常被设计成这个组织通信结构的副本，一个应用被一个小团队负责，这个团队既有产品负责人，也有开发工程师、设计师和测试工程师，既有负责某一个业务线的团队，也有做基础支撑的中间件团队。整个系统由多个这样的小团队组成，各自自主的发展和演进。



公用的应用就会被抽离出来成为中台，被其他的上层业务应用调用，以达到复用和快速创新的目的。每个应用也都会结合自身的业务特点选择不同的系统架构，简单的比如CRUD服务，直接使用常规的三层架构（即UI+BLL+DAL）即可；对于复杂的业务，可以采用领域驱动设计的四层架构（Infrastructure+Application+Service+Domain），利用面向对象分析与设计原则指导大规模复杂业务的系统开发。



但是不论采用哪一种系统架构，即便是单体应用，放在最重要位置需要考虑的是：模块化或组件化。即需要把功能强相关的服务放在一起，形成模块。这也是面向对象编程最为重视的高内聚、低耦合。有了优秀的模块化设计，才有进一步演变为分布式的可能，否则服务间相互耦合相互调用会变成程序员的噩梦。因此对于微服务，并不是拆的越细小越好，而是要先进行有合理的，合乎逻辑的业务拆分，把模块分清楚了，在考虑使用何种方式去独立部署，推荐的方式是使用演进式开发：即在不能很好的拆分模块的情况下，先都放在一个应用中部署，直到理顺业务逻辑，相对稳定的情况下再把它剥离出去独立成服务。为了减小这种变化带来的修改痛苦，应该在一开始，就把模块之间的调用方式抽象出来，只依赖于服务接口，具体实现可以在演进过程中发生变更，而不影响到调用方。