add blogs and docs (#574)
diff --git a/blog/zh-cn/2.7.5-release.md b/blog/zh-cn/2.7.5-release.md
new file mode 100644
index 0000000..743904e
--- /dev/null
+++ b/blog/zh-cn/2.7.5-release.md
@@ -0,0 +1,274 @@
+# 2.7.5 功能解析
+
+近日，备受瞩目的 Dubbo 2.7.5 版本正式发布，在 2.7.5 版本中，Dubbo 引入了很多新的特性、对现有的很多功能做了增强、同时在性能上也有了非常大的提升，这个版本无论对 Dubbo 社区亦或是开发者来说，都将是一个里程碑式的版本。
+
+* 应用粒度服务注册【beta】
+* HTTP/2 (gRPC) 协议支持
+* Protobuf 支持
+* 性能优化，调用链路性能提升 30%
+* 支持 TLS 安全传输链路
+* 优化的消费端线程模型
+* 新增更适应多集群部署场景的负载均衡策略
+* 全新的应用开发 API （兼容老版本应用）【beta】
+* 其他一些功能增强与 bugfix
+
+首先，从服务发现上，新版本突破以往基于接口粒度的模型，引入了全新的基于应用粒度的服务发现机制 - 服务自省，虽然该机制当前仍处于 beta 阶段，但对于 Dubbo 向整个微服务云原生体系靠齐，都打下了非常好的基础；得益于紧凑的协议设计和代码实现上的优化，Dubbo 一直以来都具有较好的性能表现，在 2.7.5 版本中，性能上有了进一步的提升，根据来自官方维护团队的压测，新版本在调用链路上性能提升达到 30%；云原生微服务时代，多语言需求变得越来越普遍，协议的通用性和穿透性对于构建打通前后端的整套微服务体系也变得非常关键，Dubbo 通过实现 gRPC 协议实现了对 HTTP/2 协议的支持，同时增加了与 Protobuf 的结合。
+
+## 1. 应用粒度服务注册【beta】
+
+从 Java 实现版本的角度来说，Dubbo 是一个面向接口代理的服务开发框架，服务定义、服务发布以及服务引用都是基于接口，服务治理层面包括服务发现、各种规则定义也都是基于接口定义的，基于接口可以说是 Dubbo 的一大优势，比如向开发者屏蔽了远程调用细节、治理粒度更精细等。但基于接口的服务定义同时也存在一些问题，如服务，与业界通用的微服务体系等。
+
+
+
+针对以上问题，2.7.5 版本引入了一种新的服务定义/治理机制：**服务自省**，简单来说这是一种基于应用粒度的服务治理方案。一个实例只向注册中心注册一条记录，彻底解决服务推送性能瓶颈，同时由于这样的模型与主流微服务体系如 SpringCloud、K8S 等天然是对等的，因此为 Dubbo 解决和此类异构体系间的互联互通清除了障碍。有兴趣进一步了解 Dubbo 服务自省机制如何解决异构微服务体系互联互通问题的，可具体参考我们之前的文章解析《Dubbo 如何成为联通异构微服务体系的最佳服务开发框架》。
+
+以下是服务自省机制的基本工作原理图。
+
+
+
+要了解更多关于服务自省工作原理的细节，请参与官方文档及后续文章。
+
+服务自省与当前已有的机制之间可以说是互补的关系，Dubbo 框架会继续保持接口粒度的服务治理的优势，实现接口和应用两个粒度互为补充的局面，兼顾性能、灵活性和通用性，力争使 Dubbo 成为微服务开发的最佳框架。
+
+## 2. HTTP/2 (gRPC) 协议支持
+
+Dubbo RPC 协议是构建在 TCP 之上，这有很多优势也有一些缺点，缺点比如通用性、协议穿透性不强，对多语言实现不够友好等。HTTP/2 由于其标准 HTTP 协议的属性，无疑将具有更好的通用性，现在或将来在各层网络设备上肯定都会得到很好的支持，gRPC 之所以选在 HTTP/2 作为传输层载体很大程度上也是因为这个因素。当前 gRPC 在云原生、Mesh 等体系下的认可度和采用度逐步提升，俨然有成为 RPC 协议传输标准的趋势，Dubbo 和 gRPC 在协议层面是对等竞争的，但是在框架实现上却各有侧重，Dubbo 无疑有更丰富的服务开发和治理体验 。
+
+Dubbo 支持 gRPC 协议带来的直观好处有：
+
+* 正式支持基于 HTTP/2 的远程通信，在协议通用性和穿透性上进一步提升。
+* 支持跨进程的 Stream 流式通信，支持 Reactive 风格的 RPC 编程。
+* 解决了 gRPC 框架难以直接用于微服务开发的问题，将其纳入 Dubbo 的服务治理体系。
+* 为联通组织内部已有的 gRPC 或多语言体系提供支持。
+
+2.7.5 版本开始，gRPC (HTTP/2) 成为 Dubbo 协议体系中的一等公民，对于有需求的开发者完全可以在 Dubbo 开发的微服务体系中启用 gRPC 协议，而不必束缚在 Dubbo 协议自身上，关于这点我们在《Dubbo 如何成为联通异构微服务体系的最佳服务开发框架》一文中也有类似的观点表述。
+
+关于 Dubbo 中如何开发 grpc (HTTP/2) 服务的细节，请参考文章《Dubbo 在跨语言与协议穿透性等方面的探索》，关于如何开启 TLS 和使用 Reactive RPC 编程，请参见示例。另外，Dubbo 的 go 版本目前同样也提供了对 gRPC 协议对等的支持，具体请关注 dubbogo 社区的发版计划。
+
+## 3. Protobuf 支持
+
+支持 Protobuf 更多的是从解决 Dubbo 跨语言易用性的角度考虑的。
+
+跨语言的服务开发涉及到多个方面，从服务定义、RPC 协议到序列化协议都要做到语言中立，同时还针对每种语言有对应的 SDK 实现。虽然得益于社区的贡献，现在 Dubbo 在多语言 SDK 实现上逐步有了起色，已经提供了包括 Java, Go, PHP, C#, Python, NodeJs, C 等版本的客户端或全量实现版本，但在以上提到的跨语言友好性方面，以上三点还是有很多可改进之处。
+
+ 协议上 2.7.5 版本支持了 gRPC，而关于服务定义与序列化，Protobuf 则提供了很好的解决方案。
+
+* 服务定义。当前 Dubbo 的服务定义和具体的编程语言绑定，没有提供一种语言中立的服务描述格式，比如 Java 就是定义 Interface 接口，到了其他语言又得重新以另外的格式定义一遍。因此 Dubbo 通过支持 Protobuf 实现了语言中立的服务定义。
+* 序列化。Dubbo 当前支持的序列化包括 Json、Hessian2、Kryo、FST、Java 等，而这其中支持跨语言的只有 Json、Hessian2，通用的 Json 有固有的性能问题，而 Hessian2 无论在效率还是多语言 SDK 方面都有所欠缺。为此，Dubbo 通过支持 Protobuf 序列化来提供更高效、易用的跨语言序列化方案。
+
+日后，不论我们使用什么语言版本来开发 Dubbo 服务，都可以直接使用 IDL 定义如下服务，具体请参见示例
+
+```idl
+syntax = "proto3";
+
+option java_multiple_files = true;
+option java_package = "org.apache.dubbo.demo";
+option java_outer_classname = "DemoServiceProto";
+option objc_class_prefix = "DEMOSRV";
+
+package demoservice;
+
+// The demo service definition.
+service DemoService {
+ rpc SayHello (HelloRequest) returns (HelloReply) {}
+}
+
+// The request message containing the user's name.
+message HelloRequest {
+ string name = 1;
+}
+
+// The response message containing the greetings
+message HelloReply {
+ string message = 1;
+}
+```
+
+## 4. 性能优化
+
+### 4.1 调用链路优化
+
+2.7.5 版本对整个调用链路做了全面的优化，根据压测结果显示，总体 QPS 性能提升将近 30%，同时也减少了调用过程中的内存分配开销。其中一个值得提及的设计点是 2.7.5 引入了 Servicerepository 的概念，在服务注册阶段提前生成 ServiceDescriptor 和 MethodDescriptor，以减少 RPC 调用阶段计算 Service 原信息带来的资源消耗。
+
+### 4.2 消费端线程池模型优化
+
+对 2.7.5 版本之前的 Dubbo 应用，尤其是一些消费端应用，当面临需要消费大量服务且并发数比较大的大流量场景时（典型如网关类场景），经常会出现消费端线程数分配过多的问题，具体问题讨论可参见以下 issue ：
+
+https://github.com/apache/dubbo/issues/2013
+
+改进后的消费端线程池模型，通过复用业务端被阻塞的线程，很好的解决了这个问题。
+
+**老的线程池模型**
+
+
+
+我们重点关注 Consumer 部分：
+
+1. 业务线程发出请求，拿到一个 Future 实例。
+2. 业务线程紧接着调用 future.get 阻塞等待业务结果返回。
+3. 当业务数据返回后，交由独立的 Consumer 端线程池进行反序列化等处理，并调用 future.set 将反序列化后的业务结果置回。
+4. 业务线程拿到结果直接返回
+
+
+
+**2.7.5 版本引入的线程池模型**
+
+
+
+1. 业务线程发出请求，拿到一个 Future 实例。
+2. 在调用 future.get() 之前，先调用 ThreadlessExecutor.wait()，wait 会使业务线程在一个阻塞队列上等待，直到队列中被加入元素。
+3. 当业务数据返回后，生成一个 Runnable Task 并放入 ThreadlessExecutor 队列
+4. 业务线程将 Task 取出并在本线程中执行：反序列化业务数据并 set 到 Future。
+5. 业务线程拿到结果直接返回
+
+这样，相比于老的线程池模型，由业务线程自己负责监测并解析返回结果，免去了额外的消费端线程池开销。
+
+关于性能优化，在接下来的版本中将会持续推进，主要从以下两个方面入手：
+
+1. RPC 调用链路。目前能看到的点包括：进一步减少执行链路的内存分配、在保证协议兼容性的前提下提高协议传输效率、提高 Filter、Router 等计算效率。
+2. 服务治理链路。进一步减少地址推送、服务治理规则推送等造成的内存、cpu 资源消耗。
+
+## 5. TLS 安全传输链路
+
+2.7.5 版本在传输链路的安全性上做了很多工作，对于内置的 Dubbo Netty Server 和新引入的 gRPC 协议都提供了基于 TLS 的安全链路传输机制。
+
+TLS 的配置都有统一的入口，如下所示：
+
+**Provider 端**
+
+```java
+SslConfig sslConfig = new SslConfig();
+sslConfig.setServerKeyCertChainPath("path to cert");
+sslConfig.setServerPrivateKeyPath(args[1]);
+// 如果开启双向 cert 认证
+if (mutualTls) {
+ sslConfig.setServerTrustCertCollectionPath(args[2]);
+}
+
+ProtocolConfig protocolConfig = new ProtocolConfig("dubbo/grpc");
+protocolConfig.setSslEnabled(true);
+```
+
+
+
+**Consumer 端**
+
+```java
+if (!mutualTls) {}
+ sslConfig.setClientTrustCertCollectionPath(args[0]);
+} else {
+ sslConfig.setClientTrustCertCollectionPath(args[0]);
+ sslConfig.setClientKeyCertChainPath(args[1]);
+ sslConfig.setClientPrivateKeyPath(args[2]);
+}
+```
+
+为尽可能保证应用启动的灵活性，TLS Cert 的指定还能通过 -D 参数或环境变量等方式来在启动阶段根据部署环境动态指定，具体请参见 Dubbo 配置读取规则与 TLS 示例
+
+Dubbo 配置读取规则：http://dubbo.apache.org/zh-cn/docs/user/configuration/configuration-load-process.html
+
+TLS 示例：https://github.com/apache/dubbo-samples/tree/master/java/dubbo-samples-ssl
+
+> 如果要使用的是 gRPC 协议，在开启 TLS 时会使用到协议协商机制，因此必须使用支持 ALPN 机制的 Provider，推荐使用的是 netty-tcnative，具体可参见 gRPC Java 社区的总结： https://github.com/grpc/grpc-java/blob/master/SECURITY.md
+
+在服务调用的安全性上，Dubbo 在后续的版本中会持续投入，其中服务发现/调用的鉴权机制预计在接下来的版本中就会和大家见面。
+
+## 6. Bootstrap API【beta】
+
+在上面讲《服务自省》时，我们提到了 Dubbo 面向接口的设计，面向接口编程、面向接口做服务发现和服务治理。在引入应用粒度服务发现的同时，2.7.5 版本对编程入口也做了优化，在兼容老版本 API 的同时，新增了新的面向应用的编程接口 - DubboBootstrap。
+
+以面向 Dubbo API 编程为例，以前我们要这么写：
+
+```java
+ServiceConfig<GreetingsService> service1 = new ServiceConfig<>();
+service1.setApplication(new ApplicationConfig("first-dubbo-provider"));
+service1.setRegistry(new RegistryConfig("zookeeper://" + zookeeperHost + ":2181"));
+service1.export();
+
+ServiceConfig<GreetingsService> service2 = new ServiceConfig<>();
+service2.setApplication(new ApplicationConfig("first-dubbo-provider"));
+service2.setRegistry(new RegistryConfig("zookeeper://" + zookeeperHost + ":2181"));
+service2.export();
+
+......
+```
+
+ApplicationConfig、RegistryConfig、ProtocolConfig 等全局性的配置要在每个服务上去配置；并且从 Dubbo 框架的角度，由于缺少一个统一的 Server 入口，一些实例级别的配置如 ShutdownHook、ApplicationListener、应用级服务治理组件等都缺少一个加载驱动点。
+
+在引入 DubboBootstrap 后，新的编程模型变得更简单，并且也为解决了缺少实例级启动入口的问题
+
+```java
+ProtocolConfig protocolConfig = new ProtocolConfig("grpc");
+protocolConfig.setSslEnabled(true);
+
+SslConfig sslConfig = new SslConfig();
+sslConfig.setXxxCert(...);
+
+DubboBootstrap bootstrap = DubboBootstrap.getInstance();
+bootstrap.application(new ApplicationConfig("ssl-provider"))
+ .registry(new RegistryConfig("zookeeper://127.0.0.1:2181"))
+ .protocol(protocolConfig)
+ .ssl(sslConfig);
+
+ServiceConfig<GreetingsService> service1 = new ServiceConfig<>();
+ServiceConfig<GreetingsService> service2 = new ServiceConfig<>();
+
+bootstrap.service(service1).service(service2);
+bootstrap.start();
+```
+
+## 7. 多注册中心集群负载均衡
+
+对于多注册中心订阅的场景，选址时的多了一层注册中心集群间的负载均衡：
+
+
+
+在 Cluster Invoker 这一级，我们支持的选址策略有（2.7.5+ 版本，具体使用请参见文档）：
+
+* 指定优先级
+
+ ```xml
+ <!-- 来自 preferred=“true” 注册中心的地址将被优先选择，只有该中心无可用地址时才 Fallback 到其他注册中心 -->
+ <dubbo:registry address="zookeeper://${zookeeper.address1}" preferred="true" />
+ ```
+
+* 同 zone 优先
+
+ ```xml
+ <!-- 选址时会和流量中的 zone key 做匹配，流量会优先派发到相同 zone 的地址 -->
+ <dubbo:registry address="zookeeper://${zookeeper.address1}" zone="beijing" />
+ ```
+
+* 权重轮询
+
+ ```xml
+ <!-- 来自北京和上海集群的地址，将以 10:1 的比例来分配流量 -->
+ <dubbo:registry id="beijing" address="zookeeper://${zookeeper.address1}" weight=”100“ />
+ <dubbo:registry id="shanghai" address="zookeeper://${zookeeper.address2}" weight=”10“ />
+ ```
+
+* 默认，stick to 任意可用
+
+>关于多注册中心订阅模型，Dubbo 同时也提供了 Multi-Registry 合并的解决思路，欢迎参与到以下 PR 的讨论中: https://github.com/apache/dubbo/issues/5399
+
+## 8. 其他功能增强
+
+* 新增地址变更事件通知接口，方便业务侧感知地址变化
+
+* 新增外围配置加载入口，方便开发者在启动阶段定制服务启动参数
+
+* config 模块重构
+
+* parameters 扩展配置增强
+* 其他一些 Bugfix
+
+从 Dubbo 框架自身的角度来说，2.7.5 版本也做了很多的重构与优化（比如说 config 模块的重构），这些改动对于使用者来说并无感知的，但是从优化整个 Dubbo 代码内部结构的角度来说，这些改动对后续的功能开发与新机制的引入是一个很好的铺垫。
+
+## 9. 总结与展望
+
+在后续的版本中，Dubbo 会持续快速的优化与迭代，主要从以下几个方面发力：
+
+* 继续探索服务自省成为 Dubbo 主推的服务治理模型。
+* 对于企业用户关心的微服务解决方案场景，会持续推进框架的演进，包括当前正在开发的配置、服务鉴权机制、熔断等功能。后续还会尝试联合社区推动周边配套设施如网关、治理平台 Admin 等的建设，非常期待社区能踊跃参与到此部分的建设中。
+* 性能优化上。主要从两个方面着手，一是调用链路的持续优化，同时继续探索新的更通用的 RPC 协议；另一方面是在服务治理推送机制上的优化，以进一步提高 Dubbo 在大规模服务地址推送场景下的表现。
+* 云原生方向。接下来的版本将重点探索，1. 如何更好的支持 Dubbo 在 Kubernetes 上的部署和服务治理；2. 对于混合部署的场景，如传统 VM 和 K8S 体系混合部署、SDK Dubbo 与 Mesh 混合部署的场景，如何提供更好的支持以实现混部场景的长期共存或迁移。
\ No newline at end of file
diff --git a/blog/zh-cn/apche-dubbo-2019-2020.md b/blog/zh-cn/apche-dubbo-2019-2020.md
new file mode 100644
index 0000000..e36a1e2
--- /dev/null
+++ b/blog/zh-cn/apche-dubbo-2019-2020.md
@@ -0,0 +1,321 @@
+# 从 2019 到 2020，Apache Dubbo 年度回顾与总结
+
+非常感谢大家对 Dubbo 社区的关注，通过这篇文章我们将：总结过去一年 Dubbo 社区取得的成绩，包括社区和框架演进两个方面；展望未来 Dubbo 社区和框架的新的规划（roadmap）。社区建设是推动 Dubbo 健康持续发展的一个非常重要的环节，我们需要与社区保持良性的互动、有活跃的贡献者、有积极的富有建设性的讨论，而整个 Dubbo 社区过去一年在这方面都做的不错；在框架演进上，我们主要发布了 2.7.0 - 2.7.5 共 6 个特性版本，功能层面涵盖编程模型、协议、服务治理、性能优化等多个方面；除了已经发布的功能外，我们在 Dubbo 3.0 协议、服务自省和云原生等方向上也做了深入的探索，对这些方向的支持将是 Dubbo 接下来的重要工作方向，希望能通过这篇文章将其中更详细的思考和计划同步给大家。
+
+## 社区回顾
+
+回顾 Dubbo 社区过去一年的发展，其中一个重要的节点就是 2019 年 5 月从 Apache 孵化毕业。成为第二个由 Alibaba 捐献后从 Apache 毕业的项目，我有幸参与到了从重启开源、进入 Apache 孵化到毕业的整个过程，社区在此过程中做了大量的工作，包括邮件列表建设、代码规范检查、文档和代码国际化、issue/pr 处理等，这些一方面是 Apache 社区要求的工作，同时也为推动 Dubbo 的发展起到了正面的作用。
+
+在从 Apache 毕业之后，Dubbo 相关的项目也进行了迁移，都迁移到了 github.com/apache 组织之下：
+https://github.com/apache?utf8=✓&q=dubbo&type=&language=
+
+Dubbo 社区的项目总共有 24 个之多，维护如此多的项目，并不是单纯靠几个活跃的开发者就能做到的，而是靠整个社区努力的结果。我总结了过去一年提名的所有 Committer/PMC，总过有 27 人获得提名（23 名 committer、4 名 PMC），通过下方的饼状图可以看出，只有不到 20% 的贡献者是来自于 Alibaba，而 80% 以上是来自各个不同组织的开发者或爱好者。这样的 Committer 分布，是加入 Apache 带给 Dubbo 社区的一个最重要的变化之一：Dubbo 项目是属于整个社区的，反映的是不同组织不同开发者的共同诉求，它的发展不是由一个公司控制或决定的，而是由社区共同讨论后决定的。如果你对参与到 Dubbo 社区感兴趣，都可以参与到 Dubbo 发展的讨论、决策和 coding 中来，也非常期待各位能成为下一个 Committer。
+
+
+
+
+过去一年 Dubbo 社区组织了超过 10 场的线下 meetup 活动，覆盖了国内基本所有的开发者聚集的城市，与广大 Dubbo 开发者和使用者保持了密切交流。通过这些线下或线上的直播活动，分享了超过 100 个 topic 的演讲，深度讲解了 Dubbo 社区最新动态、功能模块开发和近期规划等。并且在所有的这些主题演讲中，绝大多数都是通过社区采集的方式，最终由 Dubbo 的深度企业分享的实践主题，其中典型的嗲表包括携程、工商银行、考拉、信用算力等。
+
+
+
+从 Github 上来看，Dubbo 在过去一年也受到了非常高的关注度，一个重要的里程碑是 Star 数突破 3w，相比重启开源时增长了近 5 倍；贡献者由最初的几十个增长到现在的 282 个，而这其中有六七十个已经被提名为 committer，不论是贡献者数量还是 committer 比例都得到很大的提升；另一个数据是发布的版本，总共发布了 64 个版本，大家如果要了解每个版本的具体信息，也可以从这里点进去查看。
+
+
+
+当前社区维护的大版本主要有 3 个，分别是 2.5.x 2.6.x 和 2.7.x。
+
+其中，2.7.x 是我们的主要开发版本，在过去的一年共发布了 6 个版本（2.7.0 - 2.7.5），每个版本都带来了一些值得关注的特性或功能升级，涵盖从编程模型、服务治理、性能到协议的多个方面的增强。
+
+2.6.x 版本则定位为 bugfix 版本，过去一年共发布了 3 个版本，主要以修复问题和安全漏洞为主，并没有增加什么新 feature，因此这一系列的版本在稳定性上是得到保证的。
+
+2.5.x 版本当前从去年初开始已宣布 EOF，只做安全修复；而到了下半年已经完全停止了维护。还在使用这个版本的用户建议尽快升级到 2.6 或 2.7 版本。
+
+关于 2.6 和 2.7 版本的用户分布情况，目前并没有官方的统计数据，但是根据我们从 issue 分布及一些深度用户的跟踪情况来看，这两个版本的使用分布大概是 40% - 60% 的状态。同时我们还观察到一个趋势，即很大一部分 2.6 的用户都已经开始调研升级到 2.7 版本或在升级的过程中，毕竟一个框架是否能很好的满足业务开发诉求，一个重要的因素是其是否不断的有功能的加入，是否能跟进新的技术趋势，2.6 版本已很难满足这些诉求。
+
+对于很多开发者来说，要升级到 2.7 版本，当前最大的顾虑即是其稳定性。因为 2.7 每个版本都会增加很多新内容且迭代速度较快，要保证每个发布版本的稳定性对社区来说也是一个充满挑战的事情。为了方便用户更好的完成升级评估，我们近期在 github 上列出了单独列了一个 issue 来统计现在包括未来版本的稳定性：
+
+https://github.com/apache/dubbo/issues/5669
+
+| **版本** | **重要功能** | **升级建议** | |
+| -------- | ------------ | ------------------------------------------------------------ | ------------------------------- |
+| 1 | 2.7.5 | 服务自省 HTTP/2（gRPC） Protobuf TLS 性能优化 https://github.com/apache/dubbo/releases/tag/dubbo-2.7.5 | 不建议大规模生产使用 |
+| 2 | 2.7.4.1 | [bugfixes and enhancements of 2.7.3](https://github.com/apache/dubbo/releases/tag/dubbo-2.7.4.1) | **推荐生产使用** |
+| 3 | 2.7.3 | [bigfixes of and enhancements of 2.7.2](https://github.com/apache/dubbo/releases/tag/dubbo-2.7.3) | **推荐生产使用** |
+| 4 | 2.7.2 | [bigfixes of and enhancements of 2.7.1](https://github.com/apache/dubbo/releases/tag/dubbo-2.7.2) | 不建议大规模生产使用 |
+| 5 | 2.7.1 | [bigfixes of and enhancements of 2.7.0](https://github.com/apache/dubbo/releases/tag/dubbo-2.7.1) | 不建议大规模生产使用 |
+| 6 | 2.7.0 | 异步编程模型 - 消费端/提供端异步 服务治理规则增强 简化的注册模型 配置中心、元数据中心 package 重构 https://github.com/apache/dubbo/releases/tag/dubbo-2.7.0 | beta 版本，2.6.x 重构后首个版本 |
+
+其中 2.7.5 版本预计将在接下来的 1-2 个版本之后逐步达到稳定状态。
+
+对于后续的版本是否通过标识性的后缀如 -beta、RC 等来区分不同阶段的发布版本，社区也有过类似的讨论，后续我们将视未来发展情况而定。
+
+## 重点功能回顾
+
+接下来针对 2.7 版本中发布的新功能，从编程模型、性能优化、服务治理、传输协议、生态发展等几个角度来做具体的讲解。
+
+### 编程模型
+
+Dubbo 中涉及编程模型相关的改动主要是以下几点：
+
+* CompletableFuture 异步方法签名的服务
+* 服务端异步支持 API
+* IDL 跨语言服务定义
+* Reactive-style 方法签名的服务
+
+首先，我们先来看一下异步化相关的增强。
+Dubbo Java 版本的典型服务定义如下：
+
+```java
+public interface HelloService {
+ // Synchronous style
+ String sayHello(String name);
+}
+```
+
+如果要实现消费端的异步服务调用，则需要单独配置异步标识，并通过 RpcContext API 配合使用
+
+```java
+String result = helloService.sayHello("world"); // result is always null
+Future future = RpcContext.getContext().getFuture();
+```
+
+在 2.7 版本之后，我们可以直接定义如下方法接口，以更直观的实现消费端/提供端异步：
+
+```java
+public interface HelloService {
+ // Asynchronous style
+ CompletableFuture<String> sayHello(String name);
+}
+
+CompletableFuture<String> future = helloService.sayHello("world");
+```
+
+以上示例都是基于 Java Interface 来描述 Dubbo 服务的，如果要和多语言异构的微服务实现互调，则服务又需要用相应语言的方式重新定义一遍，无法实现跨语言的服务复用；另外跨语言的序列化也是需要注意的一个问题。
+
+为此 2.7.5 版本引入了对 IDL + Protobuf 的支持，以解决跨语言的服务定义问题，具体可参见示例：
+
+https://github.com/apache/dubbo-samples/tree/master/java/dubbo-samples-protobuf
+
+
+
+对 Reactive-style API 的支持则和上面 CompletableFuture 有些类似，允许用户定义 RxJava、Reactor API 的服务接口
+
+
+
+但是需要注意的一定是，由于外围的 Reactive API 需要有底层传输协议的支持才有意义，因此，目前 Reactive API 只能在使用 gRPC 协议时才有意义，具体请参见示例以及下面关于 ”Dubbo 对 gRPC 的支持” 一节的讲解。
+
+https://github.com/apache/dubbo-samples/tree/master/java/dubbo-samples-grpc/dubbo-samples-rxjava
+
+### 性能优化
+
+2.7 版本在性能优化方面也做了很多的工作，对 Dubbo 业务系统的吞吐量、调用链路响应速度、服务治理链路性能等都有明显提升。
+
+1. 系统吞吐量
+
+ 和提升系统吞吐量相关的增强主要有框架的全异步化改造、消费端线程模型优化、引入 Stream 语义协议等。
+
+ 全异步化改造，很关键的一点是 Filter 链路的异步化，之前的 Filter 只有一个同步的 invoke 方法，现在为了支持异步回调，增加了 Listener 回调监听器，从而可以实现对异步调用结果的监听与拦截。
+
+
+
+ 关于消费端线程模型的优化，对于网关类应用，需要消费大量服务的应用，都会在系统稳定性和性能表现上有很大提升，其优化后的总体工作原理图所下所示，具体解析可以参见之前发布的文章：
+
+
+ 老线程模型工作原理：
+
+ 
+
+ 新线程模型工作原理：
+
+ 
+
+
+2. RPC 调用链路
+
+ 从 2.7.0 到 2.7.5，从我们的测试数据来看，通过一系列的优化调用链路性能提升在 30% 以上。总体来说，优化的目标是减少调用过程中的内存分配和 cpu 计算，主要有两个方面的改造：
+
+ * 服务元数据静态化，在启动阶段尽可能多的计算并缓存，以减少调用过程中的计算成本，加快响应速度
+ * 减少调用过程中的 URL 操作产生的内存分配
+
+3. 服务治理链路
+
+ 服务治理链路上主要有以下几点值得关注：地址推送、服务治理规则推送、服务治理规则计算、路由选址等，尤其是在大规模服务集群的场景下，以上每个点都可能成为性能或稳定性瓶颈。在 2.7 版本中，目前着重对 “地址推送” 相关计算路径做了优化，简单概括起来主要是以下几点：
+
+ * 地址推送事件合并，避免短时间重复计算
+ * 全量地址推送时，避免 URL 重新分配
+ * 在 URL 合并链路上，引入 URL 可变状态，避免 URL 拷贝造成的开销
+
+### 服务治理
+
+服务治理也是 2.7 版本中着重增强的一个模块。总体上可以分为三部分
+
+* 普通路由规则相关的优化和增强
+* 增强对跨区域、跨机房部署的路由支持
+* 元数据中心、配置中心
+
+我们针对这三部分逐步展开讲解。以下是 2.7 版本路由规则的几个例子。
+
+
+
+
+
+其中，最明显的一个变化是路由规则都以 YAML 进行了重写，并且后续所有的路由规则都计划以 YAML 为基本描述语言；相比于之前路由规则直接存储于注册中心，在 2.7 版本中增加了配置中心后，新版本的路由规则默认将存储在于独立的配置中心，配置格式推送机制都得到了优化；另外，2.7 版本中还增加了应用粒度的路由规则，方便从整个应用的角度去设置流量规则。
+
+新增加的跨注册中心的路由机制，可以实现调用流量在多个注册中心间的负载均衡，对于需要做异地容灾、同机房优先或者注册中心迁移的场景比较有用处。
+
+
+
+当前支持的注册中心集群负载均衡策略有：
+
+- 同区域优先
+- 权重轮询
+- 指定优先级
+- 任意可用
+
+元数据中心存储了 Dubbo 服务方法定义的描述，目前主要的用途是服务测试，将来也可用作服务 API 管理、网关参数映射等。
+
+新增的配置中心主要有两个用途：存储/推送配置规则、应用配置托管，接下来着重讲解应用配置托管相关功能，看其对 Dubbo 的开发与运维配置的影响。Dubbo 当前支持 JVM 动态参数、配置中心、API、本地配置文件等几种配置源，他们之间按照优先级从高到低的顺序实现配置覆盖，如下图所示：
+
+
+
+配置中心相当于是共享版本的 `dubbo.properties` 的远程托管，其中，key 值有特定的命名规范：
+
+```properties
+# 应⽤用级别
+dubbo.{config-type}[.{config-id}].{config-item} {config-item-value}
+# 服务级别
+dubbo.service.{interface-name}[.{method-name}].{config-item} {config-item-value}
+dubbo.reference.{interface-name}[.{method-name}].{config-item} {config-item-value}
+# 多配置项
+dubbo.{config-type}s.{config-id}.{config-item} {config-item-value}
+```
+
+### 传输协议
+
+2.7 版本在 RPC 协议层和序列化层进行了扩展，RPC 协议层增加了对 gRPC 协议的支持，序列化层增加了对 Protobuf 协议的支持。
+
+支持 gRPC 其中一个重要原因是其基于 HTTP/2 协议构建，HTTP/2 协议作为 HTTP 标准协议，在各个层次的网络设备及网关代理上都得到了很好的支持，因此具有更好的穿透性和通用性。通过支持 gRPC 协议，对于期望使用 HTTP/2 的 Dubbo 用户提供了一种传输协议选择。
+
+gRPC 在 HTTP/2 上构建了 Stream 的 RPC 语义，支持 Request - Response、Stream - Response、Request - Stream、Bi-Stream 等多种语义，能满足不同的业务调用场景。
+
+
+
+在 Dubbo 的设计中，所有的 RPC 协议都处于一个平等的地位，无论是自有的 Dubbo 协议，还是扩展的其他三方协议如 Thrift、Hessian、gRPC 等，得益于这样的设计，我们可以扩展任何新协议支持。关于如何扩展 RPC 协议及其应用场景，请参见之前发布的《使用 Dubbo 连接异构微服务体系》文章。
+
+https://mp.weixin.qq.com/s/-fvDeGlCLjz0n60naZJnQg
+
+Protobuf 序列化协议支持更多的是考虑其在跨语言、安全性和性能方面。
+
+## Roadmap
+
+未来社区将会持续推动 Dubbo 的发展，重点来说有以下几个方向：
+
+* 继续增强服务治理相关能力，以更好的满足微服务开发和运维的需求；
+* 协议层面，着手研发下一代的 RPC 协议，新协议将提供更丰富的如 Stream、Flow Control 等内置语义，同时将具有更好的扩展性、网关的友好性等；
+* 基于应用粒度的服务发现机制，
+* 云原生带来了底层基础设施的变化，同时在此基础上衍生出了如 ServiceMesh 的微服务解决方案，我们需要继续探索 Dubbo ；
+
+### 微服务功能
+
+目前正在开发或规划中的微服务功能有服务鉴权、熔断、路由规则增强等，预计将在接下来的 2.7.6 等版本中陆续发布。后续也将会根据社区中的诉求，陆续增加其他的微服务功能支持。
+
+以当前正在开发的服务鉴权功能为例，这是社区中很多 Dubbo 使用者在实际使用中遇到的需求：虽然 Dubbo 服务主要是在内部运转，但有些服务仍期望只对部分场景或用户开放，比如某些涉及到敏感数据操作的服务，这就需要有鉴权能力的支持。
+
+以下 issue 中有关于 Dubbo 当前正在开发中的鉴权功能的详细讨论，总体来说 Dubbo 提供的鉴权功能约束了 Dubbo 侧鉴权的基本流程，这是一套通用鉴权的方案，在 token 计算、校验等环节都被设计为可扩展的，因此可以方便的对接到各种认证及权限管理系统。
+
+https://github.com/apache/dubbo/issues/5461
+
+非常感谢社区的活跃开发者，现就职于爱奇艺的 https://github.com/CodingSinger，其是鉴权模块的发起者和主要开发贡献者。
+
+
+### 协议 - 3.0
+
+以下是 Dubbo 2.0 协议，我们之前已经在多个场合做过详细的讲解
+
+
+
+Dubbo 2.0 协议在云原生、mesh 等场景下暴露出一些问题，如：
+
+* 协议缺少扩展性
+* RPC 协议层和 payload 耦合在一起
+* 基于 TCP 构建的二进制私有协议
+* 缺少 Stream 语义的支持
+
+所以，针对以上问题，新一代的 Dubbo 协议将突出以下特点：
+
+**Reactive Stream**
+Reactive Stream 引入 RPC，带来更丰富的通信语义和 API 编程模型支持，如 Request-Stream、Bi-Stream 等
+
+**协议升级**
+协议内置应⽤层协议协商机制，包括自建协议升级机制、ALPN 等，以方面将来协议升级或兼容老版本协议的迁移
+
+**HTTP/2**
+微服务云原⽣生场景下，基于 HTTP/2 构建的通信协议具有更更好的通⽤用性和穿透性
+
+**可扩展**
+协议可扩展，区分协议头 Metadata 与 RPC 方法的参数
+
+**多语⾔支持**
+如通过支持 Protobuf 提供了更完善的 跨语言服务定义 与 序列化传输 的支持
+
+**Mesh**
+协议对 Mesh 更友好，方便完成与 Mesh 的协作，包括流量控制机制、应用层配置协商等
+
+**流量控制**
+协议内置流控机制，支持类似 Reqctive Stream 的 Request (n) 流控机制
+
+**协议通用性**
+兼顾通用性与性能，支持协议能在各种设备上运行
+
+### 服务自省 - 应用粒度的服务注册
+
+Dubbo 最大的优势之一在于其易用性，其面向接口（RPC 方法）的编程模型。同时，面向接口的治理也带来了一些问题：
+
+* 地址数量成倍增长，给地址推送带来很大压力
+* 和主流微服务体系模型不匹配，如 SpringCloud、Kubernetes 等
+
+为此，我们计划引入应用粒度的服务注册机制，主要有以下几个重点：
+
+* 注册中心按 “应用 - 实例IP” 组织，不再关心 RPC 接口同步
+* 引入独立的元数据服务完成 RPC 接口同步工作
+
+以下是应用粒度服务注册（服务自省）的基本工作原理，请持续关注后续对这部分的具体解析和开发进展。
+
+
+
+### 云原生
+
+云原生带来了底层基础设施，应用开发、部署和运维等全方位的变化：
+
+**基础设施**
+
+* 基础设施调度机制变化，带来运维（生命周期）、服务治理等方面的变化。
+* 服务发现能力下沉， Kubernetes 抽象了 Native Service Discovery。
+
+**Service Mesh - 云原生微服务解决方案**
+
+* Mesh 为跨语言、sdk 升级等提供了解决方案，Dubbo sdk 要与 Mesh 协作，做到功能、协议、服务治理等多方便的适配。
+* Mesh 尚未大规模铺开，且其更适合对流量管控更关注的应用，传统 SDK 的性能优势仍旧存在，两者混部迁移场景可能会长期存在。
+
+从应用场景上，Dubbo 可能的部署环境包括：
+
+1. 不使用 Kubernetes Native Service，Kubernetes 只作为容器编排调度设施，继续使用 Dubbo 自建的服务注册、发现机制。
+2. 复用 Kubernetes Native Service，Dubbo 不再关心服务注册，Dubbo Client 负责服务发现与流量分配。
+3. Dubbo sdk 往 Mesh 迁移，一方面要做到适应 Mesh 架构，成为 Mesh 体系下的 RPC 编程和通信方案；另一方面要做到 Dubbo 与 Mesh 架构长期共存，互相打通服务发现和治理体系。
+4. Kubernetes 上与云下混合部署的平滑迁移支持，包括服务发现的统一与网络通信方案的打通。
+
+从 Dubbo 功能划分上，将着重从以下方面提供对云原生基础设施的支持：
+
+**生命周期：** Dubbo 与 Kubernetes 调度机制绑定，保持服务生命周期与 Pod 容器等生命周期的自动对齐
+**治理规则：** 服务治理规则在规则体、规则格式方面进行优化，如规则体以 YAML 描述、取消过滤规则对 IP 的直接依赖，定义规则特有的 CRD 资源等。
+**服务发现：** 支持 K8S Native Service 的服务发现，包括 DNS、API-Server，支持 xDS 的服务发现
+**Mesh 架构协作：** 构建下一代的基于 HTTP/2 的通信协议，支持 xDS 的标准化的数据下发
+
+
+
+
+
+
+
+
+
diff --git a/blog/zh-cn/connect-heterogeneous-microservices.md b/blog/zh-cn/connect-heterogeneous-microservices.md
new file mode 100644
index 0000000..7ae6c6f
--- /dev/null
+++ b/blog/zh-cn/connect-heterogeneous-microservices.md
@@ -0,0 +1,290 @@
+# 使用 Dubbo 连接异构微服务体系
+
+从编程开发的角度来说，Dubbo 首先是一款 RPC 服务框架，它最大的优势在于提供了面向接口代理的服务编程模型，对开发者屏蔽了底层的远程通信细节。同时 Dubbo 也是一款服务治理框架，它为分布式部署的微服务提供了服务发现、流量调度等服务治理解决方案。
+
+在这篇文章中，我们将以以上基础能力为背景，尝试突破 Dubbo 体系自身，探索如何利用 Dubbo 对多协议、多服务发现模型的支持，来实现异构微服务体系间的互联互通。在实际业务场景中，这可以用来解决异构技术体系共存场景下的通信问题，帮助公司实现在异构技术体系间作平滑迁移，解决大规模跨区域、多集群部署场景的地址发现及流量调度等问题。
+
+## 面向接口代理的透明服务开发框架
+
+我们还是从 **Dubbo 是一个微服务开发框架** 这个大家熟知的概念开始。就像 Spring 是开发 Java 应用的基础框架一样，我们经常会选用 Dubbo 作为开发微服务业的基础框架。 Dubbo 框架的最大优势我认为就在其面向接口的编程模型，使得开发远程服务调用就像开发本地服务一样（以 Java 语言为例）：
+
+1. 服务定义
+
+```java
+public interface GreetingsService {
+ String sayHi(String name);
+}
+```
+
+2. 消费方调用服务
+
+```java
+// 和调用本地服务一样，完全透明。
+@Reference
+private GreetingService greetingService;
+
+public void doSayHello(String name) {
+ greetingService.sayHi("Hello world!");
+}
+```
+
+下图是 Dubbo 的基本工作原理图，服务提供者与服务消费者之间通过注册中心协调地址，通过约定的协议实现数据交换。
+
+
+
+
+## 同构/异构微服务体系面临的问题
+
+关于 Dubbo 协议本身及其服务治理相关功能细节并不是本文的重点，我们今天将从一个更高的层次，来看看公司内部构建微服务体系所面的挑战，以及 Dubbo 能为架构选型和迁移等提供哪些解决思路。
+
+一个公司内部的微服务可能都是基于某一个相同的服务框架开发的，比如说 Dubbo，对于这样的架构，我们称之为是**同构的微服务体系**；而有些公司的微服务可能是使用多个不同的服务框架所建设，我们称之为**异构的微服务体系**，多个不同技术栈微服务体系的共存在大型组织内还是非常普遍的，造成这种局面可能有很多原因。比如，可能是遗留系统带来的，也可能是公司正在做技术栈迁移，或者就是不同业务部门为了满足各自特殊需求而做的独立选型（这也意味着异构微服务体系的长期共存）。
+
+**1. 异构微服务体系共存**
+
+我们很容易想到的一个挑战是：**不同的体系间通常是使用不同的 RPC 通信协议、部署独立的注册中心集群，面对这种多协议、多注册中心集群的场景，要如何实现相互之间透明的地址发现和透明的 RPC 调用？**如果我们什么都不做，那么每个微服务体系就只能感知到自己体系内的服务状态，流量也在各自的体系内封闭。而要做到从体系 A 平滑的迁移到体系 B，或者想长期的保持公司内部多个体系的共存，则解决不同体系间的互联互通，实现流量的透明调度将是非常重要的环节。
+
+
+
+
+**2. Dubbo 体系内部**
+
+**多协议、多注册中心集群的问题在同构的微服务体系中也可能存在，尤其是当一个组织内部的微服务规模增长到一定量级的时候。**
+
+* 我们可能要在不同的服务之间采用不同的通信协议，因为不同的服务面临不同的业务场景，而这也进一步导致了数据传输特点的不同，我们需要分别采用更适合各类业务特点的协议。比如典型的场景：我们可能对于普通的业务服务采用 Dubbo 协议，对于和 FrontEnd 交互的服务需要 HTTP 协议，而对于需要流式数据传输的业务则采用 gRPC 协议等等。
+
+* Dubbo 体系内部另一个常出现的问题是，在大规模分布式部署的场景下，微服务系统会做跨区域、跨注册中心的部署，这个时候就会出现多集群间地址同步和流量调度的问题。
+
+总结起来，**不论是同构体系还是异构体系，都面临对多协议通信、多注册中心集群地址发现的问题。**Dubbo 目前是支持多协议、多注册中心的，可以说就是为解决我们上面分析的 Dubbo 同构体系内的场景而设计的，因此下面我们从同构体系的多协议、多注册中心场景讲起，先了解 Dubbo 多协议、多注册中心的基本支持情况以及它们是如何工作的。而在后面的一章再进一步探索怎么扩展这个能力来支持异构微服务体系的互联互通。
+
+## Dubbo 体系内的多协议、多注册中心机制
+
+我们将通过两个场景示例，来分别具体的讲一下 Dubbo 的多协议、多注册中心机制的使用方式和工作原理。
+
+### 多协议
+
+
+
+以上是使用 Dubbo 开发的一套微服务，服务间通信使用到了不同的协议，根据我们的调研发现，公司内部启用多协议其实是非常普遍需求，具体场景在此我们暂不做解释。
+
+应用 B 作为服务提供者，发布了 5 个服务，其中：
+
+* `DemoService1` `DemoService2` 通过 `dubbo` 协议发布
+* `DemoService3` `DemoService4` 通过 `gRPC` 协议发布
+* `DemoService0` 通过 `dubbo` 、`gRPC` 双协议发布
+
+应用 A 作为消费者，使用 dubbo 协议消费 `DemoService1` `DemoService2`，使用 gRPC 协议消费 `DemoService0`。
+
+应用 B 作为消费者，使用 gRPC 协议消费 `DemoService2` `DemoService4`，使用 dubbo 协议消费 `DemoService0`。
+
+以下是具体的代码配置：
+
+1. 提供端应用 B
+
+```xml
+<dubbo:service interface="org.apache.dubbo.samples.basic.api.DemoService1" protocol="dubbo"/>
+<dubbo:service interface="org.apache.dubbo.samples.basic.api.DemoService2" protocol="dubbo"/>
+
+<dubbo:service interface="org.apache.dubbo.samples.basic.api.DemoService3" protocol="grpc"/>
+<dubbo:service interface="org.apache.dubbo.samples.basic.api.DemoService4" protocol="grpc"/>
+
+<dubbo:service interface="org.apache.dubbo.samples.basic.api.DemoService0" protocol="dubbo, grpc"/>
+```
+
+2. 消费端应用 A
+
+```xml
+<dubbo:reference protocol="dubbo" interface="org.apache.dubbo.samples.basic.api.DemoService1"/>
+<dubbo:reference protocol="dubbo" interface="org.apache.dubbo.samples.basic.api.DemoService2"/>
+
+<dubbo:reference protocol="grpc" interface="org.apache.dubbo.samples.basic.api.DemoService0"/>
+```
+
+3. 消费端应用 C
+
+```xml
+<dubbo:reference protocol="grpc" interface="org.apache.dubbo.samples.basic.api.DemoService3"/> <dubbo:reference protocol="grpc" interface="org.apache.dubbo.samples.basic.api.DemoService4"/>
+
+<dubbo:reference protocol="dubbo" interface="org.apache.dubbo.samples.basic.api.DemoService0"/>
+
+```
+
+#### Dubbo 多协议支持现状
+
+Dubbo 目前所支持的协议包括 Dubbo、REST、Thrift、gRPC、JsonRPC、Hessian 等，基本涵盖了业界大多数主流的 RPC 通信协议。需要注意的是，这些协议的支持都是以直接集成官方 Release 实现的形式来做的，我认为这是一个很好的选择，既保证了协议解析自身的稳定性，又能使 Dubbo 社区更专注的将更多的精力放在 Dubbo 外围服务治理能力的改善上。试想如果 Dubbo 社区自己为每个协议提供实现，那是要花费多少精力和时间才能使每种协议达到稳定的生产可用。
+
+除了以上官方提供支持的协议之外，得益于 Dubbo 灵活的扩展机制，想要为 Dubbo 扩展协议非常容易，开发者可以随时为 Dubbo 增加更多的协议支持，包括自有协议扩展。
+
+关于对 gRPC (HTTP/2) 协议的支持，请参阅上期文档
+
+
+
+#### 多协议能解决的问题
+
+* 将 RPC 框架无缝地接入 Dubbo 的服务治理体系。
+
+ 通过协议扩展将 RPC 协议纳入 Dubbo 服务开发体系，从而复用 Dubbo 的编程模型和服务发现、流量管控等能力。比如 gRPC，其服务治理体系相对比较弱、编程 API 不够友好，很难直接用于微服务开发。
+
+* 满足不同场景的调用需求。
+
+ 各个服务可能是为了满足不同业务需求而开发，同时外围消费端应用的技术栈也可能多种多样，通过启用不同的通信协议，可以最优化不同场景的通信需求。
+
+* 实现协议间的迁移。
+
+ 通过支持多种协议，借助注册中心的协调，可以快速满足公司内协议迁移的需求。如从自有协议升级到 Dubbo 协议，Dubbo 协议自身升级，从 Dubbo 协议迁移到 gRPC，从 REST 迁移到 Dubbo 协议等。
+
+
+### 多注册中心
+
+当服务集群规模小的时候，一个中心化的集群部署方案能很好的解决我们的业务问题。但是随着应用规模的增长、用户流量的增加，我们就不得不考虑要为业务系统引入跨区域、多集群的部署方案，而此时同业务系统密切相关的注册中心集群也面临部署方案的选型：
+
+1. 继续维持全局共享的注册中心集群。这种架构方案的优点是简单；缺点是注册中心集群由于要保存全量的地址数据，存储和推送压力会变得很大，另外对于一些注册中心产品（如 Zookeeper 等）在跨集群网络部署的场景下稳定性和性能可能都会面临挑战。
+
+2. 每个业务集群部署独立的注册中心集群。多注册中心集群的优点是能解决跨集群网络可用性的问题，同时也能够减轻注册中心的存储和推送压力；缺点则是要求服务框架（如 Dubbo 等）能有同时发布/监听多个注册中心集群的能力。
+
+下面我们具体看一下，Dubbo 为多注册中心集群场景提供的解决方案。
+
+
+
+上图有两个业务集群，分别部署在北京和上海，每个业务集群有自己独立的注册中心集群，要解决两个业务集群间服务的透明 RPC 通信问题。
+
+1. 服务提供端，双注册中心发布
+
+```xml
+<dubbo:registry id="beijingRegistry" address="zookeeper://${zookeeper.address1}" default="false"/> <dubbo:registry id="shanghaiRegistry" address="zookeeper://${zookeeper.address2}" />
+
+<dubbo:service interface="org.apache.dubbo.samples.multi.registry.api.HelloService" ref="helloService" registry="shanghaiRegistry,beijingRegistry"/>
+<dubbo:service interface="org.apache.dubbo.samples.multi.registry.api.DemoService" ref="demoService" registry="shanghaiRegistry,beijingRegistry"/>
+
+```
+
+2. 服务消费端，根据消费需求做单/双注册中心订阅
+
+```xml
+<dubbo:registry id="beijingRegistry" address="zookeeper://${zookeeper.address1}" default="false" preferred="true" weight="100"/> <dubbo:registry id="shanghaiRegistry" address="zookeeper://${zookeeper.address2}" default="true" weight="20"/>
+
+<dubbo:reference interface="org.apache.dubbo.samples.multi.registry.api.DemoService"/>
+
+<dubbo:reference interface="org.apache.dubbo.samples.multi.registry.api.DemoService" registry="beijingRegistry, shanghaiRegistry"/>
+
+<dubbo:reference interface="org.apache.dubbo.samples.multi.registry.api.HelloService" registry="beijingRegistry"/>
+
+<dubbo:reference interface="org.apache.dubbo.samples.multi.registry.api.HelloService" registry="shanghaiRegistry,shanghaiRegistry"/>
+
+```
+
+#### Dubbo 对异构注册中心集群的支持
+
+虽然我们会做多注册中心集群部署，但通常情况下，我们部署的都是相同的注册中心产品，如都是 Zookeeper、Nacos；而对于注册中心迁移的场景，则要求 Dubbo 能提供对更多的注册中心产品的支持，或者最重要的要有很好的扩展能力。Dubbo 官方目前支持的注册中心实现有：
+
+
+
+这里需要特别提到的一点是，当前 Dubbo 的服务注册/发现模型是以接口为粒度的，而从 2.7.5 版本开始，Dubbo 新引入了应用粒度的服务注册/发现模型。这一方面有助于优化 Dubbo 当前服务发现机制、提升服务容量，另一方面对于联通以 SpringCloud 为代表的微服务体系也非常重要（关于这点在下一章中有进一步提及）。更多关于《应用粒度服务发现：服务自省》的介绍，我们将在接下来的文章或文档中予以补充，请持续关注。
+
+#### 多订阅带来的流量调度问题
+
+在引入多注册中心集群后，Dubbo 在流量选址时的多了一层注册中心集群间的负载均衡：
+
+
+
+在 Cluster Invoker 这一级，我们支持的选址策略有（2.7.5+ 版本，具体使用请参见文档）：
+
+* 指定优先级
+
+ ```xml
+ <!-- 来自 preferred=“true” 注册中心的地址将被优先选择，只有该中心无可用地址时才 Fallback 到其他注册中心 -->
+ <dubbo:registry address="zookeeper://${zookeeper.address1}" preferred="true" />
+ ```
+
+* 同 zone 优先
+
+ ```xml
+ <!-- 选址时会和流量中的 zone key 做匹配，流量会优先派发到相同 zone 的地址 -->
+ <dubbo:registry address="zookeeper://${zookeeper.address1}" zone="beijing" />
+ ```
+
+* 权重轮询
+
+ ```xml
+ <!-- 来自北京和上海集群的地址，将以 10:1 的比例来分配流量 -->
+ <dubbo:registry id="beijing" address="zookeeper://${zookeeper.address1}" weight=”100“ />
+ <dubbo:registry id="shanghai" address="zookeeper://${zookeeper.address2}" weight=”10“ />
+ ```
+
+* 默认，stick to 任意可用
+
+#### 多注册中心适用的场景
+
+* 同区域流量优先调度
+
+ 出于容灾或者服务伸缩性需求，服务/应用往往需要部署在多个独立的机房/区域，在每个区域有独立注册中心集群的场景下，实现同区域的流量优先调度就能很好的解决延迟和可用性问题。
+
+* 注册中心迁移
+
+ 公司的服务一直以来可能是存储在某一个注册中心，如 Zookeeper，但到了某个时间节点，因为各种各样的原因，当我们要迁移到另外的注册中心时，多注册中心模型能够保证平滑的迁移。
+
+* 异构系统互通
+
+ 不同微服务体系开发的服务，都封闭在各自的服务发现体系中，而通过统一的多注册中心模型，可以实现不同体系的服务互相发现。
+
+## 借助 Dubbo 联通异构的微服务体系
+
+上文我们提到了在组织内存在异构微服务体系的各种合理可能性，现在我们来具体看一下异构微服务体系的实际场景，以及使用 Dubbo 实现互联互通的解决方法。首先我们先通过一张图来看一下，联通异构的微服务体系具体是一个什么样的场景。
+
+
+
+如上图所示，我们有部分微服务可以是基于 SpringCloud、gRPC、K8S 或者是自建体系构建的，他们各自之间默认是相互隔离无法联通的。当我们再构建一套基于 Dubbo 的微服务体系时，则利用 Dubbo 的多协议、多服务发现模型，我们就可以做到和各个微服务体系间的两两之间的互联互通。进一步的，如图中橙色箭头所示，依赖 Dubbo 体系作为桥接层，我们还可以实现两个异构微服务体系间的打通。
+
+对于以下几个示例场景，由于在地址发现层面目前没有统一的标准，我们暂且假设地址发现层面不同的体系建是没有障碍的，我们将重点关注迁移的基本流程以及通信协议环节。（关于地址发现部分，我们将在后续《服务自省：基于应用粒度的服务发现》之后再深入探讨）
+
+### Dubbo 体系内的协议迁移（共存）
+
+绝大多数开发者对 Dubbo 有这么一个固有认知：使用 Dubbo 开发微服务系统，则就要用 Dubbo 协议来作为服务间的通信协议才是最优方案。实际上，我们完全没有必要只束缚在 Dubbo RPC 协议上。Dubbo 作为微服务开发框架和 Dubbo 作为 RPC 协议这是两个概念，其实是完全可以分开来看待的，比如我们用 Dubbo 框架开发的业务系统，选用 rest、gRPC 通信是完全没有问题的（参加 Dubbo 支持的协议列表），具体用什么协议根据业务特点和技术规划才是最适合的。
+
+
+
+当前在云原生、Mesh 的大背景下， HTTP1/2、gRPC 协议开始受到越来越多的关注，一方面原因自然是因为它们在标准化方面做的更好，得到的更多的网络设备和基础设施的支持，具备更好的通用性和穿透性。对于很多有云原生迁移意愿的企业来说，往此类协议迁移无疑将对之后的架构升级有更多的帮助。
+
+下图演示了在 Dubbo 体系内，从 Dubbo 协议向 gRPC 协议迁移的一个中间状态。
+
+
+
+* 最左边的代表尚未迁移的老应用，这类应用在迁移过程中仍然要消费和提供 Dubbo 协议的服务。
+* 中间的代表处于迁移中的应用，他们中间可能有些是服务提供者，既要为左边的老系统提供提供 Dubbo 协议服务；又要为右边的新系统提供 gRPC 服务；因此他们都是双协议暴露服务。
+* 最右边则代表是新开发的或者已经迁移完成的应用，这个体系内已能完全用 gRPC 协议通信。
+* 最终度过中间态后，我们期望所有的应用都达到最左边应用的状态，实现完全的 gRPC 协议通信。
+
+### Spring Cloud 体系迁移到 Dubbo 体系（共存）
+
+如前文所述，由于 SpringCloud 和 Dubbo 间服务发现模型的问题，要两个体系间的地址互通需要 Dubbo 侧作相应的适配，关于这部分内容将在接下来的 2.7.5 版本《服务自省》部分发布，在此我们暂且认为已经打通。
+
+
+
+Dubbo 体系内的部分应用作为透明的联通两个体系的关键节点，部分服务提供者应用要双协议发布、部分消费者应用要做到选定协议消费。由于老的 Spring Cloud 体系不允许做任何改动，因此联通两套体系的关键是 REST 协议，对 Dubbo 侧的应用来说：
+
+* 部分应用可能要以 REST 协议消费 SpringCloud 的服务；
+* 部分应用可能要暴露 REST 协议共 SpringCloud 消费；
+* Dubbo 自有体系内则通过自己选定的协议通信，这里就比较灵活了，可以是 Dubbo、REST、gRPC 等其中的任一种。而如果选定 REST 协议则对于与 SpringCloud 体系的联通就变得更加自然了，因为两端的协议都是统一的。
+
+对于消费 Spring Cloud 服务的应用，要配置服务 ：
+
+```xml
+<dubbo:reference interface ="xxx.SpringService" protocol="rest"/>
+```
+
+对于提供服务给 Spring Cloud 侧消费的应用，则指定服务暴露为 rest 协议，或者双协议暴露（因如果这个服务还要被新体系内的应用调用到）：
+
+```xml
+<dubbo:service interface="xxx.NewService" protocol="rest,dubbo"/>
+```
+
+作为 Dubbo 的维护者，虽然我们这里有明显的偏向性，讲的是从如何从 SpringCloud 体系迁移到 Dubbo 体系。但是反过来考虑，如果你已经或者即将选型 Dubbo 来开发微服务，则未来从 Dubbo 迁移到 SpringCloud 也是同样的思路，Dubbo 的多协议、多注册模型为双向迁移都提供了同样的灵活性。
+
+### 自建体系迁移到 Dubbo 体系（共存）
+
+这个场景和上一节中讲到的的 SpringCloud 迁移有些类似，最大的区别在于 rest 协议是 Dubbo 官方默认提供支持的，而对于已有的微服务体系内的私有通信协议，则需要先要自己去扩展 Dubbo Protocol 来提供协议层面的支持，关于 Protocol 如何扩展请参见以下官方文档：
+
+http://dubbo.apache.org/zh-cn/docs/dev/impls/protocol.html
+
+## 总结与展望
+
+要实现异构微服务体系间的共存或迁移，关键点在打通异构体系间的`协议`与`服务发现`，得益于 Dubbo 自身对多协议、多注册模型的支持，我们可以很容易的使 Dubbo 成为桥接异构微服务体系的中间层。熟悉 Dubbo 多协议实现细节的同学，可能会担心在服务数量较多的场景下，多协议注册会导致地址数量翻倍从而影响地址推送性能；另外在文中《借助 Dubbo 联通异构的微服务体系》一节，关于如何实现异构体系间的透明服务发现部分我们没有做详细的说明。关于涉及服务发现的这部分，我们将在接下来的文章中做具体阐述，看看 Dubbo 2.7.5 版本引入新的服务发现机制是如何解决这个问题的，请持续关注后续文章及 Dubbo 官方文档。
\ No newline at end of file
diff --git a/blog/zh-cn/dubbo-practice-from-guazi.md b/blog/zh-cn/dubbo-practice-from-guazi.md
new file mode 100644
index 0000000..25bba40
--- /dev/null
+++ b/blog/zh-cn/dubbo-practice-from-guazi.md
@@ -0,0 +1,169 @@
+# dubbo在瓜子二手车的实践
+
+## 前言
+
+  随着瓜子业务的不断发展，系统规模在逐渐扩大，目前在瓜子的私有云上已经运行着数百个dubbo应用，上千个dubbo实例。瓜子各部门业务迅速发展，版本没有来得及统一，各个部门都有自己的用法。随着第二机房的建设，dubbo版本统一的需求变得越发迫切。几个月前，公司发生了一次与dubbo相关的生产事故，成为了公司dubbo版本升级的诱因。
+
+  接下来，我会从这次事故开始，讲讲我们这段时间所做的dubbo版本升级的历程以及dubbo后续多机房的方案。
+
+## 一、Ephermal节点未及时删除导致provider不能恢复注册的问题修复
+
+### 事故背景
+
+  在生产环境，瓜子内部各业务线共用一套zookeeper集群作为dubbo的注册中心。2019年9月份，机房的一台交换机发生故障，导致zookeeper集群出现了几分钟的网络波动。在zookeeper集群恢复后，正常情况下dubbo的provider应该会很快重新注册到zookeeper上，但有一小部分的provider很长一段时间没有重新注册到zookeeper上，直到手动重启应用后才恢复注册。
+
+### 排查过程
+
+  首先，我们统计了出现这种现象的dubbo服务的版本分布情况，发现在大多数的dubbo版本中都存在这种问题，且发生问题的服务比例相对较低，在github中我们也未找到相关问题的issues。因此，推断这是一个尚未修复的且在网络波动情况的场景下偶现的问题。
+
+  接着，我们便将出现问题的应用日志、zookeeper日志与dubbo代码逻辑进行相互印证。在应用日志中，应用重连zookeeper成功后provider立刻进行了重新注册，之后便没有任何日志打印。而在zookeeper日志中，注册节点被删除后，并没有重新创建注册节点。对应到dubbo的代码中，只有在`FailbackRegistry.register(url)`的`doRegister(url)`执行成功或线程被挂起的情况下，才能与日志中的情况相吻合。
+
+```java
+ public void register(URL url) {
+ super.register(url);
+ failedRegistered.remove(url);
+ failedUnregistered.remove(url);
+ try {
+ // Sending a registration request to the server side
+ doRegister(url);
+ } catch (Exception e) {
+ Throwable t = e;
+
+ // If the startup detection is opened, the Exception is thrown directly.
+ boolean check = getUrl().getParameter(Constants.CHECK_KEY, true)
+ && url.getParameter(Constants.CHECK_KEY, true)
+ && !Constants.CONSUMER_PROTOCOL.equals(url.getProtocol());
+ boolean skipFailback = t instanceof SkipFailbackWrapperException;
+ if (check || skipFailback) {
+ if (skipFailback) {
+ t = t.getCause();
+ }
+ throw new IllegalStateException("Failed to register " + url + " to registry " + getUrl().getAddress() + ", cause: " + t.getMessage(), t);
+ } else {
+ logger.error("Failed to register " + url + ", waiting for retry, cause: " + t.getMessage(), t);
+ }
+
+ // Record a failed registration request to a failed list, retry regularly
+ failedRegistered.add(url);
+ }
+ }
+```
+  在继续排查问题前，我们先普及下这些概念：dubbo默认使用curator作为zookeeper的客户端，curator与zookeeper是通过session维持连接的。当curator重连zookeeper时，若session未过期，则继续使用原session进行连接；若session已过期，则创建新session重新连接。而ephemeral节点与session是绑定的关系，在session过期后，会删除此session下的ephemeral节点。
+
+  继续对`doRegister(url)`的代码进行进一步排查，我们发现在`CuratorZookeeperClient.createEphemeral(path)`方法中有这么一段逻辑：在`createEphemeral(path)`捕获了`NodeExistsException`，创建ephemeral节点时，若此节点已存在，则认为ephemeral节点创建成功。这段逻辑初看起来并没有什么问题，且在以下两种常见的场景下表现正常：
+
+1. Session未过期，创建Ephemeral节点时原节点仍存在,不需要重新创建
+1. Session已过期，创建Ephemeral节点时原节点已被zookeeper删除，创建成功
+
+```java
+ public void createEphemeral(String path) {
+ try {
+ client.create().withMode(CreateMode.EPHEMERAL).forPath(path);
+ } catch (NodeExistsException e) {
+ } catch (Exception e) {
+ throw new IllegalStateException(e.getMessage(), e);
+ }
+ }
+```
+  但是实际上还有一种极端场景，**zookeeper的Session过期与删除Ephemeral节点不是原子性的**，也就是说客户端在得到Session过期的消息时，Session对应的Ephemeral节点可能还未被zookeeper删除。此时dubbo去创建Ephemeral节点,发现原节点仍存在，故不重新创建。待Ephemeral节点被zookeeper删除后，便会出现dubbo认为重新注册成功，但实际未成功的情况，也就是我们在生产环境遇到的问题。
+
+  此时，问题的根源已被定位。定位问题之后，我们与dubbo社区交流，发现考拉的同学也遇到过同样的问题，更确定了这个原因。
+
+### 问题的复现与修复
+
+  定位到问题之后，我们便开始尝试本地复现。由于zookeeper的Session过期但Ephemeral节点未被删除的场景直接模拟比较困难，我们通过修改zookeeper源码，在Session过期与删除Ephemeral节点的逻辑中增加了一段休眠时间，间接模拟出这种极端场景，并在本地复现了此问题。
+
+  在排查问题的过程中，我们发现kafka的旧版本在使用zookeeper时也遇到过类似的问题，并参考kafka关于此问题的修复方案，确定了dubbo的修复方案。在创建Ephemeral节点捕获到`NodeExistsException`时进行判断，若Ephemeral节点的SessionId与当前客户端的SessionId不同，则删除并重建Ephemeral节点。在内部修复并验证通过后，我们向社区提交了issues及pr。
+
+  kafka类似问题issues：https://issues.apache.org/jira/browse/KAFKA-1387
+
+  dubbo注册恢复问题issues：https://github.com/apache/dubbo/issues/5125
+
+## 二、瓜子的dubbo升级历程
+
+  上文中的问题修复方案已经确定，但我们显然不可能在每一个dubbo版本上都进行修复。在咨询了社区dubbo的推荐版本后，我们决定在dubbo2.7.3版本的基础上，开发内部版本修复来这个问题。并借这个机会，开始推动公司dubbo版本的统一升级工作。
+
+### 为什么要统一dubbo版本
+1. 统一dubbo版本后，我们可以在此版本上内部紧急修复一些dubbo问题（如上文的dubbo注册故障恢复失效问题）。
+2. 瓜子目前正在进行第二机房的建设，部分dubbo服务也在逐渐往第二机房迁移。统一dubbo版本，也是为dubbo的多机房做铺垫。
+3. 有利于我们后续对dubbo服务的统一管控。
+4. dubbo社区目前的发展方向与我们公司现阶段对dubbo的一些诉求相吻合，如支持gRPC、云原生等。
+
+### 为什么选择dubbo2.7.3
+1. 在我们之前，携程与dubbo社区合作进行了携程dubbo内部版本的升级，并在社区2.7.3版本上修复了很多兼容性问题。感谢携程的同学帮我们踩坑～
+2. dubbo2.7.3版本在当时虽然是最新的版本，但已经发布了2个月的时间，从社区issues反馈来看，dubbo2.7.3相对dubbo2.7之前的几个版本，在兼容性方面要好很多。
+3. 我们也咨询了dubbo社区的同学，推荐升级版本为2.7.3。
+
+### 内部版本定位
+
+  基于社区dubbo2.7.3版本开发的dubbo内部版本属于过渡性质的版本，目的是为了修复线上provider不能恢复注册的问题，以及一些社区dubbo2.7.3的兼容性问题。瓜子的dubbo最终还是要跟随社区的版本，而不是开发自已的内部功能。因此我们在dubbo内部版本中修复的所有问题均与社区保持了同步，以保证后续可以兼容升级到社区dubbo的更高版本。
+
+### 兼容性验证与升级过程
+
+  我们在向dubbo社区的同学咨询了版本升级方面的相关经验后，于9月下旬开始了dubbo版本的升级工作。
+1. **初步兼容性验证**
+首先,我们梳理了一些需要验证的兼容性case，针对公司内部使用较多的dubbo版本，与dubbo2.7.3一一进行了兼容性验证。经验证，除dubboX外，dubbo2.7.3与其他dubbo版本均兼容。dubboX由于对dubbo协议进行了更改，与dubbo2.7.3不兼容。
+1. **生产环境兼容性验证**
+在初步验证兼容性通过后，我们与业务线合作，挑选了一些重要程度较低的项目，在生产环境对dubbo2.7.3与其他版本的兼容性进行了进一步验证。并在内部版本修复了一些兼容性问题。
+1. **推动公司dubbo版本升级**
+在10月初，完成了dubbo兼容性验证后，我们开始在各个业务线推动dubbo的升级工作。截止到12月初,已经有30%的dubbo服务的完成了版本升级。按照排期，预计于2020年3月底前完成公司dubbo版本的统一升级。
+
+### 兼容性问题汇总
+
+  在推动升级dubbo2.7.3版本的过程整体上比较顺利,当然也遇到了一些兼容性问题：
+* **创建zookeeper节点时提示没有权限**
+ dubbo配置文件中已经配置了zookeeper的用户名密码，但在创建zookeeper节点时却抛出`KeeperErrorCode = NoAuth`的异常，这种情况分别对应两个兼容性问题：
+ * issues:https://github.com/apache/dubbo/issues/5076
+ dubbo在未配置配置中心时，默认使用注册中心作为配置中心。通过注册中心的配置信息初始化配置中心配置时，由于遗漏了用户名密码，导致此问题。
+ * issues:https://github.com/apache/dubbo/issues/4991
+ dubbo在建立与zookeeper的连接时会根据zookeeper的address复用之前已建立的连接。当多个注册中心使用同一个address，但权限不同时，就会出现`NoAuth`的问题。
+ 参考社区的pr，我们在内部版本进行了修复。
+
+* **curator版本兼容性问题**
+ * dubbo2.7.3与低版本的curator不兼容，因此我们默认将curator版本升级至4.2.0
+ ```xml
+ <dependency>
+ <groupId>org.apache.curator</groupId>
+ <artifactId>curator-framework</artifactId>
+ <version>4.2.0</version>
+ </dependency>
+ <dependency>
+ <groupId>org.apache.curator</groupId>
+ <artifactId>curator-recipes</artifactId>
+ <version>4.2.0</version>
+ </dependency>
+ ```
+ * 分布式调度框架elastic-job-lite强依赖低版本的curator,与dubbo2.7.3使用的curator版本不兼容,这给dubbo版本升级工作带来了一定阻塞。考虑到elastic-job-lite已经很久没有人进行维护，目前一些业务线计划将elastic-job-lite替换为其他的调度框架。
+* **openFeign与dubbo兼容性问题**
+ issues: https://github.com/apache/dubbo/issues/3990
+ dubbo的ServiceBean监听spring的ContextRefreshedEvent,进行服务暴露。openFeign提前触发了ContextRefreshedEvent，此时ServiceBean还未完成初始化，于是就导致了应用启动异常。
+ 参考社区的pr，我们在内部版本修复了此问题。
+* **RpcException兼容性问题**
+ dubbo低版本consumer不能识别dubbo2.7版本provider抛出的`org.apache.dubbo.rpc.RpcException`。因此，在consumer全部升级到2.7之前，不建议将provider的`com.alibaba.dubbo.rpc.RpcException`改为`org.apache.dubbo.rpc.RpcException`
+* **qos端口占用**
+ dubbo2.7.3默认开启qos功能，导致一些混部在物理机的dubbo服务升级时出现qos端口占用问题。关闭qos功能后恢复。
+* **自定义扩展兼容性问题**
+ 业务线对于dubbo的自定义扩展比较少，因此在自定义扩展的兼容性方面暂时还没有遇到比较难处理的问题，基本上都是变更package导致的问题，由业务线自行修复。
+* **skywalking agent兼容性问题**
+ 我们项目中一般使用skywalking进行链路追踪，由于skywalking agent6.0的plugin不支持dubbo2.7，因此统一升级skywalking agent到6.1。
+
+## 三、dubbo多机房方案
+
+  瓜子目前正在进行第二机房的建设工作，dubbo多机房是第二机房建设中比较重要的一个话题。在dubbo版本统一的前提下，我们就能够更顺利的开展dubbo多机房相关的调研与开发工作。
+
+### 初步方案
+
+  我们咨询了dubbo社区的建议，并结合瓜子云平台的现状，初步确定了dubbo多机房的方案。
+1. 在每个机房内，部署一套独立的zookeeper集群。集群间信息不同步。这样就没有了zookeeper集群跨机房延迟与数据不同步的问题。
+1. dubbo服务注册时，仅注册到本机房的zookeeper集群；订阅时，同时订阅两个机房的zookeeper集群。
+1. 实现同机房优先调用的路由逻辑。以减少跨机房调用导致的不必要网络延迟。
+
+### 同机房优先调用
+
+  dubbo同机房优先调用的实现比较简单，相关逻辑如下：
+1. 瓜子云平台默认将机房的标志信息注入容器的环境变量中。
+1. provider暴露服务时，读取环境变量中的机房标志信息，追加到待暴露服务的url中。
+1. consumer调用provider时，读取环境变量中的机房标志信息，根据路由策略优先调用具有相同标志信息的provider。
+
+  针对以上逻辑，我们简单实现了dubbo通过环境变量进行路由的功能，并向社区提交了pr。
+  dubbo通过环境变量路由pr: https://github.com/apache/dubbo/pull/5348
diff --git a/docs/zh-cn/user/demos/auth.md b/docs/zh-cn/user/demos/auth.md
new file mode 100644
index 0000000..4ae72b1
--- /dev/null
+++ b/docs/zh-cn/user/demos/auth.md
@@ -0,0 +1,28 @@
+# 服务鉴权
+
+类似支付之类的对安全性敏感的业务可能会有限制匿名调用的需求。在加固安全性方面，2.7.5 引入了基于AK/SK机制的认证鉴权机制，并且引入了鉴权服务中心，主要原理是消费端在请求需要鉴权的服务时，会通过SK、请求元数据、时间戳、参数等信息来生成对应的请求签名，通过Dubbo的Attahcment机制携带到对端进行验签，验签通过才进行业务逻辑处理。如下图所示：
+
+
+
+
+
+具体的接入方式也并不复杂：
+
+1. 使用者需要在微服务站点上填写自己的应用信息，并为该应用生成唯一的证书凭证。
+
+2. 之后在管理站点上提交工单，申请某个敏感业务服务的使用权限，并由对应业务管理者进行审批，审批通过之后，会生成对应的AK/SK到鉴权服务中心。
+
+3. 导入该证书到对应的应用下，并且进行配置。配置方式也十分简单，以注解方式为例：
+
+ 服务提供端，只需要设置`service.auth`为true，表示该服务的调用需要鉴权认证通过。`param.sign`为`true`表示需要对参数也进行校验。
+
+ ```java
+ @Service(parameters = {"service.auth","true","param.sign","true"})
+ public class AuthDemoServiceImpl implements AuthService {
+ }
+
+ ```
+
+ 服务消费端，只需要配置好对应的证书等信息即可，之后会自动地在对这些需要认证的接口发起调用前进行签名操作，通过与鉴权服务的交互，用户无需在代码中配置AK/SK这些敏感信息，并且在不重启应用的情况下刷新AK/SK，达到权限动态下发的目的。
+
+该方案目前已经提交给Dubbo开源社区，并且完成了基本框架的合并，除了AK/SK的鉴权方式之外，通过SPI机制支持用户可定制化的鉴权认证以及适配公司内部基础设施的密钥存储。
diff --git a/docs/zh-cn/user/demos/consumer-threadpool.md b/docs/zh-cn/user/demos/consumer-threadpool.md
new file mode 100644
index 0000000..699bc2b
--- /dev/null
+++ b/docs/zh-cn/user/demos/consumer-threadpool.md
@@ -0,0 +1,41 @@
+# 消费端线程池模型
+
+2.7.5 版本对整个调用链路做了全面的优化，根据压测结果显示，总体 QPS 性能提升将近 30%，同时也减少了调用过程中的内存分配开销。其中一个值得提及的设计点是 2.7.5 引入了 Servicerepository 的概念，在服务注册阶段提前生成 ServiceDescriptor 和 MethodDescriptor，以减少 RPC 调用阶段计算 Service 原信息带来的资源消耗。
+
+## 消费端线程池模型优化
+
+对 2.7.5 版本之前的 Dubbo 应用，尤其是一些消费端应用，当面临需要消费大量服务且并发数比较大的大流量场景时（典型如网关类场景），经常会出现消费端线程数分配过多的问题，具体问题讨论可参见以下 issue ：
+
+https://github.com/apache/dubbo/issues/2013
+
+改进后的消费端线程池模型，通过复用业务端被阻塞的线程，很好的解决了这个问题。
+
+**老的线程池模型**
+
+
+
+我们重点关注 Consumer 部分：
+
+1. 业务线程发出请求，拿到一个 Future 实例。
+2. 业务线程紧接着调用 future.get 阻塞等待业务结果返回。
+3. 当业务数据返回后，交由独立的 Consumer 端线程池进行反序列化等处理，并调用 future.set 将反序列化后的业务结果置回。
+4. 业务线程拿到结果直接返回
+
+
+
+**2.7.5 版本引入的线程池模型**
+
+
+
+1. 业务线程发出请求，拿到一个 Future 实例。
+2. 在调用 future.get() 之前，先调用 ThreadlessExecutor.wait()，wait 会使业务线程在一个阻塞队列上等待，直到队列中被加入元素。
+3. 当业务数据返回后，生成一个 Runnable Task 并放入 ThreadlessExecutor 队列
+4. 业务线程将 Task 取出并在本线程中执行：反序列化业务数据并 set 到 Future。
+5. 业务线程拿到结果直接返回
+
+这样，相比于老的线程池模型，由业务线程自己负责监测并解析返回结果，免去了额外的消费端线程池开销。
+
+关于性能优化，在接下来的版本中将会持续推进，主要从以下两个方面入手：
+
+1. RPC 调用链路。目前能看到的点包括：进一步减少执行链路的内存分配、在保证协议兼容性的前提下提高协议传输效率、提高 Filter、Router 等计算效率。
+2. 服务治理链路。进一步减少地址推送、服务治理规则推送等造成的内存、cpu 资源消耗。
\ No newline at end of file
diff --git a/docs/zh-cn/user/demos/protobuf-idl.md b/docs/zh-cn/user/demos/protobuf-idl.md
new file mode 100644
index 0000000..463c94b
--- /dev/null
+++ b/docs/zh-cn/user/demos/protobuf-idl.md
@@ -0,0 +1,31 @@
+# 使用 IDL 定义服务
+当前 Dubbo 的服务定义和具体的编程语言绑定，没有提供一种语言中立的服务描述格式，比如 Java 就是定义 Interface 接口，到了其他语言又得重新以另外的格式定义一遍。
+2.7.5 版本通过支持 Protobuf IDL 实现了语言中立的服务定义。
+
+日后，不论我们使用什么语言版本来开发 Dubbo 服务，都可以直接使用 IDL 定义如下服务，具体请[参见示例](https://github.com/apache/dubbo-samples/tree/master/java/dubbo-samples-protobuf)
+
+```idl
+syntax = "proto3";
+
+option java_multiple_files = true;
+option java_package = "org.apache.dubbo.demo";
+option java_outer_classname = "DemoServiceProto";
+option objc_class_prefix = "DEMOSRV";
+
+package demoservice;
+
+// The demo service definition.
+service DemoService {
+ rpc SayHello (HelloRequest) returns (HelloReply) {}
+}
+
+// The request message containing the user's name.
+message HelloRequest {
+ string name = 1;
+}
+
+// The response message containing the greetings
+message HelloReply {
+ string message = 1;
+}
+```
\ No newline at end of file
diff --git a/docs/zh-cn/user/demos/tls.md b/docs/zh-cn/user/demos/tls.md
new file mode 100644
index 0000000..e78639c
--- /dev/null
+++ b/docs/zh-cn/user/demos/tls.md
@@ -0,0 +1,44 @@
+# 开启 TLS
+
+2.7.5 版本在传输链路的安全性上做了很多工作，对于内置的 Dubbo Netty Server 和新引入的 gRPC 协议都提供了基于 TLS 的安全链路传输机制。
+
+TLS 的配置都有统一的入口，如下所示：
+
+**Provider 端**
+
+```java
+SslConfig sslConfig = new SslConfig();
+sslConfig.setServerKeyCertChainPath("path to cert");
+sslConfig.setServerPrivateKeyPath(args[1]);
+// 如果开启双向 cert 认证
+if (mutualTls) {
+ sslConfig.setServerTrustCertCollectionPath(args[2]);
+}
+
+ProtocolConfig protocolConfig = new ProtocolConfig("dubbo/grpc");
+protocolConfig.setSslEnabled(true);
+```
+
+
+
+**Consumer 端**
+
+```java
+if (!mutualTls) {}
+ sslConfig.setClientTrustCertCollectionPath(args[0]);
+} else {
+ sslConfig.setClientTrustCertCollectionPath(args[0]);
+ sslConfig.setClientKeyCertChainPath(args[1]);
+ sslConfig.setClientPrivateKeyPath(args[2]);
+}
+```
+
+为尽可能保证应用启动的灵活性，TLS Cert 的指定还能通过 -D 参数或环境变量等方式来在启动阶段根据部署环境动态指定，具体请参见 Dubbo 配置读取规则与 TLS 示例
+
+Dubbo 配置读取规则：http://dubbo.apache.org/zh-cn/docs/user/configuration/configuration-load-process.html
+
+TLS 示例：https://github.com/apache/dubbo-samples/tree/master/java/dubbo-samples-ssl
+
+> 如果要使用的是 gRPC 协议，在开启 TLS 时会使用到协议协商机制，因此必须使用支持 ALPN 机制的 Provider，推荐使用的是 netty-tcnative，具体可参见 gRPC Java 社区的总结： https://github.com/grpc/grpc-java/blob/master/SECURITY.md
+
+在服务调用的安全性上，Dubbo 在后续的版本中会持续投入，其中服务发现/调用的鉴权机制预计在接下来的版本中就会和大家见面。
diff --git a/docs/zh-cn/user/new-features-in-a-glance.md b/docs/zh-cn/user/new-features-in-a-glance.md
new file mode 100644
index 0000000..13de0b0
--- /dev/null
+++ b/docs/zh-cn/user/new-features-in-a-glance.md
@@ -0,0 +1,47 @@
+# Dubbo 版本发布及新特性速览
+
+[TOC]
+
+## 版本速览
+Dubbo 社区目前主力维护的有 2.6.x 和 2.7.x 两大版本，其中，
+* 2.6.x 主要以 bugfix 和少量 enhancements 为主，因此能完全保证稳定性
+* 2.7.x 作为社区的主要开发版本，得到持续更新并增加了大量新 feature 和优化，同时也带来了一些稳定性挑战
+
+### 2.7.x 版本
+
+| | 版本 | 重要功能 | 升级建议 |
+| ---- | ------- | ------------------------------------------------------------ | ------------------------------- |
+| 1 | 2.7.5 | 服务自省<br />HTTP/2（gRPC） <br />Protobuf <br />TLS<br />性能优化<br /><br />https://github.com/apache/dubbo/releases/tag/dubbo-2.7.5 | 不建议大规模生产使用 |
+| 2 | 2.7.4.1 | [bugfixes and enhancements of 2.7.3](https://github.com/apache/dubbo/releases/tag/dubbo-2.7.4.1) | **推荐生产使用** |
+| 3 | 2.7.3 | [bigfixes of and enhancements of 2.7.2](https://github.com/apache/dubbo/releases/tag/dubbo-2.7.3) | **推荐生产使用** |
+| 4 | 2.7.2 | [bigfixes of and enhancements of 2.7.1](https://github.com/apache/dubbo/releases/tag/dubbo-2.7.2) | 不建议大规模生产使用 |
+| 5 | 2.7.1 | [bigfixes of and enhancements of 2.7.0](https://github.com/apache/dubbo/releases/tag/dubbo-2.7.1) | 不建议大规模生产使用 |
+| 6 | 2.7.0 | 异步编程模型 - 消费端/提供端异步<br />服务治理规则增强<br />简化的注册模型<br />配置中心、元数据中心<br />package 重构<br /><br />https://github.com/apache/dubbo/releases/tag/dubbo-2.7.0 | beta 版本，2.6.x 重构后首个版本 |
+
+
+### 2.6.x 及之前版本
+
+| | 版本 | 重要功能 | 升级建议 |
+| ---- | ------------ | ----------------------- | -------------------------------------- |
+| 1 | 2.6.x | bugfix | 建议持续升级最新版本，所有版本生产可用 |
+| 2 | 2.5.x | 停止维护 | 建议升级最新 2.6.x 版本 |
+| 3 | 2.4.x 及之前 | 停止维护 | 建议升级最新 2.6.x 版本 |
+
+
+## 值得关注的新特性
+* Dubbo 云原生计划（敬请期待...）
+* Kubernetes Native Service Discovery（敬请期待...）
+* [gRPC (HTTP/2) 协议](./references/protocol/gRPC.md)
+* [使用 Protobuf 定义 Dubbo 服务](./demos/protobuf-idl.md)
+* [TLS 安全传输](./demos/tls.md)
+* [实例级服务发现]()
+* [服务鉴权](./demos/auth.md)
+* 性能优化
+ * [调用链路提升 30%](../../../blog/zh-cn/2.7.5-release.md)
+ * [消费端线程模型](./demos/consumer-threadpool.md)
+ * [地址推送链路]()
+
+## 热门文章列表
+[从 2019 到 2020，Apache Dubbo 年度总结](../../../blog/zh-cn/apche-dubbo-2019-2020.md)
+[Dubbo 2.7.5 里程碑版本发布](../../../blog/zh-cn/2.7.5-release.md)
+[Dubbo 在协议与多语言方向的探索：支持 gRPC、Protobuf](../../../blog/zh-cn/Dubbo-supporting-gRPC-HTTP2-and-protobuf.md)
diff --git a/docs/zh-cn/user/references/protocol/gRPC.md b/docs/zh-cn/user/references/protocol/gRPC.md
new file mode 100644
index 0000000..af6c6b0
--- /dev/null
+++ b/docs/zh-cn/user/references/protocol/gRPC.md
@@ -0,0 +1,19 @@
+# grpc://
+
+Dubbo 自 2.7.5 版本开始支持 gRPC 协议，对于计划使用 HTTP/2 通信，或者想利用 gRPC 带来的 Stream、反压、Reactive 编程等能力的开发者来说，
+都可以考虑启用 gRPC 协议。
+
+## 支持 gRPC 的好处
+* 为期望使用 gRPC 协议的用户带来服务治理能力，方便接入 Dubbo 体系
+* 用户可以使用 Dubbo 风格的，基于接口的编程风格来定义和使用远程服务
+
+## 如何在 Dubbo 中使用 gRPC
+大概需要以下步骤：
+1. 使用 IDL 定义服务
+2. 配置 compiler 插件，本地预编译
+3. 配置暴露/引用 Dubbo 服务
+
+具体可参见以下[示例](https://github.com/apache/dubbo-samples/tree/master/java/dubbo-samples-grpc/dubbo-samples-original)
+
+除了原生 StreamObserver 接口类型之外，Dubbo 还支持 [RxJava](https://github.com/apache/dubbo-samples/tree/master/java/dubbo-samples-grpc/dubbo-samples-rxjava)、[Reactor](https://github.com/apache/dubbo-samples/tree/master/java/dubbo-samples-grpc/dubbo-samples-reactor) 编程风格的 API
+
diff --git a/img/docs/cluster-lb.png b/img/docs/cluster-lb.png
new file mode 100644
index 0000000..79c3f52
--- /dev/null
+++ b/img/docs/cluster-lb.png
Binary files differ
diff --git a/img/docs/community-distribution.png b/img/docs/community-distribution.png
new file mode 100644
index 0000000..34a87cd
--- /dev/null
+++ b/img/docs/community-distribution.png
Binary files differ
diff --git a/img/docs/community-github.png b/img/docs/community-github.png
new file mode 100644
index 0000000..db83ed8
--- /dev/null
+++ b/img/docs/community-github.png
Binary files differ
diff --git a/img/docs/community-meetup.png b/img/docs/community-meetup.png
new file mode 100644
index 0000000..5b3d1d0
--- /dev/null
+++ b/img/docs/community-meetup.png
Binary files differ
diff --git a/img/docs/config.png b/img/docs/config.png
new file mode 100644
index 0000000..8a0241c
--- /dev/null
+++ b/img/docs/config.png
Binary files differ
diff --git a/img/docs/consumer-threadpool0.png b/img/docs/consumer-threadpool0.png
new file mode 100644
index 0000000..c615813
--- /dev/null
+++ b/img/docs/consumer-threadpool0.png
Binary files differ
diff --git a/img/docs/consumer-threadpool1.png b/img/docs/consumer-threadpool1.png
new file mode 100644
index 0000000..20a1908
--- /dev/null
+++ b/img/docs/consumer-threadpool1.png
Binary files differ
diff --git a/img/docs/dubbo-screen.png b/img/docs/dubbo-screen.png
new file mode 100644
index 0000000..0d082ba
--- /dev/null
+++ b/img/docs/dubbo-screen.png
Binary files differ
diff --git a/img/docs/dubbo-screen2.png b/img/docs/dubbo-screen2.png
new file mode 100644
index 0000000..0ec5d7b
--- /dev/null
+++ b/img/docs/dubbo-screen2.png
Binary files differ
diff --git a/img/docs/filter.png b/img/docs/filter.png
new file mode 100644
index 0000000..a931c4e
--- /dev/null
+++ b/img/docs/filter.png
Binary files differ
diff --git a/img/docs/grpcrest.png b/img/docs/grpcrest.png
new file mode 100644
index 0000000..da18c82
--- /dev/null
+++ b/img/docs/grpcrest.png
Binary files differ
diff --git a/img/docs/heterogeneous.png b/img/docs/heterogeneous.png
new file mode 100644
index 0000000..010ed97
--- /dev/null
+++ b/img/docs/heterogeneous.png
Binary files differ
diff --git a/img/docs/idl-dubbo-compiler.png b/img/docs/idl-dubbo-compiler.png
new file mode 100644
index 0000000..b0bd475
--- /dev/null
+++ b/img/docs/idl-dubbo-compiler.png
Binary files differ
diff --git a/img/docs/microservices.png b/img/docs/microservices.png
new file mode 100644
index 0000000..fac19f8
--- /dev/null
+++ b/img/docs/microservices.png
Binary files differ
diff --git a/img/docs/migrate-final.png b/img/docs/migrate-final.png
new file mode 100644
index 0000000..cab455c
--- /dev/null
+++ b/img/docs/migrate-final.png
Binary files differ
diff --git a/img/docs/migrate.png b/img/docs/migrate.png
new file mode 100644
index 0000000..16d2b1b
--- /dev/null
+++ b/img/docs/migrate.png
Binary files differ
diff --git a/img/docs/multiregistries.png b/img/docs/multiregistries.png
new file mode 100644
index 0000000..d8f752c
--- /dev/null
+++ b/img/docs/multiregistries.png
Binary files differ
diff --git a/img/docs/multisubscribe.png b/img/docs/multisubscribe.png
new file mode 100644
index 0000000..94c5c12
--- /dev/null
+++ b/img/docs/multisubscribe.png
Binary files differ
diff --git a/img/docs/route-app.png b/img/docs/route-app.png
new file mode 100644
index 0000000..b7a095e
--- /dev/null
+++ b/img/docs/route-app.png
Binary files differ
diff --git a/img/docs/route-service.png b/img/docs/route-service.png
new file mode 100644
index 0000000..9de9db4
--- /dev/null
+++ b/img/docs/route-service.png
Binary files differ
diff --git a/img/docs/service-idl.png b/img/docs/service-idl.png
new file mode 100644
index 0000000..6375503
--- /dev/null
+++ b/img/docs/service-idl.png
Binary files differ
diff --git a/img/docs/service-idl2.png b/img/docs/service-idl2.png
new file mode 100644
index 0000000..db47456
--- /dev/null
+++ b/img/docs/service-idl2.png
Binary files differ
diff --git a/img/docs/servicediscovery-new.png b/img/docs/servicediscovery-new.png
new file mode 100644
index 0000000..7f647ec
--- /dev/null
+++ b/img/docs/servicediscovery-new.png
Binary files differ
diff --git a/img/docs/servicediscovery-old.png b/img/docs/servicediscovery-old.png
new file mode 100644
index 0000000..b0857f2
--- /dev/null
+++ b/img/docs/servicediscovery-old.png
Binary files differ
diff --git a/site_config/blog.js b/site_config/blog.js
index ef1a570..c4e171c 100644
--- a/site_config/blog.js
+++ b/site_config/blog.js
@@ -199,6 +199,48 @@
postsTitle: '所有文章',
list: [
{
+ title: 'Dubbo 在瓜子二手车的实践',
+ author: '@Lijintao',
+ dateStr: 'March 27, 2020',
+ desc: '瓜子二手车的 Dubbo 实践总结',
+ link: '/zh-cn/blog/dubbo-practice-from-guazi.html',
+ },
+ {
+ title: '从 2019 到 2020，Apache Dubbo 年度回顾与总结',
+ author: '@Chickenlj',
+ dateStr: 'March 27, 2020',
+ desc: '从 2019 到 2020，Apache Dubbo 年度回顾与总结',
+ link: '/zh-cn/blog/apache-dubbo-2019-2020.html',
+ },
+ {
+ title: '2.7.5 里程碑版本正式发布：支持 gRPC、性能提升 30%',
+ author: '@Chickenlj',
+ dateStr: 'March 27, 2020',
+ desc: '详细讲解 2.7.5 版本包含的新功能，包括 gRPC、protobuf、http/2、性能优化、实例级服务注册等',
+ link: '/zh-cn/blog/2.7.5-release.html',
+ },
+ {
+ title: '2.7.5 里程碑版本正式发布：支持 gRPC、性能提升 30%',
+ author: '@Chickenlj',
+ dateStr: 'March 27, 2020',
+ desc: '详细讲解 2.7.5 版本包含的新功能，包括 gRPC、protobuf、http/2、性能优化、实例级服务注册等',
+ link: '/zh-cn/blog/2.7.5-release.html',
+ },
+ {
+ title: 'Dubbo 在跨语言和协议穿透性方向上的探索：支持 HTTP/2 gRPC 和 Protobuf',
+ author: '@Chickenlj',
+ dateStr: 'March 27, 2020',
+ desc: 'Dubbo 在跨语言和协议穿透性方向上的探索：支持 HTTP/2 gRPC 和 Protobuf。',
+ link: '/zh-cn/blog/grpc-http2-protobuf.html',
+ },
+ {
+ title: '使用 Dubbo 连接异构微服务体系',
+ author: '@Chickenlj',
+ dateStr: 'March 27, 2020',
+ desc: '探索如何使用 Dubbo 的多协议、多注册中心机制连接异构微服务体系。',
+ link: '/zh-cn/blog/connect-heterogeneous-microservices.html',
+ },
+ {
title: 'Dubbo一致性Hash负载均衡实现剖析',
author: '@sofkyle',
dateStr: 'January 7th, 2020',
diff --git a/site_config/docs.js b/site_config/docs.js
index 6197c63..3ff1999 100644
--- a/site_config/docs.js
+++ b/site_config/docs.js
@@ -651,6 +651,10 @@
title: '用户文档',
children: [
{
+ title: 'Dubbo 版本及新特性速览',
+ link: '/zh-cn/docs/user/new-features-in-a-glance.html'
+ },
+ {
title: '入门',
children: [
{
@@ -907,6 +911,22 @@
title: '简化注册中心URL',
link: '/zh-cn/docs/user/demos/simplify-registry-data.html',
},
+ {
+ title: '启动TLS',
+ link: '/zh-cn/docs/user/demos/tls.html'
+ },
+ {
+ title: '服务鉴权',
+ link: '/zh-cn/docs/user/demos/auth.html'
+ },
+ {
+ title: 'IDL 定义服务',
+ link: '/zh-cn/docs/user/demos/protobuf-idl.html'
+ },
+ {
+ title: '消费端线程池',
+ link: '/zh-cn/docs/user/demos/consumer-threadpool.html'
+ }
],
},
{
@@ -1017,6 +1037,10 @@
title: 'rest://',
link: '/zh-cn/docs/user/references/protocol/rest.html',
},
+ {
+ title: 'grpc://',
+ link: '/zh-cn/docs/user/references/protocol/gRPC.html',
+ }
]
},
{
