分布式服务--dubbo学习二

Dubbo的工作原理

1、轻量级java容器通过main函数初始化Spring上下文，根据服务提供者配置的XML文件将服务按照指定协议发布，完成服务的初始化工作。

2、服务提供者根据配置的服务注册中心地址链接服务注册中心，将服务提供者信息发布到服务注册中心。

3、消费者分局消费者XML配置文件的服务引用信息，链接注册中心，获取指定服务的地址等路由信息。

4、服务注册中心根据服务订阅关系，动态地指向消费者推送服务地址信息。

5、消费者调用远程服务时，根据路由策略，从本地的服务提供者地址列表中选择一个服务提供者，然后根据协议类型建立链路，跨进程调用服务提供者。

Dubbo架构的主要质量属性

1、连通性

①注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。

②监控中心服务统计各服务调用次数、调用时间等，统计先在内存汇总后每一分钟发送到监控中心服务器，并以报表展示。

③服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者 ，同事汇报调用时间到监控中心。

④注册中心、服务提供者、服务消费者三者之间均为长连接，监控中心除外。

⑤注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者。

⑥注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表。

⑦注册中心和监控中心都是可选的，服务消费者可以直连服务提供者。

2、健壮性

①监控中心宕机不影响使用，只是丢失部分采样数据。

②数据库宕机后，注册中心仍能通过缓存提供服务列表查询，但不能注册新的服务。

③注册中心对等集群，任意一台宕机后，将自动切换到另一台。

④注册中心全部宕机后，服务提供者和服务消费者仍能通过本地缓存通信。

⑥服务提供者无状态，任意一台宕机后不影响使用。

⑦服务提供者全部宕机后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复。

3、伸缩性

4、扩展性

绝大多数的分布式服务框架都推荐使用长连接进行内部通信，问。

1、相比于短连接，长连接更节省能源。如果发送一条消息就要创建链路、发起握手认证、关闭链路释放资源，会损耗大量的系统资源。长连接只在首次创建时或者链路断连重连才创建链路，链路创建成功之后服务提供者和服务消费者会通过业务消息和心跳维系链路，实现多消息服用同一个链路节省资源。

2、远程通信是常态，调用时延是关键指标：服务化之后，本地API调用变成了远程服务调用，大量本地方法演化成了跨进程通信，网络时延成为关键指标之一。相比于一次简单地服务调用，链路的重建通常耗时更多，这就会导致关键链路成的时延消耗远远大于服务调用本身的损耗，这对于大型的业务系统而言是无法接受的。

BIO与NIO

传统的BIO通信模型的服务端，通常由一个独立的Acceptor线程负责监听客户端的连接，它接收到客户端连接请求之后为每个客户端创建一个新的线程进行链路处理，处理完成之后，通过输出流返回应答给客户端，线程销毁，这就是典型的请求----应答模型。

此模型最大的问题就是缺乏弹性伸缩能力，当客户端并发访问量增加后，服务端的线程个数和客户端并发访问数成1:1的正比关系，由于线程是JAVA虚拟机非常宝贵的系统资源，当线程数膨胀之后，系统地性能将急剧下降，随着并发访问量的继续增大，系统会发生线程堆栈溢出、创建新线程失败等问题，并最终导致进程宕机或者僵死，不能对外提供服务。

NIO采用多路复用技术，一个多复用器Selector可以同时轮询多个Channel，由于JDK使用了epoll()代替传统的select实现，所以它并没有最大连接句柄1024/2048的限制。这也就意味着只需要一个县城负责Selector的轮询，就可以接入成千上万的客户端。

随着开源NIO框架的发展，越来越多的NIO框架。

比如Hadoop的RPC框架avro使用Netty作为底层通信框架，Storm也采用的是Netty。

Netty的优势：

①API使用简单，开发门槛低

②功能强大，预置了多种编码功能，支持多种主流协议

③定制能力强，可以通过与其他业界主流的NIO框架对比，Netty的性能最优。

④成熟、稳定、Netty修复了已经发现的所有JSK NIO BUG 业务开发人员不需要再为NIO的BUG而担心

⑤社区活跃、版本迭代周期短，发现的BUG可以被及时修复。同时，更多的新功能会加入