背景
单一应用架构 —-》 垂直应用架构 —-》 分布式架构 —-》 流动计算架构
随着互联网的发展，网站应用的规模越来越大，传统的单一，垂直架构已经无法承受，需要向分布式架构，流动计算架构发展，而这些需要一个治理系统来保证。
其中分布式架构是将核心的业务抽离处理，作为独立的服务，逐渐形成稳定的服务中心。此时，提高业务复及整合是分布式服务框架是关键。
需求
- 当服务越来越多的情况下，服务URL的配置变得越来越困难，硬件负载均衡器的压力会越来越大。
解决: 需要一个服务注册中心， 动态的注册和发现服务，是服务位置透明， 并通过消费方获取服务提供方列表，实现软负载，降低硬件负载均衡器的压力。 - 当服务间的依赖关心变得越来越复杂， 甚至分不清应用之间的启动顺序。
- 服务的调用量越来越大，服务容量的压力越来越重，这个时候该如何保证服务能够稳定的运行下去，该增加多少机器来支撑。
解决：统计服务每天的调用量，响应时间，作为容量规划的参考指标。另外可以动态的调整权重，将某台机器的权重增加，并在加大的过程中记录响应时间，知道响应时间到达阈值，记录此时的访问量，再以此访问量乘以机器数。
架构
节点角色说明
- Provider: 服务提供者，暴露服务。
- Customer：服务调用者，调用远程服务。
- Registry：注册中心，服务注册和服务发现。
- Monitor: 统计服务的调用次数和调用时间的监控中心。
- Container: 服务运行容器。
调用关系
- 服务容器负责启动，加载，运行服务提供者。
- 服务提供者在启动时，向注册中心注册自己提供的服务。
- 服务消费者在启动时，想注册中心订阅自己所需的服务。
- 注册中心向服务消费者返回提供者的地址列表，如果有变更，注册中心会基于长连接推送变更数据给消费者。
- 服务消费者从提供者的列表里，基于负载均衡算法，选择一台提供者进行调用，如果调用失败，则在选另一台调用。
- 服务消费者和提供者，在内存中的调用次数和调用时间，定时每分钟发送一次统计数据给监控中心。
连通性
- 注册中心，服务提供者，服务消费者三者之间为长连接，监控中心除外。
- 注册中心通过长连接感知提供者的存在，如果宕机，注册中心立即推送事件给服务消费者。
- 注册中心和监控中心都同时宕机，不影响已运行的提供者和消费者，消费者本地缓存了提供者的列表。
- 注册中心和监控中心都是可选的，服务消费者可以直连服务提供者。
健壮性
- 监控中心宕机不影响使用，只会丢失采样数据。
- 注册中心对等集群，任意一台宕机，都将自动切换。
- 服务提供者是无状态的，任意一台宕机，都不影响使用。
- 注册中心和监控中心都同时宕机，不影响已运行的提供者和消费者，消费者本地缓存了提供者的列表。
伸缩性
- 服务提供者无状态，可动态的增加机器部署实例，注册中心将新的服务提供者信息给到服务消费者。
- 注册中心为对等集群，所有客户端都可以发现新的注册中心。
dubbo的原理
- 服务启动时， 服务提供者和服务消费者根据配置信息， 连接到注册中心， 分别向注册中心注册服务和订阅服务
- 注册中心根据服务订阅关系， 向服务消费者返回服务生产者到信息， 同时服务消费者会将该信息缓存到本地， 如果信息有变更， 则会收到注册中心的推送
- 服务消费者会生成代理对象 同时根据负载均衡策略，选择其中一个服务生产者。
- 拿到代理对象， 通过代理对象向服务生产者进行接口调用
- 服务生产者收到请求后对数据进行反序列化， 通道代理调用具体的接口实现
