Dubbo的架构

1. Container： 服务运行容器，负责加载、运行服务提供者。必须。
2. Provider： 暴露服务的服务提供方，会向注册中心注册自己提供的服务。必须。
3. Consumer： 调用远程服务的服务消费方，会向注册中心订阅自己所需的服务。必须。
4. Registry： 服务注册与发现的注册中心。注册中心会返回服务提供者地址列表给消费者。非必须。
5. Monitor： 统计服务的调用次数和调用时间的监控中心。服务消费者和提供者会定时发送统计数据到监控中心。 非必须。

关于Dubbo架构的一些自测小问题

服务提供者宕机后，注册中心会做什么？

1. 注册中心会立即推送事件通知消费者。

注册中心和监控中心都宕机的话，服务都会挂掉吗？

1. 不会。两者都宕机也不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表。注册中心和监控中心都是可选的，服务消费者可以直连服务提供者。

什么是负载均衡？

1. 系统中的某个服务的访问量特别大，我们将这个服务部署在了多台服务器上，当客户端发起请求的时候，多台服务器都可以处理这个请求。那么，如何正确选择处理该请求的服务器就很关键。假如，你就要一台服务器来处理该服务的请求，那该服务部署在多台服务器的意义就不复存在了。负载均衡就是为了避免单个服务器响应同一请求，容易造成服务器宕机、崩溃等问题

Dubbo 提供的负载均衡策略有哪些？

1. 默认为 random 随机调用。
2. 轮询调用，就是均匀地将流量打到各个机器上去
3. 加权轮询负载均衡。
4. 最少活跃调用策略，Dubbo 就认为谁的活跃数越少，谁的处理速度就越快，性能也越好，这样的话，我就优先把请求给活跃数少的服务提供者处理。
5. 一致性 Hash 策略，使相同参数请求总是发 到同一提供者，一台机器宕机，可以基于虚拟节点，分摊至其他提供者，避 免引起提供者的剧烈变动；

架构的演化