|都已经十岁的 Apache Dubbo，还能再乘风破浪吗？( 四 )

既然面向接口有如此多的好处，那为什么我们还要探索面向应用的服务治理模式呢？
听起来似乎有些矛盾。其实到底是面向接口，还是面向应用，只是从不同的角度看 Dubbo 。我们所聊的“面向接口 -> 面向应用”的改造，主要体现在服务注册、发现层面：

本文插图

而我们说的面向应用的新模型，主要对第 2 点，即注册中心的数据组织转变为 “面向应用/实例” 粒度。这为我们解决两个问题：

在服务发现层面与 Kubernetes Service 等微服务模型对齐；
服务发现的数据量将有一个量级的下降，从 “接口数实例数 ”下降到 “应用数实例数” 。

具体可以参见文章《Dubbo 迈出云原生重要一步 - 应用级服务发现解析》，本系列文章后续也会有对这部分机制和实现的更深度解析。
云原生基础设施
云原生带来了底层基础设施，应用开发、部署和运维等全方位的变化：
基础设施

基础设施调度机制变化，带来运维（生命周期）、服务治理等方面的变化；
服务发现能力下沉，Kubernetes 抽象了 Native Service Discovery 。

Service Mesh - 云原生微服务解决方案

Mesh 为跨语言、sdk 升级等提供了解决方案， Dubbo sdk 要与 Mesh 协作，做到功能、协议、服务治理等多方便的适配；
Mesh 尚未大规模铺开，且其更适合对流量管控更关注的应用，传统 SDK 的性能优势仍旧存在，两者混部迁移场景可能会长期存在。

从应用场景上， Dubbo 可能的部署环境包括：

不使用 Kubernetes Native Service ， Kubernetes 只作为容器编排调度设施，继续使用 Dubbo 自建的服务注册、发现机制；
复用 Kubernetes Native Service ， Dubbo 不再关心服务注册， Dubbo Client 负责服务发现与流量分配；
Dubbo sdk 往 Mesh 迁移，一方面要做到适应 Mesh 架构，成为 Mesh 体系下的 RPC 编程和通信方案；另一方面要做到 Dubbo 与 Mesh 架构长期共存，互相打通服务发现和治理体系；
Kubernetes 上与云下混合部署的平滑迁移支持，包括服务发现的统一与网络通信方案的打通。

从 Dubbo 功能划分上，将着重从以下方面提供对云原生基础设施的支持：

生命周期：Dubbo 与 Kubernetes 调度机制绑定，保持服务生命周期与 Pod 容器等生命周期的自动对齐；
治理规则：服务治理规则在规则体、规则格式方面进行优化，如规则体以 YAML 描述、取消过滤规则对 IP 的直接依赖，定义规则特有的 CRD 资源等；
服务发现：支持 K8S Native Service 的服务发现，包括 DNS、API-Server ，支持 xDS 的服务发现；
Mesh 架构协作：构建下一代的基于 HTTP/2的通信协议，支持 xDS 的标准化的数据下发。

新一代的 RPC 协议和应用级服务发现模型将会是这一部分的前置基础。
总结与展望
作为系列文章开篇，我们在这里对 Dubbo 过去一年的成绩做了简要的总结与回顾，包括 Dubbo 社区、产品迭代的发展。接下来我们会看到更多来自深度 Dubbo 用户的落地经验分享， Dubbo-go 子社区的发展故事等。更重要的，我们也对下一代云原生 Dubbo - Dubbo 3.0 做了展望，后续关于 Dubbo 3.0 Roadmap、方案设计与进展解析等也将在此系列中发布。