Dubbo 时序图与微服务架构的认识

1.时序图

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







2.微服务架构的思考

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

1. 微服务架构

我的理解

因为单体应用会带来各种维护，merge代码，部署等困难，所以要把原来的一个巨无霸应用根据领域模型，拆分若干子域，划定限界上下文，实体和聚合根全部都对应起来，根据业务来拆分出合适粒度的微服务。

特点

失效转移(Fail Over)

对于集群部署的服务提供者，服务请求者可以使用加权轮询等手段访问，使服务提供者集群实现负载均衡

负载均衡

对于大型网站的微服务而言，即使是很少访问的简单服务，也需要集群部署，同时微服务框架还需要支持服务提供者的失效转移机制，以实现服务高可用。

高效的远程通信

对于大型网站，核心服务每天的调用次数会达到数亿亿计，如果没有高效的远程通信手段，服务调用可能会成为整个系统性能的瓶颈。对应用最少的侵入网站技术是为业务服务的，是否使用微服务需要根据业务发展规划。微服务也需要渐进式的演化，甚至会出现反复，即使用了微服务后又退回到集中式部署。微服务框架需要支持这种渐进式演化和反复，当然服务模块儿本身需要支持可集中式部署，也可分布式的部署。



版本管理

为了应对快速的需求，服务版本升级不可避免，如果仅仅是服务实现升级，那么这种升级对服务请求者而言是透明的，无需关注。但是如果服务的访问接口发生变化，就需要服务请求者和服务提供者同时升级才不会导致服务调用失败，企业应用系统可以申请停机维护，同时升级即可，而网站服务不可能中断，需要服务提供者先升级接口，并同时提供历史版本的服务供请求者调用。 d

落地

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

    要先搞清楚哪些服务是可以独立部署的，这些服务之间的依赖关系是啥样的。哪些功能要放到哪些服务里面去，这个是最重要的。绝大多数的微服务落地失败都是这方面没有搞好导致的。

因此一定要梳理清楚业务的边界在哪里，模块儿的边界是什么样子的， 模块儿的依赖关系如何计，模块儿内部包含哪些功能，这些是微服务架构最为重要的一点了，它是最容易出问题的点也是最容易被忽视的点。



2.先有独立的模块儿，后有分布式的服务。

    要把这些模块儿拆分清楚，组件之间的关系理清楚了，然后把这些模块儿进行独立的部署，它就变成微服务了。不要用战术上的勤奋掩盖战略上的懒惰。

    微服务的关键是业务的拆分，模块儿的边界和依赖关系。

3.业务耦合严重，逻辑复杂多变的系统进行微服务重构要谨慎

    要是模块儿都没有搞清楚了，代码原来就是一团一团的，连个组件都没有。打包的时候一坨打包，依赖关系也是一坨，这个时候要搞微服务，这种情况下还是要三思一下的！

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

    比如想要对这些服务进行业务级的复用，提供给其他的服务系统。还是希望这些服务的边界变得更加清楚，维护服务的团队或者做业务开发的工程师 和产品经理打交到的职责变得更加的清晰。还是说想要通过更多的部署，有针对性的优化，提升性能。

2. 中台架构

中台朴素的理解是公共业务下沉形成可复用的平台系统。比如平台交易中台会包含订单系统，优惠券系统等，它包含了若干服务，这些服务是若干可复用的功能组合到一起就形成了中台系统。

3. 领域驱动设计

领域就是业务的一切，要把领域分析清楚了，然后根据领域驱动产品的设计。

现在的现实大多是需求驱动开发，但是需求是散的，什么都可能成为需求。但领域是一个逻辑整体，这个整体要通过分析把各个子域相关的边界分析清楚，核心的功能分析清楚，依赖关系分析清楚。

先把领域也就是业务分析清楚了，然后映射到我们的开发来。也就是各个子域，限界上下文，实体和聚合根全部都对应起来了。

领域驱动设计是和业务对应的。

4. 组件设计原则

组件的理解

组件一般来说是物理上的，比如在C#中组件可以理解为动态链接库，Java中是jar包，React里是Component，Node中是module，Golang中是package。它们的实质都是对外提供某种服务。

模块儿有的时候不是物理上的，在一个组件里面也可能分成几个模块儿。比如在一个module里可能会包含若干个export。

设计原则