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





1、dubbo的整体架构如图





2、依赖关系如下图



3、注册流程



4、调用流程





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



无论用什么样的架构，主要目的是解决现实问题，也就是问题空间。从技术不是目的是手段这一方面出发，技术也是为业务的发展提供助力。从生产力与生产关系的角度看，科学技术能够应用于生产过程、渗透在生产力诸基本要素之中而转化为实际生产能力。科学技术上的发明创造，会引起劳动资料、劳动对象和劳动者素质的深刻变革和巨大进步，在这也充分体现了科学技术是第一生产力。



微服务架构，现在最流行的架构之一。从单体架构、垂直架构发展而来，为解决庞大的项目和业务需求提供了解决方案，重要的就是”分而治之“的思想。但同时也引入了新的问题，调用关系复杂，服务间通信、服务治理、服务维护和发布等也越来越棘手，docker和k8s在大行其道，应运而生。这解决了大部分的问题。



中台架构，主要是”大中台，小前台“的思想，充分为业务让路，沉淀公共服务或技术中间件，为业务的快速发展赋能。



但无论从技术层面还是业务层面，都没有拆分的很彻底。无论以jar包的形式提供公共组件，还是以中间件的形式提供服务，都会或多或少的存在依赖行为，对业务的侵入还是有的。为了更加让业务开发关注业务，在软件开发中提供了sideCar模式，把除了业务自身的其它角色全部剥离到sideCar中以prod单独代理的方式进行，让业务和技术充分解耦，极大地促进了业务需求的迭代发展。



组件的设计原则，主要是从技术上指导软件开发和设计。对整个软件质量的提高有很大的帮助，主要核心理念就是“高内聚，松耦合”，进而阐述的“SOLID”的指导原则等，总纲为对扩展开放，对修改关闭，以及分布式理论-CAP定理和BASE理论，为组件的发展提供了理论指导和发展方向。

同时，相关的组件的设计原则，也可以指导DDD的开发，只是面对的对象不一样，DDD更强调的是面对“业务域”对象，经常用到的依赖倒置，关注点分离，CQRS等设计原则，软件或组件的开发，更侧重于面对“技术域”对象。都是为了解决实际问题，而表现的关注点不一样而已。

当然无论微服务（sideCar）还是组件，以及DDD目标都是实现业务的快速发展为前提，把非业务的技术域尽量与业务域解耦，用分层分治，隔离（服务隔离、进程隔离等），单独去实现从而屏蔽网络通信、api或公共类的依赖等，让技术实现更灵活，更强大，更安全。最终，让业务开发把更多的精力放在业务上。



但这些都是宏观上以业务和技术两大方面而言的，但对业务而言，个人认为真正面向对象的设计更趋向于领域驱动设计，这跟中台架构及其相关的设计原则也不冲突，而是互相促进，互相取舍的过程。

领域驱动设计，关注点分离，让业务专家和技术专家统一到问题空间中，有一致的目标和认识，从而进一步提高生产力。



领域驱动设计，用到的六边形架构（端口和适配器体系架构）和 清洁架构，以及设计原则：

• 微服务：一个域问题的集合或子集。

• CQRS：将API分为与写入和读取相关的组件，以实现更好的扩展。

• EventSourcing：用事件存储替换关系数据库，并使用消息队列将组件完全分离

• 控制反转：摒弃传统的由上往下的依赖关系，以域层为中心 让其它依赖其抽象或接口的一种实现方式，尽量让域对象依赖其自身。比如SPI机制的应用

分层模式：

• 表示层

• 应用层

• 域层（业务层）

• 基础结构层（持久化、消息传递等）



微服务解决了或提升了应用的吞吐量和可用性，并没有解决日益正在的开发问题和应用复杂性，这就要求可以用微服务+DDD相结合的方式，去解决我们现实中的问题。



http://dubbo.apache.org/zh-cn/