Dubbo记录之前，先整体学习下分布式演变过程。
分布式的发展历史：
image.png
单体式架构
image.png
垂直架构
image.png
分布式架构
image.png
分布式架构所带来的成本与风险
分布式事物：
分布式事物是指一个操作，分成几个小操作在多个服务器上执行，要么多成功，要么多失败这些分布事物要做的
不允许服务有状态（****stateless service****）
无状态服务是指对单次请求的处理，不依赖其他请求，也就是说，处理一次请求所需的全部信息，要么都包含在这个请求里，要么可以从外部获取到（比如说数据库），服务器本身不存储任何信息。
服务依懒关系复杂
服务 A --> B--> C 那和服务C 的修改 就可能会影响 B 和C，事实上当服务越来 越多的时候，C的变动将会越来越困难。
部署运维成本增加
不用说了，相比之前几个节点，运维成本的增加必须的。
源码管理成本增加：
原本一套或几套源码现在拆分成几十个源码库，其中分支、tag都要进行相应管理。
如何保证系统的伸缩性：
伸缩性是指,当前服务器硬件升级后或新增服务器处理能力就能相对应的提升。
分布式会话：
此仅针对应用层服务，不能将Session 存储在一个服务器上。
分布式JOB
通常定时任务只需要在一台机器上触发执行，分布式的情况下在哪台执行呢？
如何选型分布式架构
提问：实现一个分布示框架最核心功能是什么?
RPC远程调用技术
image.png
比较熟悉的来举例：RMI 、Web Service、Http
| 协议 | 描述 | 优点 | 缺点 |
|---|---|---|---|
| RMI | JAVA 远程方法调用、使用原生二进制方式进行序列化 | 简单易用、SDK支持，提高开发效率 | 不支持跨语言 |
| Web Service | 比较早系统调用解决方案 ，跨语言, 其基于WSDL 生成 SOAP 进行消息的传递。 | SDK支持、跨语言 | 实现较重，发布繁琐 |
| Http | 采用htpp +json 实现 | 简单、轻量、跨语言 | 不支持SDK |
基于比较上述比较，大家会选择哪个方案，综合考虑RMI是比较合适的方案，基本没有学习成本。而跨语言问题基本可以勿略。
如果服务端是单个的话，这个方案差点我就用了。实际上服务端是多个的 ，好了新的问题又来了。
image.png
- 负载均衡：这么多个机器调用哪一台?
- 服务发现：怎样发现新的服务地址呢？
- 健康检测：服务关宕机或恢复后怎么办？
- 容错：如果调用其中一台调用出错了怎么办？
为什么现在逐渐分布式化，微服务化
业务量大，项目拆分，针对集群与管理，单一指责，不再牵一发而动全身。
而对于分布式出现的问题，一般会采用中间件做处理
分布式事务现在2PC，3PC方案很多，比如TCC，分布式锁等
部署成本肯定是增加的，但随着Devops ，k8s一条龙了。
分布式会话一般会引入redis等做处理
分布式job一般会引入注册中心做处理
总体来说分布式化，微服务化，利大于弊
分布式架构的三种解决方案：
- 基于反向代理的中心化架构
- 嵌入应用内部的去中心化架构
- 基于独立代理进程的Service Mesh架构
基于反向代理的集中式分布式架构
这是最简单和传统做法，在服务消费者和生产者之间，代理作为独立一层集中部署，由独立团队(一般是运维或框架)负责治理和运维。常用的集中式代理有硬件负载均衡器(如F5)，或者软件负载均衡器(如Nginx)，这种软硬结合两层代理也是业内常见做法，兼顾配置的灵活性(Nginx比F5易于配置)。
image.png
**Http+Nginx 方案总结：**
**优点：**简单快速、几乎没有学习成本
**适用场景：**轻量级分布式系统、局部分布式架构。
**瓶颈：**Nginx中心负载、Http传输、JSON序列化、开发效率、运维效率。
嵌入应用内部的去中心化架构
这是很多互联网公司比较流行的一种做法，代理(包括服务发现和负载均衡逻辑)以客户库的形式嵌入在应用程序中。这种模式一般需要独立的服务注册中心组件配合，服务启动时自动注册到注册中心并定期报心跳，客户端代理则发现服务并做负载均衡。我们所熟悉的 duboo 和spring cloud Eureka +Ribbon/'rɪbən/ 都是这种方式实现。
image.png
相比第一代架构它有以下特点几点：
* 去中心化，客户端直连服务端
* 动态注册和发现服务
* 高效稳定的网络传输
* 高效可容错的序列化
基于独立代理进程的架构(Service Mesh)
这种做法是上面两种模式的一个折中，代理既不是独立集中部署，也不嵌入在客户应用程序中，而是作为独立进程部署在每一个主机上，一个主机上的多个消费者应用可以共用这个代理，实现服务发现和负载均衡，如下图所示。这个模式一般也需要独立的服务注册中心组件配合，作用同第二代架构。
image.png
三种架构的比较
| 模式 | 优点 | 缺点 | 适应场景 | 案例 |
|---|---|---|---|---|
| 集中式负载架构 | 简单 集中式治理 与语言无关 | 配置维护成本高 多了一层IO 单点问题 | 大部分公司都适用，对运维有要求 | 亿贝、携程、早期互联网公司 |
| 客户端嵌入式架构 | 无单点 性能更好 | 客户端复杂 语言栈要求 | 中大规模公司、语言栈统一 | Dubbo 、 Twitter finagle、 Spring Cloud Ribbon |
| 独立进程代理架构 | 无单点 性能更好 与语言无关 | 运维部署复杂 开发联调复杂 | 中大规模公司 对运维有要求 | Smart Stack Service Mesh |
参考
GitBook：https://dubbo.gitbooks.io/dubbo-user-book/content/preface/background.html
书籍： 从paxos到zookeeper web内幕
网课： 推荐 慕课网 图灵学院 谷粒学院
网友评论