架构师训练营第十周作业
根据微服务框架 Dubbo 的架构图,画出 Dubbo 进行一次微服务调用的时序图
关于微服务架构(中台架构、领域驱动设计、组件设计原则),你有什么样的思考和认识?
微服务架构其实是一种架构风格,即按照领域把关联紧密的一组服务部署为一个应用,对外提供服务。整个系统由多个这样的应用组成。
微服务架构同时也是一种组织风格,正如康威定律里描述的一样:一个组织的系统通常被设计成这个组织通信结构的副本,一个应用被一个小团队负责,这个团队既有产品负责人,也有开发工程师、设计师和测试工程师,既有负责某一个业务线的团队,也有做基础支撑的中间件团队。整个系统由多个这样的小团队组成,各自自主的发展和演进。
公用的应用就会被抽离出来成为中台,被其他的上层业务应用调用,以达到复用和快速创新的目的。每个应用也都会结合自身的业务特点选择不同的系统架构,简单的比如CRUD服务,直接使用常规的三层架构(即UI+BLL+DAL)即可;对于复杂的业务,可以采用领域驱动设计的四层架构(Infrastructure+Application+Service+Domain),利用面向对象分析与设计原则指导大规模复杂业务的系统开发。
但是不论采用哪一种系统架构,即便是单体应用,放在最重要位置需要考虑的是:模块化或组件化。即需要把功能强相关的服务放在一起,形成模块。这也是面向对象编程最为重视的高内聚、低耦合。有了优秀的模块化设计,才有进一步演变为分布式的可能,否则服务间相互耦合相互调用会变成程序员的噩梦。因此对于微服务,并不是拆的越细小越好,而是要先进行有合理的,合乎逻辑的业务拆分,把模块分清楚了,在考虑使用何种方式去独立部署,推荐的方式是使用演进式开发:即在不能很好的拆分模块的情况下,先都放在一个应用中部署,直到理顺业务逻辑,相对稳定的情况下再把它剥离出去独立成服务。为了减小这种变化带来的修改痛苦,应该在一开始,就把模块之间的调用方式抽象出来,只依赖于服务接口,具体实现可以在演进过程中发生变更,而不影响到调用方。
评论