如何着手架构一套分布式系统
如何选型分布式架构
提问:实现一个分布式框架最核心功能是什么?
RPC远程调用技术:
大家知道的 有哪些远程调用的 方式?拿几个大家比较熟悉的来举例:RMI 、Web Service、Http
协议 | 描述 | 优点 | 缺点 |
---|---|---|---|
RMI | JAVA 远程方法调用、使用原生二进制方式进行序列化 | 简单易用、SDK支持,提高开发效率 | 不支持跨语言 |
Web Service | 比较早系统调用解决方案 ,跨语言, 其基于WSDL 生成 SOAP 进行消息的传递。 | SDK支持、跨语言 | 实现较重,发布繁琐 |
Http | 采用htpp +json 实现 | 简单、轻量、跨语言 | 不支持SDK |
基于比较上述比较,大家会选择哪个方案,综合考虑 RMI是比较合适的方案,基本没有学习成本。而跨语言问题基本可以忽略。 如果服务端不是单个的话,这个方案差点我就用了。实际上服务端是多个的 ,好了新的问题又来了。
负载均衡:这么多个机器调用哪一台?
健康检测:服务网关宕机或恢复后怎么办?
容错:如果调用其中一台调用出错了怎么办?
这些功能怎么解决呢?一个一个的去编码实现么?。有没有现成的方案可以直接借鉴呢?分布式架构的三种解决方案:
基于反向代理的中心化架构
嵌入应用内部的去中心化架构
基于独立代理进程的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 |