dubbophp支撑技巧_里程碑式 Dubbo 275 版本宣告机能提升30支持 HTTP2TLSProtobuf等特点

近日，备受瞩目的 Apache Dubbo（以下简称 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 编程，请拜会示例

https://github.com/apache/dubbo-samples/tree/master/java/dubbo-samples-ssl 及 https://github.com/apache/dubbo-samples/tree/master/java/dubbo-samples-grpc 。
其余，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 定义如下做事，详细请拜会示例

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 greetingsmessage HelloReply { string message = 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 部分：

业务线程发出要求，拿到一个 Future 实例。

业务线程紧接着调用 future.get 壅塞等待业务结果返回。

当业务数据返回后，交由独立的 Consumer 端线程池进行反序列化等处理，并调用 future.set 将反序列化后的业务结果置回。

业务线程拿到结果直接返回

2.7.5 版本引入的线程池模型

业务线程发出要求，拿到一个 Future 实例。

在调用 future.get 之前，先调用 ThreadlessExecutor.wait，wait 会使业务线程在一个壅塞行列步队上等待，直到行列步队中被加入元素。

当业务数据返回后，天生一个 Runnable Task 并放入 ThreadlessExecutor 行列步队

业务线程将 Task 取出并在本线程中实行：反序列化业务数据并 set 到 Future。

业务线程拿到结果直接返回

这样，比较于老的线程池模型，由业务线程自己卖力监测并解析返回结果，免去了额外的消费端线程池开销。

关于性能优化，在接下来的版本中将会持续推进，紧张从以下两个方面入手：

RPC 调用链路。
目前能看到的点包括：进一步减少实行链路的内存分配、在担保协议兼容性的条件下提高协议传输效率、提高 Filter、Router 等打算效率。

做事管理链路。
进一步减少地址推送、做事管理规则推送等造成的内存、cpu 资源花费。

5. TLS 安全传输链路

2.7.5 版本在传输链路的安全性上做了很多事情，对付内置的 Dubbo Netty Server 和新引入的 gRPC 协议都供应了基于 TLS 的安全链路传输机制。

TLS 的配置都有统一的入口，如下所示：

Provider 端

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 端

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 编程为例，以前我们要这么写：

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 后，新的编程模型变得更大略，并且也为办理了短缺实例级启动入口的问题

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;