Dubbo

一、什么是RPC1.1 RPC概念RPC，Remote Procedure Call 即近程过程调用，与之绝对的是本地服务调用，即LPC(Local Procedure Call)。本地服务调用比拟罕用，像咱们利用外部程序(留神此处是程序而不是办法，程序蕴含办法)相互调用即为本地过程调用，而近程过程调用是指在本地调取近程过程进行应用。 而RPC框架就是为了帮忙咱们在本地调用近程过程时，就像调用本地过程一样不便。 1.2 RPC与Http的关系用一句话来总结就是： RPC是一种概念，http是一种协定，能够认为http是Rpc的一种实现，或者Rpc蕴含了http。为什么说蕴含而不是相等，是因为Rpc还有很多基于自定义的Tcp的协定，例如Dubbo等，而咱们常说的rpc即指的除Http之外的基于tcp自定义的协定。 1.3 对于Rpc的思考网上对于Rpc与Http的相干文章并不少，很多人在解释RPC概念时会提到其是执行近程的办法，而后间接得出rpc蕴含http的论断。其实如果依照此概念去思考的话，其实并不能得出Http是Rpc的一种实现。因为http调用的形式，从使用者的角度来说，并不是间接调用其办法，而是依照肯定的形式，欠缺出了一条http申请，而后交由本地客户端进行数据传输。 而绝对比的，如果用过相干Rpc框架，例如Dubbo，是能够像调用本地办法一样间接调用近程办法。而http的调用形式能够认为是一种服务调用，而不是一种办法。 感觉文章博主应该是有过rpc相干的应用教训，有点先入为主了。那么到底rpc与http的关系如何呢，我也思考了很久，前面发现应该从定义上动手，咱们既然在探讨Rpc是什么，怎么能疏忽最简略的定义呢。 Remote Procedure Call，其中"Procedure"依照谷歌翻译有以下几种解释：程序、过程、步骤，并不是办法(Method)。而程序是蕴含办法的，同时也蕴含服务。因而上文中才强调了是一种程序或过程，而不是办法。 1.4 Rpc框架Rpc框架是为了帮忙咱们在本地服务调用近程服务时像调用本地服务一样简略，咱们不须要关怀其底层实现，只须要配置好相应的信息，rpc框架就会帮咱们做这些事。例如在dubbo中，咱们只须要配置好相应的注册核心与想要调用的办法，咱们就能够依照本地调用的形式调用近程服务。 1.5 总结依照咱们上文的梳理过程，能够认为Rpc是一种概念，次要有两种实现，一种是以http形式的服务调用，另一种是以自定义Tcp协定实现的办法调用形式，例如dubbo协定，当然个别rpc框架也都反对http协定。当然，无论是那种形式，最终都是以Tcp/Udp的形式进行传输。 二、Rpc框架2.1 dubbo是什么咱们上文说到Rpc框架就是帮忙咱们在调用近程服务时像调用本地服务一样简略，dubbo就是由阿里巴巴开源的一块rpc框架。 例如，在咱们想调用某个近程办法时，只须要配置好相干配置，而后间接调用即可，dubbo会帮忙咱们将解决两头的过程。 /*省略相干配置*///将配置注册到spring@Resourceprivate QueryPinService queryPinService;//间接应用近程办法，像调用本地服务一样简略ueryPinService.getPinWithConfig(paramMap, null);dubbo整体架构图如下： 节点阐明Provider提供近程服务的服务提供方Registry注册核心Consumer须要调用近程服务的服务生产方Container服务运行的容器Monitor监控核心作用流程大抵如下： 首先服务提供者Provider 启动而后向注册核心注册本人所能提供的服务。 服务消费者Consumer 启动向注册核心订阅本人所需的服务。而后注册核心将提供者元信息告诉给 Consumer， 之后 Consumer 因为曾经从注册核心获取提供者的地址，因而能够通过负载平衡抉择一个 Provider 间接调用。 之后服务提供方元数据变更的话注册核心会把变更推送给服务消费者。 服务提供者和消费者都会在内存中记录着调用的次数和工夫，而后定时的发送统计数据到监控核心。 2.2 dubbo和spring cloud的区别首先两者都是以后支流的微服务框架，不过两者也存在很多差别： 初始定位不同：SpringCloud定位为微服务架构下的一站式解决方案，次要有网关、注册核心、配置核心、监控核心等；Dubbo 是 它的关注点次要在于服务的调用和治理，其中服务调用更时其外围。生态环境不同：SpringCloud依靠于Spring平台，具备更加欠缺的生态体系；而Dubbo一开始只是做RPC近程调用，生态绝对匮乏，当初逐步丰盛起来。调用形式：SpringCloud是采纳Http协定做近程调用，接口个别是Rest格调，比拟灵便；Dubbo是采纳Dubbo协定，接口个别是Java的Service接口，格局固定。但调用时采纳Netty的NIO形式，性能较好。两者组件配置： 很显著SpringCloud领有比dubbo更欠缺的配置，反对的功能性也更强。 相比来说，SpringCloud像一台品牌机，外部所有配置都曾经帮咱们拆卸好了，咱们只须要开箱即用即可。而dubbo则更像是组装机，须要咱们本人抉择配置，只提供了外围的计算能力，而显示器、电源等须要咱们本人拆卸调试应用。 从使用者来说，老手小白更适宜品牌机，傻瓜式一键操作，就能实现咱们想要的成果。而dubbo更适宜电脑高手，本人拆卸本人想要的组件，应用起来更棘手。 作者：京东科技 韩国凯 起源：京东云开发者社区 转载请注明起源

基于 Dubbo3 定义的 Triple 协定，你能够轻松编写浏览器、gRPC 兼容的 RPC 服务，并让这些服务同时运行在 HTTP/1 和 HTTP/2 上。Dubbo TypeScript SDK[1]反对应用 IDL 或编程语言特有的形式定义服务，并提供一套轻量的 APl 来公布或调用这些服务。 Dubbo-js 已于 9 月份公布反对 Dubbo3 协定的首个 alpha 版本，它的公布将有机会彻底改变微服务前后端的架构与通信模式，让你能间接在浏览器页面或 web 服务器中拜访后端 Dubbo、gRPC 服务。 浏览器 Web 利用示例本示例演示了如何应用 dubbo-js 开发运行在浏览器上的 web 应用程序，web 页面将调用 dubbo node.js 开发的后端服务并生成页面内容。本示例演示基于 IDL 和非 IDL 两种编码模式。 IDL 模式前置条件首先，咱们将应用 Vite 来生成咱们的前端我的项目模板，它内置了咱们稍后须要的所有性能反对。 npm create vite@latest -- dubbo-web-example --template react-tscd dubbo-web-examplenpm install因为应用 Protocol Buffer 的起因，咱们首先须要装置相干的代码生成工具，这包含 @bufbuild/protoc-gen-es、@bufbuild/protobuf、@apachedubbo/protoc-gen-apache-dubbo-es、@apachedubbo/dubbo。 npm install @bufbuild/protoc-gen-es @bufbuild/protobuf @apachedubbo/protoc-gen-apache-dubbo-es @apachedubbo/dubbo应用 Proto 定义服务当初，应用 Protocol Buffer (IDL) 来定义一个 Dubbo 服务。 ...

Dubbo Dubbo 与 RPC 的关系Dubbo 是一种开源的分布式服务框架，由阿里巴巴公司开发。它为应用程序提供高性能的 RPC（近程过程调用）通信和服务治理能力，让应用程序可能在分布式环境中疾速构建高可靠性和可扩展性的服务。Dubbo 外围性能包含服务注册与发现、负载平衡、服务调用和容错能力等，实用于多种语言和多种异构环境的通信。Dubbo 采纳阻塞 I/O 和线程池的形式来实现高并发，同时还反对多种协定和序列化格局的扩大。其生态系统日趋完善，用户社区沉闷，被广泛应用于 Web 利用，企业级中间件，大数据等畛域。 Dubbo 的外围Dubbo 的外围包含了： 近程通信：Dubbo 提供了多种近程通信协定，如 Dubbo 协定、Http 协定、RMI 协定等。其中，Dubbo 协定是 Dubbo 自带的一种二进制、高性能的 RPC 通信协定，具备较低的序列化和反序列化开销，适宜高并发、大数据量的服务通信。集群容错：当 Dubbo 消费者发动服务调用时，Dubbo 提供了多种集群容错策略，如 Failover、Failfast、Failsafe、Failback 等。Failover 是 Dubbo 的默认集群容错策略，其会在服务提供者出错或超时时主动切换到其余可用节点进行调用，保障调用的可靠性。主动发现：为了便于管理泛滥的服务提供者，Dubbo 提供了注册核心作为服务注册与发现的中心化管理工具。Dubbo 反对多种注册核心，如 ZooKeeper、Redis、Consul、Etcd 等。通过注册核心，服务消费者能够主动发现可用的服务提供者，而无需手动配置服务提供者地址，大大降低了服务调用的复杂度。Dubbo 和 Spring Cloud区别Dubbo 是一个高性能的 RPC 框架，次要用于构建微服务架构下的服务治理和服务通信。它能够十分不便地扩大服务，进步零碎的性能和可扩展性。 Spring Cloud 是一个残缺的微服务框架，它提供了一整套微服务框架的解决方案，包含服务注册与发现、配置核心、负载平衡、断路器、路由等等，比 Dubbo 更为全面。 深刻理解：微服务框架比照：Spring Cloud vs Dubbo Dubbo 的节点 Provider：公布服务，并将服务注册到注册核心，期待消费者调用。Consumer：从注册核心订阅服务，和服务提供者进行通信，生产服务。Registry：记录服务提供者的信息，以及服务提供者和服务消费者之间的关系，帮忙消费者发现可用的服务实例。Monitor：收集 Dubbo 节点的性能指标、服务调用统计信息等，以便运维人员进行监控和治理。Container：服务的运行容器Dubbo 的框架Dubbo 的框架 包含了： 繁多利用框架：实用于流量较小的时候垂直利用框架：实用与流量较大的时候分布式服务架构：实用于垂直利用架构较多的时候流动计算架构：当流量超级大的时候，须要一个调度核心Dubbo 服务Dubbo 接口定义咱们能够写一个 sayHello 的办法。 /*** xml形式服务提供者接口*/public interface ProviderService { String SayHello(String word);}接着，定义它的实现类。 ...

本文次要解说了一致性哈希算法的原理以及其存在的数据歪斜的问题，而后引出解决数据歪斜问题的办法，最初剖析一致性哈希算法在Dubbo中的应用。通过这篇文章，能够理解到一致性哈希算法的原理以及这种算法存在的问题和解决方案。 一、负载平衡在这里援用dubbo官网的一段话—— LoadBalance 中文意思为负载平衡，它的职责是将网络申请，或者其余模式的负载“均摊”到不同的机器上。防止集群中局部服务器压力过大，而另一些服务器比拟闲暇的状况。通过负载平衡，能够让每台服务器获取到适宜本人解决能力的负载。在为高负载服务器分流的同时，还能够防止资源节约，两全其美。负载平衡可分为软件负载平衡和硬件负载平衡。在咱们日常开发中，个别很难接触到硬件负载平衡。但软件负载平衡还是能够接触到的，比方 Nginx。在 Dubbo 中，也有负载平衡的概念和相应的实现。Dubbo 须要对服务消费者的调用申请进行调配，防止多数服务提供者负载过大。服务提供者负载过大，会导致局部申请超时。因而将负载平衡到每个服务提供者上，是十分必要的。Dubbo 提供了4种负载平衡实现，别离是基于权重随机算法的 RandomLoadBalance、基于起码沉闷调用数算法的 LeastActiveLoadBalance、基于hash 一致性的 ConsistentHashLoadBalance，以及基于加权轮询算法的 RoundRobinLoadBalance。这几个负载平衡算法代码不是很长，然而想看懂也不是很容易，须要对这几个算法的原理有肯定理解才行。 二、哈希算法 图1 无哈希算法申请 如上所示，假如0,1,2号服务器都存储的有用户信息，那么当咱们须要获取某用户信息时，因为咱们不晓得该用户信息寄存在哪一台服务器中，所以须要别离查问0,1,2号服务器。这样获取数据的效率是极低的。 对于这样的场景，咱们能够引入哈希算法。 图2 引入哈希算法后的申请 还是下面的场景，但前提是每一台服务器寄存用户信息时是依据某一种哈希算法寄存的。所以取用户信息的时候，也依照同样的哈希算法取即可。 假如咱们要查问用户号为100的用户信息，通过某个哈希算法，比方这里的userId mod n，即100 mod 3后果为1。所以用户号100的这个申请最终会被1号服务器接管并解决。 这样就解决了有效查问的问题。 然而这样的计划会带来什么问题呢？ 扩容或者缩容时，会导致大量的数据迁徙。起码也会影响50%的数据。 图3 减少一台服务器 为了阐明问题，退出一台服务器3。服务器的数量n就从3变成了4。还是查问用户号为100的用户信息时，100 mod 4后果为0。这时，申请就被0号服务器接管了。 当服务器数量为3时，用户号为100的申请会被1号服务器解决。当服务器数量为4时，用户号为100的申请会被0号服务器解决。所以，当服务器数量减少或者缩小时，肯定会波及到大量数据迁徙的问题。 对于上述哈希算法其长处是简略易用，大多数分库分表规定就采取的这种形式。个别是提前依据数据量，事后估算好分区数。 其毛病是因为扩容或膨胀节点导致节点数量变动时，节点的映射关系须要从新计算，会导致数据进行迁徙。所以扩容时通常采纳翻倍扩容，防止数据映射全副被打乱，导致全量迁徙的状况，这样只会产生50%的数据迁徙。 三、一致性哈希算法**一致性 hash 算法由麻省理工学院的 Karger 及其合作者于1997年提出的，算法提出之初是用于大规模缓存零碎的负载平衡。**它的工作过程是这样的，首先依据 ip 或者其余的信息为缓存节点生成一个 hash，并将这个 hash 投射到 [0, 232 - 1] 的圆环上。当有查问或写入申请时，则为缓存项的 key 生成一个 hash 值。而后查找第一个大于或等于该 hash 值的缓存节点，并到这个节点中查问或写入缓存项。如果以后节点挂了，则在下一次查问或写入缓存时，为缓存项查找另一个大于其 hash 值的缓存节点即可。大抵成果如下图所示，每个缓存节点在圆环上占据一个地位。如果缓存项的 key 的 hash 值小于缓存节点 hash 值，则到该缓存节点中存储或读取缓存项。比方上面绿色点对应的缓存项将会被存储到 cache-2 节点中。因为 cache-3 挂了，本来应该存到该节点中的缓存项最终会存储到cache-4节点中。 ...

Dubbo是什么Dubbo 是阿里巴巴公司开发的一款高性能的分布式服务框架，用于近程服务调用和服务治理。它具备透明化的近程调用、负载平衡、服务注册和发现、可扩展性和服务治理等个性。Dubbo反对自定义扩大各种性能，如负载平衡、协定、序列化等，并提供了大量服务治理性能，如监控、追踪、容错和限流等，让服务的运行更加稳固和牢靠。它是一种高效、可扩大和牢靠的分布式服务框架解决方案，实用于构建大型分布式系统。 Dubbo能做什么Dubbo框架具备以下性能： 近程调用：Dubbo框架采纳 RPC（近程过程调用）形式进行近程服务调用，在实现分布式系统中的服务调用时，可使调用者感觉就像是调用本地服务一样不便。负载平衡：Dubbo框架内置多种负载平衡策略，可依据理论状况抉择不同的负载平衡策略，如随机、轮询、最小沉闷数等，使得服务申请能够均衡地散布到不同的服务提供者上，进步服务的可用性和性能。服务注册和发现：Dubbo框架提供了服务注册和发现的性能，可将服务注册到注册核心，也可从注册核心中查问服务信息，不便实现服务的动静扩容和缩容。可扩展性：Dubbo框架提供了可扩大的插件机制，可自定义扩大各种性能，如负载平衡、协定、序列化等。服务治理：Dubbo框架提供了丰盛的服务治理性能，如监控、追踪、容错和限流等，可使得服务的运行更加稳固和牢靠。Dubbo的架构Dubbo框架次要由以下组件形成： Provider：公布服务并将服务注册到注册核心，期待消费者调用。Consumer：从注册核心订阅服务，和服务提供者进行通信，生产服务。Registry：记录服务提供者的信息，以及服务提供者和服务消费者之间的关系，帮忙消费者发现可用的服务实例。Monitor：收集Dubbo节点的性能指标、服务调用统计信息等，以便运维人员进行监控和治理。Container：服务的运行容器。 Dubbo的利用上面是一个Dubbo的服务启动代码样例： spring.dubbo.application.name=spring-boot-starter-dubbo-demo-consumerspring.dubbo.registry.address=zookeeper: //localhost:2181spring.dubbo.protocal.name=dubbospring.dubbo.protocol.port=20880spring.dubbo.scan=com.sunlibin.weathercustomer3.间接在serviceImpl层通过com.alibaba.dubbo.config.annotation.Reference;package com.sunlibin.weathercustomer.service.impl;import com.alibaba.dubbo.config.annotation.Reference;import com.sunlibin.bean.District;import com.sunlibin.service.RpcDistrictService;import com.sunlibin.weathercustomer.service.DistrictService;import org.springframework.stereotype.Service;import java.util.List;@Service("districtService")public class DistrictServiceImpl implements DistrictService { @Reference private RpcDistrictService rpcDistrictService; @Override public List<District> getAllDistrict() { return this.rpcDistrictService.getAllDistrict(); } @Override public District getDistrictById(Integer id) { return this.rpcDistrictService.getDistrictById(id); }}应用Apifox拜访Dubbo服务Dubbo其实就是RPC的一种近程调用计划，因而拜访Dubbo服务可类比为调用RPC服务。咱们须要应用API工具来进行接口的申请。以下是通过Apifox拜访Dubbo服务的简要步骤： 1、在Apifox中新建Dubbo申请，填写对应名称、拜访门路和申请办法。 2、接着咱们达到运行页面，填入申请 body 的参数，传递参数的格局是： { "jsonrpc": "2.0", "method": {{要调用的办法名称}}, "params": {{办法所需的参数}}, "id": {{申请的惟一标识符}}}所以咱们填入正确格局的申请参数： { "jsonrpc": "2.0", "method": "echo", "params": { "text": "Dubbo result" }, "id": 18999}并且点击发送运行，失去 Dubbo 服务那边返回的数据。 ...

Spring Cloud是一种基于Spring Boot的微服务框架，能够帮忙开发人员疾速构建和部署分布式系统。Dubbo3是一种高性能、轻量级的分布式服务框架，能够实现服务治理、负载平衡和容错等性能。本文将介绍Spring Cloud整合Dubbo3的办法和步骤，并提供示例代码。download：https://www.97yrbl.com/t-1535.html 一、什么是Spring Cloud和Dubbo3Spring CloudSpring Cloud是一种基于Spring Boot的微服务框架，提供了各种组件和插件来简化微服务架构的开发和治理。其中包含服务注册与发现、负载平衡、断路器、配置核心等性能。 Dubbo3Dubbo3是一种高性能、轻量级的分布式服务框架，能够实现服务治理、负载平衡和容错等性能。Dubbo3应用传输层协定进行通信，反对多种序列化形式和调用形式。 二、Spring Cloud整合Dubbo3的办法引入Dubbo3依赖在Spring Boot我的项目中，能够通过Maven或Gradle等工具来引入Dubbo3的依赖。例如，在pom.xml文件中增加以下依赖： <dependency> <groupId>org.apache.dubbo</groupId> <artifactId>dubbo-spring-boot-starter</artifactId> <version>3.0.0</version></dependency>配置Dubbo3配置文件是整合Dubbo3的关键所在。在Spring Boot我的项目中，能够通过application.properties或application.yml等文件来配置Dubbo3。例如，在application.yml文件中增加以下配置： dubbo: registry: address: zookeeper://127.0.0.1:2181 protocol: name: dubbo port: 20880 scan: base-packages: com.example.service其中，registry.address示意注册核心地址，protocol.name和protocol.port示意协定名称和端口号，scan.base-packages示意扫描服务包门路。 整合Dubbo3实现以上步骤后，就能够在Spring Boot我的项目中应用Dubbo3了。例如，在须要裸露为Dubbo服务的类上增加@Service注解： @Servicepublic class UserServiceImpl implements UserService { @Override public User getUserById(Long id) { // ... }}在须要调用Dubbo服务的类中增加@Reference注解： @RestControllerpublic class UserController { @Reference private UserService userService; @GetMapping("/users/{id}") public User getUserById(@PathVariable Long id) { return userService.getUserById(id); }}三、示例代码上面是一个简略的Spring Cloud整合Dubbo3的示例代码。其中，UserService是一个Dubbo服务接口，UserServiceImpl是它的实现类。 引入Dubbo3依赖<dependency> <groupId>org.apache.dubbo</groupId> <artifactId>dubbo-spring-boot-starter</artifactId> <version>3.0.0</version></dependency>配置Dubbo3dubbo: registry: address: zookeeper://127.0.0.1:2181 protocol: name: dubbo port: 20880 scan: base-packages: com.example.service定义UserService接口和User实体类public interface UserService { User getUserById(Long id);}public class User implements Serializable { private Long id; private String name; private Integer age; // getter and setter methods}实现UserService接口@Servicepublic class UserServiceImpl implements UserService { @Override public User getUserById(Long id) { User user = new User(); user.setId(id); user.setName("Alice"); user.setAge(20); return user; }}调用Dubbo服务@RestControllerpublic class UserController { @Reference private UserService userService; @GetMapping("/users/{id}") public User getUserById(@PathVariable Long id) { return userService.getUserById(id); }}总之，Spring Cloud是一种基于Spring Boot的微服务框架，能够帮忙开发人员疾速构建和部署分布式系统。Dubbo3是一种高性能、轻量级的分布式服务框架，能够实现服务治理、负载平衡和容错等性能。通过深刻理解Spring Cloud整合Dubbo3的办法和步骤，咱们能够更好地进行分布式系统的开发和治理。 ...

背景ZooKeeper 作为通用的元数据存储组件，用处宽泛，是 Dubbo 最早反对的注册核心之一，通过长时间的磨合，目前 Dubbo 和 ZooKeeper 的组合具备很好的稳定性和扩展性。 ZooKeeper 作为 Dubbo 注册核心时，因为开源 ZooKeeper 没有提供服务注册的逻辑模型，因而对 Dubbo 服务的治理老本比拟高，存在问题排查链路长等一系列治理问题。针对这些问题，MSE ZooKeeper 最新提供 Dubbo 服务治理能力，同时联合 TopN 监控大盘，推送轨迹等自治能力，帮忙用户进步问题排查速度，集群运维效率。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1175451?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

缘起是日，公司小张在测试环境调用 Dubbo 服务遇到了点问题： 蜡笔小新服务调用了用户服务和小泥鳅服务；用户服务的 Dubbo 分组只有一个：分组A，小泥鳅服务的 Dubbo 分组有好几个：分组A、分组B、分组C ...；小张须要与小泥鳅服务 分组B 上的实例进行联调；须要如何配置呢？小张犯愁了。 事态倒退首先，要阐明的是，公司中应用的 Dubbo 版本是 com.alibaba:dubbo:2.6.3。Dubbo 原生反对哪些配置全局配置应用如下全局配置，用户服务和小泥鳅服务都会到 分组B 查找 service，最终会导致用户服务的 service 查找失败。 spring.dubbo.registry.group = 分组B@Reference应用 @Reference 配置分组，这样每个 service 都要配置一下，比拟麻烦。 @Reference(group = "分组B")private lateinit var serviceC: ServiceC有没有更好的形式于是，小张信心批改 Dubbo 底层，以更好反对这一需要。 确定指标目前的服务状况大略是这样的： 用户服务 service：com.xz.user.serviceAcom.xz.user.serviceB小泥鳅服务 service：com.xz.loach.serviceCcom.xz.loach.serviceD如果反对这样的配置，就很好： # 所有 com.xz.loach 下的 service，都到 分组B 去查找dubbo.custom.groups = {"com.xz.loach.*": "分组B"}实现剖析通过追踪 @Reference 被援用的中央，最终找到上面这段代码，是很好的切入点： public class ReferenceAnnotationBeanPostProcessor extends InstantiationAwareBeanPostProcessorAdapter implements MergedBeanDefinitionPostProcessor, PriorityOrdered, ApplicationContextAware, BeanClassLoaderAware, DisposableBean { // ...... private ReferenceBean<?> buildReferenceBean(Reference reference, Class<?> referenceClass) throws Exception { String referenceBeanCacheKey = generateReferenceBeanCacheKey(reference, referenceClass); ReferenceBean<?> referenceBean = referenceBeansCache.get(referenceBeanCacheKey); if (referenceBean == null) { ReferenceBeanBuilder beanBuilder = ReferenceBeanBuilder .create(reference, classLoader, applicationContext) .interfaceClass(referenceClass); referenceBean = beanBuilder.build(); referenceBeansCache.putIfAbsent(referenceBeanCacheKey, referenceBean); } return referenceBean; } // ...... }无奈的是，buildReferenceBean 是 private 的，它既不能被继承，又不能被代理，仿佛只能祭出 ASM 了。但，小张想了想，想到了另一个损招：间接复制 ReferenceAnnotationBeanPostProcessor 的代码，把 buildReferenceBean 改成 public，而后将 ReferenceAnnotationBeanPostProcessor 整个替换掉。 ...

咱们非常高兴地发表，Dubbo 3.2 曾经正式公布了！这个版本带来了许多新性能和改良，这也是 Dubbo 在面对云原生化的当下的一次重要的尝试。 背景介绍Apache Dubbo 是一款 RPC 服务开发框架，用于解决微服务架构下的服务治理与通信问题，官网提供了 Java、Golang 等多语言 SDK 实现。应用 Dubbo 开发的微服务原生具备相互之间的近程地址发现与通信能力， 利用 Dubbo 提供的丰盛服务治理个性，能够实现诸如服务发现、负载平衡、流量调度等服务治理诉求。Dubbo 被设计为高度可扩大，用户能够不便的实现流量拦挡、选址的各种定制逻辑。 01 Rest 协定反对1.1 Why Rest？随着挪动互联网的遍及，越来越多的应用程序须要与不同的零碎进行集成。而这些零碎可能应用不同的通信协议，这就须要应用程序可能灵便地适应各种协定。Rest 协定正是一种非常灵活的协定，它应用 HTTP 进行通信，能够与简直任何零碎进行集成。 在过来，RPC 框架通常应用二进制协定进行通信，这种协定十分高效，但不够灵便。相比之下，Rest 协定应用 HTTP 进行通信，更不便与其余系统集成，也更容易与现代化的Web和挪动应用程序集成。 除了灵活性，Rest 协定还具备易读性和易用性。应用 Rest 协定，开发人员能够应用通用的 HTTP 工具（例如 cURL 或 Postman）测试和调试服务，而不须要特定的工具。此外，因为 Rest 协定应用规范的 HTTP 办法（例如 GET、POST、PUT 和 DELETE），因而开发人员能够更容易地了解和应用服务。 1.2 How To？在之前的 Dubbo 版本中，也提供了 Rest 协定的反对，但存在以下问题： 仅反对 JAX-RS 注解域，相较于采纳度更高的 Spring Web 注解，复杂度更高须要依赖泛滥内部组件，如 Resteasy、tomcat、jetty 等，能力失常工作，极大地减少了应用老本。因而，在 Dubbo 3.2 版本中，咱们引入了 Spring Web 注解域的反对以及 Rest 协定的原生反对，无需依赖任何内部组件。 ...

对云岛业务构造的公司来说，云平台属于公司外部、齐全可控的局域网，而岛端则是有本人平安网络策略的独立外部网络。须要云岛通信时，会基于需要，按客户要求走流程开明一些端口，这个过程须要肯定的老本且不齐全可控。业务上，如果这种跨网需要增多，则会逐步变成痛点。如果能够搭建一个通明的跨网传输网络，配合良好的顶层设计，就能够在业务撑持、平安管控和运维老本中寻求较好的均衡。 本文将介绍政采云基于 Dubbo 的跨网计划落地过程中面临的技术挑战、社区单干以及更深层次形象的一些思考。在政采云这种政企业务场景中的数据跨网，与业界私有云、自建公有云的公司相比，既有共性又有本人的特点，心愿能为大家提供新的思路或者启发。 前言稳固、高效、牢靠的基础设施是互联网企业应答业务顶峰流量的底层基石。作为政采云的根底技术平台，根底平台部始终致力于通过业内前沿技术的落地，保障公司外部所有业务在线生产零碎所依赖的根底技术平台能稳固、平安、低成本、可继续地运行与倒退。 因为公司对 Dubbo 框架的重度应用，跨网数据传输零碎个别基于 Dubbo 个性开发，在政采云外部就有多个版本的实现。 早在几年前，政采云就上线了基于 Dubbo Filter 转发的计划，它解决了岛到云的单向数据传输，平安认证等问题。另外，业务部门也有依照本人的需要，推出网状点对点的计划，实现了肯定水平的通明传输。 联合前两年的摸索实际以及业界相干畛域技术的成熟度，2022 年下半年，咱们对各跨岛计划，进行了整合降级，也就是当初的高速公路计划，保障跨岛标准化同时，解决了之前计划实际过程中面临的很多业务痛点，包含： 单向传输：因为架构起因，如需双向须要对等重新部署一套，老本较大。白名单开明老本高：点对点的网状架构，须要两两开明白名单，因为政企网络特殊性，开明流程简单且慢。平台保护老本高：业务各自一套数据传输平台，反复建设且运维老本高。公共性能的缺失：外围性能，业务能够按需开发，然而数据审计、链路追踪、可观测性等公共个性，往往没有足够投入。跨网数据传输零碎演进1.1 历史架构 图一自左向右、自下而上进行模块介绍： 业务 Web：业务 Web 作为数据发送方，调本地集群 Provider 时，携带跨岛信息过来（Dubbo 上下文）。岛业务 Center：本地虚构 Provider，通过 Filter 拦挡跨岛申请，通过 http 传送到云平台 Dubbo 网关，返回数据后反序列化返回岛业务 web。Dubbo 网关：接管 Http 申请，通过泛化调用云端 Provider，解决数据后返回业务 Center。云业务 Center：一般 Dubbo Provider。1.2 高速公路架构图二 1.2.1 隧道机制隧道技术是一种通过应用互联网络的基础设施在网络之间传递数据的形式。应用隧道传递的数据 (或负载) 能够是不同协定的数据帧或包。 高速公路架构中，应用了隧道这个概念。两端（业务层）是 Dubbo 公有协定，跨网传输过程中，则应用了 http 协定，http 协定能够更好的被中间设备、网关辨认转发。这个机制的最大便当在于对业务的低侵入性。对于业务集群的利用齐全不须要批改。 图三 除了路由标记，进口 / 入口 Dubbo 协定字节流没有任何业务外信息，所以能够路由任何 Dubbo 申请。 图四 1.2.2 次要节点客户端 Sdk：不扭转用户应用 Dubbo 的形式，多种形式提供 Dubbo 的路由。Dubbo 进口网关 ：代理 Dubbo 流量进口。Dubbo 入口网关 ：代理 Dubbo 流量入口。对立网关 ：基于 Apisix，代理跨网间所有流量，能够扩大鉴权、审计、限流等个性。挑战与应答之策如前言中所述，已有的几个方案设计上存在了一些问题，落地后也限度了应用了场景。在架构上，咱们提出了高速公路计划，抉择了全双工的对等网络传输框架。角色上，云平台定位一个非凡的岛端利用，遵循 P2P 施行准则。而对用户而言，高速公路是一个通往岛端的隧道，遵循对用户通明准则。咱们能够先来看下在搭建平台的过程中面临的一些挑战以及解法。 ...

背景ZooKeeper 作为通用的元数据存储组件，用处宽泛，是 Dubbo 最早反对的注册核心之一，通过长时间的磨合，目前 Dubbo 和 ZooKeeper 的组合具备很好的稳定性和扩展性。 ZooKeeper 作为 Dubbo 注册核心时，因为开源 ZooKeeper 没有提供服务注册的逻辑模型，因而对 Dubbo 服务的治理老本比拟高，存在问题排查链路长等一系列治理问题。针对这些问题，MSE ZooKeeper 最新提供 Dubbo 服务治理能力，同时联合 TopN 监控大盘，推送轨迹等自治能力，帮忙用户进步问题排查速度，集群运维效率。 服务治理通过实例详情页中的数据管理中的服务治理来查看 ZooKeeper 中注册的服务，以及服务的提供者，订阅者信息。服务详情页展现对应的服务名以及服务类型，目前只反对 Dubbo，将来还会反对更多的服务注册类型，单击服务名进入服务详情页面。 服务详情页面展现了，服务的元信息，蕴含服务的版本，分组，利用名等信息，反对多个分组，版本展现。服务提供者信息通过更加正当的表格结构化展现，并且能够实时看到实例的高低线，权重，超时工夫等信息，可能更加清晰的把握利用的配置信息。 如果您想对 Dubbo 服务进行精细化的治理，能够将您的 Dubbo 服务接入 MSE 微服务治理。在接入服务治理的状况下，您能够通过点击接口详情按钮来跳转到微服务治理对应的页面，查看您的 Dubbo 服务的具体数据信息，蕴含服务的 QPS、延时、成功率、并发等信息。 如果您的 Dubbo 利用遇到了一些线上问题，须要在保留现场的场景下进行问题定位。您能够在跳转后的微服务治理对应的界面中找到节点详情菜单。抉择呈现问题的实例，通过右侧的服务下线按钮进行下线操作。这样就能够将出问题实例的流量摘除掉，在既保留现场又不影响业务的状况下进行问题定位。 联合 MSE 服务治理能力，可能轻松实现服务的无损伤高低线，灰度公布，使得公布过程中更加平滑，危险升高。同时联合推送轨迹性能不便查问服务提供者的高低线记录，可能帮助排查注册不上，反复注册，服务下线然而注册核心中数据未删除，频繁变更等场景。 同时通过查问订阅者的推送轨迹咱们直观看到每次服务高低线被推送的客户端状况。 同时 MSE ZooKeeper 加强了稳定性，对于异样的注册场景，Server 提供防护能力，避免因为业务侧异样导致服务宕机。 例如，某用户因为代码缺点导致 Dubbo Service Refrence 透露，ZooKeeper 中存在大量泄露的 Reference 创立的长期节点，并且因为 ZooKeeper 同步机制中的限度（可参考ZooKeeper 避坑指南，jute.maxbuffer 的设置文章），导致服务宕机，MSE ZooKeeper 针对这种极其状况做了 Server 侧的自我爱护，在 Reference 透露的状况下会限度业务注册的无用的数据，保障 Server 的稳定性。 ...

本文聊聊 dubbo 的最外围模型 Invoker，在 dubbo 官网上是这么形容的： Invoker 是实体域，它是 Dubbo 的外围模型，其它模型都向它聚拢，或转换成它，它代表一个可执行体，可向它发动 invoke 调用，它有可能是一个本地的实现，也可能是一个近程的实现，也可能一个集群实现。Invoker 是一个执行体的形象，执行体能够是本地的也能够是近程的，能够是集群的也能够是单实例的，能够是实在的业务实现也能够是假装的本地实现，能够是 dubbo协定也能够是其余协定，他的形象等级十分高，不关怀具体实现只关怀输出和输入。 先看下 Invoker 的接口申明： public interface Invoker<T> extends Node { // 这个 Invoker 可执行体是承载的那个接口，如 DemoService Class<T> getInterface(); // 最外围的调用模型，传入一个 Invocation 会话域返回一个带有后果的实体 Result invoke(Invocation invocation) throws RpcException;}另一个外围模型 Protocol 负责管理 Invoker 的生命周期，它的 API 都是围绕着 Invoker 进行的，看看它的接口申明： public interface Protocol { // 服务端裸露端口 int getDefaultPort(); // 服务端裸露形式 <T> Exporter<T> export(Invoker<T> invoker) throws RpcException; // 客户端援用形式 <T> Invoker<T> refer(Class<T> type, URL url) throws RpcException; // 销毁形式，服务端、客户端都应用 void destroy();}Invoker 是dubbo的灵魂，服务端和客户端都是围绕这个实体来运行，不同的 Invoker 承载不同的调用形式。 ...

作者：丛国庆 在 Kubernetes（简称 K8s，一个可移植容器的编排管理工具）体系中，etcd 存储集群的数据信息，kube-apiserver 作为对立入口，任何对数据的操作都必须通过 kube-apiserver。因而 Dubbo 想要以 Kubernetes 作为注册核心，必须调用 kube-apiserver 获取服务地址列表，那是以什么样的机制放弃信息的可靠性、实时性、程序性、高性能呢？答案就是基于 List/Watch 的 Informer 组件。 List/Watch 机制介绍List / Watch 机制是 Kubernetes 中实现集群管制模块最外围的设计之一，它采纳对立的异步音讯解决机制，保障了音讯的实时性、可靠性、程序性和性能等，为申明式格调的API奠定了良好的根底。 List 是向 kube-apiserver 调用 list API 获取资源列表，基于 HTTP 短链接实现。 Watch则是向 kube-apiserver 调用 watch API 监听资源变更事件，基于 HTTP 长链接，通过 Chunked transfer encoding(分块传输编码) 来实现音讯告诉。 当客户端调用 watch API 时，kube-apiserver 在 response 的 HTTP Header 中设置 Transfer-Encoding 的值为 chunked，示意采纳分块传输编码，客户端收到该信息后，便和服务端连贯，并期待下一个数据块，即资源的事件信息。例如： $ curl -i http://{kube-api-server-ip}:8080/api/v1/watch/endpoints?watch=yesHTTP/1.1 200 OKContent-Type: application/jsonTransfer-Encoding: chunkedDate: Thu, 14 Seo 2022 20:22:59 GMTTransfer-Encoding: chunked{"type":"ADDED", "object":{"kind":"Endpoints","apiVersion":"v1",...}}{"type":"ADDED", "object":{"kind":"Endpoints","apiVersion":"v1",...}}{"type":"MODIFIED", "object":{"kind":"Endpoints","apiVersion":"v1",...}} ...

本文次要记录下本人浏览源码时的一些了解，本文次要聊下dubbo client是如何援用近程服务的，以应用zookeeper作为注册核心为例。 接口申明及客户端调用形式如下： public interface DemoService { String sayHello(String name);}public class Consumer2 { public static void main(String[] args) { ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(new String[]{"META-INF/spring/dubbo-demo-consumer.xml"}); context.start(); DemoService demoService = (DemoService) context.getBean("demoService"); // get remote service proxy String hello = demoService.sayHello("world"); // call remote method System.out.println(hello); // get result }}因为 dubbo 最近在做比拟大的版本变迁，然而其外围接口并没变，所以这里以 2.6.x的版本为例解说，因为咱们选用的 server 实现是netty4，所以咱们在 netty 的 NettyClient.doConnect 办法退出一个断点，失去的调用栈如下：以dubbo官网demo为例的客户端调用栈： 34. doConnect:116, NettyClient (com.alibaba.dubbo.remoting.transport.netty4)33. connect:353, AbstractClient (com.alibaba.dubbo.remoting.transport)32. <init>:130, AbstractClient (com.alibaba.dubbo.remoting.transport)31. <init>:64, NettyClient (com.alibaba.dubbo.remoting.transport.netty4)30. connect:39, NettyTransporter (com.alibaba.dubbo.remoting.transport.netty4)29. connect:-1, Transporter$Adaptive (com.alibaba.dubbo.remoting)28. connect:81, Transporters (com.alibaba.dubbo.remoting)27. connect:40, HeaderExchanger (com.alibaba.dubbo.remoting.exchange.support.header)26. connect:111, Exchangers (com.alibaba.dubbo.remoting.exchange)25. initClient:612, DubboProtocol (com.alibaba.dubbo.rpc.protocol.dubbo)24. getSharedClient:569, DubboProtocol (com.alibaba.dubbo.rpc.protocol.dubbo)23. getClients:533, DubboProtocol (com.alibaba.dubbo.rpc.protocol.dubbo)22. refer:504, DubboProtocol (com.alibaba.dubbo.rpc.protocol.dubbo)21. refer:71, ProtocolListenerWrapper (com.alibaba.dubbo.rpc.protocol)20. refer:133, ProtocolFilterWrapper (com.alibaba.dubbo.rpc.protocol)19. refer:-1, Protocol$Adaptive (com.alibaba.dubbo.rpc)18. toInvokers:530, RegistryDirectory (com.alibaba.dubbo.registry.integration)17. refreshInvoker:349, RegistryDirectory (com.alibaba.dubbo.registry.integration)16. notify:305, RegistryDirectory (com.alibaba.dubbo.registry.integration)15. notify:490, AbstractRegistry (com.alibaba.dubbo.registry.support)14. doNotify:305, FailbackRegistry (com.alibaba.dubbo.registry.support)13. notify:290, FailbackRegistry (com.alibaba.dubbo.registry.support)12. doSubscribe:241, ZookeeperRegistry (com.alibaba.dubbo.registry.zookeeper)11. subscribe:216, FailbackRegistry (com.alibaba.dubbo.registry.support)10. subscribe:219, RegistryDirectory (com.alibaba.dubbo.registry.integration)9. doRefer:309, RegistryProtocol (com.alibaba.dubbo.registry.integration)8. refer:290, RegistryProtocol (com.alibaba.dubbo.registry.integration)7. refer:68, ProtocolListenerWrapper (com.alibaba.dubbo.rpc.protocol)6. refer:130, ProtocolFilterWrapper (com.alibaba.dubbo.rpc.protocol)5. refer:-1, Protocol$Adaptive (com.alibaba.dubbo.rpc)4. createProxy:402, ReferenceConfig (com.alibaba.dubbo.config)3. init:334, ReferenceConfig (com.alibaba.dubbo.config)2. get:163, ReferenceConfig (com.alibaba.dubbo.config)1. main:35, Consumer2 (com.alibaba.dubbo.demo.consumer)上面进行逐渐拆解：1、 main办法，入口2、 ReferenceConfig.get 简略判断以后援用是否销毁，是否初始化过，否则进入初始化逻辑3、 ReferenceConfig.init 初始化逻辑，参数校验、初始化，查看是否是泛化调用，组装URL4、 ReferenceConfig.createProxy 查看是否是 injvm(即本地调用) 调用，解决直连url调用，否则从注册核心获取援用，包含多注册核心5、 Protocol$Adaptive 调用Protocol的自适应实现类进行 refer，依据 url 参数中的 protocol 进行实现类适配，由 SPI 内容6-7、 ProtocolFilterWrapper、ProtocolListenerWrapper都是 protocol 的 Wrapper 类，会主动包装在 protocol 的实现类上，由 SPI 机制实现主动注入8、 因为目前的url中的 protocol 为 registry，所以实现类为 RegistryProtocol，该办法中将 url 的protocol 改为 zookeeper，由 SPI 获取注册核心的实现类 ZookeeperRegistry，判断有无group设置，有则应用 mergeable cluster 进行合并，没有 group 则应用 SPI 指定的 cluster 进行集群容错9、 RegistryProtocol.doRefer 将zookeeper 目录转换为一个动静 Directory ，将客户端作为 consumer 写入到注册核心，同时订阅providers、configurators、routers，启动集群容错策略，默认是 FailoverClusterInvoker，同时依据 SPI 包装一个 MockClusterInvoker 进行本地存根、服务降级加强10、上面开始拉取注册核心内容11、 FailbackRegistry 是一个注册核心实现的父类，实现了注册核心容错逻辑，次要性能是如果申请注册核心失败了会主动进行重试，默认重试周期5s12、ZookeeperRegistry.doSubscribe 进行 zookeeper 订阅申请并取得一个初始值进行 notify 回调13、FailbackRegistry.notify 进行简略的参数校验和容错，调用 FailbackRegistry.doNotify14、FailbackRegistry.doNotify 间接调用父类实现15、AbstractRegistry.notify 将回调进行分类，并调用对应的回调函数16、因为这个订阅最后是RegistryDirectory发动订阅的，回调最终执行到 RegistryDirectory.notify，这里对回调进行解决，这里解决了 configurators、routers 两种监听的回调17、 RegistryDirectory.refreshInvoker 解决providers数据回调，刷新invoker 列表，如果没有匹配的providers则设置禁用，对所有申请返回谬误，否则将providers转换为invoker，刷新本地invoker列表，这个列表里的invoker即是具体一个ip:port的网络调用了，当然这些invoker也进行了过滤器等加强18、RegistryDirectory.toInvokers 即是将多个 providers 的注册内容即url进行转换为具体的invoker逻辑，这里因为应用dubbo协定就是 DubboInvoker19、初始化 invoker 逻辑，依据 SPI 协定自适应调用对应的 Protocol 实现类20-21、 ProtocolFilterWrapper、ProtocolListenerWrapper就不多说了，协定加强类，会被 SPI 主动包装到具体的实现类上22、因为用dubbo 这里的协定实现类是 DubboProtocol23、getClients获取对应链接，依据配置决定是共享 client 还是独享 client24、getSharedClient 默认是共享链接25、initClient 因为无连贯可用，这里创立一个新的链接26-27、Exchangers 工厂类，应用 SPI获取具体实现类 HeaderExchanger28-30、Transporters 工厂类，依据SPI获取自适应Transporter，因为我配置了client=netty4所以这里是netty4.NettyTransporter31-34、委托到netty4的 bootstrap.connect 具体进行链接创立 ...

作者：周可强一、责任链模式简介1、责任链模式定义责任链（Chain of Responsibility）模式的定义：为了防止申请发送者与多个申请解决者耦合在一起，于是将所有申请的解决者通过前一对象记住其下一个对象的援用而连成一条链；当有申请产生时，可将申请沿着这条链传递，直到有对象解决它为止。在责任链模式中，客户只须要将申请发送到责任链上即可，毋庸关怀申请的解决细节和申请的传递过程，申请会主动进行传递。所以责任链将申请的发送者和申请的解决者解耦了。 2、责任链特点责任链模式是一种对象行为型模式， 其次要长处如下。 1）.升高了对象之间的耦合度。该模式使得一个对象毋庸晓得到底是哪一个对象解决其申请以及链的构造，发送者和接收者也毋庸领有对方的明确信息。 2）.加强了零碎的可扩展性。能够依据须要减少新的申请解决类，满足开闭准则。 3）.加强了给对象指派职责的灵活性。当工作流程发生变化，能够动静地扭转链内的成员或者调动它们的秩序，也可动静地新增或者删除责任。责任链简化了对象之间的连贯。每个对象只需放弃一个指向其后继者的援用，不需放弃其余所有解决者的援用，这防止了应用泛滥的 if 或者 if···else 语句。 4）.责任分担。每个类只须要解决本人该解决的工作，不该解决的传递给下一个对象实现，明确各类的责任范畴，合乎类的繁多职责准则。 其次要毛病如下。 1）.不能保障每个申请肯定被解决。因为一个申请没有明确的接收者，所以不能保障它肯定会被解决，该申请可能始终传到链的末端都得不到解决。 2）.对比拟长的职责链，申请的解决可能波及多个解决对象，零碎性能将受到肯定影响。 3）.职责链建设的合理性要靠客户端来保障，减少了客户端的复杂性，可能会因为职责链的谬误设置而导致系统出错，如可能会造成循环调用。 3、责任链结构图 二、Dubbo中的责任链模式1、过滤器日志通过打印过滤器的日志，咱们能够看到在公布服务的过程中，会顺次通过dubbo的每个过滤器类，以此来保障服务的欠缺。 2、过滤器简图dubbo通过将每个过滤器类filter封装成dubbo的外围模型invoker进行组装，最终造成早晨的过滤器责任链filterChain。 3、过滤器类图Protocol是外围模型invoker裸露和援用的主性能入口，采纳SPI的接口，他的两个办法export和refer别离对应provider和consumer端的服务性能，ProtocolFilterWapper则是Dubbo的过滤器的次要实现类，通过重写的export和refer指向buildInvokerChain办法，在buildInvokerChain中进行责任链的获取与组装，在extensionLoader中通过SPI获取Filter的各实现类，并通过ActivateComparator进行排序，最终造成残缺的责任链。 三、Dubbo中各Filter责任介绍1、provider用到的filter 2、consumer用到的filter 四、源码探析进入到外围类ProtocolFilterWrapper中，在实现类中export和refer，都采纳雷同的结构责任链办法buildInvokerChain，只是通过参数group进行辨别 在buildInvokerChain中，通过getActivateExtension获取过滤器数组，并在之后封装成外围模型invoker并组装成责任链 private static <T> Invoker<T> buildInvokerChain(final Invoker<T> invoker, String key, String group) { Invoker<T> last = invoker; // 取得过滤器数组 （曾经排好序的） List<Filter> filters = ExtensionLoader.getExtensionLoader(Filter.class).getActivateExtension(invoker.getUrl(), key, group); // 创立带 Filter 链的 Invoker 对象 if (!filters.isEmpty()) { for (int i = filters.size() - 1; i >= 0; i--) { final Filter filter = filters.get(i); final Invoker<T> next = last; last = new Invoker<T>() { @Override public Class<T> getInterface() { return invoker.getInterface(); } @Override public URL getUrl() { return invoker.getUrl(); } @Override public boolean isAvailable() { return invoker.isAvailable(); } @Override public Result invoke(Invocation invocation) throws RpcException { return filter.invoke(next, invocation); } @Override public void destroy() { invoker.destroy(); } @Override public String toString() { return invoker.toString(); } }; } } System.out.println("group:" + group); for (Filter filter : filters) { System.out.println(filter.getClass()); } return last; }getActivateExtension是次要的组装逻辑，他蕴含获取与排序等逻辑 ...

dubbogo 社区公布了 v3.0.4 https://github.com/apache/dub...，本文列出相干重大 feature、bugfix 、 性能晋升项。 1 对接 PolarisMesh互联互通工作始终是 dubbogo 社区过来四年工作的重点。往年冲破阿里社区的产品矩阵，与腾讯相干同学单干，实现了 dubbogo 对 Polaris 的服务注册发现、动静路由、拜访限流三大能力的集成。 Polaris 是一反对多语言多框架的云原生服务治理平台，具备服务治理、流量治理、故障容错、配置管理和可观测性五大性能。所以后续还会将 Polaris 的服务熔断、节点熔断、可观测性以及配置核心的能力融入到 dubbogo 中，让用户可能在 dubbogo 中应用 Polaris 一站式的服务治理性能。 更多信息参见《互联互通的新榜样：Polaris 和 dubbogo 全面对接》。 相干 pull requests 由社区 @chuntaojun 和 @jasondeng1997 两位同学奉献。 https://github.com/apache/dub...https://github.com/apache/dub...https://github.com/apache/dub...2 TLS 反对Dubbo-go 曾经对 Dubbo/gRPC/Triple 协定实现了残缺的 TLS 反对，同时在 dubbo-go-samples/tls 中给出了残缺的应用形式。 相干 pull requests 由 @ZLBer 同学奉献： https://github.com/apache/dub...https://github.com/apache/dub...3 欠缺 local/remote 模式下 metadata对齐了 dubbo 与 dubbogo 之间 metadata 实现： metadata 数据结构上报解决 remote meta 的 bug：v3.0.3 版本之前把门路配置到 zk 外面的时候，有非法拜访的问题命令行工具，从 metadata 核心拉取数据，而后进行展现 https://github.com/apache/dub...4 BUG 修复与优化修复了 leastactive 谬误抉择 invoker 的问题: https://github.com/apache/dub...为 ReferenceConfigBuilder 新增更多的 setter: https://github.com/apache/dub...批改 Triple 协定 timeout 无奈辨认 ms 单位的问题: https://github.com/apache/dub...修复 DUBBO_IP_TO_REGISTRY 环境变量不失效的问题: https://github.com/apache/dub...5 Others如果你有任何疑难，欢送钉钉扫码退出交换群【钉钉群号 23331795】。 ...

作者：黄金 一、Dubbo简介Dubbo是一款典型的高扩大、高性能、高可用的RPC微服务框架，用于解决微服务架构下的服务治理与通信问题。其外围模块蕴含 【RPC通信】 和 【服务治理】 ，其中服务治理又分为服务注册与发现、服务容错、负载平衡、流量调度等。明天将重点介绍Dubbo的服务注册与发现。 二、SPI机制在介绍服务注册发现之前，先简略介绍一下贯通整个Dubbo源码，也是Dubbo实现自适应扩大的外围--SPI机制，下图为Dubbo SPI实现的简略类图。 •1、Dubbo SPI原理：通过读取相应的配置文件找到具体实现类，而后通过以下两种形式实例化对象：（1）通过自适应的动静字节码编译技术，生成相应的动静代理类，（2）利用反射机制实现实例化。相较于Java SPI，Dubbo SPI实现了外部的IoC和Aop •2、Dubbo SPI 长处：（1）高扩大：用户能够依据理论业务需要扩大相应的实现模块，蕴含字节码编译技术、rpc协定、通信形式、注册形式等，（2）解耦： 通过封装SPI调用机制，架构上实现了下层利用与底层逻辑之间的解耦，为高扩大提供了撑持条件 •3、Dubbo SPI 罕用样例（以getExtension和getAdaptiveExtension为例） 配置文件内容test1=com.dubbo.demo.service.TestServiceimpltest2=com.dubbo.demo.service.TestServiceImpl2一、通过getExtension办法生成实例 ExtensionLoader<TestService> extensionLoader = ExtensionLoader.getExtensionLoader(TestService.class); TestService t1 = extensionLoader.getExtension("test1"); TestService t2 = extensionLoader.getExtension("test2"); 二、通过getAdaptiveExtension生成实例（办法中须要@Adaptive注解，参数会对URL校验） TestService testService = ExtensionLoader.getExtensionLoader(TestService.class).getAdaptiveExtension(); URL url = new URL("test", "localhost", 8080, new String[]{"test.service", "test1"}); testService.sayHello("bbb", url);调用getAdaptiveExtension办法最终会生成相应的代理类，最终生成的代理类会依据URL参数外面的protocol决定（以外部Protocol为例） 三、服务注册1、服务注册流程 2、服务注册类图详解 3、服务注册步骤（1）步骤一：初始化配置（类图：形象Config与初始化配置）首先须要实例化ServiceConfig实例，申明“注册接口、接口实例、注册核心配置”，其中“ServiceBean”是实现Spring与Dubbo整合的桥梁。而后会由DubboBootstrap调用initialize办法实现configManager和Environment的初始化，其中就包含将ServiceConfig中的配置转换成外部封装的协定（ApplicationModel、ProviderModel等） private static void startWithExport() throws InterruptedException { //初始化配置 ServiceConfig<DemoServiceImpl> service = new ServiceConfig<>(); service.setInterface(DemoService.class); service.setRef(new DemoServiceImpl()); service.setApplication(new ApplicationConfig("dubbo-demo-api-provider")); service.setRegistry(new RegistryConfig("zookeeper://127.0.0.1:2181")); //服务注册入口 service.export();}public synchronized void export() { if (bootstrap == null) { bootstrap = DubboBootstrap.getInstance(); // compatible with api call. if (null != this.getRegistry()) { bootstrap.registries(this.getRegistries()); } //初始化配置() bootstrap.initialize(); } ...... if (shouldDelay()) { DELAY_EXPORT_EXECUTOR.schedule(this::doExport, getDelay(), TimeUnit.MILLISECONDS); } else { //服务注册 doExport(); } exported(); }（2）步骤二：组装URL依据初始化配置组转注册接口服务的URL。其中URL也是Dubbo外部通过@Adaptive注解实现SPI的外围，通过批改URL的头部协定（如：register、dubbo、injvm等），在调用 ...

作者：黄金 一、架构演变单利用架构 ----> 垂直架构 ----> 分布式架构 ----> 微服务架构 ----> 云原生架构 二、Dubbo总体架构 1、角色职能• Container：服务容器 （tomcat、jetty、weblogic） • Provider：服务提供者 •Consumer：服务消费者 •Registry：注册核心（ zookeeper、Nacos 、Apollo） •Minitor：监控核心 2、调用流程（1）服务容器负责启动，加载，运行服务提供者。 （2）服务提供者在启动时，向注册核心注册本人提供的服务。 （3）服务消费者在启动时，向注册核心订阅本人所需的服务。 （4）注册核心返回服务提供者地址列表给消费者，如果有变更，注册核心将基于长连贯推送变更数据给消费者。 （5）服务消费者，从提供者地址列表中，基于软负载平衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。 （6）服务消费者和提供者，在内存中累计调用次数和调用工夫，定时每分钟发送一次统计数据到监控核心。 三、Dubbo分层架构 •Config 配置层：对外配置接口，以 ServiceConfig, ReferenceConfig 为核心，能够间接初始化配置类，也能够通过 spring 解析配置生成配置类 •Proxy 服务代理层：服务接口通明代理，生成服务的客户端 Stub 和服务器端 Skeleton, 以 ServiceProxy 为核心，扩大接口为 ProxyFactory •Registry 注册核心层：封装服务地址的注册与发现，以服务 URL 为核心，扩大接口为 RegistryFactory, Registry, RegistryService •Cluster 路由层：封装多个提供者的路由及负载平衡，并桥接注册核心，以 Invoker 为核心，扩大接口为 Cluster, Directory, Router, LoadBalance •Monitor 监控层：RPC 调用次数和调用工夫监控，以 Statistics 为核心，扩大接口为 MonitorFactory, Monitor, MonitorService ...

Dubbo 是阿里的开源框架，前面募捐给了Apache，所以当初都叫Apache Dubbo，然而在日常中，很多人也更喜爱简称Dubbo。Apache Dubbo 是一款微服务框架，为大规模微服务实际提供高性能 RPC 通信、流量治理、可观测性等解决方案， 涵盖 Java、Golang 等多种语言 SDK 实现。 Dubbo版本已进入3.0+时代，国内很多企业都在用Dubbo 3.0+版本，比方：阿里云、饿了么、安全衰弱 、战火递 、小米等，大部分企业应该都还停留在2.7+版本。由此可知（不想再多说废话了），学习Dubbo、把握Dubbo还是十分重要。 如果仅仅是应用Dubbo，那还是没什么难度的，但想搞清楚后背实现原理，真就没那么简略。 上面咱们来聊聊，模板办法模式在Dubbo的应用。 模板办法模式模板办法模式代码通用模板： public class abstract 父类{ method(){ first(); second(); doBusi(); third(); } //传说中的 钩子办法，有子类实现 protected abstract doBusi();}public class 具体实现类1 extends 父类{ doBusi(){ //我要变得更有钱 }}public class 具体实现类2 extends 父类{ doBusi(){ //我要变得更有文化 }}public class 具体实现类3 extends 父类{ doBusi(){ //我要变得更帅 }}//.....更多子类只有你在任何框架任何源码中看到此类型的实现，那它就是应用了模板办法模式。 咱们能够应用下面的这种形式去Dubbo，只有有相似的，那就是模板办法模式在Dubbo的中应用。 场景1咱们的provider为了高可用通常都会对同一个服务部署多个节点，那客户端拿到服务列表后，就须要从服务列表中筛选一台服务而后发动调用。 Dubbo中负载平衡算法有四种。 一致性 Hash，雷同参数的申请总是发到同一提供者。当某一台提供者挂时，本来发往该提供者的申请，基于虚构节点，平摊到其它提供者，不会引起激烈变动。起码沉闷调用数，雷同沉闷数的随机，沉闷数指调用前后计数差。使慢的提供者收到更少申请，因为越慢地提供者的调用前后计数差会越大。随机，按权重设置随机概率。在一个截面上碰撞的概率高，但调用量越大散布越平均，而且按概率使用权重后也比拟平均，有利于动静调整提供者权重。轮循，按公约后的权重设置轮循比率。存在慢的提供者累积申请的问题，比方：第二台机器很慢，但没挂，当申请调到第二台时就卡在那，长此以往，所有申请都卡在调到第二台上。 下面是Dubbo中负载平衡这一块的类关系图。 从图中能够看出AbstractLoadBalance是每个具体负载平衡算法的父类。 咱们再来看看AbstractLoadBalance是如何实现的： public <T> Invoker<T> select(List<Invoker<T>> invokers, URL url, Invocation invocation) { if (invokers == null || invokers.isEmpty()) { return null; } if (invokers.size() == 1) { return invokers.get(0); } return doSelect(invokers, url, invocation);}protected abstract <T> Invoker<T> doSelect(List<Invoker<T>> a, URL url, b c);咱们再通过IDEA，咱们能够轻松的晓得这个办法的具体实现类： ...

作者：姚辉 在 2018 年，Observability（即可观测性）首次被引入 IT 畛域，并逐步取代只关注零碎整体可用性的传统监控。随着云原生技术的一直倒退，企业从单体架构倒退到分布式架构，应用容器部署拆分进去的一众微服务、与业务联系严密，传统的监控仅适宜报告零碎的整体运行状况无奈进行高度细化的剖析与关联，于是须要将研发视角融入监控，倒退具备比原有监控更宽泛、更被动、更细粒度的能力，这种能力就是可观测性。 Dubbo 3 的建设布局有上云，可观测性是上云必不可少的能力，集群间依据实例可用性负载平衡、Kubernetes 弹性伸缩、建设实例衰弱模型等等使用场景都须要可观测性。 目前 Dubbo 3 的可观测性正在建设中，本文次要介绍 Metrics 模块基础知识与进度。 零-APM 介绍APM全称是 application performance management，翻译过去就是利用的性能治理，次要是用来治理和监控软件系统的性能和可用性。能够保障线上服务的品质，是一个重要的服务治理工具。 如果从零碎职能上分的话，APM 零碎的话能够能够分为三个子系统，别离是 Metrics、Tracing 和 Logging。 Metrics 也叫指标监控，次要是负责解决一些结构化的能够聚合的一些指标数据。 Tracing 又叫链路追踪，次要是围绕单次申请进行信息处理，而后所有的数据都被绑定到零碎的单个申请或者说单个事务上。 Logging 是日志监控，次要梳理一些非结构化的事件。 Metrics 构造与类型 一个 Metrics 由四局部组成，第一个是指标名称；第二个是 labels 或者说 tags 也就是标签，是一些维度数据，这些维度数据能够用来做一些过滤或者聚合查问；第三个是工夫戳，就是它的工夫字段；第四个就是具体的指标的一个值。 除了上述四个局部之外，还有一个十分重要的字段没有体现在数据模型里，就是这条数据的指标类型。不同的指标类型的话它是会用在不同的监控场景，同时它的一些查问和可视化的一些形式，也会有一些区别。 上面简略介绍一些罕用的指标类型。 第一个是 Gague，这个类型的特点就是他是可增可减的。比如说 CPU 负载、沉闷线程数、内存使用率、磁盘使用率，这些数它都是会随着工夫进行稳定的。它存储和展现的都是一个瞬时值。 第二个指标类型 Counter，这个类型的特点是只增不减，比如说接口申请总量，对于这个类型，个别会有几个衍生的解决，一个是能够比拟两个工夫点前后的一个差值，这样能够计算出这个单位工夫内的申请的一个稳定量。第二个就是对工夫进行求导之后，就失去 QPS 这种类型的一个字段。 第三个指标类型是 Summary，次要做的是一个汇总统计，比如说平均值，分位数这样的一些指标。而后这个指标类型的话次要用于接口响应提早这样的一个场景。因为咱们平时在看接口响应提早这个指标的时候，个别除了看它的平均值，可能还会看一些那种分位数指标。 第四个指标类型是 Historgram，它是一个柱状统计，个别是会先对指标进行一个分桶，分桶之后再去统计它的一些值。比如说咱们的还是以那个接口响应提早为例的话，它会比如说有一些那种可视化展现的话，展现它的那个柱状图。 指标收集 Dubbo 的指标体系，总共波及三个模块，别离是指标收集、本地聚合、指标推送。 指标收集：将 Dubbo 外部须要监控的指标推送至对立的 collector 中进行存储。本地聚合：指标收集获取的均为根底指标，而一些分位数指标则需通过本地聚合计算得出。指标推送：而获取指标的话有两种形式，第一种是间接拜访 Dubbo 裸露的接口就能够取得 Dubbo 外部统计的指标，第二种是接入第三方服务器进行指标推送，Dubbo 会将收集和聚合后的指标通过 pull 或者push的形式推送至第三方服务器，目前只波及 Prometheus，其中 pull 或者 push 由用户抉择。 指标收集 ...

网潘货区：SpringCloud整合Dubbo3实战高并发下的微服务架构设计王盘分xiang网站SEO关键词优化的5个技巧对于企业来说，网站很重要。通过网站能够展现企业的产品和服务，与客户进行交换。然而，一个企业只有网站是不够的。还要做好SEO优化，让网站有一个好的排名。那么企业如何做好网站SEO优化呢？上面分享一下SEO网站优化办法和网站SEO关键词优化的五个小技巧。网站SEO优化的办法 1.设置网站的TDK(题目、形容和关键字)。 网站的题目和形容是关键词布局的重要组成部分，设置网站的题目和形容是十分重要的一步。个别题目蕴含3~5个关键词。倡议应用“_”、“|”等作为连接符，重要的关键词要放在后面的地位。个别通顺的句子蕴含3~5个关键词，句子不要超过80个汉字，160个英文字符。 2.公布与主题相干的优质内容。 网站要有明确的主题，每个版块的内容都要解释和撑持这个主题，版块之间要有清晰的逻辑关系和层次感。每一节的内容不要混同，不要与主题无关。更加重视为用户提供主题相干、品质更高的原创内容。 3.向网站图片增加文本形容。 网站展现的图片要加上图片的形容，能够帮忙搜索引擎索引网站的图片，从而进步网站相干主题的排名。 4.关上HTTPS性能 有很大的反对百度HTTPS网站。Https能够减少网站的信任度，爱护数据，防止龚攻打，同时进步网站的SEO排名。该性能在在线建站后盾的“设置-域名”中一键开启，无需放心细节问题。 5.建设友情链接并推广。 一部分搜寻后果来自内部链接和流量，这意味着越多高质量的网站链接到咱们的网站，咱们的网站排名就会越高。所以你能够去各大博客、论坛或者社交网站分享咱们的网站，减少曝光率。 6.留神网站收录。通过SEO综合查问工具，每天查看网站的收录和关键词排名。咱们能够通过md5.com.cn枫叶SEO网查问网站。关上网站后，在首页的输入框中输出要查问的网站，点击查问。稍等一下，能够看到网站的收录和关键词排名。 网站SEO关键词优化的5个技巧 1.网站关键词权重的聚合 应该和题目形容中设置的关键词统一。每一页都应该有不同的题目和形容。切记不要和其余页面一样。题目中关键词的数量应不少于三次。 2.调配关键字等级。 把关键词分成好的等级，外围关键词要放在首页，而后下一级词放在栏目页，长尾词放在内容页。这样清晰的层次结构会给搜索引擎留下很好的印象，整个网站的构造也会更清晰，对搜索引擎优化更敌对。 3.网站的标签和关键词密度 网站的三个标签要依照前后的程序写，否则引擎会依据网站关键词呈现的次数来确定网站关键词。另外，alt标签也很重要，它能够减少关键词的密度，也有利于引擎抓取。同时须要留神的是，引擎无奈抓取网站的图片。为了不影响网站的关上速度，增加时通常须要对图片进行压缩。 4.网站关键词超链接 网站的关键词要有超链接。文章中出现的关键词能够进行网站内容的互相链接，咱们能够链接到一个与网站内容相干的网页。这也是在关键词优化技巧中突出关键词的体现。事实上，内容中某些段落的题目和文章中加粗的段落能够通过比照暂停，以显示关键词。5.定期更新文章。 放弃网站每天定期更新文章。更新的内容尽量是原创或者高质量的伪原创。其次要图文并茂，字数在800字左右。最初，如果优化后的网站竞争不强烈，也没必要天天更新。然而，别忘了引流。没有流量，天然就没有转化。 因为当初各行各业都很风行搞网站SEO，所以网站关键词排名的竞争也越来越强烈。进步网站关键词排名，要晓得网站SEO优化的办法和技巧。以上分享网站SEO优化办法和关键词优化技巧，心愿能帮忙到有须要的敌人。

作者：vivo 互联网服务器团队- Wang Fei、LinYupanDubbo泛化调用个性能够在不依赖服务接口API包的场景中发动近程调用, 这种个性特地适宜框架集成和网关类利用开发。 本文联合在理论开发过程中所遇到的须要近程调用多个三方零碎的问题，论述了如何利用Dubbo泛化调用来简化开发升高零碎耦合性的我的项目实际，最初对Dubbo泛化调用的原理进行了深度解析。 一、背景对立配置平台是一个提供终端设备各个模块进行文件配置和文件下发能力的平台，模块开发在后盾服务器进行文件配置，而后终端设备能够依照特定规定获取对应的配置文件，文件下发能够依照多种设施维度进行下发，具体我的项目框架能够加入下图： 现有的下发策略，都是由模块开发在对立配置后盾服务器进行下发维度配置，文件是否下发到对应终端设备，由用户在本平台所抉择的维度所确定。 然而其余业务方也存在在公司外部的A/B试验平台配置下发规定，来借助对立配置平台每天轮询服务器申请新文件的能力，然而在对立配置平台配置的文件是否可能下发由A/B试验平台来确定，A/B试验平台内会配置对应的规定以及配置对立配置平台对应的文件id，而后对立配置平台就须要针对申请调用A/B试验平台接口来判断文件是否能够下发。 随着公司外部试验平台的减少，越来越多这种由三方平台来决定文件是否下发的对接需要，如何更好更快的应答这种相似的对接需要，是咱们须要去深刻思考的问题。 二、计划选型原有对立配置的下发逻辑是先找到所有能够下发的文件，而后判断单个配置文件是否满足设施维度，如果满足则能够下发。当初在对接A/B试验平台当前，文件是否能下发还须要由内部零碎来确定，过后设计时思考过两种计划： 计划一:同样先找到所有能够下发的文件，而后针对单个文件依照①设施维度判断是否匹配，而后②调用A/B试验平台的接口获取这台设施能够下发的文件Id， 再调用③灰度试验平台获取这台设施能够下发的文件id， 最初将前三步获取到的配置文件id进行汇总失去能够下发的文件，如下图所示。 计划一突破了原来文件是否可能下发的判断逻辑，当初除了原有的判断逻辑，还须要额定步骤调用其余零碎来追加另外能够下发的文件。并且后续不可避免对接其余三方零碎，计划一须要一直减少调用三方接口的逻辑来追加能够下发的文件id。此外惯例的dubbo调用在provider端须要引入其余试验零碎的二方库以及模型类型，减少了对立配置零碎和其余零碎的强耦合性。 计划二:利用 Dubbo 泛化调用高级个性形象一个下发维度(近程调用)，专门用于其余想由三方试验零碎来决定是否下发文件的场景，如下图所示： 计划二对立形象一个近程调用下发维度，能够放弃原有的判断逻辑，也就是先把零碎中所有能够下发的文件先查找进去，而后依据设施维度进行匹配，如果某一个文件配置的是近程调用维度，那么查找这个近程调用维度所蕴含的函数名称、参数类型数组和参数值对象数组，而后调用三方接口，从而判断这个文件是否能够下发到设施，最终获取到能够下发的文件id列表。 此外，利用Dubbo泛化调用高级个性，调用方并不关怀提供者的接口的具体定义，只须要关注调用哪个办法，传什么参数以及接管到什么返回后果即可，这样防止须要依赖服务提供者的二方库以及模型类元，这样能够大大降低consumer端和provider端的耦合性。 综合下面的剖析，咱们最终确定了计划二采取利用Dubbo泛化调用来形象一个对立维度的形式，上面来看一下具体的实现。 三、具体实现1.GenericService是Dubbo提供的泛化接口，用来进行泛化调用。只提供了一个$invoke办法，三个入口参数别离为函数名称、参数类型数组和参数值对象数组。 package com.alibaba.dubbo.rpc.service; /** * Generic service interface * * @export */public interface GenericService { /** * Generic invocation * * @param method Method name, e.g. findPerson. If there are overridden methods, parameter info is * required, e.g. findPerson(java.lang.String) * @param parameterTypes Parameter types * @param args Arguments * @return invocation return value * @throws Throwable potential exception thrown from the invocation */ Object $invoke(String method, String[] parameterTypes, Object[] args) throws GenericException;创立服务援用配置对象ReferenceConfig。private ReferenceConfig<GenericService> buildReferenceConfig(RemoteDubboRestrictionConfig config) { ReferenceConfig<GenericService> referenceConfig = new ReferenceConfig<>(); referenceConfig.setApplication(applicationConfig); referenceConfig.setRegistry(registryConfig); referenceConfig.setInterface(config.getInterfaceName()); referenceConfig.setVersion(config.getVersion()); referenceConfig.setGeneric(Boolean.TRUE.toString()); referenceConfig.setCheck(false); referenceConfig.setTimeout(DUBBO_INVOKE_TIMEOUT); referenceConfig.setRetries(DUBBO_INVOKE_RETRIES); return referenceConfig;}3.设置申请参数及服务调用, 这里利用在后盾所配置的残缺办法名、参数类型数组和参数值数组就能够进行服务调用。 ...

前言微服务是近几年流行起来的软件架构格调。回顾历史，从传统的单体利用架构，到面向服务架构SOA,再到明天逐步被公众承受的微服务架构MSA，实质上来说，都是为了解决随着软件复杂度的回升，如何无效晋升开发效率、公布效率的问题。 同样，这个问题在阿里巴巴电商零碎的倒退历程中也遇到过。因为业务体量微小、需要变更频繁，导致淘宝和淘宝商城(天猫的前身)的研发效率变得低下，在这个背景下，2008年10月立项了驰名的“五彩石”我的项目，对电商零碎做了零碎的拆分，实现了服务化革新。通过这个我的项目，孕育出了以HSF、Notify 为代表的分布式中间件组件。并且，在随后的十年中，分布式中间件蓬勃发展，从软负载核心Config Server、 配置核心Diamond Server, 到全链路追踪EagleEye、限流Sentincel,再到全链路压测体系，能够说，基于分布式中间件构建的整个服务化体系是撑持“双11”GMV从2009年的5000万元到明天惊人的2135亿元的技术基石。正是服务化革新的胜利施行和一直演进，为每年万亿流量的洪峰及层出不穷的大促玩法保驾护航了有10个年头。 即便是在抉择了微服务架构之后，也会面临技术栈选型的问题，从国内宽泛应用的Apache Dubbo,到国内上的Spring Cloud, JavaEE Micoprofile畛域的JBoss Wildfly, 再到最近开始提出的Cloud Native MicroServices,抉择并胜利施行其中的一种技术栈，成为宽广架构师们挠头的事件。好在当初由8位阿里大牛合著的：《高可用可伸缩微服务架构》，从微服务根底介绍起，横向地比拟了三种有代表性的微服务架构选型，探讨了微服务架构中后期须要解决的事务、网关、服务编排、高可用等高级话题，并深刻分享了实战案例。整本书从根底概念到高级话题，从实践到实际都有波及，八面玲珑，实属架构师案头不可或缺的参考书。 这份呢由8位阿里架构师合著GitHub上星标93K+微服务架构笔记一共531页，因为篇幅限度仅展现局部目录，【间接点击此处】获取这份材料的完整版哦，童叟无欺！！！ 内容简介第1章:微服务架构概述(作者秦金卫) 本章从软件架构的倒退历程讲起，别离对单体架构、SOA架构和微服务架构的演进过程做了深入浅出的解说，同时深刻介绍了微服务架构的特点，心愿以宏观的视角为读者关上微服务的大门。 第2章:微服务畛域驱动设计(作者张逸)。 本章介绍了畛域驱动设计是什么，常见的畛域架构有哪些，如何将畛域驱动利用到微服务中,以及如何应用畛域驱动进行正当的服务划分等，帮忙读者在正式学习微服务前修炼“内功”。 第3章: Apache Dubbo框架的原理与实现(作者程超)。 目前Dubbo曾经被阿里巴巴技术团队从新保护并且失去了鼎力的倒退和推广，应用Dubbo能够很好地进行微服务建设，本章较为深刻地解说了Dubbo的应用和技巧，以及通过时源码的深入分析可能让读者对Dubbo的原理实现有--个全面的意识。 第4章: Spring Boot/Spring Cloud实际(作者方志斌)。 Spring BootCloud是目前较为风行的微服务框架，本章以大量的实战案例为线索，为读者解说如何能力应用好Spring Cloud框架，解说如何防止在应用过程中“踩坑”。 第5章:微服务稳定性保障的罕用伎俩(作者杜琪)。 在业务倒退越来越快，规模也越来越大的状况下，咱们所面临的就是如何在服务越来越多的状况下保障微服务架构的稳定性，本章解说保障稳定性的罕用技巧和伎俩。 第6章:微服务下如何保障事务的一致性(作者梁桂钊)。 本章介绍了从本地事务到分布式事务的演变，深入分析了微服务在强一致性场景 和最终一致性场景下的解决方案，探讨了二阶段提交协定、三阶段提交协定、TCC模式、弥补模式、牢靠事件模式等。同时，对开源我的项目的分布式事务进行解读，包含RocketMQ和ServiceComb. 第7章:百亿流量微服务亿级网关的设计与实现(作者秦金卫)。 本章从百亿流量交易系统微服务网关(API Gateway)的现状和面临问题登程，论述微服务架构与API 网关的关系，理顺流量网关与业务网关的脉络，分享全面的API网关常识与教训。 第8章:微服务编排(作者程超)。 本章以Netlix Conductor框架为外围，从框架的应用和原理的角度深刻介绍了什么是微服务编排，为微服务执行简单的业务逻辑提供了一种新的思路。 第9章:微服务数据抽取与统计(作者肖冠宇)。 在微服务架构下，服务必将越来越多，在这种状况下进行数据统计和剖析将变得十分艰难，本章将深刻解说如何从不同服务的数据库中抽取数据到对立-的大数据平台中， 帮忙使用者更不便地进行数据的统计。 第10章:微服务双活体系建设(作者程超)。 在企业倒退规模越来越大的状况下，用户对系统的稳定性要求也越来越高，那么单机房部署势必成为倒退的瓶颈，本章将以理论案例登程解说同城双活的建设。 第11章:基于领取场景下的微服务革新与性能优化(作者程超)。 本章从理论的案例登程，在具体的领取业务场景下，从一个新我的项目开始逐渐解说如何利用畛域驱动划分服务，如何利用微服务框架进行服务治理，以及我的项目实现后怎么晋升微服务架构的性能。 第12章:遗留零碎的微服务架构革新(作者梁桂钊)。 本章介绍了遗留零碎的微服务架构革新，梳理了代码分层构造的转变，提出-一个新的代码分层思路来应答微服务的风行与遍及，并深刻思考了遗留零碎的债券，深入探讨单体零碎拆分服务的方法论。同时，对遗留零碎的微服务架构革新的解决方案给出9个切实可行的外围实际思路。 第13章: Service Mesh详解(作者殷琦)。 ...

RPC基础知识软件架构繁多利用架构当网站流量很小时，利用规模小时，只需一个利用，将所有的性能都部署在一起，以缩小部署服务数量和老本。此时，用于简化增删改查工作量的数据拜访框架(ORM)是要害。数据库的解决工夫影响利用的性能。 这种后果的利用适宜小型零碎、小型网站、或者企业的外部零碎，用户较少，申请量不大，对申请的解决工夫没有太高的要求。将所有性能都部署到一个服务器，简略易用。开发我的项目的难度低。 但毛病也不言而喻： 性能扩大比拟艰难不利于多人同时开发不利于降级保护整个零碎的空间占用比拟大分布式服务架构当利用越来越多，利用之间交互不可避免，将外围业务抽取进去，作为独立的服务，逐步造成稳固的服务中心，是前段利用能更疾速的响应多变的市场需求。此时用于进步业务服用及整合的分布式服务框架（RPC）是要害。分布式系统将服务作为独立的利用，实现服务共享和重用。 分布式系统什么是分布式系统分布式系统是若干独立计算机（服务器）的汇合，这些计算机对于用户来说就像单个相干零碎，分布式系统（distributed system) 是建设在网络之上的服务器端的一种构造。 分布式系统中的计算机能够应用不同的操作系统，能够运行不同应用程序提供服务，将服务扩散部署到多个计算机服务器上。 什么是RPCRPC（Remote Procedure Call）是指近程过程调用，是一种过程间通信形式，是一种技术思维，而不是标准。它容许程序调用另一个地址空间（网络的另一台机器上）的过程或函数，而不必开发人员显示编码这个调用的细节。调用本地办法和调用近程办法一样。 RPC的实现办法能够不同，例如Java的rmi、spring近程调用等。 RPC概念是在上世纪80年代由Brue Jay Nelson（布鲁·杰伊·纳尔逊）提出，应用RPC能够将本地的调用扩大到近程调用（分布式系统的其余服务器） RPC的特点： 简略：应用简略，建设分布式应用更容易高效：调用过程看起来非常清晰，效率高通用：过程间通信的形式，有通用的规定RPC基本原理图解 RPC调用过程调用方client要应用右侧server的性能（办法），发动对办法的调用client stub是RPC中定义的存根，看做是client的助手。stub把要调用的办法参数进行序列化、办法名称和其余数据包装起来通过网络socket（网络通信的技术），把办法调用的细节内容发送给右侧的serverserver端通过socket承受申请的办法名称、参数等数据，传给stub.server端接到的数据由server stub（server的助手）解决，来调用server的真正办法、解决业务server办法解决完业务，把解决的后果对象（Object）交给了助手，助手把Object进行序列化，对象转为二进制数据server助手二进制数据交给网络处理程序通过网络将二进制数据，发送给clientclient接到数据，交给client助手client助手，接管到数据通过反序列化为Java对象（Object），作为近程办法调用后果RPC通信是基于tcp或udp协定 序列化办法（xml/json/二进制） Dubbo框架Dubbo概述Apache Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大外围能力： 面向接口的近程办法调用只能容错和负载平衡服务主动注册和发现Dubbo是一个车分布式服务框架，致力于提供高性能和透明化的RPC近程服务调用计划及服务治理计划 面向接口代理： 调用接口的办法，在A服务器调用B服务器的办法，由Dubbo实现对B的调用，无需关怀实现的细节。 就像Mybatis拜访Dao接口能够操作数据库一样，不要管线Dao接口办法的实现。简化了开发流程和难度。 根本架构图解 对象角色阐明服务提供者（provider）：裸露服务的提供方，服务提供者在启动时，向注册核心注册本人提供的服务。服务消费者（Consumer）：调用近程服务的生产方，服务消费者在启动时，向注册核心订阅本人所需的服务。服务消费者从提供者地址列表中，基于软负载平衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。注册核心（Registry）：注册核心返回服务提供者地址列表给消费者，如果有变更，注册核心将基于长连贯推送变更数据给消费者监控核心（Monitor）：服务消费者和提供者，在内存中累计调用次数和调用工夫，定时每分钟发送一次统计数据到监控核心调用关系阐明服务容器负责启动、加载、运行服务提供者服务提供者在启动时，向注册核心注册本人提供的服务服务消费者在启动时，向注册核心订阅本人所需的服务注册核心返回服务提供者地址列表给消费者，如果有变更，注册核心将基于长链接推送变更数据给消费者服务消费者从提供者地址列表中，基于软负载平衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用服务消费者和提供者，在内存中累计调用次数和调用工夫，定时每分钟发送一次统计数据到监控核心Dubbo反对的协定Dubbo反对多种协定，如：dubbo、hessian、rmi、http、webservice、thrift、memcached、redis等 Dubbo官网举荐应用dubbo协定，dubbo协定默认端口20880. 应用dubbo协定，须要在spring配置文件中退出下列标签注解： <dubbo:protocol name="dubbo" port="20880"/> Dubbo直连实现首先创立一个空的一般Java工程创立一个子maven web工程001-link-userService-provider，最终我的项目目录构造如图所示 新建readme.md文件，编写我的项目思路 1. 创立一个maven web工程——服务的提供者2. 配置pom.xml文件——增加须要的依赖3. 创立一个实体bean——User4. 提供一个服务接口——UserService5. 实现这个服务接口——UserServiceImpl6. 配置dubbo服务提供者的外围配置文件 + 申明dubbo服务提供者的名称（保障唯一性） + 申明dubbo应用的协定和端口号 + 裸露服务，应用直连形式7. 增加监听器编写pom.xml文件，增加依赖 <?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>xyz.rtx3090</groupId> <artifactId>001-link-userService-provider</artifactId> <version>1.0-SNAPSHOT</version> <!--packaging值默认为jar--> <packaging>war</packaging> <dependencies> <!--spring依赖--> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>4.3.16.RELEASE</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-webmvc</artifactId> <version>4.3.16.RELEASE</version> </dependency> <!--dubbo依赖--> <!-- https://mvnrepository.com/artifact/com.alibaba/dubbo --> <dependency> <groupId>com.alibaba</groupId> <artifactId>dubbo</artifactId> <version>2.6.2</version> </dependency> </dependencies> <build> <plugins> <!--规定我的项目JDK版本--> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.8.0</version> <configuration> <source>1.8</source> <target>1.8</target> </configuration> </plugin> </plugins> <resources> <!--解决Maven动态资源过滤问题--> <resource> <directory>src/main/java</directory> <includes> <include>**/*.properties</include> <include>**/*.xml</include> </includes> <filtering>true</filtering> </resource> <resource> <directory>src/main/resources</directory> <includes> <include>**/*.properties</include> <include>**/*.xml</include> </includes> <filtering>true</filtering> </resource> </resources> </build></project>新建包xyz.rtx3090.dubbo.model，并在其下创立User实体类 ...

商业转载请分割作者取得受权，非商业转载请注明出处。For commercial use, please contact the author for authorization. For non-commercial use, please indicate the source.协定(License)：署名-非商业性应用-雷同形式共享 4.0 国内 (CC BY-NC-SA 4.0)作者(Author)：Waste Code链接(URL)：https://waste-code.tech/archi...起源(Source)：Waste Code文章概览我的项目模块 common模块——实现实体类以及申明裸露的api接口provider模块——裸露的api接口的业务实现consumer模块——申请接口的实现，将会待用裸露的api接口GITHUB: Dubbo的简略应用以及Triple协定的Streaming通信的实现官网文档: Triple协定Blog目标: 记录实现过程及呈现的问题Dubbo的简略应用在common模块中定义实体类User在common模块中申明暴露出的接口，实现接口UserService public interface UserService { /** * 获取用户信息 * @param name * @return */ User getUserInfo(String name);}在provider和consumer模块中引入相干依赖 <dependency> <groupId>org.apache.dubbo</groupId> <artifactId>dubbo-spring-boot-starter</artifactId> <version>3.0.7</version></dependency><!-- 上面这个包必须援用，服务注册到zookeeper中应用，之前没有援用这个包，后果利用起不来 --><dependency> <groupId>org.apache.dubbo</groupId> <artifactId>dubbo-registry-zookeeper</artifactId> <version>3.0.7</version></dependency><dependency> <groupId>com.sample</groupId> <artifactId>common</artifactId> <version>0.0.1-SNAPSHOT</version></dependency>在provider和consumer模块中创立application.yml文件并编写相干配置 server: port: 8082 # 这里填写端口号，provider和consumer不同，spring: application: name: consumerdubbo: protocol: name: dubbo # 抉择通信协议 port: -1 registry: id: zk-zookeeper address: zookeeper://127.0.0.1:2181在provider和consumer中编写启动类，这里以consumer模块为例，这里要加上EnableDubbo注解 ...

dubbo如何测试？和spring齐全一样。 其实就是基于2个注解。 一个是springboot的注解：@SpringBootTest。 一个是spring的注解：@RunWith(SpringRunner.class)。 这两个都是测试相干的注解，而且都在测试jar里。 外围代码测试代码示例 import lombok.extern.slf4j.Slf4j;import org.apache.dubbo.spring.boot.sample.provider.bootstrap.DubboRegistryZooKeeperProviderBootstrap;import org.apache.dubbo.spring.boot.sample.provider.service.DefaultDemoService;import org.junit.Test;import org.junit.runner.RunWith;import org.springframework.beans.factory.annotation.Autowired;import org.springframework.boot.test.context.SpringBootTest;import org.springframework.test.context.junit4.SpringRunner;/** * @author javaself */@Slf4j@RunWith(SpringRunner.class) //应用junit4@SpringBootTest( classes = DubboRegistryZooKeeperProviderBootstrap.class, //指定启动入口类 webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)public class DubboTest { @Autowired DefaultDemoService defaultDemoService; //注入dubbo服务 @Test public void test() throws Exception { String s = defaultDemoService.sayHello("Hello, world!"); //调用dubbo服务进行测试 log.info(s); }}外围步骤创立测试类在测试类上，加2个注解pom文件增加依赖的测试jar运行测试类的测试方法就像个别的测试类的测试方法一样。 @SpringBootTest注解能够指定一些配置，比方classes属性是指定springboot我的项目的启动入口类。 依赖的测试jar次要是springboot和spring，还有junit <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-test</artifactId> </dependency> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <scope>test</scope> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-test</artifactId> <scope>test</scope> </dependency> zk在application.properties增加禁止注册配置，禁止本地服务注册到zk，防止影响测试环境。 # 用于自测，禁止注册到zkdubbo.registry.register=false多个测试类如果有多个测试类，能够把公共的局部独立进去。 具体来说，就是写一个根底测试类。 ...

艰深地讲，Seata-php 是 seata 的 PHP 语言实现，实现了 Java 和 PHP 之间的互通，让 PHPer 也能应用 seata-php 来实现分布式事务。 Seata是一个十分成熟的分布式事务框架，在 Java 畛域是事实上的分布式事务技术标准平台。Seata 目前正在构建其多语言体系【参考文档1】，整个体系蕴含了目前罕用的五大类语言：Java、Go、Python、Js 和 PHP，目前的态势是后四种语言都根据 Seata Java 版本构建起对应语言的实现。 除了谋求 Seata 多语言体系过程中因为开源价值要求构建 Seata 的 PHP 版本这个起因外，作为构建起 Web 1.0 时代技术根底 LAMP 架构中的要角，PHP 语言在电商和金融交易场景下仍然被宽泛应用，而这些场景对数据一致性要求十分强烈，这是构建 Seata-php 最大的诱因，也是其技术价值所在。 1 Seata 架构与多语言体系图片来自 seata 官网 Seata 总体架构由如下角色形成：事务协调器 Transaction Coordinator简称 TC，保护全局事务和分支事务的状态，驱动全局事务提交或者回滚。事务管理器 Transaction Manager简称 TM，定义全局事务的范畴，提交或者回滚全局事务。资源管理器 Resource Manager简称 RM，和分支事务在同一个利用，进行分支事务的注册，报告分支事务的状态，驱动分支事务的提交或者回滚。 从 C/S 通信架构角度来看，TC 是服务端，TM 和 RM 是客户端。TC 与 TM 以及各个 RM 之间应用 netty 框架进行长链接通信。具体而言，Seata Java 版本的通信协议是在四层 TCP 协定之上又定义了一套公有的二进制双向通信协定，通信框架应用了 netty。其余四种语言只有根据 Seata 的通信协议规范实现其通信性能，即可在多语言生态体系内任何语言之间进行通信和服务调用。 ...

dubbo-go-pixiu v0.5.1（链接https://github.com/apache/dub... ) 通过 apache 发版投票流程明天正式发版 ，在此感激关注 dubbo-go-pixiu 的搭档，以及社区搭档们的无私奉献。 1 Pixiu 是什么Pixiu 是 dubbogo 社区推出的一款基于 Dubbo 生态的高性能网关。 2 Pixiu 0.5.1 发版内容Features 1 可观测性之分布式链路追踪 咱们常说的可观测性大抵分为三个方向：Logging、Tracing 和 Metrics。皆在帮忙开发者疾速剖析和诊断分布式应用的性能瓶颈，进步开发诊断效率，而在 0.5.1 版本，Pixiu 也投入了相当一部分精力在 Tracing 方向，上面简略介绍一下由社区 Maxingg 同学为 Pixiu 提供了HTTP场景 Tracing 能力。 对于分布式应用可观测性畛域感兴趣的同学能够退出社区，一起探讨、建设。 PR：https://github.com/apache/dubbo-go-pixiu/pull/394 2.1 健康检查Pixiu 新增了服务健康检查机制，为 Pixiu 的减少更多牢靠的应用场景，由社区 ztelur 提供基于与端点建设 tcp 网络拨号来探活，上面简略介绍一下 Pixiu Heath Check。 PR: https://github.com/apache/dubbo-go-pixiu/pull/421 2.3 代理 Dubbo 直连模式Dubbo/Dubbo-go 的直连模式大家都不生疏，而这个版本，为了更好的帮忙 Pixiu 在云原生（Sidecar）的方向迈步，Pixiu 在现有基于服务发现代理申请 dubbo 的根底上，新增了直连的模式，更好的助力 Pixiu 的 Sidecar 状态。 ...

几个月后收到学习心得：通过实战场景推导出 Dubbo 外围底细https://gitbook.cn/gitchat/column/6265071b9f710200017098fc一、学习心得以下是一名在校毕业生的发我的感谢信，征求批准后，我放到了博客上： 咱们的这波疫情兜兜转转继续了快一个月了，如许心愿快点好起来呀，你是全世界人民的上海，咱们看好你，上海加油你是最棒的~ 可是一想到疫情恶化解封后又得持续找工作了，情绪不禁一阵酸酸的。我原本是一个前端，喜爱写一个业务逻辑代码，对于目前当初的前端 UI 页面各种画来画去有点好受，想转后端去尝试挑战本人。三月上旬刚辞职了没多久，上海就开始折腾这无厘头的疫情了，着实好受，当初还在窝里蹲期待解封，我太难了。 即便在被封期间，我发现一个人独处的确挺宁静的，能够静下心来各种钻研 Java 后端技术常识，为本人的转行做足充沛的筹备，我不晓得他人在疫情期间是玩手机刷视频，还是追剧各种闹折腾，我既然决定了，就保持初心，跟着本人的心田走，每天保持14小时的工夫学习 Java 基础知识，大多数工夫都是在网上看视频教程，可是视频教程太长，知识点而且也比拟凌乱，一下子无奈全盘疾速排汇把握这些知识点。就在保持了一段时间后，发现那些 Java 的英文字母我都看得懂，可是一到落笔的时候，很受限制，一来没有彻底搞明确本人须要干一个什么事件，二来是没有真切的明确有些 java 属性为什么要这么用，三来是没有找到一套通过景象剖析出代码应该如何写的这样的教程。 就这样无助、苦恼、郁闷了几天后，我偶尔在头条、知乎刷到了一个对于 dubbo 框架的技术文章，就顺手点进去看了看，可是不晓得为什么，一个原本不起眼的文章，外面的一些细碎环节教会了一些我素来都不会关注到的货色，比方平时遇到的一些案例场景真的是太平时太普通了，为什么这个作者却能写出一种让我豁然开朗的感觉；比方一些将实战案例场景怎么转化为一种技术诉求的时候，为什么这个作者却能栩栩如生让我身临其境般的感触到我就在干这个推导的细节过程，深受作者的思维启发；比方当有了解决方案后该怎么实现的时候，为什么这个作者能够从一些不起眼的要害字眼间接从源码中一步步找到曾经存在的一些性能，间接节俭了大量劳动力的开发成本，这种思维在企业中我感觉真的十分实用，因为企业在做性能时当然是越稳越准越快，而你还在慢吞吞的写性能实现，速度太慢了啊，还有很多等等，以我目前的技术水平，有些我可能根本无法用语言来形容分明，看完后有一种感觉，就是那种 "不说则已，一说就破" 的感觉，形容不进去。 前面我跟着这个帖子下方的链接找打了一本对于《通过实战场景推导出 Dubbo 外围底细》这样一本书，也不贵，我大略花了四五天的工夫认真研读了一下这本书，真的解决我目前现状的困惑，学完最初有一种思维至上的感觉，学起什么其余货色来，能够借鉴作者的推导思维过程，而后缓缓就把握新框架的套路。 而且看完最初有一种收缩的感觉，真想把所学常识大干一场实际的想法，对解封后去找工作信心倍增。而且当我看完这本书的时候，我才发现还有一套价值1299元的全套视频赠送。原本在未接触过该《通过实战场景推导出 Dubbo 外围底细》书籍的时候，曾经对视频恶感有点无助了，可是再看完这本书后，再来看看作者收费赠送的全套视频教程时，以 2 倍的速度观看后，一来坚固了所学常识，二来情绪感触不一样，几乎是醍醐灌顶，感觉通了，就是那种无奈用语言形容通的感觉。 前面又求教了作者以我目前的状态，次要关注学习哪些方面的时候，作者也是知无不言言无不尽，给了一些他的收藏宝典，而后我筹备再花上两周的工夫，重点冲破一下基础知识的牢固，为接下来疫情解封后的首次面试做足充沛的筹备。 最初，还是非常感谢《通过实战场景推导出 Dubbo 外围底细》这本书的作者，给我解了惑，让我自身有点前端基础知识的我，更加对本人的转行充斥了信息。还是得为作者打个广告，祝作者的书籍越来越滞销，真心感激与祝愿。 二、专栏地址hhttps://gitbook.cn/gitchat/column/6265071b9f710200017098fc 欢送关注，您的必定是对我最大的反对!!!

公司之前有一个 Dubbo 服务，其外部封装了腾讯云的对象存储服务 SDK，目标是对立治理这种三方服务的SDK，其余零碎间接调用这个对象存储的 Dubbo 服务。这样能够防止因平台 SDK 呈现不兼容的大版本更新，从而导致公司所有零碎批改跟着降级的问题。 想法是好的，不过这种做法并不适合，因为 Dubbo 并不适宜传输文件。好在这个零碎在上线不久就没人用废除了…… 尽管被零碎废除了，不过就这个 Dubbo 上传文件的主题还是能够详细分析下，聊聊它到底为什么不适宜上传文件。 Dubbo 怎么传文件？难道这样间接传 File 吗？ void sendPhoto(File photo);当然不行！Dubbo 只是将对象进行序列化而后传输，而 File 对象就算序列化也无奈解决文件的数据，所以只能间接发送文件内容： void sendPhoto(byte[] photo);但这样就会导致 consumer 端须要一次性读取残缺的文件内容至内存中，再大的内存也扛不住这样玩。而且 provider 端在承受数据解析报文时，也须要一次性将 byte[] 读取至内存中，也是一样有内存占用过高的问题。 基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后盾管理系统 + 用户小程序，反对 RBAC 动静权限、多租户、数据权限、工作流、三方登录、领取、短信、商城等性能。 我的项目地址：https://github.com/YunaiV/ruo... 单连贯模型问题除了内存占用问题之外，Dubbo（这里指 Dubbo 协定）的单连贯模型也不适宜文件传输。 Dubbo 协定默认是单连贯的模型，即一个 provider 的所有申请都是用一个 TCP 连贯。默认应用 Netty 来进行传输，而 Netty 中为了保障 Channel 线程平安，会将写入事件进行排队解决。那么在单连贯下，多个申请都会应用同一个连贯，也就是同一个 Channel 进行写入数据；当多个申请同时写入时，如果某个报文过大，会导致 Channel 始终在发送这个报文，其余申请的报文写入事件会进行排队，迟迟无奈发送，数据都没有发送过来，那么其余的 consumer 也天然会处于阻塞期待响应的状态中，始终无奈返回了。 ...

其实上周是打算写Dubbo的，然而发现Dubbo须要一个注册核心，因为也有学习Dubbo的打算，所以将Zookeeper和Dubbo放在一起介绍。是啥？我记得上一次看Dubbo的官网，Dubbo将本人定义为一款RPC 框架，到Dubbo3就变成了: Apache Dubbo 是一款微服务开发框架，它提供了 RPC通信 与 微服务治理 两大要害能力。这意味着，应用 Dubbo 开发的微服务，将具备相互之间的近程发现与通信能力， 同时利用 Dubbo 提供的丰盛服务治理能力，能够实现诸如服务发现、负载平衡、流量调度等服务治理诉求。同时 Dubbo 是高度可扩大的，用户简直能够在任意性能点去定制本人的实现，以扭转框架的默认行为来满足本人的业务需要。这里再讨论一下什么是RPC(这一点我在RPC学习笔记初遇篇(一) 探讨的曾经很齐备了)，不少介绍RPC的文章都会先从一个利用想要调用另一个利用的函数动手，但这不如维基百科直观： 分布式计算中，近程过程调用（英语：Remote Procedure Call，RPC）是一个计算机通信协议。该协定容许运行于一台计算机的程序调用另一个地址空间(通常为一个凋谢网络的一台计算机）的子程序，而程序员就像调用本地程序一样，无需额定地为这个交互作用编程（无需关注细节).那为什么都从函数上动手，这是一种形象和封装，两个过程须要进行通信，须要在TCP之上制订规范，也就是制订应用层的协定，能够抉择HTTP(跨语言)，也能够基于TCP，自定义应用层的协定。咱们能够在Dubbo3概念架构一节的协定印证咱们的观点: Dubbo3 提供了 Triple(Dubbo3)、Dubbo2 协定，这是 Dubbo 框架的原生协定。除此之外，Dubbo3 也对泛滥第三方协定进行了集成，并将它们纳入 Dubbo 的编程与服务治理体系， 包含 gRPC、Thrift、JsonRPC、Hessian2、REST 等。以下重点介绍 Triple 与 Dubbo2 协定。 最终咱们抉择了兼容 gRPC ，以 HTTP2 作为传输层构建新的协定，也就是 Triple。 也就是咱们能够认为HTTP协定是RPC的一种。至于微服务治理，这里不再反复的进行的探讨，参考我掘金的文章: 《写给小白看的Spring Cloud入门教程》。那既然你说HTTP协定是RPC的一种，那Dubbo的意义又何在呢，我集体认为是对HTTP协定进行革新吧，HTTP 2.0之前都是文本模式的，采取二进制字节流在网络中传输更快，除此之外应用HTTP协定传送数据，还须要本人入手将数据进行序列化，如果须要跨语言通信，定义的规定就更多了，Dubbo帮咱们做好了这所有，甚至做的更多。这也就是咱们学习Dubbo的意义所在。 梳理一下，RPC是一个计算机通信协议，那为什么都结构成了函数调用这一模式，这是因为从形象来说是最正当的，咱们能够大抵推断演进一下: 首先是两个过程须要进行替换信息, 抉择了TCP作为传输层的协定, 有的人抉择了HTTP协定，因为这更简略一些, 当替换的信息比较简单，各个高级语言的Socket API 是能够满足其需要的。如果咱们期待这种替换的信息要更简单一点呢，如果说咱们抉择TCP或HTTP作为利用间通信的模式，那么就有一些重复性的编码工作，比方取值，序列化为对象，如果是TCP协定还要思考拆包等等，这无疑减轻了程序员们编码的累赘，那么能不能简化这个过程呢，屏蔽掉网络编程中波及的简单细节，形象进去一个简略的模型呢，高级语言都内置有函数，那不如就从函数动手，让过程间替换信息就像是调用两个利用一样，这也就是很多RPC教程都从函数动手的起因，我感觉是由过程通信的过程中，为了屏蔽掉网络编程的简单细节，抉择从函数动手，这样让人容易了解一些，而不是一开始就是函数调用的模式。换句话说，少数程序员可能没理解过Socket 编程中的拆包之类的概念，然而肯定了解函数这个概念，这是一种封装。而Dubbo尽管在官网将本人申明为是一款微服务开发框架，然而在理论利用场景中，Apache Dubbo 个别会作为后端系统间RPC调用的实现框架，咱们能够将其类比为HTTP协定对应的诸多HTTP Client。Dubbo提供了多语言反对，目前只反对Java、Go、Erlang这三种语言，那么咱们天然提出一个问题，不同语言内置的数据类型、办法模式是不一样的，那作为RPC的实现者，它是如何做到跨语言的。 当然是引入一个中间层-IDL为了和计算机进行通信，咱们引入了编程语言，编程语言就是一个中间层，那么为了让不同的高级语言进行通信，Dubbo引入了IDL，Dubbo中举荐应用IDL定义跨语言服务，那什么是IDL，Dubbo官网并没有解释，于是我去了维基百科: An interface description language or interface definition language (IDL), is a generic term for a language that lets a program or object written in one language communicate with another program written in an unknown language. IDLs describe an interface in a language-independent way, enabling communication between software components that do not share one language, for example, between those written in C++ and those written in Java. ...

dubbo降级到3.0版本后, 各个应用类都有变更, 配置也不一样。请参照github上的样例https://github.com/apache/dub...

简介：Proxyless Service Mesh 能力将追随 Dubbo-go 下一版本公布，稳固的性能须要社区成员们独特的关注与建设。在此基础之上，咱们还会进一步摸索轻量级 sdk + sidecar的模型；摸索基于第三方流量治理组件的金丝雀公布能力；摸索基于 dubbo 服务框架的多语言 sevice mesh、与更丰盛的 mesh 生态组件兼容。 作者 | 李志信起源 | 阿里开发者公众号 一 什么是 Proxyless Service-Mesh (无代理服务网格) ?1 Service Mesh 简析Istio 是当今最风行的开源服务网格。它由管制立体和数据立体形成，其架构如下（图片摘自 Istio官网）。 位于图中下半局部的管制立体负责配置、服务信息、证书等资源的下发。位于上半局部的数据立体关注业务之间的通信流量；传统服务网格通过代理的形式拦挡所有的业务网络流量，代理须要感知到管制立体下发的配置资源，从而依照要求管制网络流量的走向。 在 Istio 环境中，其管制立体是一个名为 istiod 的过程，网络代理是 envoy 。istiod 通过监听 K8S 资源 例如Service、Endpoint 等，获取服务信息，并将这些资源对立通过 XDS 协定下发给位于数据立体的网络代理。envoy 是一个独立的过程，以 sidecar（边车）的模式随同业务利用 Pod 运行，他与利用过程共用同一个主机网络，并通过批改路由表的形式，劫持业务利用的网络流量。 Service Mesh 能够解决微服务场景下的泛滥问题，随着集群规模的扩充与业务复杂度的增长，基于原生 k8s 的容器编排计划将会难以应酬，开发人员不得不面对微小的服务治理挑战。而 Service Mesh 很好地解决了这一问题，它将服务治理需要封装在了管制立体与代理中，业务开发人员只须要关注于业务逻辑。在利用部署之后，只须要运维人员通过批改配置，即可实现例如故障复原、负载平衡、灰度公布等性能，这极大地提高了研发和迭代效率。 Istio 的 sidecar 通过容器注入的模式随同业务利用过程的整个生命周期，对于业务利用是毫无侵入的，这解决了业务利用可迁徙、多语言、基础架构耦合等问题。但这也带来了高资源耗费、申请时延增长的问题。 Service 为服务治理提供了一个很好的思路，将基础架构与业务逻辑解耦，让利用开发人员只需关注业务。另一方面，因为 sidecar 的弊病，咱们能够思考应用 sdk 的模式，来代替 sidecar 撑持起数据立体。 ...

一、Dubbo整体架构图 二、线程模型官网地址：https://dubbo.apache.org/zh/d... 三、本地dubbo测试记录（一）踩坑 应用SpringBoot构建dubbo服务的时候，既应用了注解配置，又遗记敞开xml文件配置，导致利用启动失败。 （二）消费者端配置dubbo.consumer.timeout=3000，管制消费者期待服务端返回音讯的最大工夫，默认1秒；【默认配置下，某些服务端又存在慢办法，很容易导致申请超时报错；】（三）服务提供端配置dubbo.protocol.threadpool=cached，配置业务线程池类型；其余线程池类型如下：【若不配置，线程池默认应用SynchronousQueue队列（除eager 线程池），SynchronousQueue没有容量，是无缓冲期待队列，是一个不存储元素的阻塞队列，会间接将工作交给消费者，必须等队列中的增加元素被生产后能力持续增加新的元素】  fixed 固定大小线程池，启动时建设线程，不敞开，始终持有；(默认)cached 缓存线程池，闲暇一分钟主动删除，须要时重建；limited 可伸缩线程池，但池中的线程数只会增长不会膨胀。只增长不膨胀的目标是为了防止膨胀时忽然来了大流量引起的性能问题；eager 优先创立Worker线程池。在工作数量大于corePoolSize然而小于maximumPoolSize时，优先创立Worker来解决工作。当工作数量大于maximumPoolSize时，将工作放入阻塞队列中。阻塞队列充斥时抛出RejectedExecutionException。(相比于cached，cached在工作数量超过maximumPoolSize时间接抛出异样而不是将工作放入阻塞队列)。dubbo.protocol.threads=10，限度业务线程池最大线程数；等于并发访问量，超过线程数的申请间接触发回绝策略；（默认fixed 线程池最大200个线程） dubbo.protocol.dispatcher=message，配置dispatcher调度模式；【个别状况下倡议配置调度模式为message】，其余调度模式如下： all 所有音讯都派发到线程池，包含申请，响应，连贯事件，断开事件，心跳等；direct 所有音讯都不派发到线程池，全副在 IO 线程上间接执行；message 只有申请响应音讯派发到线程池，其它连贯断开事件，心跳等音讯，间接在 IO 线程上执行；execution 只有申请音讯派发到线程池，不含响应，响应和其它连贯断开事件，心跳等音讯，间接在 IO 线程上执行；connection 在 IO 线程上，将连贯断开事件放入队列，有序一一执行，其它音讯派发到线程池。dubbo.provider.actives=10，每个服务消费者，个办法最大并发调用数；从生产端管制，并发数是业务线程池大小的子集。 dubbo.provider.executes=10，每个服务提供者各办法最大可并行执行申请数；从提供端管制，并发数是业务线程池大小的子集（小于等于业务线程池大小）。四、主动stack dump 当业务线程池满时，咱们须要晓得线程都在期待哪些资源、条件，以找到零碎的瓶颈点或异样点。dubbo 通过 Jstack 主动导出线程堆栈来保留现场，不便排查问题。 默认策略: 导出门路，user.home标识的用户主目录导出距离，最短距离容许每隔10分钟导出一次指定导出门路：配置dubbo.properties文件，批改dubbo.application.dump.directory=/tmp

dubbo-gatewaydubbo-gateway 高性能dubbo网关，提供了http协定到dubbo协定的转换,但【并非】应用dubbo的【泛化】调用（泛化调用性能比一般调用有10-20%的损耗,通过一般异步的调用形式与基于webflux系列的响应式网关(spring cloud gateway)整合进步零碎的吞吐量,一般调用须要依赖api jar包,须要对接口定义进行革新,除此之外不须要做任何其它革新.另外也反对基于servlet类的利用或网关(spring cloud zuul)进行整合 泛化毛病泛化过程数据流会通过了三次转换, 会产生大量的长期对象, 有很大的内存要求。应用反射形式对于旨在榨干服务器性能以获取高吞吐量的零碎来说, 难以达到性能最佳同时服务端也会对泛化申请多一重 Map <-> POJO 的来回转换的过程。整体上，与一般的Dubbo调用相比有10-20%的损耗泛化调用在网关或服务消费者阶段无奈校验参数类型的有效性，数据要到服务提供者反序列化时能力校验出参数类型的有效性 开源地址https://github.com/smallbeant... 相干注解@GateWayDubbo标识这个接口须要主动进行协定转换 /** 服务id,能够和dubbo一般调用的配置属性关联. */@AliasFor("id") String value() default ""; /** 服务id,能够和dubbo一般调用的配置属性关联.例如: com.atommiddleware.cloud.config.dubboRefer.<userService>.version=1.1.0 com.atommiddleware.cloud.config.dubboRefer.<userService>.group=userSystem 以上相当于会调用版本号为1.1.0并且groupw为userSystem的dubbo服务,与@DubboReference的参数对齐，具体反对哪些参数详见配置类DubboReferenceConfigProperties*/ @AliasFor("value") String id() default ""; @PathMapping标记这个接口办法须要进行协定主动转换 /** 门路表达式 */@AliasFor("path") String value() default ""; /** 门路表达式 */@AliasFor("value") String path() default ""; /** 提交办法，GET或POST */RequestMethod requestMethod() default RequestMethod.POST; public enum RequestMethod { GET, POST} @FromBody示意参数对象来源于音讯体 /** 是否查看参数 */@AliasFor(annotation = ParamAttribute.class) boolean required() default true; ...

背景前不久翎野君帮共事看一个问题，比拟有启发性，特记录一下。一个dubbo rpc办法中，从申请对象中取出Set<Byte>变量进行循环操作，而后呈现上面的问题。 java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Byte乍一看还有些费解，好好的代码，看上去那么的灵巧可恶，怎么会忽然冒出来这个问题，带着狐疑的态度本人本地编写了Test办法试验了一下，发现也没有问题。而后就把眼光放在dubbo传输框架下面了，查阅了一些材料，发现dubbo默认的hessian2序列化协定不反对Byte类型。 问题复现package com.lingyejun.test;import com.alibaba.com.caucho.hessian.io.Hessian2Input;import com.alibaba.com.caucho.hessian.io.Hessian2Output;import org.junit.Test;import java.io.ByteArrayInputStream;import java.io.ByteArrayOutputStream;import java.io.IOException;import java.util.HashMap;import java.util.HashSet;import java.util.Map;import java.util.Set;public class HessianTest { @Test public void test() throws IOException { Byte basicByte = 88; byte[] basicByteArray = serialize(basicByte); // 序列化后失去的是Integer类型的变量 Object obj = deserialize(basicByteArray); // 会报类型转换谬误 Byte desB = (Byte) obj; Set<Byte> byteSet = new HashSet<>(); byteSet.add((byte) 11); byteSet.add((byte) 6); byte[] byteSetArray = serialize(byteSet); Set<Byte> dsByteSet = (Set<Byte>) deserialize(byteSetArray); // 会报类型转换谬误 for (Byte aByte : dsByteSet) { System.out.println(aByte); } Map<Byte, Byte> byteMap = new HashMap<>(); byteMap.put((byte) 2, (byte) 3); byte[] byteMapArray = serialize(byteMap); Map<Byte, Byte> dsByteMap = (Map<Byte, Byte>) deserialize(byteMapArray); // 会报类型转换谬误 Byte value = dsByteMap.get(2); System.out.println(value); } public static byte[] serialize(Object obj) throws IOException { ByteArrayOutputStream os = new ByteArrayOutputStream(); Hessian2Output ho = new Hessian2Output(os); byte[] cc = null; try { if (obj == null) throw new NullPointerException(); ho.writeObject(obj); ho.flushBuffer(); cc = os.toByteArray(); } catch (Exception e) { e.printStackTrace(); } finally { ho.close(); } return cc; } public static Object deserialize(byte[] by) { try { if (by == null) throw new NullPointerException(); ByteArrayInputStream is = new ByteArrayInputStream(by); Hessian2Input hi = new Hessian2Input(is); return hi.readObject(); } catch (Exception e) { e.printStackTrace(); } return null; }}过程hessian2官网文档：Hessian 2.0 Serialization Protocol ...

Dubbo-go-pixiu 是一款高性能 API 网关，反对 Dubbo 和 Http 等多种协定。具体介绍文章能够参考《Dubbo 跨语言调用神兽：dubbo-go-pixiu》。 近期社区公布了 0.4.0 版本，具体请查看 v0.4.0。相干改良切实太多，本文只列出相干重大 feature、bugfix 、 性能晋升项。 1 动静从 Spring Cloud 和 Dubbo 注册核心拉取路由和集群配置数据Pixiu 本来依赖本地配置文件读取路由和 upstream 集群配置数据，对于实在生产场景非常不不便。因而，Pixiu 须要反对从集群注册核心动静获取路由和集群配置数据的性能。 如上图所示，服务A、B、C 进行服务注册，将本身元数据存储在注册核心。而 Pixiu 则从注册核心拉取注册的服务元数据，构建本人的路由规定和转发集群配置。当客户端发送申请时，Pixiu 会基于构建的转发规定，将申请转发给对应的后端服务。 社区同学别离就目前支流的两大微服务解决方案 Spring Cloud 和 Dubbo 进行了相干个性开发，相干的 pr 为 https://github.com/apache/dub... 和 https://github.com/apache/dub... 目前，该个性只反对从 zk 和 nacos 拉取元数据，更多服务注册核心的反对工作正在进行中，欢送感兴趣的同学参加，能够退出钉钉群 31203920。 2 反对 Http 协定 转换为 gRPC 协定gRPC 协定曾经是事实上的云原生根底通信协议。etcd、istio、dapr 等大量云原生中间件都提供 gRPC 相干的 API 接口供外界应用，dubbogo 3.0 也是基于 gRPC 构建了齐全兼容 gRPC 的 triple协定。 ...

框架设计的有弹性扩展性好会给使用者带来很大的不便，如果业务有新的变动只有应用新的实现去替换之前的实现，且框架如何去加载实现咱们也不必太关注，显然这对咱们开发者来说是十分敌对的。java里的SPI是这个思维，dubbo里的SPI同样是这个思维，对于java里的spi因为会一次性将扩大点逻辑都执行而显得不够灵便，所以这里不再开展(能够参考java spi)，这里重点说下dubbo里的SPI. 应用形式1，在META-INF/services目录下依据接口的全路径名创立一个文件，文件内容为key=value的模式2，ExtensionLoader.getExtensionLoader(xxx.class).getExtension("key")这样就能够获取到咱们自定义的实现了。 实现剖析上面咱们对ExtensionLoader.getExtensionLoader(xxx.class).getExtension(name)这行代码开展下。 public static <T> ExtensionLoader<T> getExtensionLoader(Class<T> type) { if (type == null) throw new IllegalArgumentException("Extension type == null"); //判断给定type是否为接口 if (!type.isInterface()) { throw new IllegalArgumentException("Extension type(" + type + ") is not interface!"); } //判断给定接口上是否有SPI注解 if (!withExtensionAnnotation(type)) { throw new IllegalArgumentException("Extension type(" + type + ") is not extension, because WITHOUT @" + SPI.class.getSimpleName() + " Annotation!"); } //先从map里获取ExtensionLoader，如果没有进行创立 ExtensionLoader<T> loader = (ExtensionLoader<T>) EXTENSION_LOADERS.get(type); if (loader == null) { EXTENSION_LOADERS.putIfAbsent(type, new ExtensionLoader<T>(type)); loader = (ExtensionLoader<T>) EXTENSION_LOADERS.get(type); } return loader; }这全办法次要是获取ExtensionLoader：1，对给定的type进行判断，一是判断是否是接口类型；二是判断接口上是否有SPI注解2，依据给定的type先从Map获取对应的ExtensionLoader，要是没有进行创立。 ...

.......

本篇次要介绍一下dubbo admin的应用，应用之前咱们须要先进行搭建，对于如何搭建，参考 dubbo admin搭建。 如何应用登录胜利之后咱们会看到如下界面，下面的服务就是咱们注册核心注册下来的服务在对应的服务上点击详情此时咱们就能看到对应服务的相干信息，很多时候如果你配置有问题是看不到这么多信息的，这里须要重点阐明一下这个页面怎么进去元数据信息的。 元数据信息怎么显示1）application.properties 配置文件要配置好配置核心也就是上图中的 admin.config-center，其余两个就间接正文掉不配了，这一点dubbo官网也提到了官网这里提到一点，须要在配置核心配置注册核心以及元数据中心地址，这点怎么做呢？我这里也阐明一下（用的zookeeper）1） 进入zookeeper装置目录的命令目录下，执行./zkCli.sh，登录到 zookeeper（如果你不是在本机的则须要制订ip和端口）2） 创立 /dubbo/config/dubbo/dubbo.properties 节点，执行命令create /dubbo/config/dubbo/dubbo.properties ""，如果上一层目录不存在的，则一层层创立。3） ctrl + c 或者执行quit退出zookeeper命令窗口，再执行 ./zkCli.sh -server 127.0.0.1:2181 set /dubbo/config/dubbo/dubbo.properties "dubbo.registry.address=zookeeper://192.168.10.118:2181dubbo.metadata-report.address=zookeeper://192.168.10.118:2181"这里须要留神的是 dubbo.registry.address 和 dubbo.metadata-report.address 之间是要换行的，不然前面 dubbo-admin 是无奈解析胜利的。实现这几步，元数据信息如果还不显示，那还有一种可能：你应用的 dubbo 版本太低，咱们这里介绍的 dubbo-admin 是基于dubbo 2.7.12版本的，去注册核心获取元数据信息的节点是 /dubbo/metadata/com.example.dubboprovider.rpc.CityService/provider/provider，如果你服务援用的版本是2.7.2之前的版本，它注册到的节点门路是 /dubbo/metadata/com.example.dubboprovider.rpc.CityService/provider/provider/service.data，这样就导致 dubbo-admin 获取不到元数据信息了。别问我怎么晓得的，调进去的。 接口测试有了元数据信息之后，咱们就能够应用这个测试的性能了，尽管咱们在 测试工具 这篇文章讲过其余的测试工具，然而其实 dubbo-admin 自带了测试性能。找到对应的服务之后点击测试按钮而后就会显示所有的接口点击对应的接口进行测试当然你也能够在这边进入测试页 接口文档（dubbo-api-docs）在界面中，咱们能够看到有一个接口文档的项这个其实就是 dubbo-admin 应用了 dubbo-api-docs 的性能，这里说的应用并不是说间接引入对应的包，而是依据 dubbo-api-docs 裸露服务的规定来调用服务。简略的介绍一下 dubbo-api-docs 原理：其实就是裸露一个org.apache.dubbo.apidocs.core.providers.IDubboDocProvider接口，看下源码对于应用 dubbo-api-docs（基于2.7.8.1版本），这里须要留神几点： dubbo版本须要在2.7.7以上，不然不反对DubboService注解配置文件中肯定要配置ApplicationConfig、RegistryConfig、ProtocolConfig，须要在application.properties 中配置，其余中央比方 dubbo.properties 中配置会启动出错，临时还没找到具体起因（前面会再看下）对于具体的应用，官网写得比拟具体了，参考 dubbo-api-docs应用。dubbo-api-docs介绍到这，持续看接口文档性能应用，目前是直连模式间接去提供者取的，所以填入提供者的ip和端口（后续据说会反对去注册核心拿），点击加载接口列表这里有个点要留神：dubbo-admin 默认调 dubbo-api-docs 时会带上版本号 v1 以及 group 值apiDocsGroup，而咱们服务提供者并没有，这样会导致调用失败，所以能够在 application.properties 中加配置设置为空值或者你本人须要的值点击服务之后就会呈现服务接口点击接口之后左边就会呈现相应的接口信息 ...

本文已同步至我的公众号 Code4j，欢送各位看官老爷来玩。1. 什么是近程过程调用在讲述 Dubbo 的服务调用过程之前，让咱们先来理解一下什么是近程过程调用。 近程过程调用即 Remote Producedure Call，简略来说就是跨过程调用，通过网络传输，使得 A 机器上的利用能够像调用本地的服务一样去调用 B 机器上的服务。 举个最简略的栗子，假如当初有一个电商零碎，其中有着用户服务，优惠券服务，订单服务等服务模块，这些不同的服务并不是运行在同一个 JVM 中，而是离开运行在不同的 JVM 中。因而，当订单服务想要调用优惠券服务时，就不能像以前的单体利用一样，间接向对应服务发动本地调用，只可能通过网络来发动调用。 那么，一个最简略的近程过程调用是怎么样的呢？来看上面这张图。 也就是说，一次最简略的 RPC 调用，无非就是调用方通过网络，将调用的参数传送到服务方，服务方收到调用申请后，依据参数实现本地调用，并且将后果通过网络传送回调用方。 在这个过程中，像参数的封装，网络传输等细节会由 RPC 框架来实现，把下面的图片欠缺一下，一个残缺的 RPC 调用的流程是这样的： 客户端（Client）以本地调用的形式调用近程服务。客户端代理对象（Client Stub）将本次申请的相干信息（要调用的类名、办法名、办法参数等）封装成 Request，并且对其序列化，为网络通信做筹备。客户端代理对象（Client Stub）找到服务端（Server）的地址，通过网络（Socket 通信）将 Request 发送到服务端。服务端代理对象（Server Stub）接管到客户端（Client）的申请后，将二进制数据反序列化为 Request。服务端代理对象（Server Stub）依据调用信息向本地的办法发动调用。服务端代理对象（Server Stub）将调用后的后果封装到 Response 中，并且对其序列化，通过网络发送给客户端。客户端代理对象（Client Stub）收到响应后，将其反序列化为 Response，近程调用完结。 2. Dubbo 的近程调用过程本节内容基于 Dubbo 2.6.x 版本，并且应用官网提供的 Demo 对同步调用进行剖析。在上一节内容中，咱们曾经对服务调用的过程有了肯定的理解。实际上，Dubbo 在实现近程调用的时候，外围流程和下面的图片是齐全一样的，只不过 Dubbo 在此基础上减少了一些额定的流程，例如集群容错、负载平衡、过滤器链等。 本篇文章只剖析外围的调用流程，其它的额定流程能够自行理解。 在解说 Dubbo 的调用过程之前，咱们先来理解一下 Dubbo 的一些概念。 Invoker：在 Dubbo 中作为实体域，也就是代表了要操作的对象模型，这有点像 Spring 中的 Bean，所有的操作都是围绕着这个实体域来进行。 代表了一个可执行体，能够向它发动 invoke 调用。它有可能是一个本地实现，也有可能是一个近程实现，也有可能是一个集群实现。Invocation：在 Dubbo 中作为会话域，示意每次操作的刹时状态，操作前创立，操作后销毁。 ...

本篇次要介绍一下 Dubbo 运维命令的应用以及实现原理。平时咱们的服务曾经上线了之后呈现问题怎么下线？如何晓得咱们上线的服务有哪些？通过 Dubbo QOS能够一一实现。 QOS应用生产端和服务端启动的时候，Dubbo默认都会启动一个后盾端口来监听运维命令，生产上不必倡议关掉。通过以下配置能够对QOS性能进行自定义配置。 //是否启用QOS性能，默认truedubbo.application.qos.enable=true//启动QOS性能开启的端口，默认22222dubbo.application.qos.port=8998//QOS性能是否只能本机执行，默认falsedubbo.application.qos.accept.foreign.ip=true目前 Dubbo的QOS命令次要有5种，看上面的表格 命令含意help查看所有能用的命令ls查看裸露的服务以及援用的服务offline下线服务online上线服务quit退出控制台咱们来一一应用看下以上命令，基于telnet形式来演示（QOS命令反对http协定以及telnet协定），这里我启动一个dubbo服务并且设置qos端口为8999，先通过控制台连贯下来 telnet localhost 8999后果如下图阐明曾经连贯胜利了 help先来应用一下 help 命令能够看到控制台列出了所有能用的命令，和咱们下面表格列出来的一样，对于不同版本的 Dubbo，可能命名会有些不一样的，所以应用之前先通过 help 命令来看下有哪些可用。咱们还能够通过 help 来查看某个命令是如何应用的，比方我要看 ls 命令如何应用 help ls如果看 online 命令，则 help online其余的命令应用以此类推 ls这个命令比拟繁多，间接 ls后果如图下面是 Provider 相干状况，上面是 Consumer 相干状况，PUB 指的是是否注册胜利了，NUM 指的是有几个服务在注册核心 offline将服务从注册核心移除，能够指定某个服务或者所有服务，能够应用正则匹配，默认所有服务举例：我当初启动一个服务端和一个消费者，先应用ls命令别离看下服务状况，服务端：生产端：此时能够看到有一个服务并且只有一个节点注册了，接着咱们将该服务下线 offline com.example.dubboprovider.rpc.CityService再看下服务状况能够看到此时服务曾经被下线，注册核心也没有，不信你能够本人找一下注册核心中是否还存在，因为该服务从注册核心下线了，注册核心会告诉生产端，导致生产端也移除了该服务，此时咱们看下生产端的状况确认下能够看到生产端也没有任何可用的服务节点了，发动调用试下：和预期一样，抛出了没有服务可用的异样，看到这应该对于offline的性能理解了吧。当然你能够通过正则形式移除某类服务，默认是所有服务 offline com.example.dubboprovider.rpc.*online和 offline 对应，这个命令是上线服务。接着方才offline的例子，此时服务复原了，咱们须要上线。连贯服务端执行 online com.example.dubboprovider.rpc.CityService看下后果能够看到服务又有了，此时注册核心也有了该服务，生产端同样也收到了告诉，所以咱们再看下生产端的服务状况合乎预期，和offline一样，也能够用正则匹配服务 quit这个命名顾名思义，就是退出控制台的意思，间接执行试下 quit 原理QOS看起来是不是很神奇，咱们竟然能够间接用控制台进行管制（当然也能够用http形式，url + /ls，这个ls就是命令），Dubbo 是怎么做到的，咱们来解析一下。首先咱们须要看到一个很要害的类QosProtocolWrapper，该类也是 Protocol 的一种SPI扩大，咱们晓得在服务裸露和服务援用的过程中，会波及到 Protocol 的 export 以及 refer，秉着SPI的有 wrapper 先 wapper 的准则，无论是 export 还是 refer，都会先走 QosProtocolWrapper 的 export 和 refer，来看下做了什么能够看到逻辑根本一样，就是启动了一个qos用的server，外面的逻辑比较简单，间接跟到这里org.apache.dubbo.qos.server.Server#start能够看到实质上就是应用netty启动了一个后盾，也就是咱们的操作实际上就是和这个后盾的一个交互而已，这里退出了一个 QosProcessHandler，看下是怎么做的channel注册的时候会退出一个延时工作来输入控制台信息，也就是申请进来的时候会先进行申请协定判断，是http还是其余，能够看到协定的判断是基于魔数来的http 协定应用 HttpProcessHandler，否则应用 TelnetProcessHandler，他们两者的不同是对于申请内容的解析不同，最终还是调用 CommandExecutor 去执行命令能够看到这里应用了SPI机制，而 BaseCommand 刚好有5种实现，别离对于每种命令，非常灵活的扩大机制剩下的就看每个命名的具体实现，不再多做介绍。 ...

本篇次要介绍一下 Dubbo 的异步编程，包含客户端如何发动异步调用、服务端如何异步执行，以及其实现原理。 客户端异步调用先看下整体流程：再来看下怎么调用，有两种形式，定义 CompletableFuture 返回类型的接口以及应用 RpcContext。第一种：定义一个 CompletableFuture 返回类型的接口及实现 public interface CityService { CompletableFuture<String> getCityId();}@Servicepublic class CityServiceImpl implements CityService { @Override public CompletableFuture<String> getCityId() { CompletableFuture<String> completableFuture = new CompletableFuture<>(); completableFuture.complete("ni hao"); return completableFuture; }}客户端引入该接口并发动调用 @Reference CityService cityService; ... CompletableFuture<String> future = cityService.getCityId(); future.whenComplete((o, t) -> { System.out.println(o); });第二种：应用async配置，能够用在 Reference 或者 Method 级别还是定义一个服务接口 public interface CityService { String getCityName();}@Servicepublic class CityServiceImpl implements CityService { @Override public String getCityName() { return "hangzhou"; }}客户端引入该接口并发动调用 ...

Dubbo作为一款服务治理框架，自身也蕴含了服务降级的性能，次要是对非重要的服务进行降级解决免得影响整体业务，本篇次要介绍一下如何做服务降级以及Dubbo是怎么实现的。 如何做服务降级Dubbo提供了两种配置能够实现服务降级，一个是stub，一个是mock，当然为了兼容以前版本还有个local（和stub根本一样，不做具体介绍），实际上stub不是用作降级解决的，它本来的设计用意是在服务端接口层做一层代理，在服务调用前后通过自定义的扩大退出一些客户端的逻辑，所以官网称它叫本地存根，当然咱们也能够用它实现一些相似降级的性能。而mock就是真的服务降级，除了用于降级，还能够作用一些接口测试。他们的区别大略就是：stub与 AOP 的 around advice 相似，mock等同于 AOP 中的 after-throwing advice。从Dubbo官网提供的图，咱们也能看到区别： stub咱们先说说如何通过stub的形式实现服务降级，对于stub，有三种赋值形式： 值含意true取对应Service对应类全名+Stubdefault同true类全名（含包名）取本人指定的类举个例子：当初有个service接口如下： package com.example.dubboprovider.rpc;public interface CityService { String getCityName();}消费者端引入： @Reference(stub = "true")CityService cityService;消费者端还须要新建一个类： package com.example.dubboprovider.rpc;/** * @author Don * @date 2021/11/8. */public class CityServiceStub implements CityService { CityService cityService; public CityServiceStub(CityService cityService){ this.cityService = cityService; } @Override public String getCityName() { //before call cityService.getCityName(); //after call return "stub"; }}这里有两点要留神：1、包名必须和服务端提供的Service包名统一，这里是com.example.dubboprovider.rpc；2、类要继承服务端提供的Service接口并要有一个有该Service类型参数的构造函数； 对于第一点的束缚，咱们能够通过第三种配置来躲避。比方包名改为com.example.dubboanalyze.stub之后，对应的生产端引入的stub改为具体的类全名 @Reference(stub = "com.example.dubboanalyze.stub.CityServiceStub")CityService cityService;mock再来说一下真正的降级mock，这里要留神的一点是，mock只反对客户端，不反对服务端，2.7.0之后的版本如果在定义的Service中加了mock会导致启动失败，如：@Service(mock = "true")。mock反对以下值配置，长度不能大于200 值含意true/default/fail/forceService类全名 + Mockreturn返回 nullreturn xxx返回 xxxthrow xxx抛出指定异样，xxx 必须是异样类全名，如：throw com.example.dubboanalyze.exception.DubboExceptionfail:近程调用失败发动mock调用force:不做近程调用，间接发动mock调用，可用于测试类全名同fail有下面的表格我想差不多都明确了，这里再举个例子：service接口还是和下面一样，消费者端引入： ...

本篇次要是基于2.7.1对罕用的dubbo配置进行整顿以及介绍dubbo配置是如何集成spring的。 前言对于dubbo配置，我这里就讲目前我的项目里用的多的两种形式，property文件配置以及xml配置，其实配置的项都一样。property文件形式的配置对立前缀dubbo.，xml形式的配置的配置对立前缀dubbo:，下文配置项不写前缀了。 罕用配置application利用级别的配置，用于配置利用信息 配置项作用name利用的名称，用于标识哪个dubbo利用version利用的版本owner利用的维护者logger指定日志框架，可选：slf4j, jcl, log4j, log4j2, jdk，默认log4jcompiler指定字节码解决类，可选：jdk, javassist，默认Javassistenvironment指定所属环境，可选：develop, test, productmodule用于配置以后模块信息，可选，用途不大，只是为了配置补充 配置项作用name模块名称version模块的版本owner模块的维护者isDefault是否默认配置，如果配置多个module则须要指定defaultregistry注册核心配置 配置项作用address注册核心服务器地址，如果地址没有端口缺省为9090，同一集群内的多个地址用逗号分隔，如：ip:port,ip:port，不同集群的注册核心，请配置多个<<dubbo:registry>>标签username登录注册核心用户名password登录注册核心明码port注册核心缺省端口，当address没有带端口时应用此端口做为缺省值，默认9090protocol注册核心地址协定，反对dubbo, multicast, zookeeper, redis, consul(2.7.1), sofa(2.7.2), etcd(2.7.2), nacos(2.7.2)等协定transporter网络传输方式，可选mina,netty，默认nettycheck注册核心不存在时，是否报错，默认truetimeout注册核心申请超时工夫(毫秒)，默认5000register是否向此注册核心注册服务，如果设为false，将只订阅，不注册，默认truesubscribe是否向此注册核心订阅服务，如果设为false，将只注册，不订阅，默认truegroup服务注册分组，跨组的服务不会相互影响，也无奈互相调用，实用于环境隔离。protocol服务提供者协定配置 配置项作用name协定名称，默认dubbohost主动查找本机IP，多网卡抉择或指定VIP及域名时应用，为空则主动查找本机IPport服务端口，dubbo协定缺省端口为20880，rmi协定缺省端口为1099，http和hessian协定缺省端口为80；如果没有配置port，则主动采纳默认端口，如果配置为-1，则会调配一个没有被占用的端口threadpool线程池类型，可选：fixed/cached，默认fixedthreads服务线程池大小(固定大小)，默认200iothreadsio线程池大小(固定大小)，默认cpu个数+1accepts服务提供方最大可承受连接数，默认0payload申请及响应数据包大小限度，单位：字节，默认8388608(=8M)codec协定编码方式，默认dubboserialization协定编码方式，协定序列化形式，当协定反对多种序列化形式时应用，比方：dubbo协定的dubbo,hessian2,java,compactedjava，以及http协定的json等，dubbo协定缺省为hessian2，rmi协定缺省为java，http协定缺省为jsonaccesslog设为true，将向logger中输入拜访日志，也可填写拜访日志文件门路，间接把拜访日志输入到指定文件transporter协定的服务端和客户端实现类型，比方：dubbo协定的mina,netty等，能够分拆为server和client配置，dubbo协定缺省为nettycodec协定编码方式，默认dubbodispatcher协定的音讯派发形式，用于指定线程模型，比方：dubbo协定的all, direct, message, execution, connection等，默认allmonitor监控核心配置 配置项作用protocol监控核心协定，如果为protocol=“registry”，示意从注册核心发现监控核心地址，否则直连监控核心。默认dubboaddress直连监控核心服务器地址，address=“10.20.130.230:12080”username用户名password明码provider服务提供者缺省值配置 配置项作用host服务主机名，多网卡抉择或指定VIP及域名时应用port服务提供者端口threadpool线程池类型，可选：fixed/cached/limit(2.5.3以上)/eager(2.6.x以上)，默认fixedthreads服务线程池大小(固定大小)，默认200iothreadsio线程池大小(固定大小)，默认cpu个数+1timeout近程服务调用超时工夫(毫秒)，1000retries近程服务调用重试次数，不包含第一次调用，不须要重试请设为0，默认2loadbalance负载平衡策略，可选值：random,roundrobin,leastactive，别离示意：随机，轮询，起码沉闷调用，默认 randomstub设为true，示意应用缺省代理类名，即：接口名 + Local后缀。自定义扩大mock设为true，示意应用缺省Mock类名，即：接口名 + Mock后缀。降级用token令牌验证，为空示意不开启，如果为true，示意随机生成动静令牌registry向指定注册核心注册，在多个注册核心时应用，值为 <<dubbo:registry>> 的id属性，多个注册核心ID用逗号分隔，如果不想将该服务注册到任何registry，可将值设为N/Aweight服务权重executes服务提供者每服务每办法最大可并行执行申请数proxy生成动静代理形式，可选：jdk/javassist，默认javassistcluster集群形式，可选：failover/failfast/failsafe/failback/forking，默认failoverdeprecated服务是否过期，如果设为true，生产方援用时将打印服务过期正告error日志async是否缺省异步执行，不牢靠异步，只是疏忽返回值，不阻塞执行线程，默认falseconsumer服务消费者缺省值配置 配置项作用timeout近程服务调用超时工夫(毫秒)，默认1000retries近程服务调用重试次数，不包含第一次调用，不须要重试请设为0,仅在cluster为failback/failover时无效，默认2loadbalance负载平衡策略，可选值：random,roundrobin,leastactive，别离示意：随机，轮询，起码沉闷调用async是否缺省异步执行，默认falsegeneric是否缺省泛化接口，默认falsecheck启动时查看提供者是否存在，true报错，false疏忽，默认truecluster集群形式，可选：failover/failfast/failsafe/failback/forking，默认failoverfilter服务生产方近程调用过程拦截器名称，多个名称用逗号分隔registry向指定注册核心注册，在多个注册核心时应用，值为<dubbo:registry>的id属性，多个注册核心ID用逗号分隔，如果不想将该服务注册到任何registry，可将值设为N/Ainit是否在afterPropertiesSet()时饥饿初始化援用，否则等到有人注入或援用该实例时再初始化，默认falsecache以调用参数为key，缓存返回后果，可选：lru, threadlocal, jcache等validation是否启用JSR303规范注解验证，如果启用，将对办法参数上的注解进行校验async是否缺省异步执行，默认falsecorethreads线程池的外围线程数threads线程池的最大线程数injvm是否只裸露在本地jvmlazy是否在发动近程调用的时候初始化连贯mock设为true，示意应用缺省Mock类名，即：接口名 + Mock后缀。降级用stub设为true，示意应用缺省代理类名，即：接口名 + Local后缀。自定义扩大config-center配置核心配置，平时根本没用 配置项作用protocol应用哪个配置核心：apollo、zookeeper、nacos等。默认zookeeperaddress配置核心地址，以zookeeper为例 1. 指定 protocol，则 address 能够简化为127.0.0.1:2181；2. 不指定 protocol，则 address 取值为 zookeeper://127.0.0.1:2181username配置核心用户名password配置核心明码timeout获取配置的超时工夫，默认3000check当配置核心连贯失败时，是否终止利用启动，默认truemetadata-report元数据中心配置，平时根本没用 配置项作用address元数据中心地址username元数据中心用户名password元数据中心明码timeout超时工夫dubbo是如何集成到spring的集成到spring的模块是dubbo-config-spring。 注解形式咱们在应用注解形式应用dubbo的时候通常会用到注解@EnableDubboConfig能够看到下面有个@Import(DubboConfigConfigurationRegistrar.class)，进去看下实现了接口ImportBeanDefinitionRegistrar（这是spring自定义bean的一种形式），从上图圈进去的中央能够看到对DubboConfigConfiguration.Multiple或者DubboConfigConfiguration.Single进行了注册（Multiple形式我也没用过），咱们拿 Single 来举例，其实实现形式是一样的。能够看到诸如dubbo.application等咱们在配置文件里配置的前缀及其对应的类。进来EnableDubboConfigBinding，能够看到又是一个import。间接看registerDubboConfigBindingBeanPostProcessor办法，咱们发现这里又去注册一个DubboConfigBindingBeanPostProcessor类型的bean，再跟进去看这里能够看到进行了数据绑定。绑定的类实际上是DefaultDubboConfigBinder能够看到最终是用的spring的DataBinder进行了属性文件内容和对象字段的绑定。 xml文件形式spring对于xml的解析其实是提供了扩大的，咱们能够通过扩大来自定义本人的xml标签（如何自定义xml标签），dubbo就是这么做的。从resources文件夹下咱们能够看到这些文件，其中dubbo.xsd就是所有自定义标签的定义。举个例子：application定义 <xsd:element name="application" type="applicationType"> <xsd:annotation> <xsd:documentation><![CDATA[ The application config ]]></xsd:documentation> <xsd:appinfo> <tool:annotation> <tool:exports type="org.apache.dubbo.config.ApplicationConfig"/> </tool:annotation> </xsd:appinfo> </xsd:annotation> </xsd:element>能够看到对于的类型是applicationType，再看applicationType定义这样就很分明了，applicationType定义了所有属性字段。spring.schemas 文件定义了指定的标签文件门路spring.handlers文件定义了集成spring的自定义解决类，dubbo的是DubboNamespaceHandler。看下图的逻辑根本就很清晰了，标签和类对应起来最初数据绑定是在org.apache.dubbo.config.spring.schema.DubboBeanDefinitionParser#parse(org.w3c.dom.Element, org.springframework.beans.factory.xml.ParserContext, java.lang.Class<?>, boolean) ...

本篇次要介绍一下dubbo 2.7.x以及3.0 版本是如何实现netty同步转异步的操作的。对于应用的netty的同学也会有一些帮忙。 知识点dubbo 2.7.x如何实现同步转异步dubbo 3.0版本是如何实现的dubbo 2.7.x如何实现同步转异步源码咱们间接从发申请这一段开始看 org.apache.dubbo.rpc.protocol.dubbo.DubboInvoker#doInvoke红框处就是同步申请逻辑，持续进去看下申请是怎么发的 org.apache.dubbo.remoting.exchange.support.header.HeaderExchangeChannel#request(java.lang.Object, int)这里是十分重要的一段，咱们看到有一个 DefaultFuture，这里的 newFuture 就是新建一个DefaultFuture，进入 DefaultFuture 的构造函数能够看到他把本次申请的id和对应的channel以及本身关联起来了，这里咱们就能够联想到在响应之后从这外面依据id取出来就能够了。FUTURES 是一个线程平安的Map再回到第一幅图的逻辑 (Result) currentClient.request(inv, timeout).get(); 处，这里的 get 就是一个同步期待后果的逻辑（设置了超时工夫）进去get办法之后能够看到其实就是应用了一个对象锁期待信号量开释或者超时，这里咱们又会联想到信号量在哪里开释，必定是收到响应的逻辑里。咱们在netty初始化的时候设置了channelhandler，细节就不讲了，间接看代码处 org.apache.dubbo.remoting.exchange.support.header.HeaderExchangeHandler#handleResponse这段代码能够看到收到响应后又用 DefaultFuture 进行了解决，咱们看看是否和咱们下面预期的解决一样这里看到把响应后果设置到变量 response 之后触发对象信号量开释，和咱们料想的一样。这里要留神的是信号量期待和开释必须要在同步块里，所以须要加lock，当然也能够用synchronized。 dubbo 3.0 版本如何实现还是这段逻辑 org.apache.dubbo.rpc.protocol.dubbo.DubboInvoker#doInvoke能够看到这段代码做了很大的优化，没有具体辨别同步还是异步了，全副以异步返回。看这段代码 CompletableFuture<AppResponse> appResponseFuture = currentClient.request(inv, timeout, executor).thenApply(obj -> (AppResponse) obj);这里应用了 CompletableFuture 并在完结后返回对应的后果 AppResponse。currentClient.request 外面的逻辑还是和之前版本一样通过 DefaultFuture.newFuture 创立一个和 reqid 关联的 future，不过是多了异步执行器 executor。通过 AsyncRpcResult 对future 进行了封装并返回。返回后在上面逻辑中进行同步期待，当然如果不须要同步的则间接返回。再看上面逻辑同步期待时候，如果有执行器则会先执行执行器的逻辑，最初就是期待后果返回。那后果在什么时候返回呢？还是在 org.apache.dubbo.remoting.exchange.support.DefaultFuture#doReceived 处只不过这里用到了 CompletableFuture 的个性来设置后果并触发同步期待后果。 总结其实精确的来说并不是2.7.x和3.0的差别，应该是2.7.x两头某个版本开始就改掉，我感觉这个不重要所以没去细查到底是哪个版本开始改的。重要的是咱们晓得dubbo为了解决netty的异步转同步问题到底做了哪些解决，尽管说是两种形式，其实实质上还是一个理念：多线程下通过共享的变量进行同步。

本篇次要介绍dubbo的隐式传参如何应用以及其原理。通过隐式传参，咱们能够在不改变接口的状况下传递一些额定的数据给服务端来实现一些特定的性能。 概念什么是隐式传参，咱们看名字根本就可能猜出来，暗地里把参数传给服务提供者。先思考一下咱们平时是怎么应用dubbo的（如何搭建并进行调用），个别都是服务提供方会定义好接口而后交给客户端来引入应用，也就是一开始客户端就晓得服务端有哪些接口以及其定义是怎么样的。而隐式传参则是客户端本人定义的参数，客户端和服务端要约定好想要传哪些参数，客户端传了之后服务端能够取出来做一些解决。更艰深的说：当初华山派招弟子，有心法系和剑系两项能够抉择，你进入华山派的话失常只能练其中一项，然而你能够在抉择任何一项之后本人偷偷带一本秘籍过来修炼，这偷偷带过来的货色就是隐式传参。 应用上面用一个例子来阐明一下如何进行应用，本例子要达到的目标是日志惟一追踪号传递，具体的细节在这篇曾经讲过dubbo Filter应用，这里就讲一下其中波及到的隐式传参怎么做的。在那篇例子中，咱们写到一段代码： //对于服务提供端，Activate改为Constants.PROVIDER@Activate(group = {Constants.CONSUMER})public class UniqIdTraceFilter implements Filter { @Override public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException { //此处逻辑能够自定义 String traceId = UUID.randomUUID().toString().replace("-", ""); RpcContext.getContext().setAttachment("traceId", traceId); return invoker.invoke(invocation); }}这段代码里 RpcContext.getContext().setAttachment("traceId", traceId); 这句话就是隐式传参的应用。咱们看下 setAttachment 办法的定义：这里能够看进去其中就是一个map，key就是咱们要传递给服务端的参数的键，value就是服务端将会获取到的值，具体如何应用你能够在服务端自定义。这里传递traceId给服务端之后，服务端就能够通过RpcContext.getContext().getAttachment("traceId") 来获取到日志惟一追踪号。 原理借着应用来讲一下隐式传参的原理。基于下面的例子，咱们晓得应用隐式传参很简略： RpcContext.getContext().setAttachment("traceId", traceId)咱们看下 dubbo 是如何做到从客户端传递到服务端的。在下面的例子中，咱们在客户端申请过来的时候，通过了 Filter，在 Filter 中退出了我本人的定义的隐式传参的内容 traceId，在org.apache.dubbo.rpc.protocol.AbstractInvoker#invoke 的逻辑中会将咱们RpcContext中的参数传递到 RpcInvocation 中，如图：这个 RpcInvocation 就是客户端申请服务端带过来的是数据。在服务端接管到的申请内容中，咱们能够看到traceId，其余的是dubbo本人须要解决的参数：在咱们讲 dubbo Filter应用 的时候讲到过dubbo有一些本人内置的 Filter，其中有一个 Filter 叫做 ContextFilter，该 Filter 就会将收到的 RpcInvocation 中的参数设置到 RpcContext中去：大略的实现原理就是如此，其实也非常简单。 总结本篇曾经对隐式传参讲得十分分明了，这里的案例是用的Filter的形式设置和获取参数，大家也能够在其余代码逻辑下来传递和获取，如果对于原理篇还是不了解，能够本人参照原理篇说的调试下。

dubbo配置文件dubbo:application 配置利用信息配置。对应的配置类：org.apache.dubbo.config.ApplicationConfig 属性形容是否必填name以后利用的名称，与以后的我的项目名保持一致。是owner负责人否version以后利用的版本否qos.enable是否开启运维接口否qos.port运维接口的端口号否qos.accept.foreign.ip是否容许近程拜访否dubbo:registry 配置注册核心配置。对应的配置类： org.apache.dubbo.config.RegistryConfig。同时如果有多个不同的注册核心，能够申明多个 <dubbo:registry> 标签，并在 <dubbo:service>或 <dubbo:reference> 的 registry 属性指定应用的注册核心。 属性形容是否必填id注册核心id，因为能够容许配置多个注册核心否address注册核心地址是protocol注册核心地址协定，反对dubbo, multicast, zookeeper, redis, consul(2.7.1), sofa(2.7.2), etcd(2.7.2), nacos(2.7.2)等协定。（协定个别写在地址上）否timeout注册核心申请超时工夫(毫秒)否dubbo:protocol 配置服务提供者协定配置。对应的配置类： org.apache.dubbo.config.ProtocolConfig。同时，如果须要反对多协定，能够申明多个 <dubbo:protocol>标签，并在 <dubbo:service> 中通过 protocol 属性指定应用的协定。 属性形容是否必填id协定id否namedubbo, rmi, hessian, http, webservice, thrift, memcached, redis是port近程调用协定端口是dubbo:service 配置服务提供者裸露服务配置。对应的配置类：org.apache.dubbo.config.ServiceConfig 属性形容是否必填interface注册的服务接口类是ref服务在容器中治理的名称是version服务版本，倡议应用两位数字版本，如：1.0，通常在接口不兼容时版本号才须要降级否registry指定注册核心的id否dubbo:reference 配置服务消费者援用服务配置。对应的配置类： org.apache.dubbo.config.ReferenceConfig 属性形容是否必填id服务注册到Spring中的id是interface要调用的服务接口类是version指定以后服务版本，与服务提供者的版本统一。否registry指定注册核心的id否dubbo:method 配置办法级配置。对应的配置类： org.apache.dubbo.config.MethodConfig。同时该标签为 <dubbo:service> 或 <dubbo:reference> 的子标签，用于管制到办法级。 属性形容是否必填name办法名是timeout超时工夫否retries重试次数否async是否异步执行，不牢靠异步，只是疏忽返回值，不阻塞执行线程否demosxml格局 <dubbo:application name="demo-provider" version="v1.0" owner="allen"> <dubbo:parameter key="qos.enable" value="true"/> <dubbo:parameter key="qos.port" value="22222"/> <dubbo:parameter key="qos.accept.foreign.ip" value="false"/> </dubbo:application> <dubbo:registry address="zookeeper://152.136.111.235:2181" timeout="10000"/> <dubbo:protocol name="dubbo" port="20880"/> <!--生产者配置--> <dubbo:service interface="com.allen.api.HelloService" ref="helloService" version="0.0.0"/> <!--消费者配置--> <dubbo:reference id="helloService" interface="com.allen.api.HelloService" check="true"> <dubbo:method name="sayHello" timeout="3000" retries="2"/> </dubbo:reference>SpringBoot主动拆卸application.properties#dubbo服务配置dubbo.application.name=dubbo-demo-annotation-consumerdubbo.application.owner=allendubbo.application.version=v1.0dubbo.application.qosEnable=truedubbo.application.qosPort=22222dubbo.application.qosAcceptForeignIp=false#注册核心的协定和地址dubbo.registry.protocol=zookeeperdubbo.registry.address=127.0.0.1:2181#近程调用协定dubbo.protocol.name=dubbodubbo.protocol.port=20880

通用调用java 从零开始手写 RPC (01) 基于 socket 实现 java 从零开始手写 RPC (02)-netty4 实现客户端和服务端 java 从零开始手写 RPC (03) 如何实现客户端调用服务端？ java 从零开始手写 RPC (04) -序列化 上一篇咱们介绍了，如何实现基于反射的通用服务端。 这一节咱们来一起学习下如何实现通用客户端。 因为内容较多，所以拆分为 2 个局部。 基本思路所有的办法调用，基于反射进行相干解决实现。 外围类为了便于拓展，咱们把外围类调整如下： package com.github.houbb.rpc.client.core;import com.github.houbb.heaven.annotation.ThreadSafe;import com.github.houbb.log.integration.core.Log;import com.github.houbb.log.integration.core.LogFactory;import com.github.houbb.rpc.client.core.context.RpcClientContext;import com.github.houbb.rpc.client.handler.RpcClientHandler;import com.github.houbb.rpc.common.constant.RpcConstant;import io.netty.bootstrap.Bootstrap;import io.netty.channel.*;import io.netty.channel.nio.NioEventLoopGroup;import io.netty.channel.socket.nio.NioSocketChannel;import io.netty.handler.codec.serialization.ClassResolvers;import io.netty.handler.codec.serialization.ObjectDecoder;import io.netty.handler.codec.serialization.ObjectEncoder;import io.netty.handler.logging.LogLevel;import io.netty.handler.logging.LoggingHandler;/** * <p> rpc 客户端 </p> * * <pre> Created: 2019/10/16 11:21 下午 </pre> * <pre> Project: rpc </pre> * * @author houbinbin * @since 0.0.2 */@ThreadSafepublic class RpcClient { private static final Log log = LogFactory.getLog(RpcClient.class); /** * 地址信息 * @since 0.0.6 */ private final String address; /** * 监听端口号 * @since 0.0.6 */ private final int port; /** * 客户端解决 handler * 作用：用于获取申请信息 * @since 0.0.4 */ private final ChannelHandler channelHandler; public RpcClient(final RpcClientContext clientContext) { this.address = clientContext.address(); this.port = clientContext.port(); this.channelHandler = clientContext.channelHandler(); } /** * 进行连贯 * @since 0.0.6 */ public ChannelFuture connect() { // 启动服务端 log.info("RPC 服务开始启动客户端"); EventLoopGroup workerGroup = new NioEventLoopGroup(); /** * channel future 信息 * 作用：用于写入申请信息 * @since 0.0.6 */ ChannelFuture channelFuture; try { Bootstrap bootstrap = new Bootstrap(); channelFuture = bootstrap.group(workerGroup) .channel(NioSocketChannel.class) .option(ChannelOption.SO_KEEPALIVE, true) .handler(new ChannelInitializer<Channel>(){ @Override protected void initChannel(Channel ch) throws Exception { ch.pipeline() // 解码 bytes=>resp .addLast(new ObjectDecoder(Integer.MAX_VALUE, ClassResolvers.cacheDisabled(null))) // request=>bytes .addLast(new ObjectEncoder()) // 日志输入 .addLast(new LoggingHandler(LogLevel.INFO)) .addLast(channelHandler); } }) .connect(address, port) .syncUninterruptibly(); log.info("RPC 服务启动客户端实现，监听地址 {}:{}", address, port); } catch (Exception e) { log.error("RPC 客户端遇到异样", e); throw new RuntimeException(e); } // 不要敞开线程池！！！ return channelFuture; }}能够灵便指定对应的服务端地址、端口信息。 ...

通用调用java 从零开始手写 RPC (01) 基于 socket 实现 java 从零开始手写 RPC (02)-netty4 实现客户端和服务端 java 从零开始手写 RPC (03) 如何实现客户端调用服务端？ java 从零开始手写 RPC (04) -序列化 后面咱们的例子是一个固定的出参和入参，固定的办法实现。 本节将实现通用的调用，让框架具备更宽泛的实用性。 基本思路所有的办法调用，基于反射进行相干解决实现。 服务端外围类RpcServer调整如下: serverBootstrap.group(workerGroup, bossGroup) .channel(NioServerSocketChannel.class) // 打印日志 .handler(new LoggingHandler(LogLevel.INFO)) .childHandler(new ChannelInitializer<Channel>() { @Override protected void initChannel(Channel ch) throws Exception { ch.pipeline() // 解码 bytes=>resp .addLast(new ObjectDecoder(Integer.MAX_VALUE, ClassResolvers.cacheDisabled(null))) // request=>bytes .addLast(new ObjectEncoder()) .addLast(new RpcServerHandler()); } }) // 这个参数影响的是还没有被accept 取出的连贯 .option(ChannelOption.SO_BACKLOG, 128) // 这个参数只是过一段时间内客户端没有响应，服务端会发送一个 ack 包，以判断客户端是否还活着。 .childOption(ChannelOption.SO_KEEPALIVE, true);其中 ObjectDecoder 和 ObjectEncoder 都是 netty 内置的实现。 ...

download：Dubbo 3 深度分析 - 透过源码意识你import java.io.*;import java.util.*;import java.util.zip.*;public class FolderUnzip {private static String sourcepath="D:\tmp";private static ListfolderList=new ArrayList(Arrays.asList(sourcepath));private static ListfolderList2=new ArrayList(Arrays.asList("E:\tt"+File.separator+sourcepath.substring(sourcepath.lastIndexOf(File.separator))));private static FileInputStream fis = null;private static FileOutputStream fos = null;private static ZipInputStream zipin = null; public static void main(String[] args) { for (int j = 0; j < folderList.size(); j++) { new File(folderList2.get(j)).mkdirs(); String[] file = new File(folderList.get(j)).list(); File temp = null; for (int i = 0; i < file.length; i++) { if (folderList.get(j).endsWith(File.separator)) temp = new File(folderList.get(j), file[i]); else temp = new File(folderList.get(j), file[i]); File originalFile = null; if (temp.getName().endsWith(".zip")) originalFile = new File(folderList2.get(j), temp.getName() .substring(0, temp.getName().lastIndexOf('.'))); if (temp.isFile() && !originalFile.exists()) { try { fis = new FileInputStream(temp); zipin = new ZipInputStream(fis); ZipEntry entry = zipin.getNextEntry(); fos = new FileOutputStream(new File(folderList2.get(j),entry.getName())); byte[] buffer = new byte[20480]; int nNumber; while ((nNumber = zipin.read(buffer, 0, buffer.length)) != -1) fos.write(buffer, 0, nNumber); fos.flush(); } catch (IOException e) { continue; } finally { try { zipin.close(); fos.close(); fis.close(); } catch (IOException e) { } } } else if (temp.isDirectory()) { folderList.add(folderList.get(j) + File.separator + file[i]); folderList2.add(folderList2.get(j) + File.separator+ file[i]); } } }}} ...

序列化java 从零开始手写 RPC (01) 基于 socket 实现 java 从零开始手写 RPC (02)-netty4 实现客户端和服务端 java 从零开始手写 RPC (03) 如何实现客户端调用服务端？ 后面几节咱们实现了最根底的客户端调用服务端，这一节来学习一下通信中的对象序列化。 为什么须要序列化netty 底层都是基于 ByteBuf 进行通信的。 后面咱们通过编码器/解码器专门为计算的入参/出参进行解决，这样不便咱们间接应用 pojo。 然而有一个问题，如果想把咱们的我的项目形象为框架，那就须要为所有的对象编写编码器/解码器。 显然，间接通过每一个对象写一对的形式是不事实的，而且用户如何应用，也是未知的。 序列化的形式基于字节的实现，性能好，可读性不高。 基于字符串的实现，比方 json 序列化，可读性好，性能绝对较差。 ps: 能够依据集体还好抉择，相干序列化可参考下文，此处不做开展。 json 序列化框架简介实现思路能够将咱们的 Pojo 全副转化为 byte，而后 Byte 转换为 ByteBuf 即可。 反之亦然。 代码实现maven引入序列化包： <dependency> <groupId>com.github.houbb</groupId> <artifactId>json</artifactId> <version>0.1.1</version></dependency>服务端外围服务端的代码能够大大简化： serverBootstrap.group(workerGroup, bossGroup) .channel(NioServerSocketChannel.class) // 打印日志 .handler(new LoggingHandler(LogLevel.INFO)) .childHandler(new ChannelInitializer<Channel>() { @Override protected void initChannel(Channel ch) throws Exception { ch.pipeline() .addLast(new RpcServerHandler()); } }) // 这个参数影响的是还没有被accept 取出的连贯 .option(ChannelOption.SO_BACKLOG, 128) // 这个参数只是过一段时间内客户端没有响应，服务端会发送一个 ack 包，以判断客户端是否还活着。 .childOption(ChannelOption.SO_KEEPALIVE, true);这里只须要一个实现类即可。 ...

阐明java 从零开始手写 RPC (01) 基于 socket 实现 java 从零开始手写 RPC (02)-netty4 实现客户端和服务端 写完了客户端和服务端，那么如何实现客户端和服务端的调用呢？ 上面就让咱们一起来看一下。 接口定义计算方法package com.github.houbb.rpc.common.service;import com.github.houbb.rpc.common.model.CalculateRequest;import com.github.houbb.rpc.common.model.CalculateResponse;/** * <p> 计算服务接口 </p> * * <pre> Created: 2018/8/24 下午4:47 </pre> * <pre> Project: fake </pre> * * @author houbinbin * @since 0.0.1 */public interface Calculator { /** * 计算加法 * @param request 申请入参 * @return 返回后果 */ CalculateResponse sum(final CalculateRequest request);}pojo对应的参数对象： CalculateRequestpackage com.github.houbb.rpc.common.model;import java.io.Serializable;/** * <p> 申请入参 </p> * * <pre> Created: 2018/8/24 下午5:05 </pre> * <pre> Project: fake </pre> * * @author houbinbin * @since 0.0.3 */public class CalculateRequest implements Serializable { private static final long serialVersionUID = 6420751004355300996L; /** * 参数一 */ private int one; /** * 参数二 */ private int two; public CalculateRequest() { } public CalculateRequest(int one, int two) { this.one = one; this.two = two; } //getter setter toString}CalculateResponsepackage com.github.houbb.rpc.common.model;import java.io.Serializable;/** * <p> 申请入参 </p> * * <pre> Created: 2018/8/24 下午5:05 </pre> * <pre> Project: fake </pre> * * @author houbinbin * @since 0.0.3 */public class CalculateResponse implements Serializable { private static final long serialVersionUID = -1972014736222511341L; /** * 是否胜利 */ private boolean success; /** * 二者的和 */ private int sum; public CalculateResponse() { } public CalculateResponse(boolean success, int sum) { this.success = success; this.sum = sum; } //getter setter toString}客户端外围局部RpcClient 须要增加对应的 Handler，调整如下： ...

本篇文章次要介绍dubbo的泛化调用。次要知识点如下： 什么是泛化调用如何应用泛化调用泛化调用原理 什么是泛化调用泛化接口调用形式次要用于客户端没有 API 接口及模型类元的状况，这是官网的说法，对于新人我认为太形象了，这里解释一下。咱们在做失常的dubbo调用时，服务端会提供一个所有接口的jar包让客户端引入，此时客户端就晓得服务端提供了哪些接口并进行应用，参考 如何搭建并进行调用，而对于泛化调用，咱们还是须要晓得服务端提供了哪些接口，只不过是程序不晓得而已，此时咱们在程序中应用泛化调用，显示填入须要调用的接口名称，dubbo会进行匹配并进行调用后返回。 如何应用泛化调用下面介绍了泛化调用的概念，这里介绍一下如何应用。假如服务端提供如下接口 package com.example.dubboprovider.rpc; public interface CityService { String getCityName();}泛化调用最重要的就是 GenericService，首先咱们定义一个服务援用 @Reference(interfaceName = "com.example.dubboprovider.rpc.CityService", generic = true) GenericService genericService;下面的代码里定义了一个 GenericService，留神下面的注解 @Reference，在之前的文章中说到过这个注解表明是一个dubbo援用，注解外面 interfaceName 用来表明你要应用的接口类，generic 为true用来表明是泛化调用，这样一个泛化接口就实现了。再来看下调用 Object name = genericService.$invoke("getCityName", new String[]{}, new Object[]{});通过以上几个步骤，一个简略的泛化调用就实现了。 原理顺着下面的例子讲述，介绍一下泛化调用的原理。首先援用服务（参考服务调用过程解析，前面会写），dubbo会为下面定义的 genericService 生成一个代理类，在代码逻辑 genericService.$invoke 的时候就会走到dubbo生成的代理类中。在讲 dubbo filter 的时候咱们讲到dubbo内置了一些filter，其中就有两个filter别离叫做 GenericImplFilter、GenericFilter。GenericImplFilterGenericFilter这两个filter就是对泛化调用的解决，其中 GenericImplFilter 是生产端的解决，而 GenericFilter 是服务端的解决。生产端的解决就是对参数做一些预处理（非内置的进行序列化、以及取得后果之后的反序列化，内置的进行校验以及传递generic值），而服务端的解决就是对内置的泛化调用进行解决（序列化以及返序列化），从逻辑中咱们能够看到其实 generic 能够有三种赋值形式，别离为true、nativejava以及bean，其实就是对应的对于咱们传递的参数的解析形式，上面别离介绍一下： true这个是最简略的解决形式，dubbo内置的PojoUtils工具类就会进行解析。nativejava如果参数是byte数组类型的，则咱们能够通过实现 Serialization 接口来自定义实现序列化和反序列化。bean如果你的参数类继承JavaBeanDescriptor，则能够通过该种形式来转换对象。dubbo内置的类型转换曾经很全了，如果你有本人的转换需要，能够思考在这一块进行革新。从源码中咱们也能够看进去，其实泛化调用就是通过filter过滤对传递的参数进行了一层转换，而后找到匹配的接口以及办法进行调用。 总结泛化调用的确是一种非常灵活的形式，其实现也很简略，然而对于调用者来说，绝对一般调用显得麻烦一些。在理论业务中，咱们能够联合具体场景应用泛化调用，比方测试、网关路由等。

download：Dubbo 3 深度分析 - 透过源码意识你网格布局 页面基本元素： 样式： .wrapper { border: 2px solid #f76707;border-radius: 5px;background-color: #fff4e6;} .box { border: 2px solid #FDC180;} 通过在元素上申明 display：grid 或 display：inline-grid 来创建一个网格容器： .wrapper { display: grid;} 如下成果： 定义网格中的行和列 通过 grid-template-columns和grid-template-rows属性来定义网格中的行和列。这些属性定义了网格的轨道。网格轨道是网格中任意两条线之间的空间。 如下网格，蕴含了三个200像素宽的列轨道： .wrapper { display: grid;grid-template-columns: 200px 200px 200px;} fr单位 新的fr单位代表网格容器中可用空间的一等份。下一个网格定义将创建三个相等宽度的轨道，这些轨道会随着可用空间增长和膨胀。 .wrapper { display: grid;grid-template-columns: 1fr 1fr 1fr;} 也可能和像素单位混用： .wrapper { display: grid;grid-template-columns: 500px 1fr 2fr;} 在轨道清单中使用repeat() repeat 的语法如下： repeat(number of columns/rows, the column width we want); 有着多轨道的大型网格可使用 repeat() 标记来重复部分或整个轨道列表。如下方的网格定义： .wrapper { display: grid;grid-template-columns: 1fr 1fr 1fr;} ...

本篇文章次要是介绍一下dubbo filter性能的应用以及其原理。 什么是dubbo filterdubbo filter是dubbo提供的一项扩大的性能，dubbo在做调用的过程中，会先通过一层filter，顾名思义，也就是一层拦挡过滤。通过dubbo filter性能，咱们能够记录一些额定的操作日志、传递一些公共的信息、做一些自定义校验和权限管制等。 如何应用dubbo 提供了Filter接口类，咱们只有定义一个本人的类，而后继承该接口即可实现本人的逻辑。以实现一个传递链路惟一追踪号为案例来看下如何实现，比方当初我有一个A服务，还有一个B服务，当初A服务有本人的逻辑链路追踪号，须要传递到B服务中去，使得两个服务可能用同一个追踪号来关联某一次申请的所有链路。A服务先定义一个本人的Filter类并实现dubbo的Filter接口： //对于服务提供端，Activate改为Constants.PROVIDER@Activate(group = {Constants.CONSUMER})public class UniqIdTraceFilter implements Filter { @Override public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException { //此处逻辑能够自定义 String traceId = UUID.randomUUID().toString().replace("-", ""); RpcContext.getContext().setAttachment("traceId", traceId); return invoker.invoke(invocation); }}再在resources目录下新建一个META-INF文件夹，在其下再创立一个dubbo目录。在META-INF\dubbo目录下创立一个名称为org.apache.dubbo.rpc.Filter（如果你用的是2.7之前的版本，则名称为com.alibaba.dubbo.rpc.Filter），如图：在文件里写上你定义的filter全名uniqIdTraceFilter=com.example.dubboanalyze.filter.UniqIdTraceFilter到这里，咱们演示的dubbo filter就实现了。 原理还在学习等级2的同学能够只看到下面就好，这里介绍的原理就到等级3了。下面介绍的案例非常简单，那么两头到底是怎么实现的呢？这里要从服务援用的时候说起，咱们在启动生产端的时候，dubbo会基于protocol创立一个invoker，invoker保护着某个接口的近程调用，在创立invoker的时候也是基于spi机制加载所有须要的Protocol，这里有一个Protocol就是ProtocolFilterWrapper该Protocol在创立invoker的时候加载了所有的Filter，这里应用了责任链模式，咱们在下面自定义的Filter就是被加载到这里的。从代码中咱们能够看到返回的Invoker是一个Filter的包装，传入的Invoker是在所有filter调用之后才会调用，这样就做到了过滤拦挡的性能。 原生Filterdubbo自身带有一些Filter实现，都施展了各自的作用比方GenericFilter就是dubbo用来拦挡并实现泛化调用的性能，TokenFilter用来做调用的令牌验证，CacheFilter来实现缓存等。具体大家能够本人再去理解。 总结dubbo filter自身的实现还是比较简单的，dubbo也提供了十分不便的自定义扩大。

download：Dubbo 3 深度分析 - 透过源码意识你也能够是其余符号，有这种问题的时候应该思考先改存储的中央（能够按制订字符串拆分成数组，长度大于1的时候才加分隔符，否则开端就不必增加了） Boolean isNotEmpty = StringUtils.isNotBlank(this.version);Boolean lastIndex = false;if(isNotEmpty){ lastIndex = ",".equals(this.version.substring(version.length()-1));} if(isNotEmpty && lastIndex){ return this.version.substring(0,version.length()-1);}else{ return this.version;}

download:Dubbo 3 深度分析 - 透过源码意识你也能够是其余符号，有这种问题的时候应该思考先改存储的中央（能够按制订字符串拆分成数组，长度大于1的时候才加分隔符，否则开端就不必增加了） Boolean isNotEmpty = StringUtils.isNotBlank(this.version);Boolean lastIndex = false;if(isNotEmpty){ lastIndex = ",".equals(this.version.substring(version.length()-1));} if(isNotEmpty && lastIndex){ return this.version.substring(0,version.length()-1);}else{ return this.version;}

download：Dubbo 3 深度分析 - 透过源码意识你输入： 2006-08-302006-09-03(2)roll方法 cal.set(Calendar.YEAR,2006);cal.set(Calendar.MONTH,8);cal.set(Calendar.DAY_OF_MONTH,3);cal.roll(Calendar.DATE, -4);date=cal.getTime();System.out.println(df.format(date));cal.roll(Calendar.DATE,4);date=cal.getTime();System.out.println(df.format(date)); 输入： 2006-09-292006-09-03可见，roll()方法在本月内循环，个别应用add()方法； 6、核算两个任意时刻两头的间隔天数 (1)传进Calendar指标 /**核算两个时刻之间相隔天数 *@paramstartday 开始时刻 *@paramendday 结束时刻 *@return */publicintgetIntervalDays(Calendar startday,Calendar endday){ //保障startday在endday之前if(startday.after(endday)){ Calendar cal=startday; startday=endday; endday=cal;}//分离失去两个时刻的毫秒数longsl=startday.getTimeInMillis();longel=endday.getTimeInMillis();longei=el-sl; //依据毫秒数核算间隔天数return(int)(ei/(1000*60*60*24));} (2)传进Date指标 /**核算两个时刻之间相隔天数 @param startday 开始时刻@param endday 结束时刻@return */publicintgetIntervalDays(Date startday,Date endday){ //保障startday在endday之前if(startday.after(endday)){ Date cal=startday; startday=endday; endday=cal;}//分离失去两个时刻的毫秒数longsl=startday.getTime();longel=endday.getTime();longei=el-sl; //依据毫秒数核算间隔天数return(int)(ei/(1000*60*60*24));} 同理，能够用雷同的方法核算出任意两个时刻相隔的小时数，分钟数，秒钟数等 注：以上方法是齐全按时刻核算，有时并不能令人满意，如： startday="2006-10-11 20:00:00"endday="2006-10-12 8:00:00" 核算成绩为0，然而咱们兴许相让核算成绩变为1，此刻能够用如下方法实现： 在传参之前，先设定endday的时刻，如： endday.set(Calendar.HOUR_OF_DAY,23);endday.set(Calendar.MINUTE,59);endday.set(Calendar.SECOND,59);endday.set(Calendar.MILLISECOND,59); 这样再传进去startday,endday，则成绩就如咱们所愿了。不过，如果嫌以上方法麻烦，能够参考以下方法： (3)改良准确核算相隔天数的方法 publicintgetDaysBetween (Calendar d1, Calendar d2) { if(d1.after(d2)) { // swap dates so that d1 is start and d2 is end java.util.Calendar swap = d1; d1 = d2; d2 = swap; } intdays = d2.get(Calendar.DAY_OF_YEAR) - d1.get(Calendar.DAY_OF_YEAR); inty2 = d2.get(Calendar.YEAR); if(d1.get(Calendar.YEAR) != y2) { d1 = (Calendar) d1.clone(); do{ days += d1.getActualMaximum(Calendar.DAY_OF_YEAR);//失去当年的实际天数 d1.add(Calendar.YEAR,1); }while(d1.get(Calendar.YEAR) != y2); } returndays;}

download：Dubbo 3 深度分析 - 透过源码意识你packagecn.outofmemory.codes.Date; importjava.util.Calendar;importjava.util.Date; publicclassCalendarDemo { publicstaticvoidmain(String[] args) { Calendar calendar=Calendar.getInstance(); calendar.setTime(newDate()); System.out.println("当初时刻是："+newDate()); String year=String.valueOf(calendar.get(Calendar.YEAR)); String month=String.valueOf(calendar.get(Calendar.MONTH)+1); String day=String.valueOf(calendar.get(Calendar.DAY_OF_MONTH)); String week=String.valueOf(calendar.get(Calendar.DAY_OF_WEEK)-1); System.out.println("当初时刻是："+year+"年"+month+"月"+day+"日，星期"+week); longyear2009=calendar.getTimeInMillis(); calendar.set(1989,9,26);//这儿与实在的月份之间相差1 longyear1989=calendar.getTimeInMillis(); longdays=(year2009-year1989)/(1000*60*60*24); System.out.println("明天和1989年10月26日相隔"+days+"天，"+"也就是说我在这个漂亮的星球上现已美妙的生存了"+days+"天。");}} Calendar类的动态方法getInstance()可能初始化一个日历指标: Calendar now = Calendar.getInstance(); 可能使用上面三个方法把日历定到任何一个时刻： set(intyear ,intmonth,intdate)set(intyear ,intmonth,intdate,inthour,intminute)set(intyear ,intmonth,intdate,inthour,intminute,intsecond) 如果想获得年份、月份、小时等信息可能使用： Now.get(Calendar.Month) 这样的方法0表明一月，1表明二月get(Calendar.DAY_OF_MONTH)获得这个月的第几天get(Calendar.DAY_OF_WEEK)获得这个星期的第几天get(Calendar.DAY_OF_YEAR)获得这个年的第几天getTimeMillis()获得过后时刻的毫秒表明如下是Calendar类方法简介 abstractvoidadd(intfield,intamount) 依据日历的规矩，为给定的日历字段减少或减去指定的时刻量。booleanafter(Object when) 判断此 Calendar 表明的时刻是否在指定 Object 表明的时刻之后，回来判断后果。booleanbefore(Object when) 判断此 Calendar 表明的时刻是否在指定 Object 表明的时刻之前，回来判断后果。voidclear()将此 Calendar 的所日历字段值和时刻值（从历元至当初的毫秒偏移量）设置成未界说。voidclear(intfield) 将此 Calendar 的给定日历字段值和时刻值（从历元至当初的毫秒偏移量）设置成未界说。Object clone()创立并回来此指标的一个正本。intcompareTo(Calendar anotherCalendar) 比拟两个 Calendar 指标表明的时刻值（从历元至当初的毫秒偏移量）。protectedvoidcomplete()填充日历字段中所有未设置的字段。protectedabstractvoidcomputeFields()将过后毫秒时刻值 time 转换为 fields[] 中的日历字段值。protectedabstractvoidcomputeTime()将 fields[] 中的过后日历字段值转换为毫秒时刻值 time。booleanequals(Object obj) 将此 Calendar 与指定 Object 比拟。intget(intfield)回来给定日历字段的值。intgetActualMaximum(intfield)给定此 Calendar 的时刻值，回来指定日历字段或者具备的最大值。intgetActualMinimum(intfield)给定此 Calendar 的时刻值，回来指定日历字段或者具备的最小值。staticLocale[] getAvailableLocales()回来所有语言环境的数组，此类的 getInstance 方法可能为其回来本地化的实例。String getDisplayName(intfield,intstyle, Locale locale) 回来给定 style 和 locale 下的日历 field 值的字符串表明形式。Map getDisplayNames(intfield,intstyle, Locale locale) 回来给定 style 和 locale 下蕴含日历 field 所有名称的 Map 及其相应字段值。intgetFirstDayOfWeek()获取一星期的榜首天；例如，在美国，这一天是 SUNDAY，而在法国，这一天是 MONDAY。abstractintgetGreatestMinimum(intfield)回来此 Calendar 实例给定日历字段的最高的最小值。staticCalendar getInstance() 使用默认时区和语言环境获得一个日历。staticCalendar getInstance(Locale aLocale) 使用默认时区和指定语言环境获得一个日历。staticCalendar getInstance(TimeZone zone) 使用指定时区和默认语言环境获得一个日历。staticCalendar getInstance(TimeZone zone, Locale aLocale) 使用指定时区和语言环境获得一个日历。abstractintgetLeastMaximum(intfield) 回来此 Calendar 实例给定日历字段的最低的最大值。abstractintgetMaximum(intfield) 回来此 Calendar 实例给定日历字段的最大值。intgetMinimalDaysInFirstWeek()获取一年中榜首个星期所需的起码天数，例如，如果界说榜首个星期蕴含一年榜首个月的榜首天，则此方法将回来1。abstractintgetMinimum(intfield) 回来此 Calendar 实例给定日历字段的最小值。Date getTime()回来一个表明此 Calendar 时刻值（从历元至当初的毫秒偏移量）的 Date 指标。longgetTimeInMillis()回来此 Calendar 的时刻值，以毫秒为单位。TimeZone getTimeZone()获得时区。inthashCode()回来该此日历的哈希码。protectedintinternalGet(intfield)回来给定日历字段的值。booleanisLenient()判断日期/时刻的讲解是否为宽松的。booleanisSet(intfield) 确定给定日历字段是否现已设置了一个值，其中包含因为调用 get 方法触发外部字段核算而导致现已设置该值的情况。abstractvoidroll(intfield,booleanup) 在给定的时刻字段上减少或减去（上/下）单个时刻单元，不更改更大的字段。voidroll(intfield,intamount) 向指定日历字段减少指定（有符号的）时刻量，不更改更大的字段。voidset(intfield,intvalue) 将给定的日历字段设置为给定值。voidset(intyear,intmonth,intdate) 设置日历字段 YEAR、MONTH 和 DAY_OF_MONTH 的值。voidset(intyear,intmonth,intdate,inthourOfDay,intminute) 设置日历字段 YEAR、MONTH、DAY_OF_MONTH、HOUR_OF_DAY 和 MINUTE 的值。voidset(intyear,intmonth,intdate,inthourOfDay,intminute,intsecond) 设置字段 YEAR、MONTH、DAY_OF_MONTH、HOUR、MINUTE 和 SECOND 的值。voidsetFirstDayOfWeek(intvalue) 设置一星期的榜首天是哪一天；例如，在美国，这一天是 SUNDAY，而在法国，这一天是 MONDAY。voidsetLenient(booleanlenient) 指定日期/时刻讲解是否是宽松的。voidsetMinimalDaysInFirstWeek(intvalue) 设置一年中榜首个星期所需的起码天数，例如，如果界说榜首个星期蕴含一年榜首个月的榜首天，则使用值1调用此方法。voidsetTime(Date date) 使用给定的 Date 设置此 Calendar 的时刻。voidsetTimeInMillis(longmillis) 用给定的long值设置此 Calendar 的过后时刻值。voidsetTimeZone(TimeZone value) 使用给定的时区值来设置时区。String toString() 回来此日历的字符串表明形式Calendar的罕用方法示例 ...

简介： 服务框架就像铁路的铁轨一样，是互通的根底，只有解决了服务框架的互通，才有可能实现更高层的业务互通，所以用雷同的规范对立，合二为一并共建新一代的服务框架是必然趋势。Dubbo3.0 是 Dubbo2.0 与 HSF 交融而来，是阿里经济体面向外部业务、商业化、开源的唯一标准服务框架。 服务框架就像铁路的铁轨一样，是互通的根底，只有解决了服务框架的互通，才有可能实现更高层的业务互通，所以用雷同的规范对立，合二为一并共建新一代的服务框架是必然趋势。 Dubbo3.0 是 Dubbo2.0 与 HSF 交融而来，是阿里经济体面向外部业务、商业化、开源的唯一标准服务框架。 阿里巴巴服务框架的抉择与实际Dubbo 和 HSF 在阿里巴巴的实际Dubbo 和 HSF 都是阿里巴巴目前在应用的微服务 RPC 框架。 Dubbo 则在 2011 年开源后，迅速成为业界广受欢迎的微服务框架产品，在国内外均有着广泛应用。Dubbo 我的项目诞生于 2008 年，起初只在一个阿里外部的零碎应用；2011 年，阿里 B2B 决定将整个我的项目开源，仅用了一年工夫就播种了来自不同行业的少量用户；2014 年，因为外部团队调整，Dubbo 暂停更新；2017 年 9 月，Dubbo 3.0 重启开源，在 2019 年 5 月由 Apache 孵化毕业，成为第二个由阿里巴巴募捐至 Apache 毕业的我的项目。 HSF 在阿里巴巴应用更多，承接了外部从单体利用到微服务的架构演进，撑持了阿里历年双十一的安稳运行；自 2008 年 5 月公布第一个版本 1.1 后，经验数年迭代，HSF 从一个根底的 RPC 框架逐步演变成为日撑持十万亿级别调用的易于扩大的微服务框架。外部场景中，用户既能够抉择大量配置轻松接入微服务体系，获取高性能的稳固服务调用。也能够依照本身业务需要，对 HSF 进行扩大，获取整条链路的能力加强。 对于团体内的需要而言，稳固和性能是外围，因而，过后选型了在电商这种高并发场景久经考验的 HSF 做为新一代服务框架外围。随后，HSF 推出了 2.0 的版本，并针对 HSF 之前版本的次要问题进行重构革新，升高了保护老本，进一步提高了稳定性和性能。HSF2.0 解决了通信协定反对不通明，序列化协定反对不通明等框架扩展性问题。基于 HSF2.0 的 Java 版本，团体内也演进出了 CPP/NodeJs/PHP 等多语言的客户端。因为 HSF 还兼容了 Dubbo 的协定，原有的 Dubbo 用户能够平滑地迁徙到新版本上，所以 HSF 推出后很快就在团体全面铺开，部署的 server 数量达到数十万，根本实现了阿里巴巴外部微服务框架的对立，并经验了多年双十一零点流量洪峰的验证。 ...

作者|泮圣伟、董建凯 服务框架就像铁路的铁轨一样，是互通的根底，只有解决了服务框架的互通，才有可能实现更高层的业务互通，所以用雷同的规范对立，合二为一并共建新一代的服务框架是必然趋势。 Dubbo3.0 是 Dubbo2.0 与 HSF 交融而来，是阿里经济体面向外部业务、商业化、开源的唯一标准服务框架。 阿里巴巴服务框架的抉择与实际Dubbo 和 HSF 在阿里巴巴的实际Dubbo 和 HSF 都是阿里巴巴目前在应用的微服务 RPC 框架。 Dubbo 则在 2011 年开源后，迅速成为业界广受欢迎的微服务框架产品，在国内外均有着广泛应用。Dubbo 我的项目诞生于 2008 年，起初只在一个阿里外部的零碎应用；2011 年，阿里 B2B 决定将整个我的项目开源，仅用了一年工夫就播种了来自不同行业的少量用户；2014 年，因为外部团队调整，Dubbo 暂停更新；2017 年 9 月，Dubbo 3.0 重启开源，在 2019 年 5 月由 Apache 孵化毕业，成为第二个由阿里巴巴募捐至 Apache 毕业的我的项目。 HSF 在阿里巴巴应用更多，承接了外部从单体利用到微服务的架构演进，撑持了阿里历年双十一的安稳运行；自 2008 年 5 月公布第一个版本 1.1 后，经验数年迭代，HSF 从一个根底的 RPC 框架逐步演变成为日撑持十万亿级别调用的易于扩大的微服务框架。外部场景中，用户既能够抉择大量配置轻松接入微服务体系，获取高性能的稳固服务调用。也能够依照本身业务需要，对 HSF 进行扩大，获取整条链路的能力加强。 对于团体内的需要而言，稳固和性能是外围，因而，过后选型了在电商这种高并发场景久经考验的 HSF 做为新一代服务框架外围。随后，HSF 推出了 2.0 的版本，并针对 HSF 之前版本的次要问题进行重构革新，升高了保护老本，进一步提高了稳定性和性能。HSF2.0 解决了通信协定反对不通明，序列化协定反对不通明等框架扩展性问题。基于 HSF2.0 的 Java 版本，团体内也演进出了 CPP/NodeJs/PHP 等多语言的客户端。因为 HSF 还兼容了 Dubbo 的协定，原有的 Dubbo 用户能够平滑地迁徙到新版本上，所以 HSF 推出后很快就在团体全面铺开，部署的 server 数量达到数十万，根本实现了阿里巴巴外部微服务框架的对立，并经验了多年双十一零点流量洪峰的验证。 ...

简介： 随着云原生时代的到来，Dubbo 3.0 的一个很重要的指标就是全面拥抱云原生。正因如此，Dubbo 3.0 为了可能更好的适配云原生，将原来的接口级服务发现机制演进为利用级服务发现机制。 作者介绍 熊聘，Github账号pinxiong，Apache Dubbo贡献者，关注RPC、Service Mesh和云原生等畛域。现任职于携程国内事业部研发团队，负责市场营销、云原生等相干工作。 背景随着云原生时代的到来，Dubbo 3.0 的一个很重要的指标就是全面拥抱云原生。正因如此，Dubbo 3.0 为了可能更好的适配云原生，将原来的接口级服务发现机制演进为利用级服务发现机制。 基于利用级服务发现机制，Dubbo 3.0 能大幅升高框架带来的额定资源耗费，大幅晋升资源利用率，次要体现在： 单机常驻内存降落 75% 能反对的集群实例规模以百万计的集群 注册核心总体数据量降落超 90% 目前对于 Dubbo 服务端裸露流程的技术文章很多，然而都是基于 Dubbo 接口级服务发现机制来解读的。在 Dubbo 3.0 的利用级服务发现机制下，服务端裸露流程与之前有很大的变动，本文心愿能够通过 对Dubbo 3.0 源码了解来解析服务端裸露全流程。 什么是利用级服务发现简略来说，以前 Dubbo 是将接口的信息全副注册到注册核心，而一个利用实例个别会存在多个接口，这样一来注册的数据量就要大很多，而且有冗余。利用级服务发现的机制是同一个利用实例仅在注册核心注册一条数据，这种机制次要解决以下几个问题： 对齐支流微服务模型，如：Spring Cloud反对 Kubernetes native service，Kubernetes 中保护调度的服务都是基于利用实例级，不反对接口级缩小注册核心数据存储能力，升高了地址变更推送的压力 假如利用 dubbo-application 部署了 3 个实例（instance1, instance2, instance3），并且对外提供了 3 个接口（sayHello, echo, getVersion）别离设置了不同的超时工夫。在接口级和利用级服务发现机制下，注册到注册核心的数据是截然不同的。如下图所示： 接口级服务发现机制下注册核心中的数据 "sayHello": [ {"application":"dubbo-application","name":"instance1", "ip":"127.0.0.1", "metadata":{"timeout":1000}}, {"application":"dubbo-application","name":"instance2", "ip":"127.0.0.2", "metadata":{"timeout":2000}}, {"application":"dubbo-application","name":"instance3", "ip":"127.0.0.3", "metadata":{"timeout":3000}},],"echo": [ {"application":"dubbo-application","name":"instance1", "ip":"127.0.0.1", "metadata":{"timeout":1000}}, {"application":"dubbo-application","name":"instance2", "ip":"127.0.0.2", "metadata":{"timeout":2000}}, {"application":"dubbo-application","name":"instance3", "ip":"127.0.0.3", "metadata":{"timeout":3000}},],"getVersion": [ {"application":"dubbo-application","name":"instance1", "ip":"127.0.0.1", "metadata":{"timeout":1000}}, {"application":"dubbo-application","name":"instance2", "ip":"127.0.0.2", "metadata":{"timeout":2000}}, {"application":"dubbo-application","name":"instance3", "ip":"127.0.0.3", "metadata":{"timeout":3000}}]利用级服务发现机制下注册核心中的数据 ...

背景和论断上线的时候，不同项目组开发进度不一样，然而服务有依赖，消费者可能先上线，消费者的入参对象增加了一个字段，然而提供者没有上线，所以没有增加该字段。会不会有问题？ 论断是没有。测试过程见截图。 消费者多了一个字段 提供者少了一个字段 消费者调用之后，返回数据 官网文档 看官网文档，提供者少了字段，有兼容问题，理论测试并没有兼容问题。

实践个别，接口都有设置超时工夫，不论是http接口，还是dubbo接口。 为什么要设置超时工夫？因为不设置的时候，一旦高并发，就会把零碎搞挂。 具体就是可能局部交易申请很慢，耗时很久，然而没有设置超时，而后就始终占着dubbo线程池的线程资源，这个时候，就会因为局部慢交易，影响和导致了整个零碎，因为其余原本失常的交易，当初因为dubbo线程池满了，也解决不了了，这个时候，零碎就解体了，所有的交易都耗时很慢。 dubbo超时的维度有2个维度，一个是作用域粒度，一个是消费者还是生产者。 粒度有3个 1、所有接口 comsumer/provider 2、接口级别 reference/service 3、办法级别 个别很少用。 优先级 粒度越小，优先级越高，即办法>接口>所有服务。 消费者 生产者优先级 消费者比生产者优先级高。 总结如果2个维度都有设置，那么 1、粒度维度优先级更高 2、消费者生产者维度优先级比粒度保护优先级低 举个例子 1、消费者是在所有接口粒度设置60s 2、提供者是在接口级别粒度设置15s 那么这个时候，就是以提供者为准，因为提供者的粒度这个维度更小，并且粒度优先级高于消费者生产者维度优先级，所以，这个时候就以提供者的15s超时为准。 总结 所以dubbo的超时工夫优先级为：消费者Method>提供者method>消费者Reference>提供者Service>消费者全局配置consumer>提供者全局配置provider。 最佳实际最好在提供者设置超时工夫。其实不仅仅是超时工夫设置，其余消费者和生产者都有的配置，都应该在提供者设置，因为提供者是写代码的一方，最理解代码，所以超时工夫等配置，就应该由你来设置。 只有非凡状况下，非凡场景下，消费者才须要配置，但这个也是属于定制超时工夫。 实战以后现状网关：comsumer 60s——》对立订单：service 15s；消费者：？——》前置：提供者：无；消费者：30s——》交易：提供者：无；消费者：15s。 优化前置和交易的提供者目前都没有设置超时工夫，所以必须要设置超时工夫，因为最佳实际就是提供者设置超时工夫，为什么呢？因为提供者最懂服务提供者须要耗时多久，代码是你写的，必定是你设置超时工夫最合适。 最佳实际是设置多久？原本是15s，其实15s都太大了，个别接口耗时几s就曾经很大了，当初为了逐步优化，能够先设置为30s。而后再优化为15s。 目前公司交易的都是15s，大一点就是30s，还有更大的是60s，比方网关，所以网关也须要优化，最多15s，然而实际上线的时候能够逐步优化，即先优化为30s，而后再优化为15s。不然高并发的时候，把零碎拖死了。 非交易接口 比方营销，报备，风控，都是1s，最多3s。不重要的，非核心接口，即失败了也不会影响交易的接口，工夫都设置的很短，个别就1s，不然的话，如果设置得很大，会让整个交易链路耗时太久。 参考https://dubbo.apache.org/zh/d...

本篇次要是介绍一下如何搭建dubbo admin，基于0.3.0版本。 源码下载首先咱们去github上下载一下dubbo-admin的源码，地址https://github.com/apache/dub...，抉择对应的版本，这里抉择最新的0.3.0版本。下载完后用idea关上这里咱们只有关注dubbo-admin-server和dubbo-admin-ui两个我的项目，最新版本的admin是采纳前后端拆散的，后盾就是server我的项目，前端就是这个ui我的项目。 启动后盾我这里用idea形式启动，你也能够本人打包之后通过java -jar dubbo-admin.jar形式启动。 批改配置找到server端的application.properties文件，批改对应的zookeeper配置地址以及端口号（如果端口号没抵触能够不改）我本地改了zookeeper地址，另外两个地址别离是配置核心和元数据中心的，能够不动。 启动改完之后就能够间接启动了。当然顺利的话，这里就完结了（前面能够跳过），然而我这边不是很顺利，启动失败，谬误如下：翻下去会看到这条谬误，大略就是连贯zookeeper失败了。然而咱们的zookeeper地址和端口通过cmd命令是通的，这时候只能调试了。大略是这段逻辑抛出来的，这里不讲细节逻辑，大略是同步期待zookeeper连贯胜利，后果等待时间到了仍然发现没胜利，于是就抛出了失败的异样（具体起因不在这里剖析）。这里咱们只有缩短连贯等待时间即可，我这里是调整为10秒（默认是5秒）。 启动前端前端用的是vue框架做的，这里我也没学过vue，依据github提醒操作就行。没装置过npm的先装置一下。关上命令行窗口，进入到ui代码的目录下：执行npm install，把你这个vue我的项目中用到的依赖都给下过去，它是基于package.json来下载对应依赖包的。下载实现之后，执行npm run dev，该命令示意执行dev字段对应的脚本内容，这里对应的就是执行完之后，就胜利了，呈现如下后果在vue页面里，用到script时，idea默认会缩进两个空格，而eslint校验时会认为这是不符合规范的。如果你在执行过程中呈现一些error，都是一些语法类的校验谬误，比方expected indentation of 0 spaces but found 2能够不必理睬，也能够通过idea的配置来解决最初关上对应的地址：http://localhost:8082/这里默认的用户名明码是root/root，当然你要改的话，就在后盾那个我的项目的application.properties配置文件中改一下，比方我这里就把用户名改成了don最初试下登录完满登录! 总结任何你认为简略的事件，在做的时候往往没有那么简略，还是须要多练练。另外这里也波及到vue的一些常识，这个我的项目也能够拿来当简略的源码学习。 github地址：https://github.com/apache/dub...npm run命令相干材料：https://www.jianshu.com/p/553...

简介dubbo-getty 是一个用 go 编写的异步网络 I/O 库，提供了三种通信模式，tcp、udp 以及 websocket，并为其设计了绝对对立的流程和 API，目前 dubbogo 等出名我的项目都应用 getty 作为底层的网络通信库，其特点是封装性好，应用简略。下图是 getty 外围构造的类图，根本囊括了整个 getty 框架的设计。 灰色局部为 go 内置库上面以 TCP 为例介绍下 getty 如何应用以及该类图里各个接口或对象的作用。 TCP Server 端server其中 server/client 是提供给用户应用的封装好的构造，client 的逻辑与 server 很多水平上统一，因而这里只讲 server。 在 getty 中，server 服务的启动流程只须要两行代码 server := getty.NewTCPServer(options...)server.RunEventLoop(NewHelloServerSession)第一行非常明显是一个创立 server 的过程，options 是一个个 func(*ServerOptions) 函数，用于给 server 增加一些额定性能设置，如启用 ssl，应用工作队列提交工作的模式执行工作等。 第二行的 server.RunEventLoop(NewHelloServerSession) 则是启动 server，同时也是整个 server 服务的入口，它的作用是监听某个端口（具体监听哪个端口能够通过 options 指定），并解决 client 发来的数据。RunEventLoop 办法须要提供一个参数 NewSessionCallback，该参数的类型定义如下： type NewSessionCallback func(Session) error这是一个回调函数，将在胜利建设和 client 的连贯后被调用，个别提供给用户用于设置网络参数，如设置连贯的 keepAlive 参数、缓冲区大小、最大音讯长度、read/write 超时工夫等，但最重要的是，用户须要通过该函数，为 session 设置好要用的 Reader、Writer 以及 EventListener。 ...

本篇文章次要是提供根本的dubbo服务端和消费者模型搭建并进行简略调用的案例。基于dubbo2.7.1，并应用注解形式进行服务裸露和援用。 实现性能服务端提供城市信息获取的性能。生产端通过dubbo调用服务端获取到城市信息。 服务端搭建首先咱们新建一个springboot我的项目，名称叫dubbo-provider。（如何创立springboot我的项目能够自行百度）而后在pom文件中引入dubbo的jar <dependency> <groupId>org.apache.dubbo</groupId> <artifactId>dubbo</artifactId> <version>2.7.1</version></dependency>新建一个CityService的接口类，提供获取城市名称的性能 public interface CityService { String getCityName();}创立一个实现该接口的类，并加上@Service注解（属于包org.apache.dubbo.config.annotation下的） @Servicepublic class CityServiceImpl implements CityService { @Override public String getCityName() { return "hangzhou"; }}@Service注解示意裸露服务，dubbo辨认到该注解会将其注册到注册核心去。在你的springboot利用的Application上加上注解@EnableDubbo @EnableDubbo@SpringBootApplicationpublic class DubboAnalyzeApplication { public static void main(String[] args) { SpringApplication.run(DubboAnalyzeApplication.class, args); }}EnableDubbo注解示意启用dubbo扫描，除了会将配置文件里的配置注入以外，还会解析@Service以及@Reference注解并实例化成bean。resources目录下新增dubbo.properties文件，增加内容如下 dubbo.application.name=providerdubbo.protocol.port=20889dubbo.registry.address=zookeeper://192.168.10.118:2181dubbo会主动去扫dubbo.properties文件并解析内容，注册核心改为你本人的地址。至此服务端就搭建实现了。 生产端搭建同样的咱们新建一个springboot我的项目，名称叫dubbo-consumer。引入dubbo的jar包 <dependency> <groupId>org.apache.dubbo</groupId> <artifactId>dubbo</artifactId> <version>2.7.1</version></dependency>再引入服务端的接口，服务端能够将接口独自放到一个module里并打成jar包对外提供应用，我这里为了不便，没有做拆散，间接引入了服务端的jar包 <dependency> <groupId>com.example</groupId> <artifactId>dubbo-provider</artifactId> <version>0.0.1-SNAPSHOT</version></dependency>创立一个调用服务的类，我这里为了Web演示，用springmvc来创立类名为MyController的类，加一个成员变量CityService类型的（此类型就是下面服务端中创立的接口类），并在下面加一个@Reference注解。 @RestControllerpublic class MyController { @Reference CityService cityService; @PostMapping("hello") public void hello(){ String name = cityService.getCityName(); System.out.println("finish"); }}Reference注解用于援用对应的城市信息服务，dubbo会为其生成一个代理类。其余的步骤和下面服务端的一样，Application上加注解@EnableDubbo并在resources目录下新增dubbo.properties文件，注册核心一样改为你本人的地址。 @EnableDubbo@SpringBootApplicationpublic class DubboAnalyzeApplication { public static void main(String[] args) { SpringApplication.run(DubboAnalyzeApplication.class, args); }}dubbo.application.name=consumerdubbo.protocol.port=20888dubbo.registry.address=zookeeper://192.168.10.118:2181至此生产端也搭建实现了。 ...

本篇次要是对dubbo进行一些根本的介绍，让大家理解一下什么是dubbo。这里是基于dubbo 2.7.x版本进行的介绍。 什么是dubbo如果当初公司要你做一个分布式的服务程序，要保障整个零碎的高可用、高并发、高牢靠，你会怎么做？首先必定会去网上搜是否有现成的框架，通过搜寻你很有可能会搜到dubbo、spring cloud等，他们都是为了分布式服务程序做筹备的。当然，你也有可能会感觉这些都太low，本人去开发一个，那你要思考哪些货色呢？1、服务之间调用如何做负载平衡2、服务之间调用出错了如何进行降级解决3、服务之间如何进行高效稳固的通信4、服务端如何裸露服务、生产端如何调用服务5、如何监控到整个服务零碎的运行状况6、...除了性能上的实现，你还得思考如何对业务端通明、可能疾速接入。以上说的这些如果你要本人做一个的话，预计没个一年半载是不太可能的。此时dubbo、spring cloud就露出身影了。这里咱们不探讨Spring Cloud，只介绍dubbo，从下面的问题能够看出，dubbo就是为了解决这些货色的框架，再进一步总结：一套基于RPC的分布式服务通信和治理框架。 比对这两幅图更形象地阐明了dubbo到底是什么。 社区活跃度作为一款支流的rpc通信框架，dubbo的成长天然也是离不开社区的奉献，从对应的源码star咱们就能看出dubbo的受关注度。另外从issue的解决状况也看进去活跃度 模块这里说的模块次要是指dubbo调用各方的形成，截取官网一张图：能够看到有4个模块 服务提供方服务生产方服务注册方服务监控方其中必须的是服务提供方、生产方和注册方。简略的介绍一下这个图：大略就是有一个服务注册方，服务提供方启动的时候把提供的服务注册到注册方，服务生产方在启动的时候去注册方订阅服务，一旦有服务变动，注册方会被动告诉到服务生产方进行服务列表更新，另外咱们能够启动服务监控方对所有运行的服务进行监控。 元素最初介绍一下dubbo目前有哪些元

简介： Dubbo 3.0 是在云原生背景下诞生的，应用 Dubbo 构建的微服务遵循云原生思维，能更好的复用底层云原生基础设施、贴合云原生微服务架构。Dubbo3.0 介绍 作者 | 十眠 自从 Apache Dubbo 在 2011 年开源以来，通过多年一众大规模互联网、IT 公司的实际积攒了大量教训，Dubbo 凭着对 Java 用户敌对、功能丰富、治理能力强等长处在过来获得了很大的认可，成为国内外风行支流的 RPC 框架之一。 但随着云原生时代的到来，对以 Apache Dubbo、Spring Cloud 等为代表的 Java 微服务治理体系提出了新的要求，包含冀望利用能够更快的启动、利用通信的协定穿透性能够更高、可能对多语言的反对更加敌对等。比方 Spring 在往年也推出了其基于 GraalVM 的 Spring Native Beta 解决方案，领有毫秒级启动的能力、更高的解决性能等。 这样的背景对下一代 Apache Dubbo 提出了两大要求： 1、要保留已有开箱即用和落地实际背景下带来的益处，这也是泛滥开发者所冀望的； 2、尽可能地遵循云原生思维，能更好的复用底层云原生基础设施、贴合云原生微服务架构。 Dubbo 3.0 是在云原生背景下诞生的，应用 Dubbo 构建的微服务遵循云原生思维，能更好的复用底层云原生基础设施、贴合云原生微服务架构。这体现在： 服务反对部署在容器、Kubernetes 平台，服务生命周期可实现与平台调度周期对齐； 反对经典 Service Mesh 微服务架构，引入了 Proxyless Mesh 架构，进一步简化 Mesh 的落地与迁徙老本，提供更灵便的抉择； 作为桥接层，反对与 SpringCloud、gRPC 等异构微服务体系的互调互通。 在云原生大背景下，Apache Dubbo 3.0 抉择全面拥抱云原生，对 Dubbo 架构降级，提出了全新的服务发现模型、下一代 RPC 协定和云原生基础设施适配等。 ...

简介： Pixiu 是基于 Dubbogo 的云原生、高性能、可扩大的微服务 API 网关。作为一款网关产品，Pixiu 帮忙用户轻松创立、公布、保护、监控和爱护任意规模的 API ，承受和解决成千上万个并发 API 调用，包含流量治理、 CORS 反对、受权和访问控制、限度、监控，以及 API 版本治理。 Pixiu 是什么在答复 Pixiu 是什么之前，咱们简略解释一下 Dubbo 是什么。Dubbo 是一个开源的高性能 RPC 框架，有着丰盛的服务治理能力以及优良的扩大能力。Dubbo 更扩大出 Dubbo-go，为用户提供了 Golang 的 Dubbo 解决方案，买通了两种语言之间的隔膜，使 Dubbo 更加贴近云原生。 Dubbo-go 作为 Golang 服务，实现与 Dubbo 服务之间的互相调用。然而，在日常应用场景中，用户往往有把 Dubbo 服务以 RESTful 格调向外裸露的需要同时也要兼顾外部 Dubbo 调用。为了解决这种场景，作为 Dubbo API 网关的 Pixiu (中文: 貔貅， 曾用名 dubbo-go-proxy) 便应运而生。之所以采纳 Pixiu 这个名称，是因为 Java 同类产品 Zuul 的意象是一个东方怪兽，Pixiu 作为一个国产产品，就用了咱们中国的一个相似的神兽貔貅作为项目名称。也同时表白了 Dubbo 社区心愿扩大出一整套云原生生态链的信心。 目前 Dubbo 多语言生态，倒退最好的天然是 Java，其次是 Golang，其余语言都差强人意。dubbo-go-pixiu 我的项目是一个基于 dubbo-go 倒退起来的我的项目，目前接口协议层反对的是七层的 HTTP 申请调用，打算在将来的 0.5 版本中反对 gRPC 申请调用，其另外一个使命是作为一种新的 dubbo 多语言解决方案。 ...

按语dubbogo 我的项目已进入第六个年头。dubbogo 我的项目初期的使命就是 "bridging the gap between Java and Go" ，目前 dubbogo 曾经对齐所有 dubbo 版本，正与 Dubbo 齐头并进，并在云原生方向反哺 Dubbo。 参加过 dubbogo 我的项目跟着社区一路走来的人，有贡献者100多人，apache dubbo committer 23 人，其中PMC 5 人。社区根底我的项目在 https://github.com/dubbogo ，孵化成熟后即募捐到apache https://github.com/apache ，到目前为止曾经胜利地奉献了 5 个 我的项目，整体代码有 17 万行之多。 从本期开始，本账号将陆续采访社区的 PMC/committer，回首各位同学退出社区时的初心，回顾在社区成长的朝朝暮暮，以照亮将来在社区的前行路。 于雨引语社区目前 PMC 五人中，曾经陆续采访了 何鑫明【社区人称 何老板】和 方银城【社区送雅号 方队长】，本期采访人物是 望哥。如果选举社区里最受人崇敬的人，我想选 望哥，我猜测大家也都会批准我的观点。我对望哥的评估是：讷于言而敏于行。社区很多人在我的项目参加期很沉闷，望哥却始终站在旁边冷眼旁观，依照本人的节奏做事，当这些人拿到 committer 因为各种缘故从社区隐没后，望哥还在那里默默做事，无需我多言。 从 2018 年开始到当初的三年间先后有 31 人参加过 dubbogo 的外围我的项目 dubbo-go-hessian2，大多数人也都是来去匆匆，唯有望哥 2018 从我这里我这个我的项目始，到当初始终在保护，诠释了专一二字的含意。望哥曾给我承诺只有社区须要这个我的项目，他就会始终保护上来。  兴许很多人对 dubbogo 其余我的项目抱有认识，但对这个库应该抱有尊敬 --- 这是全网品质最好的 hessian2 协定的 Go 语言版本。 我想，望哥应该对目前 dubbogo 社区的倒退感到称心，至多会打分优良：dubbogo 和 dubbo-go-hessian2 井水不犯河水，没有 dubbogo 的倒退兴许望哥这两年会剩下心来做别的事件，这个库的倒退也可能沦落到 github 千万亿我的项目中的某个角落，反过来没有望哥在如此负责任的人在保护这个高质量库， dubbogo 也不会如此持重地前行。 ...

dubbogo 我的项目已进入第六个年头。dubbogo 我的项目初期的使命就是 "bridging the gap between Java and Go" ，目前 dubbogo 曾经对齐所有 dubbo 版本，正与 Dubbo 齐头并进，并在云原生方向反哺 Dubbo。 参加过 dubbogo 我的项目跟着社区一路走来的人，有贡献者100多人，apache dubbo committer 23 人，其中PMC 5 人。社区根底我的项目在 https://github.com/dubbogo ，孵化成熟后即募捐到apache https://github.com/apache ，到目前为止曾经胜利地奉献了 5 个 我的项目，整体代码有 17 万行之多。 从本期开始，本账号将陆续采访社区的 PMC/committer，回首各位同学退出社区时的初心，回顾在社区成长的朝朝暮暮，以照亮将来在社区的前行路。 1. 首先回顾下是什么契机让你理解到 dubbogo 的？ 一开始理解 dubbo-go 还是因为公司内的 go 语言我的项目须要一个能和 dubbo 互通的 rpc 框架，在过后只能找到于雨老板奉献的 dubbo-go 能够做到通过 dubbo 协定和 java 利用互通，于是开始了我在 dubbo-go 社区的奉献和自我晋升之路。 2. 参加到 dubbogo 的开源奉献是什么样的体验？ 开源我的项目的参加是和工作中的我的项目齐全不一样的一种体验，根本都是线上的合作形式、自在自主的开发模式让我不只是技术的成长，还有实现工作时的极大成就感。来自不同公司不同行业的贡献者的技术交换也很容易拓展本人的技术视线，大佬们对pr的代码review也的确让我意识到了不少的技术细节。总之就是一个绝对纯正的技术气氛。 3. 撑持你继续奉献 dubbogo 最大的能源，以及给 dubbogo 做出的最大奉献是什么？ ...

简介： 一个新的里程碑！ 一、背景自从 Apache Dubbo 在 2011 年开源以来，在一众大规模互联网、IT公司的实际中积攒了大量教训后，Dubbo 凭借对 Java 用户敌对、功能丰富、治理能力强等长处在过来获得了很大的胜利，成为国内外热门支流的 RPC 框架之一。 但随着云原生时代的到来，以 Apache Dubbo、Spring Cloud 等为代表的 Java 微服务治理体系面临了许多新的需要，包含冀望利用能够更快的启动、利用通信的协定穿透性能够更高、可能对多语言的反对更加敌对等。例如Spring 也在往年推出了其基于 GraalVM 的 Spring Native Beta 解决方案，领有毫秒级启动的能力、更高的解决性能等优化晋升。 这样的背景对下一代 Apache Dubbo 提出了两大要求：一是要保留已有的开箱即用和落地实际背景下积攒的长处，这也是泛滥开发者所冀望的；二是尽可能地遵循云原生思维，能更好的复用底层云原生基础设施并且更贴合云原生的微服务架构。 二、拥抱云原生在现在的大背景下，Apache Dubbo 3 抉择全面拥抱云原生，将 Dubbo 的架构降级，提出了全新的服务发现模型、下一代 RPC 协定和云原生基础设施适配等优化计划。 1、全新服务发现模型（利用级服务发现）利用级注册模型 以 Dubbo 原有的设计，存储在注册核心中的数据会在很大水平上存在反复的内容，这其实节约了一部分的存储。而当整个集群的规模足够大的时候，因为服务注册发现是服务维度的，注册核心的数据量就会爆发式地增长。 以后同样是微服务治理工具的 Spring Cloud 和 gRPC 都是基于利用级的服务发现，如果仍应用接口级别的注册形式，Dubbo 就很难和他们进行互通。但如果 Dubbo 也能够像 Spring Cloud 一样以服务级注册，那么在异构体系下将能够很轻松地工作起来。 异构下部署计划 利用级服务发现机制是 Apache Dubbo 面向云原生走出的重要一步，它帮 Apache Dubbo 买通了与其余微服务体系之间在地址发现层面的鸿沟，也成为 Apache Dubbo 适配 Kubernetes Native Service 等基础设施的根底。 ...

前言大家好，明天给大家分享 — Dubbo 3.0.0 相干简介。首先给大家说声道歉！因为 Dubbo 3.0.0 曾经在 6月14日曾经公布了最新的 release 版本，因为在做一些《Dubbo高阶教程》后期筹备工作所有始终没有工夫进行更新。当前如果 Dubbo 有重要的新版本公布作者会在第一工夫进行相干的分享。上面就开始咱们明天的内容吧！ 1. Dubbo 3.0.0 简介首先咱们先来看看 Dubbo 在 Github 公布的新个性： 利用级别服务发现机制下一代 RPC 协定: Triple全新的路由规定极大的性能晋升Kubernetes 服务集成其中咱们着重理解下利用级别服务与Kubernetes 服务集成反对。Dubbo 3.0.0 次要在云服务能力上做了新的能力晋升。为什么这么说呢？因为作者之前在工作中集成 Kubernetes 时候服务注册核心这个组件能力就十分的难堪，因为 Kubernetes 自身就提供了服务注册与发现能力，然而不能和 Dubbo 完满整合起来。因而在Dubbo 3.0.0 之前咱们的实现形式可能就是在 Kubernetes 部署一个 zookeeper 服务集群来进行服务注册与发现。但这样的实现形式在云服务利用来说并不是太适合，这种服务注册和发现能力交给根底服务组件来实现比拟适合。同时 Dubbo 3.0.0 扭转以前的接口级服务注册而是采纳利用级服务注册，什么意思呢？比方在3.0.0版本前所有的服务都是以接口模式的元数据进行注册如下元数据： dubbo://192.168.101.8:20880/com.example.demo.async.api.BookFacade?anyhost=true&application=demo-provider&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=com.example.demo.async.api.BookFacade&metadata-type=remote&methods=queryByName,queryAll&pid=53639&release=3.0.0&side=provider×tamp=1624889509797dubbo://192.168.101.8:20880/com.example.demo.common.api.FoodFacade?anyhost=true&application=demo-provider&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=com.example.demo.common.api.FoodFacade&metadata-type=remote&methods=findAll&pid=53639&release=3.0.0&side=provider×tamp=1624889510225咱们能够看到如果咱们以接口级进行服务注册会存在大量的反复数据，这样就会导致注册核心数据与接口数量成正比，接口越多注册的元数据就越多。而如果咱们以利用级服务注册会是怎么的？上面是利用级服务注册的共享元数据： { "name": "demo-provider", "id": "192.168.101.8:20880", "address": "192.168.101.8", "port": 20880, "sslPort": null, "payload": { "@class": "org.apache.dubbo.registry.zookeeper.ZookeeperInstance", "id": null, "name": "demo-provider", "metadata": { "anyhost": "true", "application": "demo-provider", "deprecated": "false", "dubbo": "2.0.2", "dubbo.endpoints": "[{\"port\":20880,\"protocol\":\"dubbo\"}]", "dubbo.metadata-service.url-params": "{\"version\":\"1.0.0\",\"dubbo\":\"2.0.2\",\"release\":\"3.0.0\",\"port\":\"20880\",\"protocol\":\"dubbo\"}", "dubbo.metadata.revision": "525892dddd25ea459ee539d0734b2f1a", "dubbo.metadata.storage-type": "remote", "dynamic": "true", "generic": "false", "interface": "com.example.demo.async.api.BookFacade",//多个服务接口只保留一个 "metadata-type": "remote", "methods": "queryByName,queryAll", "pid": "63941", "release": "3.0.0", "side": "provider", "timestamp": "1624891074206" } }, "registrationTimeUTC": 1624891075236, "serviceType": "DYNAMIC", "uriSpec": null}从这些共享元数据能够看出利用级注册缩小了大量反复的元数据，能最大幅度的加重注册核心的存储、推送压力，进而缩小 Dubbo 生产端的地址计算压力。集群规模也开始变得可预测、可评估（与 RPC 接口数量无关，只与实例部署规模相干）。 ...

一、SPISPI全称为Service Provider Interface，对应中文为服务发现机制。SPI相似一种可插拔机制，首先须要定义一个接口或一个约定，而后不同的场景能够对其进行实现，调用方在应用的时候无需过多关注具体的实现细节。在Java中，SPI体现了面向接口编程的思维，满足开闭设计准则。 1.1 JDK自带SPI实现从JDK1.6开始引入SPI机制后，能够看到很多应用SPI的案例，比方最常见的数据库驱动实现，在JDK中只定义了java.sql.Driver的接口，具体实现由各数据库厂商来提供。上面一个简略的例子来疾速理解下Java SPI的应用形式： 1）定义一个接口 package com.vivo.studypublic interface Car {void getPrice();}2）接口实现 package com.vivo.study.impl /** * 实现一 * */public class AudiCar implements Car { @Override public void getPrice() { System.out.println("Audi A6L's price is 500000 RMB."); }} package com.vivo.study.impl/** * 实现二 * */public class BydCar implements Car { @Override public void getPrice() { System.out.println("BYD han's price is 220000 RMB."); }}3）挂载扩大类信息 在META-INF/services目录下以接口全名为文件名的文本文件，对应此处即在META-INF/services目录下创立一个文件名为com.vivo.study.Car的文件，文件内容如下： com.vivo.study.impl.AudiCarcom.vivo.study.impl.BydCar4）应用 public class SpiDemo {public static void main(String[] args) { ServiceLoader<Car> load = ServiceLoader.load(Car.class); Iterator<Car> iterator = load.iterator();while (iterator.hasNext()) { Car car = iterator.next(); car.getPrice(); } }}下面的例子简略的介绍了JDK SPI机制的应用形式，其中最要害的类为ServiceLoader，通过ServiceLoader类来加载接口的实现类，ServiceLoader是Iterable接口的实现类，对于ServiceLoader加载的具体过程此处不开展。 ...

简介：阿里云始终心愿能够做标准化的技术，跟社区的规范、行业的规范进行买通，这样对于阿里云的客户而言，简化了很多流程，其具备的能力也是将来的支流。 文章起源：雷锋网 作者：杨丽 原题目：《独家解读：阿里云原生利用的布局与策略》 受访人 | 丁宇 出品 | 雷锋网产业组 进化到这一阶段，云原生使得客户的数字化转型门路一直缩短。如果说云原生时代所有是以客户视角为出发点，那么进一步拆解就是围绕客户的业务场景、零碎架构，而不再是过来堆人、费劲的形式。如何正确引导客户独特享受到云原生的技术红利？丁宇，花名叔同，阿里巴巴研究员、阿里云智能云原生利用平台负责人，他所看到且给出的，兴许不是客户数字化转型的惟一计划，但却是通过阿里云多年实际得出的对某类问题的最优解。回顾过去十五年，阿里巴巴的云原生实际随同着团体业务规模和撑持场景复杂度的一劳永逸。对内，阿里淘宝作为寰球最大的电商交易平台，每年双11电商业务带来的都是极大的技术挑战；对外，阿里云撑持了寰球300万的企业客户数，帮忙客户解决问题的同时也会关注其业务的倒退。实际上，每一阶段不同问题的呈现，也是阿里本身产品技术冲破的翻新引擎。 如果对这十五年的阿里云原生实际变迁做个拆解，那么肯定离不开这个逻辑：自研-自用-上云凋谢。 • 第一阶段：2006年-2011年，淘宝商城从集中式架构切换到微服务分布式架构，外围解决高可用性和稳定性的问题。• 第二阶段：2011年-2015年，开始投入做容器，以解决老本和运维效率的问题。• 第三阶段：2015年-2019年，推动产品技术的全面商业化，全面拥抱云原生的规范。• 第四阶段：2019年-至今，从撑持双11外围零碎全面上云，到撑持外围零碎全面云原生化。 能够说，阿里巴巴赶上了两个红利，一是互联网规模经济的红利；二是云计算的红利。通过一直解决在这些红利中遇到的问题，才有可能让阿里巴巴打造这些产品，并有机会全面降级下一代云原生技术，一直反哺给客户。 然而，并非所有的企业都有机会和工夫（窗口期）来接触和塑造本身业务的云原生能力。“没有云原生之前，只有能力极强的企业能够解决这个问题，但随着云原生的呈现，每家企业都能够实现对云和极致弹性能力的调取，这是一个普适性红利的开释。”丁宇说道。 目前，阿里云有300+款云原生产品，上千个解决方案，为企业数字翻新提供全方位能力撑持。 以容器技术为代表，因与云的联合，可能向下屏蔽基础设施的差异性，成为云服务调用的新界面，向上又能够撑持各类产品。 那么咱们该如何进一步了解云原生，以及什么样的先进性企业能率先一步走出云原生实际的路子？丁宇，阿里巴巴研究员、阿里云智能云原生利用平台负责人 这次访谈中，丁宇向咱们分享了阿里云原生十五年实际的演进路线，以及对云计算畛域的察看和对业务将来倒退的思考，对于云原生企业和从业者有不少可借鉴之处。以下将是此次独家访谈的残缺总结。 两个“30%”外界有太多的技术或厂商视角下的云原生解读，这次咱们尝试从客户视角来看云原生带来了哪些扭转。 云原生自身在整个行业的市场接受度和落地成熟度越来越高。这源自于云原生给企业带来的两个直观感触。 • 一是老本和资源的优化。很多企业购买了一个月的云资源，但理论可能只用了一周。企业上云、弹性用云的能力不强，只能通过工夫换空间，多买点工夫以解决能力不强的问题。但云原生解决了这个问题，可能让用户随用随取、用完即还，这自身就是一种十分强的资源优化。 去年疫情期间，在线教育行业客户通过阿里云的撑持，晋升了近50%~60%的资源利用率。客户能够向下治理资源，向上治理AI、大数据、数据库、音视频等各项任务，通过灵便调度、混合部署、以及对工作全生命周期的治理、DevOps等，实现全生命周期的优化。 • 二是研发效率的优化。企业的研发效率往往取决于架构的先进性。云原生实现了公布、上线、运维，以及开发工具等全栈优化，晋升了研发人员单位生产的吞吐能力。 一项数据显示，核桃编程利用云原生可观测性产品ARMS缩小了30%运维工作量，缩短了60%的故障定位均匀耗时。 “咱们肯定会做一点，就是只有企业来试了，就会喜爱并且违心持续应用。阿里云提供的云原生技术和产品在业界具备很好的通用性和先进性，是在企业数字翻新发展趋势的主线上。只管对企业客户来讲，可能会存在肯定理念上的学习老本，但这种实打实的效率晋升、老本升高，对于企业将来五年、十年甚至更久远的倒退是十分有价值的。” 在此之前，阿里云通过云原生技术和产品带来了两个“30%”的晋升，即晋升30%研发效率，升高30%的IT老本，心愿通过本身实际实现对外赋能数百万企业进行云原生革新。 在跟各行业的客户接触过程中，丁宇感触很深： “云原生的劣势反馈到客户侧会有很显著的扭转，但这种扭转并不是客户最关怀的。客户更关怀的是如何实现业务的胜利，帮忙本身实现数字化转型，这些是外围问题。阿里云会从这个角度登程，依据客户的需要提供相应的产品解决方案。这些实质上都是云原生的体系，只是产品状态和档次会有所不同。” 云原生里的“二八准则”正如上文提到的，阿里巴巴在2019年提出并实现了外围零碎全面上云，2020年又提出外围零碎全面云原生化，通过云原生产品全面撑持团体双11大促。云原生并非欲速不达，尤其对于阿里巴巴这样宏大的体系，它是一个循序渐进的过程，然而咱们会从一些新兴业务里疾速看到云原生带来的扭转。 对于阿里巴巴而言，云原生的终态大略会是二八状态，即至多20%仍是自建，80%的业务会实现云原生化，不会做到100%的云原生化。 起因在于，在企业上云时代，更多讲的是IaaS上云。规模效应下，云计算的老本能够像水煤电一样做到老本足够低，从自建机房到租赁式服务，让企业客户直观感触到老本的大幅降落。但到了PaaS这个档次，会波及不同的角色和场景、工具和服务，PaaS的差异性开始凸显进去，比方企业开发工具、运维工具、企业云管平台，以及外部IT零碎等，这部分很长一段时间内都没有齐全云原生化。 阿里巴巴的本身业务体量十分大，如果全面云原生化意味着要做很多的定制服务，这并非最优解。将来实现80%的云原生化，其实也代表着阿里本身对于投入云原生技术的信心，甚至能够节约掉一些老本，以解决遗留资产的问题。 在2016年，阿里巴巴就实现了100%的容器化，以新一代的容器化形式替换原有的业务构建形式。这在互联网企业里能够说是绝无仅有。 相比之下，很多云原生时代的新兴势力，可能最大的劣势就是不存在20年前阿里所面临的遗留资产问题，它们实现100%的云原生化就容易很多。 以批发行业为例。这个行业的竞争态势决定了企业必须要走在前列，踊跃拥抱数字化转型伎俩，利用数据驱动业务，买通跟客户的连贯，实现门店治理、营销数字化等。 批发行业的全渠道营销等新业务往往是100%云原生的，然而一些存量的业务板块，企业可能不会有太大的能源、精力和能力实现云原生化。 丁宇提到，“咱们要认清一个矛盾点，咱们能够解决企业最外围的业务数字转型问题，但不能做一套计划来满足企业的所有零碎。云原生并不是万能钥匙，帮忙企业解决全副的问题。” 一股“新兴势力”对于云原生带来的先进生产力，各行各业都会存在肯定的需要。只不过那天有没有到来，仍取决于所在行业和客户的成熟度。 容器+Kubernetes曾经成为云计算的新界面，能够对上游的业务包含大数据、AI、区块链、边缘计算等新兴负载进行撑持。站在这一层面，云原生是不分行业的，它是依据场景和技术平台的特点来决定的。 但这并不意味着不同客户对云原生技术利用的需要会是雷同的。实际上，不同行业对计划的接受度、爱好的差异是较为显著的。 比方，政企、金融等线下实体行业比拟喜爱平台级的PaaS产品，心愿体验好、门槛低、稳定性高、可迭代；而互联网企业就不太承受PaaS，他们更心愿是模块化、可组装的，具备肯定的灵便度和开放性，这类企业往往技术实力较强，也有本人把控的想法。 此外，互联网企业对Serverless的偏好是非常明显的。Serverless将云的界面大幅上移，升高了对开发人员的精力耗费。在阿里团体外部，像闲鱼、高德等业务板块，就率先于阿里团体应用了Serverless的技术。 “说不好哪个业务会走到后面，业务对新技术的渴求是一样的，然而不同业务板块会依据本身的能力和所处的阶段，做一些新的畛域和产品的尝试。” 规范和开源减速了云原生单讲概念，云原生直到2013年前后才有一个大抵规范的定义，到2018年又被CNCF持续诠释。但实际上，阿里云对云原生也有本人的了解。 在阿里云看来，云原生有广义和狭义了解之分。广义了解上，云原生是从容器而来，企业的IT架构要跟云联合，才会有更好的劣势。云原生的劣势在于可能充分发挥云的能力，利用云的劣势，构建弹性、可扩大、易治理、易保护的零碎。 同时，云本身也在发生变化、降级。比方神龙服务器的降级，跟容器进行软硬一体的协同优化，使得性能、弹性各方面指标都能失去很大的晋升；数据库跟云原生联合，可能将数据库跑在容器上，做存储计算拆散，数据库的弹性自动化运维。 云实际上革新了技术的实现形式。 狭义了解上，云原生的外延可能更为丰盛，因云而生、为云变动，云上生、云上长，这种实际形式曾经远远超过了容器化所带来的意义。 以丁宇所负责的阿里云云原生利用平台为例，不同于之前咱们所了解的容器服务、中间件等产品，云原生利用平台是一个丰盛、关涉多元角色体系的平台。它既不是容器平台，也不是PaaS，却须要连贯很多外围的第三方SaaS服务商、PaaS服务商，凋谢兼容性接口给客户。那么，规范与开源可能是欠缺将来商业化体系的方向之一。 比方，阿里联结微软在社区推出的一款用于构建和交付云原生利用的标准规范OAM（Open Application Model），其核心理念即“以利用为核心”。起因在于，过来五年的云原生技术，次要是向下解决问题，而今它向上能够撑持很多工作工作，却不足对模型治理的标准化。 原来，开源走商业化十分难，但明天的状况不同，大量的开源软件能够在云上提供服务，无论容器还是大数据、音视频服务，都能够开发合乎标准规范的利用，以云的形式触达客户。 这种拥抱开源的形式也最终影响了软件的凋谢规范，造成阿里云原生利用平台的最外围特色。 开源仍在路上在阿里巴巴外部有这样一句话叫做“因为置信，所以看见”。无论最终论断导向了哪一方，你为之All In的全过程，其实就是在证实你的愿景。 相比过来，开源因云计算订阅模式的扭转，造成了一条新的商业门路。目前阿里云的开源我的项目曾经超过了2600个，Star数超百万，这是过来难以想象的事件。 以容器技术的倒退为例。2011年至2016年期间，很多容器服务厂商就呈现了这样一个规范的踏空。阿里云也是在2016年才替换掉本人的容器技术，抉择了过后曾经成为业界事实标准的Docker。 这无疑就回到一个问题：对技术的抉择，是自研，还是应用开源技术？ 对于阿里而言，采纳开源或第三方产品基本支撑不了其规模和体量，如果可能撑持的话，老本也是十分高的。如果企业全是自研的话，会同时带来一个问题，企业不肯定容易招人，从语言到平台、框架、架构全是自研，人才培训就是问题，人才来到后也不肯定好找工作。 所以最初导向一点，就是肯定要有规范。这个规范可能面向行业普适性，这样人才好招，同时还能够排汇里面的力量，自研的货色也有机会造成商业化。 现在来看，通过过来多年的实际，阿里云成为了很多事实标准（如Dubbo、RocketMQ），也追随业界的趋势，采纳了很多行业的规范（如Kubernetes ）。 ...

前言接触dubbo分布式框架的开发也有一段时间了，其中为了解决我的项目中遇到的一些杂症，还特意学习了一下Dubbo服务裸露和服务引入的一些源码知识点。最近在我的项目开发的过程中，有应用到了dubbo的隐式参数技术点，但发现了几个在应用上非常容易出错并且一出错就是生产事变的坑，当初记录一下。一、理解Dubbo隐式参数之前先理解下Dubbo的上下文信息什么是Dubbo的上下文信息？这里总结下本人的了解： 上下文中寄存的是以后调用过程中所需的环境信息。所有的配置信息都将转换成URL的参数。RpcContext类就是Dubbo的上下文，然而它仅仅是一个ThreadLocal级别的长期状态记录器，当接管到RPC申请或发动RPC申请时，RpcContext的状态都会变动。比方：A调用B、B再调用C的状况下。B机器的RpcContext会有如下的状况产生：在B调用C之前，RpcContext记录的是A调B的信息，在B调用C之后，RpcContext记录的是B调C的信息。比方：咱们想要获取到服务调用者的host相干信息，那么咱们能够在服务提供者中获取以后生产此服务的消费者的host信息，其代码如下所示： // 获取调用方的host信息String serverIP = RpcContext.getContext().getRemoteHost();二、Dubbo上下文携带的隐式参数attachment不晓得各位在开发的时候，有没有遇到一种须要额定传递给上游服务的参数（比方标识以后用户申请的jwt、记录分布式系统全链路跟踪的全局traceId）。当有这方面的需要时，咱们不可能批改办法的参数签名，这与业务耦合了。此时，可能就须要应用Dubbo的隐式参数attachment了。什么是attachment？能够把它认定为Dubbo协定中的一个扩大点。就有点相似于Http协定，咱们能够自定义申请头信息。而在Dubbo中，咱们也能够自定义RPC申请中的参数。举个例子：用户在执行下单这个业务，最终必定会通过后盾的订单服务、库存服务等服务。当初有个需要：在订单服务中，要明确晓得这个订单是哪个用户创立的。在库存服务中，要明确晓得这个商品最终是用户的哪个操作导致缩小的。整个需要外面有个外围：就是要晓得操作者是谁！假如我的项目用的是jwt技术来记录用户的状态，那么订单服务和库存服务就必须要晓得这个jwt字符串，将jwt解码后，就能晓得以后申请是由哪个用户发动的。在这样的一个场景中，应用dubbo的隐式参数能够达到上述的目标。实现的伪代码如下所示： RpcContext.getContext().setAttachment("jwt", "xxxxxxxxxxjwt字符串xxxxxxxx");// dubbo rpc 调用库存服务：缩小库存warehouseService.decrement();// dubbo rpc 调用订单服务：创立订单orderService.create();这里先总结下attachment在应用上的几个特点： 1、key名称不能以小驼峰命名，上游服务序列化后，会将key名称变成全小写（Dubbo 2.6.x版本，在2.7.x版本被修复了） 2、隐式参数设置后，仅在第一次RPC申请失效，后续的RPC申请将无奈获取到隐式参数 因为attachment有上述的两个特点，因而咱们很容易如下的两个谬误： 易犯谬误1易犯谬误2咱们在warehouseService.decrement()的上游服务中能顺利的从attachment中获取jwt参数，而在orderService.create()的上游服务中曾经无奈顺利的从attachment中获取jwt参数了在本例中，增加到attachment中的key为jwt，是ok的。但如果咱们把key设置成大驼峰的命名形式，比方：userJwt。在通过Dubbo的一系列解决后，在warehouseService.decrement()上游服务中的rpcContext对象中的attachment中的key曾经变成了userjwt，曾经无奈获取到key为jwt的参数了。三、筛选出最优的解决方案针对谬误1，咱们有三个实现计划，其对应的计划策略如下所示： 计划长处毛病计划1：在每一次发动RPC之前，都手动执行一次RpcContext.getContext().setAttachment("jwt", "xxxxxxxxxxjwt字符串xxxxxxxx");代码能解决问题，但不是最优计划减少编码的复杂度和代码的反复度。计划2：应用spring的aop 的before机制，在执行rpc发动近程服务之前，先把jwt放入到attachment中能解决问题dubbo的近程调用对象自身就很分量，当初再增加一层代理，不利于定位问题。计划3：应用Dubbo的filter机制，在对指定近程服务增加一层filter，filter的逻辑就是将jwt放入到attachment中去比拟好的一种解决方案，充分利用到了Dubbo框架本身提供的filter扩大。这也是比拟通用的解决方案，全链路追踪的traceId也是这么玩的。（举荐）代码浏览性不高，filter同aop一样，都是解耦的，不利于定位问题。针对谬误2，在不对源码进行扩大的状况下，最简略的形式就是批改key的命名形式，这里能够应用两种形式： 形式1参考Dubbo源码的org.apache.dubbo.common.constants.CommonConstants类中对增加到URL中的key的命令形式，多个单词用.做辨别形式2单词与单词间应用自定义的符号做分隔，比方_，#等符号。这种形式也能够辨别于key是本人增加的还是Dubbo框架自带的。四、总结避坑指南：有波及到隐式参数的代码改变时，肯定要多测试。若某个环节被疏忽，很容易造成生产事变如果你感觉我的文章有用的话，欢送点赞和关注。I'm a slow walker, but I never walk backwards

简介：该问题源于咱们想对 dubbo-go 的 module path 做一次变更，应用 dubbo.apache.org/dubbo-go/v3 替换之前的 github.com/apache/dubbo-go。 作者 | 董剑辉、盛傲飞 起源 | 阿里巴巴云原生公众号 问题背景 该问题源于咱们想对 dubbo-go 的 module path 做一次变更，应用 dubbo.apache.org/dubbo-go/v3 替换之前的 github.com/apache/dubbo-go。 首先，咱们做了门路映射，在 dubbo.apache.org 下搁置了一个 dubbogo/v3 文件，内容如下： <html> <head> <meta name="go-import" content="dubbo.apache.org/dubbo-go/v3 git <https://github.com/apache/dubbo-go>"> <meta name="go-source" content="dubbo.apache.org/dubbo-go/v3 git <https://github.com/apache/dubbo-go/tree/3.0{/dir}> <https://github.com/apache/dubbo-go/blob/3.0{/dir}/{file}#L{line}>"> <meta http-equiv="refresh" content="0; url=https://pkg.go.dev/dubbo.apache.org/dubbo-go/v3"> </head> <body> <p>Redirecting to <a href="<https://pkg.go.dev/dubbo.apache.org/dubbo-go/v3>">pkg.go.dev/dubbo.apache.org/dubbo-go/v3</a>...</p> </body></html> 其次，咱们批改了 go.mod 的 module 和对应的所有 import，并批改了所有子模块援用 dubbo-go 应用的 module 门路。 问题剖析 在做完上述的批改后，咱们提 PR 时，发现 CI 失败，通过进一步的日志排查，咱们确定是 CI 在跑集成测试时产生了谬误，具体的谬误提示信息如下： ...

前言大家好，明天开始给大家分享 — Dubbo 专题之 Dubbo 线程池模型。在后面上个章节中咱们探讨了 Dubbo SPI，理解了 Dubbo SPI 其本质是从 JDK 规范的 SPI (Service Provider Interface) 扩大点发现机制增强而来，同时解决了 Java 中 SPI 的一些缺点。以及咱们应用 Dubbo SPI 实现自定义能力的拓展。那本章节咱们要探讨的 Dubbo 线程模型也是基于 SPI 实现，那什么是线程模型呢？以及其在咱们的我的项目中有什么作用呢？那么咱们在本章节中进行探讨。上面就让咱们疾速开始吧！ 1. 线程模型简介小伙伴如果对 Servlet 相熟就晓得，从 Servlet 3.x 开始反对异步非阻塞模式。至于什么异步非阻塞后面我在后面的章节中有探讨小伙伴能够自行学习之前的文章。咱们通过一个拜访Web利用流程图简略阐明： 在下面的流程图中咱们能够看到第一个申请发动同步 Web 调用，而后 Web 再发动对第三方服务的调用，整个过程全链路是同步调用。第二个申请同样也是发动同步调用，然而在发动第三方调用的时候切换了线程(基于 Servlet 3.x 咱们不须要手动的创立线程来切换)。这么做的益处在于咱们能够用专门解决线程池去做业务解决或第三方服务的调用。那什么状况下咱们须要切换线程不应用主线程呢？如果事件处理的逻辑能迅速实现，并且不会发动新的 IO 申请，比方只是在内存中记个标识，则间接在 IO 线程上解决更快，因为缩小了线程池调度。但如果事件处理逻辑较慢，或者须要发动新的 IO 申请，比方须要查询数据库或其它服务调用时，则必须派发到线程池，否则 IO 线程阻塞，将导致不能接管其它申请。 2. 应用形式那在 Dubbo 中给咱们提供了通过不同的派发策略和不同的线程池配置的组合来应答不同的场景。配置形式如下： <dubbo:protocol name="dubbo" dispatcher="all" threadpool="fixed" threads="100" />上面咱们简略形容下dispatcher和threadpool的参数阐明： Dispatcherall 所有音讯都派发到线程池，包含申请，响应，连贯事件，断开事件，心跳等。（默认）direct 所有音讯都不派发到线程池，全副在 IO 线程上间接执行。message 只有申请响应音讯派发到线程池，其它连贯断开事件，心跳等音讯，间接在 IO 线程上执行。execution 只有申请音讯派发到线程池，不含响应，响应和其它连贯断开事件，心跳等音讯，间接在 IO 线程上执行。connection 在 IO 线程上，将连贯断开事件放入队列，有序一一执行，其它音讯派发到线程池。ThreadPoolfixed 固定大小线程池，启动时建设线程，不敞开，始终持有。(默认)cached 缓存线程池，闲暇一分钟主动删除，须要时重建。limited 可伸缩线程池，但池中的线程数只会增长不会膨胀。只增长不膨胀的目标是为了防止膨胀时忽然来了大流量引起的性能问题。eager 优先创立Worker线程池。在工作数量大于corePoolSize然而小于maximumPoolSize时，优先创立Worker来解决工作。当工作数量大于maximumPoolSize时，将工作放入阻塞队列中。阻塞队列充斥时抛出RejectedExecutionException。(相比于cached:cached在工作数量超过maximumPoolSize时间接抛出异样而不是将工作放入阻塞队列)3. 应用场景通过后面的介绍咱们应该明确咱们为什么须要切换线程，遵循一个很简略的准则：如果咱们解决的工作须要操作新的 IO 或者解决工作须要很长的工夫那么咱们就能够把这部分工作放到咱们的工作线程池去解决。那么咱们简略的总结下在工作常遇到的场景： ...

前言大家好，明天开始给大家分享 — Dubbo 专题之 Dubbo 服务在线测试。在前一个章节中咱们介绍了 Dubbo 中的服务治理，同时咱们理解到 Dubbo 为咱们提供了一些罕用的服务治理能力包含：调节路由、标签路由、黑白名单、动静配置、负载平衡等等。咱们也学习到怎么应用 Dubbo Admin 控制台给咱们的分布式服务进行服务治理。那么在本章节咱们会次要探讨 Dubbo Admin 为咱们提供一种在线调用服务的能力，咱们能够利用这种形式进行服务的在线测试而不须要编写咱们的单元测试用例。那上面就让咱们疾速开始吧！ 1. 服务在线测试简介在 Dubbo Admin 中为咱们提供一种能够在控制台进行近程服务调用的能力，其实现原理就是利用了咱们 Dubbo 提供的泛化调用在不须要 jar 包依赖的状况下对近程服务进行调用。各位小伙伴能够参考咱们后面章节《Dubbo 泛化援用》中对泛化援用的探讨，其外围原理是利用服务的元数据进行近程调用，外围API 为GenericService。 2. 示例演示上面咱们就开始咱们的服务在线测试演示。首先咱们创立一个服务提供方，我的项目构造如下： 因为这里只须要服务提供者提供服务即可，而在咱们的 Dubbo Admin 中调用服务提供方，所有这里不须要生产端。上面咱们看看定义的接口代码： /** * @author <a href="http://youngitman.tech">青年IT男</a> * @version v1.0.0 * @className BookService * @description * @JunitTest: {@link } * @date 2020-10-24 13:29 **/public interface BookFacade { //查问所有图书 List<Book> queryAll(); //依据申请参数过滤图书 default List<Book> queryByName(@NotNull RequestParameter request) { return Lists.newArrayList(); }}3. 服务在线测试 上面咱们开始 Dubbo Admin 的演示，首先咱们找到应用的入口： ...

简介： 该问题源于咱们想对 dubbo-go 的 module path 做一次变更，应用 dubbo.apache.org/dubbo-go/v3 替换之前的 github.com/apache/dubbo-go。 作者 | 董剑辉、盛傲飞起源 | 阿里巴巴云原生公众号 问题背景该问题源于咱们想对 dubbo-go 的 module path 做一次变更，应用 dubbo.apache.org/dubbo-go/v3 替换之前的 github.com/apache/dubbo-go。首先，咱们做了门路映射，在 dubbo.apache.org 下搁置了一个 dubbogo/v3 文件，内容如下： <html> <head> <meta name="go-import" content="dubbo.apache.org/dubbo-go/v3 git <https://github.com/apache/dubbo-go>"> <meta name="go-source" content="dubbo.apache.org/dubbo-go/v3 git <https://github.com/apache/dubbo-go/tree/3.0{/dir}> <https://github.com/apache/dubbo-go/blob/3.0{/dir}/{file}#L{line}>"> <meta http-equiv="refresh" content="0; url=https://pkg.go.dev/dubbo.apache.org/dubbo-go/v3"> </head> <body> <p>Redirecting to <a href="<https://pkg.go.dev/dubbo.apache.org/dubbo-go/v3>">pkg.go.dev/dubbo.apache.org/dubbo-go/v3</a>...</p> </body></html>其次，咱们批改了 go.mod 的 module 和对应的所有 import，并批改了所有子模块援用 dubbo-go 应用的 module 门路。 问题剖析在做完上述的批改后，咱们提 PR 时，发现 CI 失败，通过进一步的日志排查，咱们确定是 CI 在跑集成测试时产生了谬误，具体的谬误提示信息如下： 这一段的执行逻辑是心愿利用 docker 对 dubbo-go 中的集成测试内容构建镜像，并启动容器进行测试，该镜像打包所用的 Dockerfile 门路在 github.com/apache/dubbo-go/test/integrate/dubbo/go-server 目录下，对照谬误日志的 STEP 标识，咱们能够定位到具体谬误产生上面的两个步骤： ...

前言大家好，明天开始给大家分享 — Dubbo 专题之 Dubbo 服务治理简介。在后面的章节中咱们介绍了 Dubbo 序列化，理解到了 Dubbo 中反对的序列化形式以及其实现原理。那么从这个章节开始咱们探讨服务治理相干话题，在这个章节中咱们会继介绍 Dubbo 服务治理。那么什么是服务治理呢？为什么须要服务治理？Dubbo 中提供哪些服务治理形式呢？。那就让咱们疾速开始吧！ 1. 架构演进首先在探讨咱们的服务治理之前咱们先看看咱们的软件架构设计的倒退。在传统的企业应用或桌面利用中，往往都是一个单体的利用架构设计如下图所示： 能够看到咱们的单体架构很简略一个 Java 过程和数据库就能够搞定。然而随着业务的倒退，咱们的业务逻辑越来越简单比方：咱们一个电商零碎次要蕴含用户零碎、商品零碎、订单零碎、评估零碎、领取零碎、门店治理等等，同时咱们的我的项目团队也可能随着业务增长不断扩大，那么如果咱们还在以前的单体零碎上进行开发可能会导致咱们的零碎代码变得无奈保护、一个零碎上线可能导致所有服务不能应用等等问题。那么这个时候咱们就应用多利用架构把性能在一个畛域的放在一个零碎中，同时利用之间不能间接的交互架构如下图所示： 咱们能够很直观的感触到当咱们的零碎倒退到一定量的时候咱们就须要对其进行拆分。当然下面的架构有一个显著的问题：利用零碎互相独立后独特的业务或代码无奈复用。那怎么解决这个问题呢？接下来就是咱们探讨的重点分布式系统架构，在大型的电商零碎中分布式架构是咱们经常应用的解决大数据量、高并发的无效解决方案，同时咱们在实际过程中经常遇到有很多的服务或者组件是共用的、用户需要变更快、疾速迭代等等问题。因而，咱们心愿拆散变与不变，从而使组件或服务失去更好的复用和更容易拓展和保护，下层的业务零碎更加灵便多变的业务场景组合底层通用的公共服务能力来实现复杂多变的利用场景。以下是简要的分布式架构图： 从图中咱们能够看出应用层调用底层公共的形象能力来组合成下层业务逻辑。 Tips：这里的架构短少接入网关零碎。2. 服务治理简介从下面介绍的架构演进中，咱们能够晓得当咱们零碎随着业务减少须要面对：高并发、大数据量、高吞吐量等问题。那么咱们就须要调整咱们的零碎架构使咱们的零碎服务化。服务治理次要作用是扭转运行时服务的行为和选址逻辑、达到限流、权重配置等目标。上面咱们通过服务化的特点、劣势和所面临的挑战维度来进行论述。 服务化的特点： 利用按业务拆分成服务各个服务均可独立部署服务可被多个利用共享服务之间能够通信服务化所带来的劣势： 架构上零碎更加清晰外围模块稳固，以服务组件为单位进行降级，防止了频繁公布带来的危险开发治理不便独自团队保护、工作明显，职责清晰业务复用、代码复用非常容易拓展服务化面临的挑战： 服务越来越多，配置管理简单服务间依赖关系简单服务之间的负载平衡服务的拓展服务监控服务降级服务鉴权服务上线与下线<script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script><ins class="adsbygoogle" style="display:block; text-align:center;" data-ad-layout="in-article" data-ad-format="fluid" data-ad-client="ca-pub-4279907681900931" data-ad-slot="6812672741"></ins><script> (adsbygoogle = window.adsbygoogle || []).push({});</script> 3. Dubbo 中服务治理以下来自于官网的 Dubbo 服务治理架构图： 其中 Dubbo 反对的服务治理能力包含：服务发现注册、服务监控、集群容错、负载平衡、黑白名单、标签路由、条件路由、权重调节、服务降级等等。 4. 小结在本大节中咱们次要学习了 Dubbo 中服务治理，别离从单体架构到分布式架构的演进进行剖析咱们为什么要一直的改良咱们的架构设计。同时也晓得了服务治理次要作用是扭转运行时服务的行为和选址逻辑、达到限流、权重配置等目标，其中 Dubbo 服务治理提供了：服务发现注册、服务监控、集群容错、负载平衡、黑白名单、标签路由、条件路由、权重调节等能力。 本节课程的重点如下： 了解 Dubbo 服务治理理解架构演进背景学习 Dubbo 中提供的服务治理形式作者集体从事金融行业，就任过易极付、思建科技、某网约车平台等重庆一流技术团队，目前就任于某银行负责对立领取零碎建设。本身对金融行业有强烈的喜好。同时也实际大数据、数据存储、自动化集成和部署、散布式微服务、响应式编程、人工智能等畛域。同时也热衷于技术分享创建公众号和博客站点对常识体系进行分享。关注公众号：青年IT男 获取最新技术文章推送！博客地址： http://youngitman.tech 微信公众号：

前言大家好，明天开始给大家分享 — Dubbo 专题之 Dubbo 路由规定之标签路由。在前一个章节中咱们介绍了 Dubbo 路由规定之标签路由，以及咱们也例举了常见的应用场景并且进行了源码解析来剖析其实现原理，同时晓得 Dubbo 中标签路由其本质上是通过过滤器对服务提供者列表进行规定的匹配，如果匹配不上则过滤掉服务提供者。那接下来咱们解析探讨标签路由，什么是标签路由呢？有什么应用场景呢？上面就让咱们疾速开始吧！ 1. 标签路由简介首先小伙伴能够通过《Dubbo 路由规定之条件路由》回归一下什么是路由规定？上面咱们次要探讨什么标签路由： 上图中咱们能够看到有两个机房别离是机房A、机房B，其中机房 A 只能拜访到 Service A 和 Service B ，而机房B 只能拜访到 Service C 和 Service D。要实现下面这种场景咱们就须要用到标签路由。从机房 A 发动的调用携带标签 TAG_A 拜访到 Service A 和 Service B，而从机房 B 发动的调用携带 TAG_B Service C 和 Service D 。那什么是标签路由呢？ 标签路由：以服务提供者利用为粒度配置路由规定，通过将某一个或多个服务的提供者划分到同一个分组，束缚流量只在指定分组中流转，从而实现流量隔离的目标，能够作为蓝绿公布、灰度公布等场景的能力根底。标签次要是指对Provider端利用实例的分组，目前有两种形式能够实现实例分组，别离是动静规定打标和动态规定打标，其中动静规定相较于动态规定优先级更高，而当两种规定同时存在且呈现抵触时，将以动静规定为准。2. 应用形式上面咱们简略的探讨下标签路由的应用形式： 2.1 标签路由动静规定打标，可随时在服务治理控制台下发标签归组规定 # demo-provider利用减少了两个标签分组tag1和tag2# tag1蕴含一个实例 127.0.0.1:20880# tag2蕴含一个实例 127.0.0.1:20881--- force: false runtime: true enabled: true key: demo-provider tags: - name: tag1 addresses: ["127.0.0.1:20880"] - name: tag2 addresses: ["127.0.0.1:20881"]动态打标 ...

简介：一说到参加开源我的项目奉献，个别大家的反馈都是代码级别的奉献，总感觉我的代码被社区合并了，我才算一个贡献者，这是一个常见的谬误认知。其实，在一个开源社区中有十分多的角色是 non-code contributor，一个开源社区中的很多要害职责被大家给疏忽了。 头图起源：https://opensource.guide/ 起源 | 阿里巴巴云原生公众号 只有奉献代码才算是参加开源我的项目社区奉献吗？一说到参加开源我的项目奉献，个别大家的反馈都是代码级别的奉献，总感觉我的代码被社区合并了，我才算一个贡献者，这是一个常见的谬误认知。其实，在一个开源社区中有十分多的角色是 non-code contributor，一个开源社区中的很多要害职责被大家给疏忽了。 组织流动也能够是奉献社区： 你能够像远在巴西库亚巴的 @fzamperin学习，为你喜爱的开源我的项目组织 workshop 或线下 meetup你还能够帮忙社区成员找到适合的线下峰会来提交技术议题……技术写作或者技术布道也是奉献社区： 为你喜爱的开源我的项目编写或者改良文档建设一个如何应用这个开源我的项目的 samples将文档翻译成其余语言，帮忙寰球开发者意识、应用该我的项目在本人的公众号或者博客分享应用该项目标指南和心得……设计和官网开发也是奉献社区： 重构开源我的项目官网来帮忙开发者更好的意识、应用该开源我的项目进行用户调研来更好地改善官网导航和目录构建一个 style guide 来帮忙该我的项目领有一个更对立、欠缺的视觉设计为该开源我的项目设计贴纸、T 恤等周边……Apache Dubbo Samples SIG 成立！samples 贡献者招募中Apache Dubbo 倒退到明天，曾经有 386 个贡献者，贡献者了包含代码、测试、用例、文档、应用倡议等丰盛内容。以后 Dubbo Core 有 2.7、3.0 两个十分沉闷的演进分支，其中 2.7 版本已被泛滥知名企业大规模的投入生产环境，如携程、工商银行、瓜子二手车等，而 3.0 分支也曾经在 3 月份公布了 preview 版本，依照打算在 6 月份第一个 3.0 可用版本也将正式公布。 内核的疾速演进与迭代促成了 Dubbo 的疾速倒退，同时，也给整个社区与 Committer 外围项目组带来新的挑战，这体现在： 新 Feature 相干的用户示例与文档缺失。用户对新版本个性如何应用无从通晓，翻阅代码成为惟一的路径。稳定性无奈失去充沛保障。在迭代过程中，单元测试、集成测试没有失去无效的补充，这导致测试覆盖度的降落和回归老本的低落，更蹩脚的是如果发版环节有些问题仍未被发现，则它们将不可避免的被带到用户应用环节。因为文档和用例的缺失，咱们不得不解决大量的 Issue、也包含其余的线上答疑，来解答用户的疑难，其中有一些是用户不晓得某个具体性能怎么用，有一些则是应用了不正确的配置形式导致不能失常运行；稳定性的降落则是对咱们本人以及 Dubbo 用户两方面的双重打击，继续的呈现问题会导致用户开始对 Dubbo 的版本公布失去信念，而对咱们这些外围维护者而言，破费大量精力实现的版本却给用户带来了困扰，这会让整个开发组也变得丧气。毫无疑问，对于 Dubbo 社区而言，解决以上问题成为了以后火烧眉毛的工作工作，这自身的重要性并不亚于大家所热衷的外围性能开发，但咱们也意识到，投入到其中须要破费肯定的精力，仅仅靠以后的几位维护者会十分吃力，尤其是思考到他们还须要兼顾整个 Dubbo 社区的运作。 在这样的背景下，咱们想到了招集来自社区的力量，明天在 Committer 核心成员的统一倡议下，Apache Dubbo 决定成立 Samples SIG（注：SIG  是 special interest group 的缩写，即兴趣小组），以期能改善以上的示例缺失、稳定性等问题。毫无疑问，这个 SIG 的运行须要宽广开发者的积极参与，当然，社区的外围开发者们也会踊跃的沉闷在其中。 ...

前言大家好，明天开始给大家分享 — Dubbo 专题之 Dubbo 令牌验证和优雅停机。在后面的章节中咱们介绍了 Dubbo 提早和粘滞连贯，理解了什么是提早和粘滞连贯以及日常的应用场景和实现原理，同时咱们晓得提早连贯是在应用实例对象的时候才创立通信连贯，粘滞连贯是尽可能的应用曾经创立的连贯，它们都有相似缩小连贯创立的作用。那本章节探讨一些轻松的话题就是令牌验证和优雅停机，那什么是令牌呢？以及它的作用是什么呢？。那就让咱们疾速开始吧！ 1. 令牌验证和优雅停机简介首先介绍什么是令牌，咱们通过一个生存中的小例子探讨什么是令牌。例如：咱们小伙伴常常坐火车出去玩那得首先购买火车票吧，而后咱们拿着火车票到安检口进行检票，检票胜利咱们就能够乘坐火车，如果检票失败则不能乘坐。这里的火车票就是咱们所说的令牌，只有拿到无效的令牌咱们才有权限或资格做后续的事件。 那什么是优雅停机呢？简略的了解就是在利用失常解决实现过后才退出利用，然而如果咱们通过kill -9 PID 等强制敞开指令，是不会执行优雅停机的，只有通过 kill PID 时，才会执行。在我的 Dubbo 是通过 JDK 的 ShutdownHook 来实现优雅停机。 2. 配置形式Dubbo 次要通过 XML 、注解、配置文件的形式配置： 2.1 令牌验证配置形式XML 配置形式： 全局设置<!--随机token令牌，应用UUID生成--><dubbo:provider token="true" />或者 <!--固定token令牌，相当于明码--><dubbo:provider token="123456" />服务级别设置<!--随机token令牌，应用UUID生成--><dubbo:service interface="com.muke.dubbocourse.common.api.BookFacade" token="true" />或者 <!--固定token令牌，相当于明码--><dubbo:service interface="com.muke.dubbocourse.common.api.BookFacade" token="123456" />注解形式：服务级别设置 @DubboService(token = "true")//@Service(token = "true")配置文件：全局配置 dubbo.provider.token=true2.2 优雅停机配置形式Dubbo 中次要通过属性配置和编码方式： 属性配置： # dubbo.propertiesdubbo.service.shutdown.wait=15000编码方式： DubboShutdownHook.destroyAll();Tips：应用 tomcat 等容器部署的场景，倡议通过扩大 ContextListener 等自行调用以下代码实现优雅停机3. 应用场景上面咱们看看 Dubbo 中令牌验证和优雅停机的应用场景。首先 Dubbo 中的场景形容是令牌验证在注册核心管制权限，以决定要不要下发令牌给消费者，能够避免消费者绕过注册核心拜访提供者，另外通过注册核心可灵便扭转受权形式，而不需批改或降级提供者。优雅停机在 Dubbo 中留神也是用于资源的回收解决等。上面咱们探讨罕用的应用场景： 令牌验证应用场景：从 Dubbo 令牌验证场景形容中咱们能够晓得能够通过令牌对消费者拜访接口进行受权拜访，即咱们能够通过自行拓展对注册信息进行动静调整以反对接口权限动静访问控制。优雅停机应用场景：在 Dubbo 利用退出时敞开底层的网络连接资源、缓存操作资源等等。4. 示例演示上面咱们以获取图书列表为例进行实例演示次要演示令牌验证。我的项目构造如下： 上面咱们看看服务生产端的配置dubbo-provider-xml.xml： ...

前言大家好，明天给大家分享 Dubbo 中的负载平衡。在前一个章节中咱们介绍 Dubbo提早服务裸露，咱们例举了常见的应用场景并且进行了源码解析来剖析其实现原理，同时咱们也晓得 Dubbo 提早服务裸露其外围就是通过一个 提早的调度器指定延迟时间后开始服务的裸露。很多小伙伴可能会好奇：咱们的服务部署根本都是集群模式，那服务生产端到底是调用哪一个服务提供者呢？都有哪些常见的服务抉择算法？为了揭开这些困惑，上面就让咱们疾速开始吧！ 1. 负载平衡简介那么什么是负载平衡呢？举个简略例子：在火车站购买火车票场景，咱们晓得节假日必定有十分多的人购买火车票，那么一个售票窗口卖票的话必定会排很长的队对用户来说体验十分差。那咱们能不能多减少几个售票窗口呢？是不是并行处理的能力马上失去进步了呢？没错！咱们在软件工程外面也是如此。比方 Nginx 经常用作软件负载平衡、F5用作硬件的负载均衡器等等。负载平衡算法能够无效进步零碎的并发解决能力、容错能力、一致性拜访等。如下图所示： 并发解决能力：通过横向拓展部署后端服务器数量做到服务扩容。容错能力：通过 Nginx 代理申请后端服务失败时转移调用其余存活服务。一致性拜访：在某些场景中指定路由到固定服务器，比方：特定服务器对登录用户 Session 进行缓存。2. Dubbo 反对负载平衡算法2.1 加权随机算法随机算法比较简单就和数学中的随机值选取一样，比方：1-100中随机抉择一个数字。在 Dubbo 中对随机算法减少了一个权重概念。举个例子： 服务列表权重Service0110Service0220Service0320Service0450从上表中咱们晓得4个服务权重别离是10、20、20、50，参考下图形容了随机抉择步骤： 首先咱们依据权重总和利用随机值获取初始 offset，假如 offset 值为 60。第一步循环服务列表第一个服务获取权重值 10 并应用 offset - weight 后果值为 50 > 0 继续执行从新赋值offset = 50。第二步循环服务列表第二个服务获取权重值 20 并应用 offset - weight 后果值为 30 > 0 继续执行。第三步循环服务列表第三个服务获取权重值 20 并应用 offset - weight 后果值为 10 > 0 继续执行。第四步循环服务列表第四个服务获取权重值 50 并应用 offset - weight 后果值为 -40 > 0 找到服务终止。Tips：此算法数据量越大数据调配越平均。2.1.1 算法实现：public class RandomLoadBalance extends AbstractLoadBalance { public static final String NAME = "random"; @Override protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) { // 服务总数 int length = invokers.size(); // 标识这些服务是否具备雷同的权重 boolean sameWeight = true; // 所有服务权重汇合 int[] weights = new int[length]; // 第一个服务权重 int firstWeight = getWeight(invokers.get(0), invocation); weights[0] = firstWeight; // 权重总和 int totalWeight = firstWeight; for (int i = 1; i < length; i++) { int weight = getWeight(invokers.get(i), invocation); // 记录权重 weights[i] = weight; // 共计权重值 totalWeight += weight; if (sameWeight && weight != firstWeight) { sameWeight = false; } } if (totalWeight > 0 && !sameWeight) { // 从（0,totalWeight]范畴抉择权重值 int offset = ThreadLocalRandom.current().nextInt(totalWeight); // 基于随机值返回服务 for (int i = 0; i < length; i++) { // offset = offset - weights[i] offset -= weights[i]; if (offset < 0) { return invokers.get(i); } } } // 如果权重值雷同或者totalWeight=0返回服务列表中随机服务 return invokers.get(ThreadLocalRandom.current().nextInt(length)); }}2.1.2 算法过程剖析：循环 invokers 服务列表计算出权重总和并标记出是否存在权重全副雷同状况。依据下面步骤的标记判断 invokers 服务列表所有服务权重是否雷同，雷同则随机返回服务列表中的一个服务。invokers 服务列表存在服务权重不雷同时，产生一个权重总和范畴内的一个大于0的随着整数赋值给 offset，而后循环拜访服务列表中的元素并且应用 offset 减去以后循环元素的权重值，如果差值大于0则赋值给以后的 offset 继续执行元素循环，当 offset 减去以后元素的权重大于零时进行循环，则以后查找的元素为抉择的服务。2.2 加权轮询算法轮询负载平衡算法顾名思义就是轮流调用服务。举个例子：假如4个申请通过 Nginx 代理转发到后端服务： ...

前言大家好，明天开始给大家分享 — Dubbo 专题之 Dubbo 提早服务裸露。在前一个章节中咱们介绍了 Dubbo Stub 和 Mock，咱们例举了常见的应用场景并且进行了源码解析来剖析其实现原理，同时咱们晓得 Dubbo Stub 和 Mock 都是基于对调用代理对象的包装实现的，这样能够为咱们在调用服务时做一些前置或后置解决工作。有的小伙伴可能会遇到这样的场景：在咱们的应用服务中有很多的本地缓存或者分布式缓存，这些缓存有可能须要加载一段时间那么在这个缓存加载过程中咱们心愿接口不要对外提供服务，那有没有一种机制让咱们对缓存加载实现后再裸露服务的机制呢？那么在本章节咱们会通过介绍 Dubbo 提早裸露服务来解决这个问题。那什么是提早服务裸露？以及提早服务裸露的实现原理是什么呢？上面就让咱们疾速开始吧！ 1. 提早服务裸露简介在以后咱们应用的Dubbo2.7.x版本中服务裸露机会是 Spring 容器启动实现并播送出事件 ApplicationContextEvent 时才进行对服务裸露。那这里所谓的提早裸露也就是在接管到 ApplicationContextEvent 事件后开始一个指定工夫的提早直到延迟时间到才开始对服务进行裸露。提早服务裸露的外围就是一个提早调度器，当延迟时间到就开始进行服务裸露。其配置参数为：delay="5000"，这里的工夫单位为毫秒。 Tips：其余的 Dubbo 版本的服务裸露可能有一些出入，读者以最新版本为主。2. 应用形式提早服务裸露能够通过 XML 或者注解的形式进行配置且指定的延迟时间单位为毫秒。 2.1 XML 配置形式 <!--提早1秒裸露Dubbo服务--> <dubbo:service interface="com.muke.dubbocourse.protocol.api.BookFacade" ref="bookFacade" delay="1000" />如果配置delay="-1"则示意在 Spring 容器初始化完后再裸露服务。 2.2 注解配置形式@DubboService(delay = 1000)public class BookFacadeImpl implements BookFacade {}应用@DubboService注解或@Service注解。delay = 1000示意提早1秒后才进行服务裸露。 3. 应用场景通过下面的提早服务裸露的简介咱们能够理解到：提早服务裸露其实就是针对须要裸露的服务配置一个固定的延迟时间，延迟时间一到立刻开始服务的裸露。那么咱们基于下面的服务裸露的时效性咱们简略的介绍一些工作中常应用的场景： 缓存预热：当咱们的裸露服务须要依赖一些静态数据，这些静态数据是通过加载数据库或者文件而后缓存到利用内存中。此时咱们能够通过在服务提早裸露的时间段内进行缓存预加载。依赖资源：假如咱们对外提供的服务须要依赖另外一个服务，而另外一个服务的裸露工夫比拟迟缓，那么咱们就能够把以后对外裸露的服务进行提早裸露，这样就能够缩小当调用依赖服务时呈现超时异样的状况。4. 示例演示咱们同样以获取图书列表为例来进行演示。我的项目构造如下： 因为提早服务裸露是配置服务提供端，所有咱们这里只看服务提供者的 XML 配置dubbo-provider-xml.xml： <?xml version="1.0" encoding="UTF-8"?><beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dubbo="http://dubbo.apache.org/schema/dubbo" xmlns="http://www.springframework.org/schema/beans" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-4.3.xsd http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd"> <dubbo:application name="demo-provider" metadata-type="remote"/> <!--注册核心--> <dubbo:registry address="zookeeper://127.0.0.1:2181"/> <bean id="bookFacade" class="com.muke.dubbocourse.delayexport.provider.BookFacadeImpl"/> <!--提早1秒裸露Dubbo服务--> <dubbo:service interface="com.muke.dubbocourse.common.api.BookFacade" ref="bookFacade" delay="1000"/></beans>下面的 XML 配置中次要配置了delay="1000"示意等 Spring 容器启动实现后服务提早1秒钟后才开始裸露服务。其注解配置也是相似就不再演示。 ...

前言大家好，明天开始给大家分享 — Dubbo 专题之 Dubbo Stub和Mock。在前一个章节中咱们介绍了 Dubbo 事件告诉，以及咱们也例举了常见的应用场景并且进行了源码解析来剖析其实现原理，同时晓得 Dubbo 中的事件告诉能够在某个服务调用之前、调用之后、异样产生时触发回调事件，咱们能够通过回调事件做一些额定的工作。咱们在 Dubbo 服务开发过程中可能遇到咱们调用的服务方并没有编写实现，那咱们是不是须要期待服务提供方开发实现咱们能力开始测试呢？那么在本章节咱们会通过介绍 Dubbo Stub 和 Mock来解决这个问题。那么什么是 Stub 和 Mock ？上面就让咱们疾速开始吧！ 1. 本地 Stub/Mock 简介在 Dubbo 中提供的 Stub 也可称为本地存根具备相似代理模式的性能，即把咱们调用的真正对象从新包装而后把包装对象提供给调用方，那么在调用真正的对象之前和之后咱们能够做相应解决逻辑。同理 Mock 也可称为本地假装和本地存根具备相似原理只是 Mock 针对产生RpcException异样或者咱们强制应用 Mock 形式才去调用 Mock 的实现。从上面咱们能够看进去Stub 和 Mock与代理对象关系： 从图中咱们能够看出的 Stub 和 Mock 都是实现同一个服务的接口，它们都是通过代理对象来调用近程裸露的服务，而 Mock 紧紧是在调用失败时会触发。 Tips：Mock 是 Stub 的一个子集，便于服务提供方在客户端执行容错逻辑，因常常须要在呈现 RpcException (比方网络失败，超时等)时进行容错，而在呈现业务异样(比方登录用户名明码谬误)时不须要容错，如果用 Stub，可能就须要捕捉并依赖 RpcException 类，而用 Mock 就能够不依赖 RpcException，因为它的约定就是只有呈现 RpcException 时才执行。2. 应用形式2.1 Stub 配置形式<dubbo:service interface="com.foo.BarService" stub="true" />或者 <dubbo:service interface="com.foo.BarService" stub="com.foo.BarServiceStub" />Stub 的实现类： /** * @author <a href="http://youngitman.tech">青年IT男</a> * @version v1.0.0 * @className BookFacadeStub * @description * @JunitTest: {@link } * @date 2020-11-15 23:43 **/public class BookFacadeStub implements BookFacade { //真正近程服务对象 private BookFacade bookFacade; //必须提供BookFacade签名的构造函数 public BookFacadeStub(BookFacade bookFacade){ this.bookFacade = bookFacade; } @Override public List<Book> queryAll() { try { //做一些前置解决 return bookFacade.queryAll(); } catch (Exception e) { // 产生异样做一些解决 return Lists.newArrayList(); }finally { //做一些后置解决 } }}2.2 Mock 配置形式<dubbo:reference interface="com.foo.BarService" mock="true" />或者 ...

简介： Dubbo 是一款轻量级的开源 Java 服务框架，是泛滥企业在建设分布式服务架构时的首选。中国工商银行自 2014 年开始摸索分布式架构转型工作，基于开源 Dubbo 自主研发了分布式服务平台。 作者 | 颜高飞起源 | 阿里巴巴云原生公众号 Dubbo 是一款轻量级的开源 Java 服务框架，是泛滥企业在建设分布式服务架构时的首选。中国工商银行自 2014 年开始摸索分布式架构转型工作，基于开源 Dubbo 自主研发了分布式服务平台。 Dubbo 框架在提供方生产方数量较小的服务规模下，运行稳固、性能良好。随着银行业务线上化、多样化、智能化的需要越来越旺盛，在可预感的将来，会呈现一个提供方为数千个、甚至上万个生产方提供服务的场景。 在如此高负载量下，若服务端程序设计不够良好，网络服务在解决数以万计的客户端连贯时、可能会呈现效率低下甚至齐全瘫痪的状况，即为 C10K 问题。那么，基于 Dubbo 的分布式服务平台是否应答简单的 C10K 场景？为此，咱们搭建了大规模连贯环境、模仿服务调用进行了一系列摸索和验证。 C10K 场景下 Dubbo 服务调用呈现大量交易失败1. 筹备环境应用 Dubbo2.5.9（默认 netty 版本为 3.2.5.Final）版本编写服务提供方和对应的服务生产方。提供方服务办法中无理论业务逻辑、仅 sleep 100ms；生产方侧配置服务超时工夫为 5s，每个生产方启动后每分钟调用1次服务。 筹备 1 台 8C16G 服务器以容器化形式部署一个服务提供方，筹备数百台 8C16G 服务器以容器化形式部署 7000 个服务生产方。 启动 Dubbo 监控核心，以监控服务调用状况。 2. 定制验证场景，察看验证后果 验证状况不尽如人意。C10K 场景下 Dubbo 服务调用存在超时失败的状况。 如果分布式服务调用耗时长，从服务生产方到服务提供方全链路节点都会长工夫占用线程池资源，减少了额定的性能损耗。而当服务调用并发突增时，很容易造成全链路节点梗塞，从而影响其余服务的调用，并进一步造成整个服务集群性能降落甚至整体不可用，导致产生雪崩。服务调用超时问题不可漠视。因而，针对该 C10K 场景下 Dubbo 服务调用超时失败状况咱们进行了详细分析。 C10K 场景问题剖析依据服务调用交易链路，咱们首先狐疑交易超时是因为提供方或生产方本身过程卡顿或网络存在提早导致的。 ...

前言大家好，明天开始给大家分享 — Dubbo 专题之 Dubbo 泛化援用。在前一个章节中咱们介绍了 Dubbo 中的参数验证以及应用场景。咱们在这个章节会持续介绍 Dubbo 泛化援用。那么什么是泛化援用呢？泛化援用有什么作用呢？上面就让我具体理解下吧！ 1. 泛化援用简介在后面的章节中咱们编写的 Dubbo 服务都是基于 API 接口，例如：com.muke.dubbocourse.common.api.BookFacade接口。咱们在日常开发中的步骤都是首先定义好裸露服务的 API 接口，而后把这个接口打包成 jar 提供给服务调用方。也就是说通常状况下咱们的服务调用方都会依赖咱们定义的 API 接口编程。那么在 Dubbo 中为咱们提供一种不须要依赖 API 接口的形式进行服务调用，这种形式就泛化援用。其示意类为GenericService 。 2. 应用形式在这里咱们次要介绍两种应用形式： 通过Spring应用泛化援用配置 XML 文件中的服务援用为generic="true" <dubbo:reference id="barService" interface="com.muke.dubbocourse.common.api.BookFacade" generic="true" />在代码中应用泛化调用 GenericService barService = (GenericService) applicationContext.getBean("bookFacade");Object result = barService.$invoke("queryAll", null, null);通过 Java API形式应用// 援用近程服务 ReferenceConfig<GenericService> reference = new ReferenceConfig<GenericService>(); // 弱类型接口名reference.setInterface("com.muke.dubbocourse.common.api.BookFacade"); reference.setVersion("0.0.1");// 申明为泛化接口 reference.setGeneric(true); // 用org.apache.dubbo.rpc.service.GenericService能够代替所有接口援用 GenericService genericService = reference.get(); // 如果返回实体对象将主动转成Map Object result = genericService.$invoke("queryByName",new String[]{"com.muke.dubbocourse.common.api.RequestParameter"}, new Object[]{parameter}); 3. 应用场景从泛化援用自身咱们能够晓得它是不须要 API 接口，也就是说泛化援用应用场景在服务提供方没有明确的 API 接口提供的状况下咱们都能够应用。通常用于框架集成，比方：实现一个 Dubbo 服务对外对立网，就可通过 GenericService 调用后端所有服务实现。 例如： ...

简介： dubbogo 社区近期公布了 dubbogo v1.5.6。该版本和 dubbo 2.7.8 对齐，提供了命令行工具，并提供了多种加载配置的形式。 作者 | 铁城 dubbo-go 社区 committer起源 | 阿里巴巴云原生公众号 dubbogo 社区近期公布了 dubbogo v1.5.6。该版本和 dubbo 2.7.8 对齐，提供了命令行工具，并提供了多种加载配置的形式。 相干改良切实太多，本文只列出相干重大 feature 和 性能晋升项。 1. 命令行工具 相熟dubbo 的敌人可能晓得 dubbo 反对 telnet 命令行在线调试。 本次公布也减少了 dubbo-go 的 cli 命令行工具，能够不便用户直连特定服务，通过编写 json 文件来定义传输构造和数据，发动调用进行在线调试，打印返回数据和耗时状况。 目前反对嵌套 struct，然而只反对单个参数的申请包和回包。数据类型因为须要在 json 中定义，只反对 golang 根本数据类型：字符串、整形、浮点。 社区后续会再发一篇文章，着重解说其原理和实现。相干 pr 为 https://github.com/apache/dub... dubbogo 最年老的 00 后 apache committer 李志信同学实现。 2. 代理实现扩大 重构 Proxy，增加 ImplementFunc 函数，容许我的项目对 Proxy 的代理进行从新实现。在应用 ProxyFactory 自定义注册的场景下，创立的 proxy.Proxy 也自定义实现，能够对返回数据进行批改。 ...

简介：3 月 20 日，Nacos 2.0 正式公布。Nacos 是阿里巴巴在 2018 年开源的一个更易于构建云原生利用的动静服务发现、配置管理和服务治理平台，也能够了解为微服务的注册核心 + 配置核心。 起源 | 阿里巴巴云原生公众号 3 月 20 日，Nacos 2.0 正式公布。Nacos 是阿里巴巴在 2018 年开源的一个更易于构建云原生利用的动静服务发现、配置管理和服务治理平台，也能够了解为微服务的注册核心 + 配置核心。 Nacos 目前在获取用户和开源社区运维上都获得了不错的问题。据 Nacos 联结创始人李艳林介绍，在一次 2245 人样本的开发者调研中显示，用户在注册核心的抉择上，抉择 Nacos 的开发者曾经达到了 49%。Nacos 在同畛域中曾经是国内开发者的首选。 此外 Nacos 开源社区的贡献者有 80% 以上来自阿里之外，奉献了 Nacos 的 20% 左右的代码，尤其 Nacos 多语言局部，全副由内部开发者奉献，并且放弃着不错的迭代速度。 而此次大降级，相较 1.x 版本，Nacos 2.0 性能晋升了 10 倍，内核进行了分层形象，并且实现插件扩大机制。将来 Nacos 打算通过集成支流 Sidecar 技术实现对 Nacos 多语言生态和云原生生态的整合。 为进一步理解 Nacos 是如何实现 2.0 架构大降级，实现 10 倍性能晋升的，以及 Nacos 社区经营教训和将来布局。OSCHINA 邀请 Nacos 联结创始人为咱们做了深刻解读。 ...

起源 | 阿里巴巴云原生公众号 3 月 20 日，Nacos 2.0 正式公布。Nacos 是阿里巴巴在 2018 年开源的一个更易于构建云原生利用的动静服务发现、配置管理和服务治理平台，也能够了解为微服务的注册核心 + 配置核心。 Nacos 目前在获取用户和开源社区运维上都获得了不错的问题。据 Nacos 联结创始人李艳林介绍，在一次 2245 人样本的开发者调研中显示，用户在注册核心的抉择上，抉择 Nacos 的开发者曾经达到了 49%。Nacos 在同畛域中曾经是国内开发者的首选。 此外 Nacos 开源社区的贡献者有 80% 以上来自阿里之外，奉献了 Nacos 的 20% 左右的代码，尤其 Nacos 多语言局部，全副由内部开发者奉献，并且放弃着不错的迭代速度。 而此次大降级，相较 1.x 版本，Nacos 2.0 性能晋升了 10 倍，内核进行了分层形象，并且实现插件扩大机制。将来 Nacos 打算通过集成支流 Sidecar 技术实现对 Nacos 多语言生态和云原生生态的整合。 为进一步理解 Nacos 是如何实现 2.0 架构大降级，实现 10 倍性能晋升的，以及 Nacos 社区经营教训和将来布局。OSCHINA 邀请 Nacos 联结创始人为咱们做了深刻解读。 Nacos 之于微服务 = Etcd 之于 K8sQ：首先介绍下本人吧，如集体背景、与 Nacos 我的项目是如何结缘的等等? A：大家好，我是李艳林，花名彦林，阿里云软负载团队负责人，Nacos 联结创始人。阿里云产品 MSE 创始人。 ...

Dubbo 简介大家好，从当初开始给大家分享 — Dubbo 专题。那么咱们为什么要学习 Dubbo 呢？Dubbo 是什么货色呢？对于刚接触或刚开始工作的小伙伴可能有很多疑难。首先 Dubbo 是咱们微服务开发的根底能力框架，在国内能够说是名列前茅的 RPC 框架，它不仅有残缺的服务治理能力、服务注册发现能力、容错能力、集群能力等等，而且还提供丰盛的可插拔的拓展能力。那什么是 RPC 以及市面上有哪些 RPC 框架呢？他们的性能劣势如何呢？那么通过咱们这个 Dubbo 专题系列进行具体的解说。 前言首先解释一下什么是 RPC ，RPC 其全称为 Remote Procedure Call 即近程过程调用。RPC 用于在近程计算机上调用函数过程(通常也能够在同一台机器上的过程之间应用它）。假如这个场景：服务 A、B 两个服务别离部署在两台服务器上，服务 A 须要调用服务 B 上的某个办法，此时因为这是在两台不同的服务器部署的服务，因而须要通过建设网络连接进行交互的这一过程就叫近程服务调用。 下图展现常见的两种 RPC 调用形式： RPC 跨过程调用：即在雷同操作系统中不同过程间的服务调用 PRC 跨零碎且跨过程调用：即在不同操作系统间且跨过程近程服务调用 从通信协定层面上讲能够分为： 基于 HTTP 协定： 1.1 SOAP (基于 XML 传输) 1.2 REST (基于 JSON 传输) 1.3 Hessian(基于二进制传输) 基于 TCP 协定： 2.1 Mina 2.2 Netty 从语言和平台层面可分为： Java平台 1.2 RMI .NET平台 2.1 Remoting ...

起源 | 阿里巴巴云原生公众号 Arthas Star 冲破 2.5 万啦 开源地址：_h_ttps://github.com/alibaba/arthas文档：https://arthas.aliyun.com/doc/随着微服务的风行，利用更加轻量和高效，然而带来的窘境是线上问题排查越来越简单艰难。传统的 Java 排查问题，须要重启利用再进行调试，然而重启利用之后现场会失落，问题难以复现。 因而自 2018 年 9 月，阿里巴巴开源了久经考验，深受开发者青睐的利用诊断利器 Arthas。 Arthas 通过翻新的字节码织入技术，能够在利用无需重启时，查看调用上下文，高效排查问题；联合火焰图，能够间接定位热点，发现性能瓶颈；通过字节码替换，实现在线热更新代码；同时反对黑屏化和白屏化诊断，能够连贯诊断大规模的集群。 在 2020 年 5 月时，咱们做了 Arthas Star 破 2 万的回顾： 精益求精 | 开源利用诊断利器 Arthas GitHub Star 冲破两万冬去春又来，转眼间一年过来了，Arthas 的 Star 数冲破 2.5 万了～ 上面来回顾 Arthas 去年的一些数据和工作。 Arthas 过来一年的数据1. Arthas Github Star 数冲破 2.5W 2. Arthas Github Contributors 数Arthas 的开源贡献者人数从 85 增长到 119，非常感谢他们的工作： 3. Arthas 注销公司数从 117 增长到 151 家过来一年，Arthas 在工商银行、中原银行、朴朴科技、贝壳找房、斗鱼等生产场景落地，欢送更多用户注销：https://github.com/alibaba/arthas/issues/111。 工商银行打造在线诊断平台的摸索与实际4. Arthas 在线教程学习人次：133,996，学习时长：51798小时人均体验时长 23 分钟以上。 ...

一、前言工欲善其事，必先利其器，后面通过几篇文章简略的介绍了如何应用Dubbo搭建一个简略的分布式系统，在接下来的的一段时间就来钻研Dubbo原理设计，本文作为原理设计的开篇先整体介绍下dubbo的架构。参考书籍： 《深度分析Apache Dubbo核心技术底细》京东连贯：https://item.jd.com/12769688....链接: https://pan.baidu.com/s/1WA7z... 提取码: rets 二、整体架构 image.png dubbo官网的这个图很简单，然而一开始没有必要深刻细节，上面咱们简略解说次要模块。 其中Service 和 Config 层为 API，对应服务提供方来说是应用ServiceConfig来代表一个要公布的服务配置对象，对应服务生产方来说ReferenceConfig代表了一个要生产的服务的配置对象。能够间接初始化配置类，也能够通过 spring 解析配置生成配置类。其它各层均为 SPI，SPI意味着上面各层都是组件化能够被替换的，这也是dubbo比拟好的一点，次要性能组件都能够插件化替换。dubbo加强了JDK中的SPI性能，在dubbo中其它各层都是应用扩大点进行提供服务的，dubbo加强的SPI减少了对扩大点 IoC 和 AOP 的反对，一个扩大点能够间接 setter 注入其它扩大点；并且不会一次性实例化扩大点的所有实现类，这防止了有扩大实现初始化很耗时，但如果没用上也加载，会很浪费资源的状况，加强的SPI是在具体用某一个实现类时候才进行实例化。后续会具体解说加强的SPI的实现原理。proxy 服务代理层：扩大接口为 ProxyFactory，dubbo实现的SPI次要JavassistProxyFactory（默认应用）和JdkProxyFactory，用来对服务提供方和服务生产方的服务进行代理。registry 注册核心层：封装服务地址的注册与发现，扩大接口为 Registry , RegistryService,Dubbo提供的扩大接口实现为ZookeeperRegistry，RedisRegistry，MulticastRegistry，DubboRegistry。扩大接口RegistryFactory，dubbo提供的扩大接口实现DubboRegistryFactory，DubboRegistryFactory，RedisRegistryFactory，ZookeeperRegistryFactory。cluster 路由层：封装多个提供者的路由及负载平衡，并桥接注册核心，扩大接口为 Cluster , Directory , Router ,LoadBalance。monitor 监控层：RPC 调用次数和调用工夫监控，扩大接口为 MonitorFactory , Monitor , MonitorService。protocol 近程调用层：封将 RPC 调用，扩大接口为 Protocol , Invoker , Exporter。exchange 信息替换层：封装申请响应模式，同步转异步，扩大接口为 Exchanger , ExchangeChannel ,ExchangeClient , ExchangeServertransport 网络传输层：形象 mina 和 netty 为对立接口扩大接口为 Channel , Transporter , Client , Server , Codecserialize 数据序列化层：可复用的一些工具，扩大接口为 Serialization ,ObjectInput , ObjectOutput , ThreadPool对于dubbo扩大点一个简略的例子：以扩大 Dubbo 的协定为例，在协定的实现 jar 包内搁置文本文件： METAINF/dubbo/com.alibaba.dubbo.rpc.Protocol ，内容为： ...

我在阿里实习做开源3月19日，初春的杭州，仍旧阴雨朦胧。透过 EFC 健身房的落地窗往外看，远处的楼宇、青山、参差的街道和稠密的车辆在水雾中若有若无。 午后的小憩时光，我拿了瓶咖啡回到工位，看着刚刚提交的PR通过了CI check，这或者是我人生中作为实习生的最初一天了。 成长的过程就是一直经验和体验的过程，一段又一段不同心情的开始和完结。我心愿三个月后，那个过了22岁生日的年轻人会如愿顺利拿到毕业证，再次出现在这里，我想那时的他肯定更相熟 java 了吧。 本科时光安分守己的大学生涯大略是是四年本科和三年硕士，而我属于校园的时光，只有两年半。在外实习到当初曾经整整一年了，从北京到深圳再到杭州，我也十分庆幸能领有这样的经验。 三段不同方向的实习，从最一开始在学校里的 GoOnline 在线 IDE 我的项目，让我对真正落地的开发我的项目充斥了向往；到 “互享“ 平台运维开发，让我对企业落地的日常开发运维流程有所理解；再到看点业务开发与需要上线，让我对领有百万用户的我的项目和技术充斥了激情；再到中间件研发，专一于云原生畛域的摸索和落地。 第一段实习是在北京图森科技，期间充斥了糊涂和纠结的，纠结于是抉择研发还是科研，糊涂与对从没见过的花里胡哨的各种工具的胆小，但很侥幸最终习惯了本人的抉择。 第二段实习是在深圳腾讯，整个过程充斥了刺激和危机感，危机来源于在社会上和技术上如何站住脚跟，惊险刺激于一连串从没料到的事件。很感激我能沉着看待遇到的各种突发状况，来自待业的压力，来自转正的压力，都不足以压垮一个有幻想的年轻人。至今仍旧思念过后率领我成长的导师 Steven【见链接 1】。 去年秋天开始在阿里团体中间件团队开始了我的第三段实习经验，相比前两次，这次实习难受了很多。当看清前路的时候，活的还是比拟滋润的，所要做的就是积攒、积淀和享受来自研发的高兴。很侥幸，实习经验中遇到的导师、共事和领导们都十分 nice，都能够遇到一起聊天交心、一起吃饭喝酒的前辈们，或者对于初入社会的年轻人，是一盏盏指向将来散发光满的灯塔。 dubbogo 社区拿到阿里实习 offer 后还未入职西厂前，便被大 Boss 引入了 dubbogo 社区，被告知实习的工作就是推动 dubbo-go 在外部的落地和 dubbo-go 3.0 的开发。这是一个有技术的组织，更是一个有人情味的中央。 时光到回到去年刚拿到 offer 的10月份，第一次将 dubbo-go clone 到本地，胜利实现了 RPC 调用，情绪是无比冲动的。因为这个场景生疏中带着相熟。第一次 bug fix，第一次奉献feature，写源码解读，再到前面成为 dubbo committer，投入 Dubbo-go 3.0 的奉献中。专属于年老 IT 工程师的高兴，莫非于让本人和我的项目一起成长。 在阿里的实习过程，2021 年的重大版本 dubbo-go 3.0 贯通了整条工夫线。从我尚未入职还在石家庄的时候，便开始一边在按摩店洗脚一边开周会接工作，到前面熟识了社区中的领导们、技术大佬们，很屡次被前辈的技术和精力所打动，说社区充斥了人情味毫不为过。 马上就要到了三月底，我也心愿 dubbo-go 3.0 能够成为实习过程中属于我的一份期末答卷，而 3.0 版本肯定不是起点，而是国内开源 RPC 框架倒退的过程所在，因为有了每一个阶段的翻新，才成就了在将来长河中的丰盛的云原生发展史。 比起我的项目自身，我更爱这种技术气氛： 很多技术人员能够凝聚在一起，各尽所长为了一个指标而致力；一种“有我在我的项目就在”的责任心；一种在贯彻于编码中的开源我的项目的谨严；一种团聚时能够高兴吹水和交换的默契。 就在上周六早晨，dubbogo 社区负责 dubbo-go-pixiu 我的项目的负责人铁城大哥，为了庆贺本人胜利从阿里外围公司转到盒马，招集了社区杭州的网友们胜利小聚。觥筹交错间从技术八卦到社区秘闻，无所不谈，并纷纷“讨伐”图中某位马上从杭州某 IoT 公司到职要投奔蚂蚁的大佬 ^_^。 ...

demo github 地址 0、docker 启动 zkdocker-compose.yml version: '3'services: zoo1: image: zookeeper restart: always hostname: zoo1 ports: - 2181:2181docker-compose up -d1、创立父 pom<?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.csp</groupId> <artifactId>dubbo-exam</artifactId> <packaging>pom</packaging> <version>1.0-SNAPSHOT</version> <modules> <module>dubbo-api</module> <module>dubbo-provider</module> <module>dubbo-consumer</module> </modules> <dependencyManagement> <dependencies> <dependency> <groupId>com.101tec</groupId> <artifactId>zkclient</artifactId> <version>0.10</version> </dependency> <dependency> <groupId>org.apache.zookeeper</groupId> <artifactId>zookeeper</artifactId> <version>3.4.13</version> <type>pom</type> <exclusions> <exclusion> <groupId>org.slf4j</groupId> <artifactId>slf4j-log4j12</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>org.apache.curator</groupId> <artifactId>curator-recipes</artifactId> <version>2.8.0</version> </dependency> <dependency> <groupId>org.apache.dubbo</groupId> <artifactId>dubbo-spring-boot-starter</artifactId> <version>2.7.7</version> <exclusions> <exclusion> <groupId>org.slf4j</groupId> <artifactId>slf4j-log4j12</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>org.apache.dubbo</groupId> <artifactId>dubbo</artifactId> <version>2.7.7</version> </dependency> <dependency> <groupId>org.apache.curator</groupId> <artifactId>curator-framework</artifactId> <version>4.0.1</version> </dependency> </dependencies> </dependencyManagement></project>2、创立 API maven 工程package com.csp.dubbo.demo;public interface TestApiService { String sayHello(String name);}3、创立 Provider maven 工程pom.xml ...

0、docker 启动 zkdocker-compose.yml version: '3'services: zoo1: image: zookeeper restart: always hostname: zoo1 ports: - 2181:2181docker-compose up -d1、创立父 pom<?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.csp</groupId> <artifactId>dubbo-exam</artifactId> <packaging>pom</packaging> <version>1.0-SNAPSHOT</version> <modules> <module>dubbo-api</module> <module>dubbo-provider</module> <module>dubbo-consumer</module> </modules> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.1.7.RELEASE</version> <relativePath/> <!-- lookup parent from repository --> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> <dependency> <groupId>org.apache.dubbo</groupId> <artifactId>dubbo-spring-boot-starter</artifactId> <version>2.7.7</version> <exclusions> <exclusion> <groupId>org.slf4j</groupId> <artifactId>slf4j-log4j12</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>org.apache.dubbo</groupId> <artifactId>dubbo</artifactId> <version>2.7.7</version> </dependency> <dependency> <groupId>org.apache.curator</groupId> <artifactId>curator-framework</artifactId> <version>4.0.1</version> </dependency> <dependency> <groupId>org.apache.curator</groupId> <artifactId>curator-recipes</artifactId> <version>2.8.0</version> </dependency> <dependency> <groupId>org.apache.zookeeper</groupId> <artifactId>zookeeper</artifactId> <version>3.4.13</version> <type>pom</type> <exclusions> <exclusion> <groupId>org.slf4j</groupId> <artifactId>slf4j-log4j12</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>com.101tec</groupId> <artifactId>zkclient</artifactId> <version>0.10</version> </dependency> </dependencies></project>2、创立 api maven 工程package com.csp.dubbo.demo;public interface TestApiService { String sayHello(String name);}3、创立服务提供者Application ...