分布式架构 组织结构 分布式的架构

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、

协议	描述	优点	缺点
RMI	JAVA 远程方法调用、使用原生二进制方式进行序列化	简单易用、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