架构师训练营 - 第七章作业

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



Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 [1]  Spring框架无缝集成。

Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。Dubbo架构图见下：





服务提供者服务器的服务要向注册中心服务器进行注册服务，以提供消费者请求。

Dubbo 进行一次微服务调用的时序图见下：



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



架构设计的理念是分层、分治。事实上，领域驱动设计的核心理念恰恰也是分层、分治。它是在用分层、分治的思想解决分层、分治的问题。它天然地要求我们在做架构设计时，必须时刻区分此刻所处的是问题域空间还是解决方案域空间。对于软件系统来说，业务及其对应的业务架构是软件要解决的问题，所以业务架构处于问题域空间；而软件系统自然就是业务上的解决方案，所以软件架构处于解决方案域空间。这是DDD的分治理念。同时，DDD区分战术设计层与战略设计层。战术设计层是微观视角，描述领域模型的细节；战略设计层是宏观视角，把控领域模型的总体设计。这是DDD的分层理念。通过分层、分治，DDD使我们能够在保持关注点分离的同时可以直达问题本质，从而平滑地从问题过渡到解决方案。





1）识别与聚焦核心域是领域驱动设计首要原则。这是另一个层面上的分治。子域的目的一方面是要给产品后续开发提供投资策略依据，另一方面由于子域属于问题域空间，子域的明确有助于定义清晰的问题边界，从而有助于解决方案的验证。



2）分治的理念必然要求整个建模的过程是协同共创的。问题域空间的子域探索需要业务人员与领域专家提供输入并主导。他们需要向技术人员解释清楚业务流程，场景与问题，确保他们的业务输入是正确而完备的。这是影响最后模型质量的关键。解决方案域的领域建模与架构设计需要架构师与技术人员依据业务的输入进行深入的讨论、思考和抽象，并且需要向业务人员解释清楚建模的依据，以及验证模型是否具有足够的能力支撑业务。而由于业务的多变性，对模型的探索也不是一蹴而就的，它是一个迭代演进的过程，是需要花费一定的成本来维持的。如果没有持之以恒的动力坚持，模型最终只会沦为僵尸文档。



3）由于整个探索过程是一个持续协同共创的过程，协同的各方需要形成统一的语言才能互相沟通无碍。事实上，在持续的协同过程中，协同的各方自然而然就会消除沟通中存在歧义的词汇，形成一套相互理解的语言，并最终反映到模型中。不用纠结什么是统一语言，也不用刻意去形成它，只要坚持协同共创的模式，你最终得到的模型就是最好的统一语言。



通过战略设计，划分模块和服务的边界及依赖关系，对微服务架构的设计至关重要。



微服务架构落地要求

• 业务先行，先理顺业务边界和依赖，技术是手段而不是目的。

• 先有独立的模块，后有分布式的服务。

• 业务藕合严重，逻辑复杂多变的系统进行微服务重构要谨慎。

• 要搞清楚实施微服务的目的是什么，业务复用?开发边界清晰?分布式集群提升性能?



领域驱动设计正好是微服务架构落地重要保证。