【架构】分布式架构介绍及实现（简略）

偏执的太偏执、 2023-01-07 13:25 289阅读 0赞

## 1.分布式架构介绍 ##

> 分布式系统（distributed system）是建立在网络之上的软件系统。正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。因此，网络和分布式系统之间的区别更多的在于高层软件（特别是操作系统），而不是硬件。

以上是百度百科关于分布式系统的解释，有点复杂，我们可以简单点理解就是一个节点来干的活，现在分成多个节点来干。

**问题一**：为什么会发展分布式架构？

1.  稳定性和可用性这两个指标很难达到。比如单点问题，一旦大型主机出现故障，那整个系统就将处于不可用的状态。而对于大型机的使用机构来说，这种不可用导致的损失是非常巨大的。
2.  单机处理能力存在瓶颈
3.  升级单机处理能力的性价比越来越低

**问题二**：分布式架构所带来的成本？

1.  分布式事物：是指一个操作，分成几个小操作在多个服务器上执行，要么多成功，要么多失败这些分布事物要做的
2.  不允许服务有状态（stateless service）：无状态服务是指对单次请求的处理，不依赖其他请求，也就是说，处理一次请求所需的全部信息，要么都包含在这个请求里，要么可以从外部获取到（比如说数据库），服务器本身不存储任何信息。
3.  服务依懒关系复杂：服务 A --> B–> C 那和服务C 的修改 就可能会影响 B 和C，事实上当服务越来 越多的时候，C的变动将会越来越困难。
4.  部署运维成本增加：不用说了，相比之前几个节点，运维成本的增加必须的。
5.  源码管理成本增加：原本一套或几套源码现在拆分成几十个源码库，其中分支、tag都要进行相应管理。
6.  如何保证系统的伸缩性：伸缩性是指,当前服务器硬件升级后或新增服务器处理能力就能相对应的提升。
7.  分布式会话：此仅针对应用层服务，不能将Session 存储在一个服务器上。
8.  分布式JOB：通常定时任务只需要在一台机器上触发执行，分布式的情况下在哪台执行呢？

最后通过一张图直观感受一下 单体到分布式的区别：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center]

**问题三**：改造升级分布式架面临的风险？

场景：一家做政务OA系统的公司老板发现跟竞争对手比，自己的系统的架构不是分布式的，找到技术负责人问，把系统架构升级成分布示架构要多长时间？技术负责人网上查了查 Dubbo 官网看了看 Demo 这不很简单吗，拍着胸脯一个月能升级好。

现在我的问题是：这位技术理在改造过程中可能会遇到什么风险和问题？

1.  新功能和旧BUG的问题
2.  业务完整性的问题
3.  团队协作方式转变
4.  开发人员技能提升
5.  系统交付方式转变

这些问题解决涉及业务部门及整个技术部门（开发、测试、运维）协商与工作标准的制定。业务相关问题暂不做讨论,技术架构上应该要清楚自己的职责是，如何通过技术手段把业务波动降至最低、开发成本最低、实施风险最低？

## 2.分布式架构实现 ##

### 2.1 远程通信 ###

实现一个分布示框架最核心功能是什么? **RPC(Remote procedure call)远程调用技术**。

![在这里插入图片描述][20210118025721861.png_pic_center]

大家知道的有哪些远程调用的方式？拿几个大家比较熟悉的来举例：RMI 、Web Service、Http、

<table> 
 <thead> 
  <tr> 
   <th align="left"><strong>协议</strong></th> 
   <th align="left"><strong>描述</strong></th> 
   <th align="left"><strong>优点</strong></th> 
   <th align="left"><strong>缺点</strong></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">RMI</td> 
   <td align="left">JAVA 远程方法调用、使用原生二进制方式进行序列化</td> 
   <td align="left">简单易用、SDK支持，提高开发效率</td> 
   <td align="left">不支持跨语言</td> 
  </tr> 
  <tr> 
   <td align="left">Web Service</td> 
   <td align="left">比较早系统调用解决方案 ，跨语言, 基于WSDL 生成 SOAP 进行消息的传递</td> 
   <td align="left">SDK支持、跨语言</td> 
   <td align="left">实现较重，发布繁琐</td> 
  </tr> 
  <tr> 
   <td align="left">Http</td> 
   <td align="left">采用http +json 实现</td> 
   <td align="left">简单、轻量、跨语言</td> 
   <td align="left">不支持SDK</td> 
  </tr> 
  <tr> 
   <td align="left">Hessian</td> 
   <td align="left">采用http +hessian 序列化实现</td> 
   <td align="left">简单，轻量、sdk支持</td> 
   <td align="left">不能跨语言</td> 
  </tr> 
 </tbody> 
</table>

我们来看看 RMI。

Java RMI，即远程方法调用(Remote Method Invocation)，一种用于实现远程过程调用(RPC)的 Java API， 能直接传输序列化后的 Java 对象和分布式垃圾收集。它的实现依赖于Java虚拟机，因此它仅支持从一个 JVM 到另一个 JVM 的调用。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 1]

由于 RMI 基本没有学习成本，所以也算是一个比较合适的方案。下面来看看如何通过 RMI 进行远程服务调用：

1）注册中心：

LocateRegistry.createRegistry(8080);

2）注册远程服务

UserService hello = new UserServiceImpl();
    Naming.bind("rmi://localhost:8080/UserService", hello);

3）引用远程服务，并发起调用

UserService userService = (UserService) Naming.lookup("rmi://localhost:8080/UserService");
    userService.getName(“zs”);

### 2.2 服务治理 ###

实现一个分布式架构除了上面的远程通信，我们还要考虑当有多个服务（集群）时，如何对这些服务进行统一管理  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 2]

1.  负载均衡：这么多个机器调用哪一台?
2.  服务发现：样发现新的服务地址呢？
3.  健康检测：服务关宕机或恢复后怎么办？
4.  容错：如果调用其中一台调用出错了怎么办？

--------------------

这些功能怎么解决呢？一个一个的去编码实现么？有没有现成的方案可以直接借鉴呢？

分布式架构的三种解决方案：

1.  基于反向代理的中心化架构
2.  嵌入应用内部的去中心化架构
3.  基于独立代理进程的Service Mesh架构

**1.基于反向代理的集中式分布式架构**

这是最简单和传统做法，在服务消费者和生产者之间，代理作为独立一层集中部署，由独立团队(一般是运维或框架)负责治理和运维。常用的集中式代理有硬件负载均衡器(如F5)，或者软件负载均衡器(如Nginx)，这种软硬结合两层代理也是常见做法，兼顾配置的灵活性(Nginx比F5易于配置)。

![在这里插入图片描述][2021011803041858.png_pic_center]

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 3]

*  优点：简单快速、几乎没有学习成本
 *  适用场景：轻量级分布式系统、局部分布式架构。
 *  瓶颈：Nginx中心负载、Http传输、JSON序列化、开发效率、运维效率。

**2.嵌入应用内部的去中心化架构**

这是很多互联网公司比较流行的一种做法，代理(包括服务发现和负载均衡逻辑)以客户库的形式嵌入在应用程序中。这种模式一般需要独立的服务注册中心组件配合，服务启动时自动注册到注册中心并定期报心跳，客户端代理则发现服务并做负载均衡。我们所熟悉的 duboo 和spring cloud Eureka +Ribbon/'rɪbən/ 都是这种方式实现。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 4]

相比第一代架构它有以下特点几点：

*  去中心化，客户端直连服务端
 *  动态注册和发现服务
 *  高效稳定的网络传输
 *  高效可容错的序列化

**3.基于独立代理进程的架构(Service Mesh)**

这种做法是上面两种模式的一个折中，代理既不是独立集中部署，也不嵌入在客户应用程序中，而是作为独立进程部署在每一个主机上，一个主机上的多个消费者应用可以共用这个代理，实现服务发现和负载均衡，如下图所示。这个模式一般也需要独立的服务注册中心组件配合，作用同第二代架构。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 5]

**=> 三种架构的比较**

<table> 
 <thead> 
  <tr> 
   <th align="left"><strong>模式</strong></th> 
   <th align="left"><strong>优点</strong></th> 
   <th align="center"><strong>缺点</strong></th> 
   <th align="left"><strong>适应场景</strong></th> 
   <th align="center"><strong>案例</strong></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">集中式负载架构</td> 
   <td align="left">简单 <br>集中式治理 <br>与语言无关</td> 
   <td align="center">配置维护成本高 <br> 多了一层IO<br> 单点问题</td> 
   <td align="left">大部分公司都适用，对运维有要求</td> 
   <td align="center">亿贝、携程、早期互联网公司</td> 
  </tr> 
  <tr> 
   <td align="left">客户端嵌入式架构</td> 
   <td align="left">无单点 <br> 性能更好</td> 
   <td align="center">客户端复杂 <br> 语言栈要求</td> 
   <td align="left">中大规模公司、语言栈统一</td> 
   <td align="center">Dubbo 、 Twitter finagle、 Spring Cloud Ribbon</td> 
  </tr> 
  <tr> 
   <td align="left">独立进程代理架构</td> 
   <td align="left">无单点 <br> 性能更好 <br> 与语言无关</td> 
   <td align="center">运维部署复杂 <br> 开发联调复杂</td> 
   <td align="left">中大规模公司、对运维有要求</td> 
   <td align="center">Smart Stack Service Mesh</td> 
  </tr> 
 </tbody> 
</table>

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center]: /images/20221119/1d8a4f49634148b390a8cef17c52db47.png
[20210118025721861.png_pic_center]: https://img-blog.csdnimg.cn/20210118025721861.png#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 1]: https://img-blog.csdnimg.cn/20210118030034476.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw==,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 2]: https://img-blog.csdnimg.cn/20210118030921244.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw==,size_16,color_FFFFFF,t_70#pic_center
[2021011803041858.png_pic_center]: https://img-blog.csdnimg.cn/2021011803041858.png#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 3]: https://img-blog.csdnimg.cn/2021011803045456.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw==,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 4]: https://img-blog.csdnimg.cn/20210118030629330.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw==,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 5]: https://img-blog.csdnimg.cn/2021011803070494.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw==,size_16,color_FFFFFF,t_70#pic_center