怎样用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版本在做的云原生、服务治理、安全与性能监控等模式支持都非常优秀。