如何着手架构一套分布式系统

Posted 2021-03-29 倾风吟

如何选型分布式架构

提问：实现一个分布式框架最核心功能是什么?

RPC远程调用技术：

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

协议	描述	优点	缺点
RMI	JAVA 远程方法调用、使用原生二进制方式进行序列化	简单易用、SDK支持，提高开发效率	不支持跨语言
Web Service	比较早系统调用解决方案 ，跨语言, 其基于WSDL 生成 SOAP 进行消息的传递。	SDK支持、跨语言	实现较重，发布繁琐
Http	采用htpp +json 实现	简单、轻量、跨语言	不支持SDK

基于比较上述比较，大家会选择哪个方案，综合考虑 RMI是比较合适的方案，基本没有学习成本。而跨语言问题基本可以忽略。 如果服务端不是单个的话，这个方案差点我就用了。实际上服务端是多个的 ，好了新的问题又来了。

1. 负载均衡：这么多个机器调用哪一台?

3. 健康检测：服务网关宕机或恢复后怎么办？

4. 容错：如果调用其中一台调用出错了怎么办？

这些功能怎么解决呢？一个一个的去编码实现么？。有没有现成的方案可以直接借鉴呢？分布式架构的三种解决方案：

1. 基于反向代理的中心化架构

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

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

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

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

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

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

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

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

• 去中心化，客户端直连服务端

• 动态注册和发现服务

• 高效稳定的网络传输

• 高效可容错的序列化

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

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

三种架构的比较

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