Dubbo流程

全流程时序图

dubbo调用流程主要包含：服务注册、服务发现、服务调用、服务更新和调用重试这几个环节

服务注册

Provider绑定指定端口并启动服务，指供者连接注册中心，并发本机IP、端口、应用信息和提供服务信息发送至注册中心存储

服务发现

Consumer连接注册中心 ，并发送应用信息、所求服务信息至注册中心，注册中心根据 消费 者所求服务信息匹配对应的提供者列表发送至Consumer 应用缓存。

服务调用

Client发送请求到Consumer，Consumer根据负载均衡策略从本地缓存的Provider列表中选择一个提供者，然后通过ip+port的方式直连对应的Provider

服务更新

Provider更新之后会主动发送新的注册信息到注册中心，注册中心更新存储的Provider信息，然后将新的Provider列表信息发送给Consumer，Consumer更新本地缓存的Provider列表

调用重试

当调用超时或者异常时会进行调用重试，默认是重试2次，重试的时候会从本地缓存的Provider列表中重新选择一个Provider进行直连调用

对微服务架构思考和认知

微服务

微服务架构是按照一定的规则将原先在一起的服务拆分为多个可以独立运行、独立开发、独立部署、独立运维的微服务，从而满足业务快速变化及分布式多团队并行开发的需求。

中台

阿里官方的定义：

“企业中台就是，将企业的核心能力随着业务不断发展以数字化形式沉淀到平台，形成以服务为中心，由业务中台和数据中台构建起数据闭环运转的运营体系，供企业更高效的进行业务探索和创新，实现以数字化资产的形态构建企业核心差异化竞争力。”

通俗的说中台就是通过领域建模、切当服务拆分和关键业务的抽取等方法论构建的，需要不断迭代、进化，进化的企业级系统平台。

服务网格

服务网格是用于控制和监控微服务应用程序中的内部服务到服务流量的软件基础结构层。它通常采取与应用程序代码一起部署，作为网络代理的 "数据平面" 和与这些代理交互的 "控制平面" 的形式。

领域驱动设计DDD

领域驱动设计简单的说就是为解决场景下的问题而构建领域模型，那如何构建领域模型呢？具体：

微服务和中台

微服务和中台的核心都是为了拆分，都将大问题拆成小问题。区别是在站得角度不一样。

微服务的本质是大单体要拆分和进一步解耦，将大服务拆分小服务。微服务更多的还是站在技术层次，是一种技术手段。

中台的更多的是指横向拆分，即共性业务能力的下沉，然后再将服务能力开放给前台应用使用。中台更多的是站在业务角度，是一种业务思维。中台的实现可以使用微服务也可以不使用微服务。

微服务和服务网格

上面说了微服务是一种拆分和进一步解耦的技术架构，而服务网格是一个专注于处理服务间通信的基础设施层。服务网格是一个底层的基础设施技术，通过服务网格可以更好的管理微服务。

DDD和微服务、中台

微服务的强大之处在于清晰地定义了它们的职责并划定了它们之间的边界。它的目的是在边界内建立高内聚，在边界外建立低耦合。领域驱动设计（DDD） 是 Eric Evans 提出的一种软件设计方法和思想，主要解决业务系统的设计和建模。DDD本质就是构建领域模型，领域模型是业务逻辑和状态的对象，是从具体业务（领域）中提取出来的。因此DDD的思想可以很好的指导微服务的构建，它们本质上都是抽象、提取、拆分。

架构设计的理念是分层、分治。事实上，领域驱动设计的核心理念恰恰也是分层、分治。DDD是在用分层、分治的思想解决分层、分治的问题。DDD实施方法是事件风暴，顾名思义，它是关于事件的头脑风暴。事件风暴不但按照时间线把系统的行为剖析开了，而且它把承载这个行为的载体也暴露在我们眼前。通过事件风暴对业务中台建模的过程与一般的事件风暴过程大同小异。整个过程其实就是在战略层与战术层来回探索。