详解分布式架构与dubbo原理

分布式与dubbo

分布式

分布式系统演化

1. 传统应用为单服务器应用，应用与数据库都在同一台服务器，服务器压力大
2. 增加数据库服务器（已经是一种分布式系统架构了）
3. 增加本地缓存（效果有限），增加分布式缓存服务器，减轻操作数据库压力
4. 在服务器前增加nginx做负载均衡，应用服务器横向拓展（集群）
5. 单个数据库服务器压力依旧大，做服务器主从复制
6. 在进入niginx做分发前，请求达到时间不同，如果离服务器的网络节点越近请求越快到达，那么可以做CDN加速，保持更大范围的负载均衡
7. 分布式数据库，不同应用模块专门对应一个数据库服务器
8. 引入Nosql服务器,性能更高

分布式和集群

• 分布式是相对于系统架构来说的，更像是一个系统的整体设计。在一个系统中，通常系统业务比较复杂，那么可以划分不同的模块交给不同小组完成，每个小组都会有自己对应的服务比如订单服务，不同地服务会部署在不同地服务器中，每个应用服务器又会对应相应的分布式数据库集群。（不同的服务之间可能出现调用或者彼此依赖的情况，因为此时服务都部署在不同服务器，如何进行调用？这样rpc远程调用就出来了，一些rpc远程调用框架比如dubbo,spring cloud等，除了进行rpc远程服务调用之外dubbo还提供了一套完整的微服务解决方案，包括做负载均衡，熔断等功能）。分布式更像是对一个系统体系的划分，包含分布式DB,分布式cache,分布式文件，监控管理等，这样一个系统会被划分成不同的模块

• 集群的概念是相较于高并发而提出的，通常在分布式系统中，有些时候应用服务器只有一台无法满足高的访问量和并发量，因此可以搭建服务器集群，把压力分散到多台服务器上；

二者区别：

1. 集群是个物理形态，分布式是个工作方式。
2. 只要是一堆机器，就可以叫集群，他们是不是一起协作着干活，这个谁也不知道；一个程序或系统，只要运行在不同的机器上，就可以叫分布式
3. 集群一般是物理集中、统一管理的，而分布式系统则不强调这一点，分布式是避免中心化，如果一个系统所有服务都在一台中心节点，那么中心节点宕机，这个系统就挂了，系统稳定性太差
4. 集群可能运行着一个或多个分布式系统，也可能根本没有运行分布式系统；分布式系统可能运行在一个集群上，也可能运行在不属于一个集群的多台（2台也算多台）机器上。
5. “分头做事”与“一堆人”的区别；回想厨师分工案例

为什么使用分布式

1. 从开发模式上，分布式系统更方便于团队开发，降低不同模块之间的耦合性，提高开发效率
2. 从系统稳定性上，分布式系统稳定性更好，一个节点挂掉，对整个系统影响较小
3. 从性能上看，单台机器无法承载高访问量或者处理很慢，希望通过使用多台机器来提高系统的负载能力

rpc远程调用

• rpc协议
  RPC（Remote Procedure Call Protocol）——远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务。就是在网络中调用其它服务器上的服务

• 组成部分

1. 网络传输协议：http，tcp（推荐使用tcp）；dubbo是基于tcp也就是socket编程实现的，spring cloud 是基于http实现
2. 序列化和反序列化：可以使用Java原生的序列化和反序列化，也可以使用高性能序列化/反序列化工具，如Hessian，FST等，还可以使用表单序列化。

• 底层原理
  RPC协议的底层原理，就是对象的序列化、反序列化以及序列化后数据的传输。

• 实现细节（涉及到动态代理，socket,反射）
  需求：公共api中存有共同的User和IuserService,服务消费者和服务生产者都依赖于公共api,现在client想rpc调用从生产者拿到指定id的user

1. client端通过动态代理创建出IUserService的动态代理类，在动态代理中写业务逻辑
2. 定义协议内容会把服务接口(IUserService),方法名getById,方法参数(id=1)序列化成为二进制数据，然后通过socket编程指定生产者那边服务的ip以及端口号，然后通过socket像服务端发起请求
3. 服务生产者拿到传来的数据,首先通过spring中的getBeanOfType拿到对应的那个service,然后通过反射调用方法并执行（就是调用业务逻辑查询数据库），把获得的对象序列化二进制数据再通过socket响应给调用者
4. 服务消费者拿到返回的二进制数据通过反序列化拿到对应的user
   以上就是dubbo中进行rpc远程调用的原理

TCP/IP协议族划分的网络与telnet

• 常见的四层协议
  数据链路层：ARP,RARP
  网络层： IP,ICMP,IGMP
  传输层：TCP ,UDP,UGP
  应用层：Telnet,FTP,SMTP,SNMP，http

• telnet
  是TCP/IP协议族中的一员，属于应用层协议，是Internet远程登录服务器的标准协议和主要方式,telnet可以用来查看某个端口是否可访问。
  使用telnet服务目的：
  1）建立与远程主机的TCP连接。默认端口为23号端口，如果远程主机上的Telnet服务器软件一直在这个端口上侦听到连接请求，则这个连接便会建立起来。
  2）以终端方式为用户提供人机界面。
  3）将用户输入的信息通过telnet协议传送给远程主机。
  4）接受远程主机发送来的信息，并经过适当的转换显示在用户计算机的屏幕上

• 在我们的应用中如何使用？
  比如dubbo中启动一个服务生产者，我们就可以通过telnet与它建立连接并传输数据

• 常用指令
  访问dubbo中启的某个服务： telnet 192.168.99.1 20880
  ls：显示服务列表；
  ls -l：显示详细服务列表；
  ps：显示端口信息；
  ps -l：显示服务地址列表信息；
  invoke：执行dubbo服务；
  exit：退出telnet；

注册中心

• 在我们应用中，其实也可以直接使用消费者rpc远程调用生产者服务，但是这样管理很不方便，生产者增加了服务无法动态的通知消费者，使用注册中心进行统一管理，即便新增服务，注册中心也会及时把信息告知消费者
  主要作用： 1.服务端服务的注册和客户端服务的发现 2、提高系统的可用性 3、提高系统的可伸缩性 4、集中管理服务 ；
  常见的注册中心：zookeeper，eurake，Redis；

• zookeeper
  ZooKeeper 是一个高可用的分布式数据管理系统协调框架,zookeeper应用场景如下：
  zookeeper的节点数至少三个，而且最好为奇数个，更节省资源。因为leader选举，要求 可用节点数量 > 总节点数量/2

1. 数据发布与订阅（配置中心），每次有新的发布可以及时的通知订阅的客户端进行更新
2. 做软负载均衡，针对生产者和消费者都可以做负载均衡。因为在分布式系统中，服务提供方可能会部署多份，而消费者去消费哪一个，就是由zookeeper的负载均衡来做抉择
3. ZooKeeper 中特有 watcher 注册不异步通知机制，能够很好的实现分布式环境下丌同系统乊间的通知不协调，实现对数据变更的实时处理
4. 为什么搭建zookeeper集群（至少三个）？防止单点故障，一个注册中心挂掉，其余的注册中心会通过master选举选出新的leader,其余的为follower

补充：服务器负载均衡有三大基本Feature：负载均衡算法，健康检查和会话保持
常见负载均衡算法:
1. 轮询：将请求顺序循环地发到每个服务器。当其中某个服务器发生故障，AX就把其从顺序循环队列中拿出，不参加下一次的轮询，直到其恢复正常。
2. 比率（权重）：给每个服务器分配一个加权值为比例，根椐这个比例，把用户的请求分配到每个服务器
3. 优先权：给所有服务器分组，给每个组定义优先权，将用户的请求分配给优先级最高的服务器组（在同一组内，采用预先设定的轮询或比率算法，分配用户的请求）
4. 最少连接数：AX会记录当前每台服务器或者服务端口上的连接数，新的连接将传递给连接数最少的服务器
5. 最快响应时间： 新的连接传递给那些响应最快的服务器
6. 哈希算法：将客户端的源地址，端口进行哈希运算，根据运算的结果转发给一台服务器进行处理，当其中某个服务器发生故障，就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。

健康检查：
健康检查用于检查服务器开放的各种服务的可用状态。负载均衡设备一般会配置各种健康检查方法，例如Ping，TCP，UDP，HTTP，FTP，DNS等

会话保持：
会话保持用于保持会话的连续性和一致性，由于服务器之间很难做到实时同步用户访问信息，这就要求把用户的前后访问会话保持到一台服务器上来处理

dubbo

• 概念
  是rpc远程调用的一个框架，是微服务领域的一套完整的解决方案，dubbo是阿里的!!!
  微服务的核心要素在于服务的发现、注册、路由、熔断、降级、分布式配置

• dubbo执行流程
  首先启动注册中心，然后启动服务生产者（生产者运行于容器之上），生产者会向注册中心注册。启动消费者，消费者也会注册到注册中心，然后消费者会从注册中心订阅服务，把服务列表下载到本地，然后通过rpc远程调用调用生产者服务。如果添加了新的服务，注册中心会通知消费者，消费者会更新自己的服务列表然后再去调用服务。当然，生产者和消费者每次的生产与消费都在监控中心（monitor）的监控下。

补充：如果注册中心（考虑单注册中心情况）挂掉，消费者依旧可以通过rpc远程调用调用已有的生产者服务，只是新增的服务无法通知消费者。因为消费者调用是通过本地已经订阅的服务列表区进行调用的

• dubbo支持的通信协议

1. dubbo
   是一种tcp协议，是dubbo的默认缺省协议，Dubbo缺省协议采用单一长连接和NIO异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。
2. rmi
   是一种tcp协议
   RMI协议采用JDK标准的java.rmi.*实现，采用阻塞式短连接和JDK标准序列化方式
3. hessian
   是一种http协议
   Hessian协议用于集成Hessian的服务，Hessian底层采用Http通讯，采用Servlet暴露服务，Dubbo缺省内嵌Jetty作为服务器实现
   传入传出参数数据包较大，提供者比消费者个数多，提供者压力较大，可传文件。
4. http
   采用Spring的HttpInvoker实现
   传入传出参数数据包大小混合，提供者比消费者个数多，可用浏览器查看，可用表单或URL传入参数，暂不支持传文件
5. webservice
6. thrift
7. memcached
8. redis

• dubbo vs springcloud

1. Dubbo 只是实现了服务治理，而 Spring Cloud 子项目分别覆盖了微服务架构下的众多部件，服务治理只是其中的一个方面；也可以理解为springcloud子项目提供了一整套微服务解决组件，但是dubbo没有,但是dubbo可以配置Filter来完善功能
2. 从核心要素来看，Spring Cloud 更胜一筹，在开发过程中只要整合 Spring Cloud 的子项目就可以顺利的完成各种组件的融合，而 Dubbo 却需要通过实现各种 Filter 来做定制，开发成本以及技术难度略高
3. dubbo的rpc调用是基于tcp,springcloud基于http和rest;Dubbo 支持各种通信协议，而且消费方和服务方使用长链接方式交互，通信速度上略胜 Spring Cloud，如果对于系统的响应时间有严格要求，长链接更合适
4. 对于3的解释，也就是说dubbo暴露的是service层的接口，使用的方式为：消费者的controller层调用服务提供者的service（基于tcp+socket）。 而springcloud暴露的是controller接口，使用的方式为：消费者的service层调用服务者的controller。（基于http+rest）
5. Dubbo 需要自己开发一套 API 网关，而 Spring Cloud 则可以通过 Zuul 配置即可完成网关定制。使用方式上 Spring Cloud 略胜一筹

dubbo实例

1. 纯API方式发布和调用服务
   demo-api:存放接口,实体
   demo-client:客户端
   demo-server:服务端

   • 生产者API:

     1. ApplicationConfig:主要配置发布的服务名称
     2. ProtocolConfig：定义服务的协议与端口
     3. RegistryConfig：配置注册中心地址
     4. ServiceConfig：定义服务的内容，包括服务接口与接口实现类
     5. 使用ServiceConfig关联前三个对象，然后调用export发布服务

   • 消费者API:

     1. ApplicationConfig:配置消费者名称
     2. RegistryConfig：配置注册中心地址
     3. ReferenceConfig:关联前两个对象，并且设置要获取的服务接口（比如IuserService），设置rpc调用的url地址(IuserService对应的访问地址)
     4. 通过ReferenceConfig中get方法拿到userServiceImpl的动态代理对象
     5. 使用动态代理对象去调用服务的方法完成消费

2. 基于Spring发布和调用服务
   以spring配置文件的方式改造纯API的配置，配置内容基本一致

3. springboot环境下集成dubbo