微服务架构-Dubbo3

前言

https://dubbo.apache.org
https://cn.dubbo.apache.org/zh-cn/blog/index.html

很多人对Dubbo的理解是RPC框架，但是就目前看来，Dubbo已经不仅仅是一个RPC框架了。
Dubbo 定位是一款微服务开发框架，它侧重解决微服务实践从服务定义、开发、通信到治理的问题，因此 Dubbo 同时提供了 RPC 通信、与应用开发框架的适配、服务治理等能力。

Dubbo3在官网首页的介绍中是这样描述的：Dubbo3是下一代云原生微服务框架 - 3.0 版本的正式发布，标志着 Apache Dubbo 正式进入云原生时代。
3.0 在通信协议、服务发现、部署架构、服务治理上都对云原生基础设施进行了全面适配，提供了Triple、应用级服务发现、Dubbo Mesh等核心特性。

Dubbo与SpringCloud

https://cn.dubbo.apache.org/zh-cn/overview/what/xyz-difference/

Dubbo与Istio

Dubbo3

https://cn.dubbo.apache.org/zh-cn/overview/what/overview/

服务治理抽象控制面
服务治理控制面不是特指如注册中心类的单个具体组件，而是对 Dubbo 治理体系的抽象表达。
控制面包含协调服务发现的注册中心、流量管控策略、Dubbo Admin 控制台等，如果采用了 Service Mesh 架构则还包含 Istio 等服务网格控制面。
Dubbo数据面
数据面代表集群部署的所有 Dubbo 进程，进程之间通过 RPC 协议实现数据交换，Dubbo 定义了微服务应用开发与调用规范并负责完成数据传输的编解码工作。
- 服务消费者 (Dubbo Consumer)，发起业务调用或 RPC 通信的 Dubbo 进程
- 服务提供者 (Dubbo Provider)，接收业务调用或 RPC 通信的 Dubbo 进程

如何结合K8S云原生？

架构设计

服务注册与发现架构
元数据服务架构
事件驱动架构

服务自省 - 应用级服务注册与发现

随着微服务架构和云原生技术的兴起，以应用为粒度的注册模型已是大势所趋，如 Spring Cloud 和 Kubernetes 服务注册与发现模型。
在术语上，微服务架构中的“服务”（Services）与云原生中“应用”（Applications）是相同的概念，属于逻辑名称，而它们的成员则以服务实例（Service Instances）体现，服务和服务实例的数量关系为 1:N。

Dubbo 服务自省首要需求是减轻注册中心的承载的压力，同时，以应用为粒度的服务注册与发现模型不但能够最大化的减少 Dubbo 服务元信息注册数量，而且还能支持 Spring Cloud 和 Kubernetes 环境，可谓是一举两得。

服务提供者启动，首先解析应用定义的“普通服务”并依次注册为 RPC 服务，紧接着注册内建的 MetadataService 服务，最后打开 TCP 监听端口。
启动完成后，将实例信息注册到注册中心（仅限ip、port等实例相关数据），提供者启动完成。
服务消费者启动，首先依据其要“消费的 provider 应用名”到注册中心查询地址列表，并完成订阅（以实现后续地址变更自动通知）。
消费端拿到地址列表后，紧接着对 MetadataService 发起调用，返回结果中包含了所有应用定义的“普通服务”及其相关配置信息。
至此，消费者可以接收外部流量，并对提供者发起 Dubbo RPC 调用