转载:https://blog.csdn.net/u012453843/article/details/65937993
Dobbo的架构,第0步是服务提供者的发布,provider的发布需要用到容器,我们的spring便是专门用来做容器的,因此服务提供者的发布需要用到spring。
第1步是进行注册,就是说服务提供者在发布之后,要在dubbo的注册管理中心进行注册,扮演Registry(注册中心的最好是zookeeper,其次可以选择 redis),这样注册中心便知道有哪些服务可供消费者使用了。第2步是消费者要调用服务,但是它是不知道有哪些服务可供调用的,因此它需要先到注册中心进行询问,查询一下是否有自己想要调用的服务,注册中心查找之后发现有匹配的服务可供调用,便会向消费者返回可供调用的服务的IP和端口号。消费者拿到IP和端口号之后,便不再需要经过注册中心,直接就可以访问服务了(这就是第4步),第5步是指dobbo想要监测都是哪些消费者调用了哪些服务,调用了多少次,这样便于管理。
上图的节点角色说明:
Provider:暴露服务的服务提供方。
Consumer:调用远程服务的服务消费方。
Registry:服务注册与发现的注册中心。
Monitor:统计服务的调用次数和调用时间的监控中心。
Container:服务运行容器。
调用关系说明:
0.服务容器负责启动、加载,运行服务提供者。
1.服务提供者在启动时,向注册中心注册自己提供的服务。
2.服务消费者在启动时,向注册中心订阅自己所需的服务。
3.注册中心返回服务提供者地址列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者。
4.服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用。
5.服务消费者和服务提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心。