DUBBO框架学习起源背景•想象下这么个场景：有个做生活服务的APP，主要提供一些生活化的咨询信息，比如天气、新闻、个人三金账单、政府办事事项等等，那么把这些功能全部放入一个应用肯定是不现实的。按照分布式服务的设计理念，可能最终的结果是用户登录、注册相关的作为一个user应用，天气相关的一个weather应用，新闻资讯相关的一个news应用，账单相关的一个bill应用，政府办事相关的一个life应用，这样就被拆分成了若干个功能相对稳定的应用，同时应用之间通过RPC调用，共同构成了一个分布式服务框架。这种分布式服务架构在流量、服务数量相对小的时候足够满足实际需要，但是在服务数量越来越大、流量增大或者间断性流量出现峰值、服务间调用越来越复杂的情况下，这种架构就就很难再满足需要了。比如上述的APP这周搞推广注册送礼的活动，突然间登录、注册的操作暴增，此时负责处理相关业务的user应用负荷增加，出现响应慢、超时、宕机的情况，怎么办？按分布式服务框架，最简单直接的办法是增加user应用的实例、带宽等硬件资源，再在调用方或者Nginx端改改user应用相关的负载列表，重启over。等推广结束之后再改改负载列表，停掉增加的资源，重启over.......如此一来，反复地增加、删除、停止、启动，只要中间某一步做错，就会造成难以想象的错误。那么如何弹性、动态地计算所需资源，又如何动态地增加、删除资源，最大程度不影响业务流转，减少犯错误的几率，是一个新的课题。由此流动式的架构理念运用而生，而dubbo框架正是流动式计算架构的一种。简介•Dubbo是阿里旗下的一个弹性的分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。•Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的RPC实现服务的输出和输入功能，可以和Spring框架无缝集成。主要核心组件•Remoting:•网络通信框架，实现了sync-over-async和request-response消息机制.•RPC:•一个远程过程调用的抽象，支持负载均衡、容灾和集群功能•Registry:•服务目录框架用于服务的注册和服务事件发布和订阅DUBBO服务架构及调用流程•Dubbo架构图如下所示：DUBBO服务架构及调用流程•节点角色说明：•Provider:“暴露服务的服务提供方，称之为服务提供者”。•Consumer:“调用远程服务的服务消费方，称之为服务消费者”。•Registry:“服务注册与发现的注册中心，可选，称之为服务注册中心”。•Monitor:统计服务的调用次调和调用时间的监控中心，可选，“称之为服务监控中心”。•Container:服务运行容器。DUBBO服务架构及调用流程•调用流程：•0.服务容器负责启动、加载，运行Provider。•1.Provider在启动时，向Registry注册自己提供的服务，Registry缓存服务列表，并建立长连接心跳检测。•2.Consumer在启动时，向Registry订阅自己所需的服务，并建立长连接心跳检测。•3.Registry返回服务提供者地址列表给Consumer并缓存，如果服务有变更，Registry将基于长连接推送变更数据给Consumer并更新。•4.Consumer在使用服务时，基于软负载均衡算法，从提供者地址列表中，选一台Provider进行调用，如果调用失败，则切换到另一台调用。•5.Consumer和Provider，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到Monitor。特性•(1)连通性：•注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小•监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示•服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销•服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销•注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外•注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者•注册中心和监控中心全部宕机，不影响已运行的提供者和...
