标签：逻辑 可视化 image directory 监控 计数 alt 多项目 同步
1）：前言
随着互联网的发展，网站应用的规模不断扩大，软件架构也在不断演进。
单一应用架构：
当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。
此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。
垂直应用架构：
当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。
此时，用于加速前端页面开发的Web框架(MVC)是关键。
分布式服务架构：
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。
此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。
流动计算架构：
当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。
此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。
在分布式服务中，各应用之间需要实现远程通信，有哪些方案呢？
1、Webservice：基于Soap协议，效率不高。项目中不推荐使用。
2、使用Restful形式的服务：Http+Json，很多项目中应用。如果服务太多，服务之间调用关系混乱，需要治理服务。
3、使用Dubbo。使用rpc协议进行远程调用，直接使用socket通信。传输效率高，并且可以统计出系统之间的调用关系、调用次数。
除此之外，Dubbo还是资源调度和治理中心的管理工具。
2）：Dubbo是什么
Dubbo是阿里巴巴开源的一款高性能、轻量级、基于Java的RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。
特征：
1、基于透明接口的RPC
2、智能负载均衡
3、自动服务注册和发现
4、可扩展性高
5、运行时流量路由
6、可视化的服务治理
3）：Dubbo总体架构 调用流程
节点角色说明：
Provider: 暴露服务的服务提供方。
Consumer: 调用远程服务的服务消费方。
Registry: 服务注册与发现的注册中心。
Monitor: 统计服务的调用次调和调用时间的监控中心。
Container: 服务运行容器。
调用关系说明：
0. 服务容器负责启动，加载，运行服务提供者。
1. 服务提供者在启动时，向注册中心注册自己提供的服务。
2. 服务消费者在启动时，向注册中心订阅自己所需的服务。
3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
4）：Dubbo 整体设计
主要摘自官方文档《dubbo-dev-book.pdf》
图例说明：
图中左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口，位于中轴线上的为双方都用到的接口。
图中从下至上分为十层，各层均为单向依赖，右边的黑色箭头代表层之间的依赖关系，每一层都可以剥离上层被复用，其中，Service 和 Config 层为 API，其它各层均为 SPI。
图中绿色小块的为扩展接口，蓝色小块为实现类，图中只显示用于关联各层的实现类。
图中蓝色虚线为初始化过程，即启动时组装链，红色实线为方法调用过程，即运行时调时链，紫色三角箭头为继承，可以把子类看作父类的同一个节点，线上的文字为调用的方法。
各层说明：
config 配置层：对外配置接口，以 ServiceConfig , ReferenceConfig为中心，可以直接初始化配置类，也可以通过 spring 解析配置生成配置类
proxy 服务代理层：服务接口透明代理，生成服务的客户端 Stub 和服务器端Skeleton, 以 ServiceProxy 为中心，扩展接口为 ProxyFactory
registry 注册中心层：封装服务地址的注册与发现，以服务 URL 为中心，扩展接口为 RegistryFactory , Registry , RegistryService
cluster 路由层：封装多个提供者的路由及负载均衡，并桥接注册中心，以Invoker 为中心，扩展接口为 Cluster , Directory , Router ,LoadBalance
monitor 监控层：RPC 调用次数和调用时间监控，以 Statistics 为中心，扩展接口为 MonitorFactory , Monitor , MonitorService
protocol 远程调用层：封将 RPC 调用，以 Invocation , Result 为中心，扩展接口为 Protocol , Invoker , Exporter
exchange 信息交换层：封装请求响应模式，同步转异步，以 Request ,Response 为中心，扩展接口为 Exchanger , ExchangeChannel ,ExchangeClient , ExchangeServer
transport 网络传输层：抽象 mina 和 netty 为统一接口，以 Message 为中心，扩展接口为 Channel , Transporter , Client , Server , Codec
serialize 数据序列化层：可复用的一些工具，扩展接口为 Serialization ,ObjectInput , ObjectOutput , ThreadPool
关系说明：
1）：在 RPC 中，Protocol 是核心层，也就是只要有 Protocol + Invoker + Exporter就可以完成非透明的 RPC 调用，然后在 Invoker 的主过程上 Filter 拦截点。
2）：图中的 Consumer 和 Provider 是抽象概念，只是想让看图者更直观的了解哪些类分属于客户端与服务器端，
不用 Client 和 Server 的原因是 Dubbo 在很多场景下都使用 Provider, Consumer, Registry, Monitor 划分逻辑拓普节点，保持统一概念。
3）：而 Cluster 是外围概念，所以 Cluster 的目的是将多个 Invoker 伪装成一个Invoker，这样其它人只要关注 Protocol 层 Invoker 即可，加上 Cluster 或者去掉 Cluster 对其它层都不会造成影响，
因为只有一个提供者时，是不需要Cluster 的。
4）：Proxy 层封装了所有接口的透明化代理，而在其它层都以 Invoker 为中心，只有到了暴露给用户使用时，才用 Proxy 将 Invoker 转成接口，或将接口实现转成 Invoker，
也就是去掉 Proxy 层 RPC 是可以 Run 的，只是不那么透明，不那么看起来像调本地服务一样调远程服务。
5）：而 Remoting 实现是 Dubbo 协议的实现，如果你选择 RMI 协议，整个Remoting 都不会用上，Remoting 内部再划为 Transport 传输层和 Exchange信息交换层，
Transport 层只负责单向消息传输，是对 Mina, Netty, Grizzly 的抽象，它也可以扩展 UDP 传输，而 Exchange 层是在传输层之上封装了Request-Response 语义。
6）：Registry 和 Monitor 实际上不算一层，而是一个独立的节点，只是为了全局概览，用层的方式画在一起。
引文：感谢大牛分享 点我进入传送门
标签：逻辑 可视化 image directory 监控 计数 alt 多项目 同步
原文地址：https://www.cnblogs.com/codingmode/p/12706662.html
