【架构】分布式架构介绍及实现(简略)

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:通常定时任务只需要在一台机器上触发执行,分布式的情况下在哪台执行呢?

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

在这里插入图片描述

问题三:改造升级分布式架面临的风险?

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

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

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

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

2.分布式架构实现

2.1 远程通信

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

在这里插入图片描述

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

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

我们来看看 RMI。

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

在这里插入图片描述

由于 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 服务治理

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

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

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

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

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

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

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

在这里插入图片描述

在这里插入图片描述

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

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

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

在这里插入图片描述

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

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

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

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

在这里插入图片描述

=> 三种架构的比较

模式优点缺点适应场景案例
集中式负载架构简单
集中式治理
与语言无关
配置维护成本高
多了一层IO
单点问题
大部分公司都适用,对运维有要求亿贝、携程、早期互联网公司
客户端嵌入式架构无单点
性能更好
客户端复杂
语言栈要求
中大规模公司、语言栈统一Dubbo 、 Twitter finagle、 Spring Cloud Ribbon
独立进程代理架构无单点
性能更好
与语言无关
运维部署复杂
开发联调复杂
中大规模公司、对运维有要求Smart Stack Service Mesh
已标记关键词 清除标记
表情包
插入表情
评论将由博主筛选后显示,对所有人可见 | 还能输入1000个字符
相关推荐
©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页