哈喽各位同学们大家好呀，小编今天带着开发者学院中课程“Dubbo分布式Order订单服务集群治理实战”干货总结来了~一起学习新课程吧！

课程链接以及图谱地址小编已经为大家指路了，搭配学习效果更佳????

课程名称：Dubbo分布式Order订单服务集群治理实战  

课程地址：https://developer.aliyun.com/learning/course/72/detail/1188

图谱名称：Alibaba Java 技术图谱

图谱地址：https://developer.aliyun.com/graph/java

Dubbo分布式Order订单服务集群治理实战

这节课模拟淘宝订单服务看如何使用Dubbo，之前提到Dubbo有许多不同协议，包括核心部分注册中心、客户端、服务端。注册中心要先上线，类似微服务架构，可以用zookeeper注册服务中心注册。 

 

一、Dubbo分布式集群架构 

实战开发首先安装JAVA开发环境，Dubbo需要加部分依赖，因为Dubbo没有快速创建的整套模板，需要自己构建服务端、注册中心等，客户端需要添加依赖进行开发。 

Dubbo是典型的分布式集群架构，首先理清楚整个项目的结构关系，消费者是订单的调度端，服务端是订单的增、删、改、查的服务，注册中心可以采用Zookeeper也可采用Nacos，具体项目可以继续扩展，如加入订单服务、支付服务、商品服务、账号服务等相关服务集群。目前先模拟一个服务，然后再到多个服务，单条线路跑通再做周边的服务开发。 

 

 

二、Dubbo分布式Order Service集群架构 

Dubbo模拟订单服务，有服务的订单就是服务端，需要host容器，可直接用自定义开发的控制台程序，需要在服务端定服务实现或服务接口，客户端要实现调度端或有代理对象。注意，还需要Zookeeper注册中心，可用内嵌的Zookeeper服务，也可用独立部署的Zookeeper服务。 

服务端的配置文件和客户端的配置文件要配置，服务端配置文件主要是：服务的端口、地址以及需要用哪些服务类型。客户端配置文件主要是：要调用的服务，注册中心的位置使用什么协议等关键参数。 

 

 

三、Dubbo订单服务集群调用实战 

模拟整个开发工作，API端是服务接口，客户端是客户端程序，客户端程序通用API代理，后面会调用后端真正的服务，真正的服务托管在Provider，是远程服务提供方，规范服务类型托管、运行、接受请求。 

如下图所示，Provider复制了4份，参考其中一个代码，是 main函数。 

  

启动后有自己的主进程去加载Bean，启动接受请求，会模拟起用Zookeeper，Zookeeper是嵌入式模拟注册中心。配置文件对应的是provider，看下核心参数： 

 

需要配置一下Zookeeper注册中心地址，使用的协议是Dubbo原生协议。然后配置服务，服务接口暴露给客户端使用。 

之前复制了4份provider，后面多启动几个服务，主要用于模拟集群，比如订单服务要起用3台、30台、300台，是一对多的过程。同理都自己的配置文件，因为在同一台机器上，配置不一样，端口要变， 在同一台机器上模拟各个不同端口。如下图所示，端口是“20893”： 

 

模拟几台机器一个集群，当这几台实例上线以后，都会Zookeeper进行注册，输入成功以后客户端进行调用。客户端调用订单服务，订单通过ID查询订单打印下返回字符串。具体项目可以通过JDBC等链接数据库。 

调度端里面是Dubbo的订单接口，模拟死循环，不断循环向客户端发请求。 

 

客户端代理对象是proxy，proxy起客户端代理作用，获取配置文件 Beanba的配置信息，调取方法：通过创建对象调取订单接口，根据ID模拟调用情况返回结果。循环调用实际上只起用了一个客户端，只不过每隔一秒调用一次。 

 

 

四、Dubbo订单服务集群 

模拟集群，调用服务端一台机器的效果，调用客户端，虽经过注册中心，但客户端经过注册中心调用后端。如下图所示，每隔一秒调后端，显示“20890”： 

 

说明这台服务器只有一台，再怎么轮询负载均衡都在一台机器。这时启动第二台服务器，逐步上线更多服务，如下图所示，有“20890”、“20891”，两台机器都被调用了。 

 

再上线第三台，客户端本身加载最新服务列表有时间，这里会有延迟，涉及服务上线和客户端发现最新的服务列表的过程，这个机制跟微服务架构很像。 

这里面第二台服务器已经出来，正常生产环境下，客户端和服务端通过注册中心解耦，可进行服务集群的灵活扩容，平时只有100台，但在双11的时候可以加到1000台。体现了Duddo相比传统简单架构，往更高级别灵活性弹性集群架构进行升级扩展，Duddo还有性能监控功能、生产环境的上线下线等功能。在当年背景下，阿里能够做出这种框架，并且在生产环境下大规模验证（双11验证）非常牛。 

分析整个Duddo架构，整个设计思想解决的问题，比当前的微服务架构协议更灵活、部署方式更灵活，架构更原生。现在Spring Cloud在全球范围内使用更广、生态文档更完善，但实际上Duddo体系更单一，功能更丰富，性能更高。Duddo的并发性一定比Spring Cloud高，Duddo可以灵活的在局域网和公网之间协议切换。 

现在Duddo结合阿里其他框架，逐步做分布式大规模集群治理生态的完善工作，虽然有些已经开始对接Spring Cloud微服务，但并不是重点。严格来说，Spring Cloud体系里面的协议，只是Duddo的一种，Duddo后面会做的越来越好Duddo3.0版本在做的云原生、服务治理、安全与性能监控等模式支持都非常优秀。