微服务是SOA的一种升华，而dubbo是SOA的一种最佳实现（暂时这么理解）
需求的变化带动架构的演进：
随着服务增多，1) URL配置管理变得困难，F5硬件负载均衡单点压力愈来愈大。2) 服务间的依赖关系变得错综复杂。3) 服务的容量问题，服务需要多少机器支撑？什么时候该加机器？
这时候我们需要，1) 服务注册中心，动态注册和发现服务。2) 自动画出服务依赖关系图。3) 统计服务调用量和响应时间，动态调整权重。
dubbo服务治理应运而生！
一、架构
0. 服务容器负责启动，加载，运行服务提供者。
1. 服务提供者在启动时，向注册中心注册自己提供的服务。
2. 服务消费者在启动时，向注册中心订阅自己所需的服务。
3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，选另一台调用。
5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。