微服务？集群？分布式？CAP-BASE定理？RPC？
文章目录
一、微服务
微服务是一种面向服务的架构(SOA)风格（Java开发人员最重要的技能之一），其中，应用程序被构建为多个不同的小型服务的集合而不是单个应用程序。与单个程序不同的是，微服务让你可以同时运行多个独立的应用程序，而这些独立的应用程序可以使用不同的编码或编程语言来创建。庞大而又复杂的应用程序可以由多个可自行执行的简单而又独立的程序所组成。这些较小的程序组合在一起，可以提供庞大的单程序所具备的所有功能。
微服务是一种面向服务的架构风格,具有灵活性和低成本两个特点.
- 灵活性:由于这些较小的应用程序无需使用相同的编程语言,因此,开发人员可以使用他们最熟悉的语言,这是灵活性.
- 低成本:由于他们都用自己擅长的语言去开发,所以效率会高,相应的开发成本会降低.
1.单体应用（ALL IN ONE）
一个单块应用系统是以一个单个单元的方式来构建的。企业应用系统经常包含三个主要部分：客户端用户界面、数据库和服务端应用系统。客户端用户界面包括HTML页面和运行在用户机器的浏览器中的JavaScript。数据库中包括许多表，这些表被插入一个公共的且通常为关系型的数据库管理系统中。这个服务端的应用系统就是一个单块应用。
2.单体应用的缺点
软件变更受到了很大的限制，应用系统中一个很小部分的一处变更，也需要将整个单块应用系统进行重新构建和部署。随着时间的推移，单块应用逐渐难以保持一个良好的模块化结构，这使得它变得越来越难以将一个模块的变更所产生的影响控制在该模块内。当对系统进行扩展时，不得不扩展整个应用系统，而不能仅扩展该系统中需要更多资源的那些部分。
3.催生出微服务架构风格
以构建一组小型服务的方式来构建应用系统。除了这些服务能被独立地部署和扩展之外，每一个服务还能提供一个稳固的模块边界，甚至能允许使用不同的编程语言来编写不同的服务。这些服务也能被不同的团队来管理。
4.微服务应用（大型分布式应用）
一个微服务应用应该是一组小型服务；
每一个节点代表一个服务，服务之间可以通过HTTP方式进行互通；
每一个功能元素最终都是一个可独立替换和独立升级的软件单元。
不过服务微服务化后带来的挑战也是显而易见的，例如服务粒度小，数量大，后期运维将会很难。
二、集群
集群模式是不同服务器部署同一套服务对外访问，实现服务的负载均衡。
区别集群的方式是根据部署多台服务器业务是否相同。
注：集群模式需要做好session共享，确保在不同服务器切换的过程中不会因为没有获取到session而中止退出服务。
一般配置Nginx的负载容器实现：静态资源缓存、Session共享可以附带实现，Nginx支持5000个并发量。
三、分布式
所谓分布式,无非就是将一个系统拆分成多个子系统并分布到多个服务器上，这些对于用户就像单个相关系统.
简单的说，是指将用户界面、控制台服务、数据库管理三个层次部署在不同的位置上。其中用户界面是客户端实现的功能，控制台服务是一个专门的服务器，数据管理是在一个专门的数据库服务器上实现的。
1.分布式与微服务的关系
简单的说，微服务是架构设计方式，分布式是系统部署方式，两者概念不同
分布式是将多个子系统分布到多个服务器，而这些子系统可能包含多个服务。所以说，微服务相比分布式服务来说，它的粒度更小，服务之间耦合度更低，由于每个微服务都由独立的小团队负责，因此它敏捷性更高，分布式服务最后都会向微服务架构演化，这是一种趋势， 不过服务微服务化后带来的挑战也是显而易见的，例如服务粒度小，数量大，后期运维将会很难。
生产环境下的微服务肯定是分布式部署的，分布式部署的应用不一定是微服务架构的，比如集群部署，它是把相同应用复制到不同服务器上，但是逻辑功能上还是单体应用。
2.分布式与集群的关系
集群指的是将几台服务器集中在一起，实现同一业务。
分布式中的每一个节点，都可以做集群，而集群并不一定就是分布式的。
3.大型分布式应用（微服务应用）构建
你可能在学习spring的时候在官网看过下面这张图片：
如果按照 一.4 那个图那样创建项目搭建环境，会耗费大量的时间。
那么spring就将大型分布式应用分为三步：
springboot快速构建应用、springcloud进行分布式应用网之间的互调、springData做流式数据计算批处理
四、分布式系统CAP问题
1.什么是CAP
CAP原则又称CAP定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。
一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
分区容忍性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
2.C和A之间的抉择
CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于网络硬件肯定会出现延迟丢包等问题，所以分区容错性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。
2.1 CP架构
当出现网络分区时，N1已被更新为了y，N2已被更新为了x，y无法同步到x。当C访问N2时，系统返回错误（也可能会阻塞，知道数据一致）。当C访问N1，就可得到最新的y值，所以保证了一致性。因为返回错误，所以牺牲了可用性。因为分区出现时，系统还可以履行职责，所以就保证了分区容错性。
ZooKeeper就是保证了CP，它在底层实现了raft算法（共识算法）来实现一致性。
Redis实现了AP，但开启哨兵模式后，它也实现了raft算法来保证一致性。
那么可以得知，要实现分布式的一致性，raft算法是必要的。
raft动态演示：http://thesecretlivesofdata.com/raft/
2.2 AP架构
当出现网络分区时，N1已被更新为了y，N2已被更新为了x，y无法同步到x。当C访问N2时，系统返回x。当C访问N1，就可得到最新的y值。因为访问N1或N2，会返回不同的值，所以牺牲了一致性。因为访问N1或N2都可以返回合理的值，所以保证了可用性。因为分区出现时，系统还可以履行职责，所以就保证了分区容错性。
2.3 CA架构
在现在的分布式存储系统中，这种架构没有意义，那什么时候可以实现呢，就是将应用部署在一台服务器上面，就可以实现满足CA.
3.与NoSQL的关系
一般CAP定理用于NoSQL数据库，而对于传统的关系型数据库事务通常支持ACID的强事务机制.
- A代表原子性，即在事务中执行多个操作是原子性的，要么事务中的操作全部执行，要么一个都不执行
- C代表一致性，即保证进行事务的过程中整个数据库的状态是一致的，不会出现数据花掉的情况
- I代表隔离性，即两个事务不会相互影响，覆盖彼此数据等
- D表示持久化，即事务一旦完成，那么数据应该是被写到安全的，持久化存储的设备上（比如磁盘）
NoSQL系统仅提供对行级别的原子性保证，也就是说同时对同一个Key下的数据进行的两个操作，在实际执行的时候是会串行的执行，保证了每一个Key-Value对不会被破坏。
4.与BASH的关系
BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写。
BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。
- 基本可用：指分布式系统在出现不可预知故障的时候，允许损失部分可用性。
注意，这绝不等价于系统不可用，以下两个就是“基本可用”的典型例子：
响应时间上的损失：正常情况下，一个在线搜索引擎需要0.5秒内返回给用户相应的查询结果，但由于出现异常（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1~2秒。
功能上的损失：正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利地完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。 - 弱状态：也称为软状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
- 最终一致性：强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
五、RPC
由于分布式系统的出现，服务之间的调度问题随之而来，RPC也就因此诞生。
RPC（Remote Procedure Call）是指远程过程调用，是一种进程间通信方式，它是一种技术的思想，而不是规范。它允许程序调用另一个地址空间（通常是共享网络的另一台机器上）的过程或函数，而不用程序员显式编码这个远程调用的细节。即程序员无论是调用本地的还是远程的函数，本质上编写的调用代码基本相同。
它来解决分布式系统的各个服务之间相互交互问题
1.REST与RPC
REST是一种架构风格，指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。REST规范把所有内容都视为资源，网络上一切皆资源。
REST与RPC应用场景：
- REST：主要用于各组件之间的通信（如nova与glance的通信），或者说用于组件对外提供调用接口
- RPC：则用于同一组件中各个不同模块之间的通信（如nova组件中nova-compute与nova-scheduler的通信）
两者其实并不是一个维度的概念， RPC 可以基于 TCP/UDP，也可以基于 HTTP 协议进行传输的，按理说它和REST不是一个层面意义上的东西，不应该放在一起讨论，但是谁让REST这么流行呢，它是目前最流行的一套互联网应用程序的API设计标准，某种意义下，我们说 REST 可以其实就是指代 HTTP 协议。
2.RPC基本原理
RPC框架三大核心模块：
- 服务端如何确定客户端要调用的函数
在远程调用中，客户端和服务端分别维护一个【ID->函数】的对应表， ID在所有进程中都是唯一确定的。客户端在做远程过程调用时，附上这个ID，服务端通过查表，来确定客户端需要调用的函数，然后执行相应函数的代码。
- 如何进行序列化和反序列化
客户端和服务端交互时将参数或结果转化为字节流在网络中传输，那么数据转化为字节流的或者将字节流转换成能读取的固定格式时就需要进行序列化和反序列化，序列化和反序列化的速度也会影响远程调用的效率。
- 如何进行网络传输（选择何种网络协议）
多数RPC框架选择TCP作为传输协议，也有部分选择HTTP。如gRPC使用HTTP2。不同的协议各有利弊。TCP更加高效，而HTTP在实际应用中更加的灵活。
3.Dubbo 和 Zookeeper
RPC只是一个远程调用的框架，那么具体的实现，市面上常见的就是Dubbo（Java）和ZooKeeper、Thrift（跨语言）。
3.1 Dubbo工作流程
Dubbo节点角色：
- provide：暴露服务的服务提供方
- consumer：调用远程服务的服务消费方
- registry：服务注册于发现的注册中心
- monitor：统计服务调用次数和调用时间的监控中心
- container：服务运行容器
Dubbo运行流程简述：
- （start）dubbo容器初始化并启动
- （register）服务提供者的信息注册到注册中心（dubbo推荐ZooKeeper）
- （subscribe）服务消费者在注册中心订阅自己需要的服务
- （notify）异步通知服务消费者订阅的服务可以使用
- （invoke）服务消费者知道服务地址之后，直接与服务地址进行通信，并调用服务（具体参考RPC原理）
- （count）监控中心异步统计服务调用次数、调用时间
3.2 Dubbo特性
Dubbo的特性官网介绍的都非常清楚，直接贴图看吧
主要的三大核心能力：
- 面向接口的远程方法调用
- 智能容错和负载均衡
- 服务自动注册和发现
3.3 ZooKeeper（服务注册中心）
Dubbo推荐的服务注册中心ZooKeeper；
ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。
ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
4.SpringCloud 与 Dubbo
简单来说，Dubbo只是针对服务之间RPC问题所产生的应用，而SpringCloud是一个分布式的整体解决方案，SpringCloud解决了分布式系统中所能遇到的所有问题。
| Dubbo | SpringCloud | |
|---|---|---|
| 服务注册中心 | ZooKeeper | Spring Cloud Netflix Eureka |
| 服务调用方式 | RPC | REST API |
| 服务监控 | Dubbo-monitor | Spring Boot Admin |
| 断路器 | 不完善 | Spring Cloud Netflix Hystrix |
| 服务网关 | 无 | Spring Cloud Netflix Zuul |
| 分布式配置 | 无 | Spring Cloud Config |
| 服务跟踪 | 无 | Spring Cloud Sleuth |
| 消息总线 | 无 | Spring Cloud Bus |
| 数据流 | 无 | Spring Cloud Stream |
| 批量任务 | 无 | Spring Cloud Task |
最大区别：
Spring Cloud抛弃了Dubbo 的RPC通信，采用的是基于HTTP的REST方式。
严格来说，这两种方式各有优劣。虽然在一定程度上来说，后者牺牲了服务调用的性能，但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更为合适。
总结：
Dubbo和Spring Cloud并不是完全的竞争关系，两者所解决的问题域不一样：Dubbo的定位始终是一款RPC框架，而Spring Cloud的目的是微服务架构下的一站式解决方案。
非要比较的话，Dubbo可以类比到Netflix OSS技术栈，而Spring Cloud集成了Netflix OSS作为分布式服务治理解决方案，但除此之外Spring Cloud还提供了包括config、stream、security、sleuth等分布式服务解决方案。
当前由于RPC协议、注册中心元数据不匹配等问题，在面临微服务基础框架选型时Dubbo与Spring Cloud只能二选一，这也是两者总拿来做对比的原因。
Dubbo之后会积极寻求适配到Spring Cloud生态，比如作为SpringCloud的二进制通讯方案来发挥Dubbo的性能优势，或者Dubbo通过模块化以及对http的支持适配到Spring Cloud