分布式系统的技术栈

分布式系统的技术栈

分布式由来

​ 国内来讲，移动互联网的爆发伴随着分布式系统的突现，移动互联网最大的特点是2(to)c的o2o产品越来越多，这跟传统2b的系统最大区别就是用户量的不同，2c系统的用户量远远要高于2b系统，这就对系统提出了各种各样的高标准，响应时间，性能，灾备，吞吐量等等，各种分布式技术也是为了这些标准而服务。

RPC

​ RPC（Remote Process Call），即远程服务调用，被广泛地应用在很多企业应用中，是早期主要的服务治理方案，其流程较为简单，客户端consumer携带参数发送RPC请求到服务提供方provider，provider根据参数路由到具体函数，方法，并将执行获得的结果返回，至此一次RPC调用完成

SOA

​ 由于简单的RPC调用已经不能随着时代发展满足需求，因此复杂的业务逻辑对于分布式应用架构体系的需求愈发强烈，业务希望自己的服务是分布式部署的，请求是分流的，对数据的操作是能读写分离的，同时能屏蔽许多复杂需要自己编写的底层服务，借助已有的公共服务，去快速的构建自己的应用，降低人力开发维护的成本和提高应用交付的效率，基因此，基于分布式服务思想的SOA（Service-Oriented Architecture）成了新的受追捧的架构

分布式服务框架主要模块名词释义

​ （1）Provider：服务提供者，无论是业务服务，还是一个系统中公用的SAAS，都属于Provider

（2）Consumer：即发起调用的客户端

（3）Registry：服务注册中心，是分布式服务系统中的一个重要组成模块，管理Provider的Manager，在实际的运行环境中，服务注册中心Registry被动通知或Consumer主动询问，在Provider有节点宕机或新增节点时，客户端也可实时感知到，从而避免了某个Provider被无限调用或是无限闲置

（4）Gateway：网关也是分布式服务框架中不可或缺的部分，每种系统与框架都有自己的一套协议，当异构系统互相调用时，网关的作用即显现出来，Gateway接受各种外部HTTP请求，完成相应的权限校验，报文适配，路由转发到对应的Provider，再将Provider返回的结果传递给异构系统的Consumer，完成异构系统的互相调用

（5）负载均衡，服务分流：Consumer从Registry获得具体的Provider列表后，如何选取合适的Provider，取决与一定的负载均衡算法，常见的算法有轮询法，随机法，源地址哈希，加权轮询，加权随机等

（6）监控：接收来自Consumer和Provider异步上报的性能监控数据，对有风险的节点发出告警

构建分布式系统的目的

• 提高整体架构的吞吐量，服务更多的并发和流量

  大流量处理，通过集群技术将大规模并发请求的负载分散到不同机器上

• 提高系统的的稳定性，让系统可用性更高

  关键业务保护。提高后台服务的可用性，把故障隔离起来阻止雪崩效应，如果流量过大，需要对业务降级，保护关键业务

提高系统的性能

缓存系统：缓存分区、缓存更新、缓存命中

负载均衡系统（网关系统）：负载均衡、服务路由、服务发现

异步调用：消息队列、消息持久、异步事务

数据镜像：数据同步、读写分流、数据一致性

数据分区：分区策略、数据访问层、数据一致性

缓存系统

可以提高快速访问能力

从前端浏览器、网络、后端服务、底层数据库、文件系统、硬盘、cpu都有缓存

对于分布式缓存系统，需要一个缓存集群，其中一个Proxy做缓存的分片和路由

负载均衡

做水平拓展的关键

异步调用

通过消息队列来对请求做排队处理，把前端请求进行削峰，后端请求根据自己的处理速度来处理请求。

优点：增加系统的吞吐量

缺点：实时性比较差，数据丢失问题，需要对消息持久化，造成有状态节点，增加服务调度难度

数据分区和数据镜像

• 把数据按照一定方式分成多个区，不同的数据来分担不同的流量，需要一个数据路由的中间件，会导致跨库join和跨库事务复杂
• 数据镜像：把多个数据库备份，多个节点可以提供数据读写功能，节点间在内部实现数据同步，缺点是数据一致性问题
• 在初期使用读写分离的数据镜像方式，后期使用分库分表方式

提高系统稳定性

• 服务拆分(服务治理)：服务调用、服务依赖、服务隔离
• 服务冗余(服务调度)：弹性伸缩、故障转移、服务发现
• 限流降级：异步队列、降级控制、服务熔断
• 高可用架构：多租户系统、灾备多活、高可用服务
• 高可用运维：全栈监控、DevOps、自动化运维

服务拆分

隔离故障

重用服务模块

服务拆分完之后，会引入服务调用间的依赖问题

服务冗余

• 去除单点故障，并可以支持服务的弹性伸缩以及故障转移。

• 对于一些有状态的服务来说，冗余这些有状态的服务会带来更高的复杂性。

  当其中一个进行弹性伸缩时，需要考虑数据的复制或重新分片，迁移的时候还要迁移数据到其他机器上

限流降级

当系统流量超过系统承载时，只能通过限流或者功能降级的方式来处理

高可用架构

主要为了不出现单点故障

高可用运维

• DevOps中的CI(持续集成)/CD(持续部署)。
• 应该有一条很流畅的软件发布管线，包括足够的自动化测试，还可以做好相应的灰度发布，以及线上系统的自动化控制。

分布式和集群

在通常情况下不做严格区分，正如并发和并行一样。

分布式：一个电商系统，用户模块部署在server1, 订单模块部署在server2, 促销模块部署在server3, 商品模块部署在server4，他们之间通过远程rpc实现服务调用，这就叫分布式。强调的是不同功能模块，单独部署在不同的server上，所有server加起来是一个完整的系统。

集群：更多强调的是灾备，一个电商系统，完整的部署在server1上一个，完成的部署在server2上一个，server1宕机后，server2仍然可以正常提供请求服务，这叫集群。同样对于某一功能模块，比如用户模块部署在server1上，同样部署在server2上，也叫做集群。分布式系统的每个功能模块节点，都可以用多机做成集群。

抽象问题具体化（通俗的表述）：拿做菜示例，假如一个厨师做菜要经历切菜，炒菜两个功能，饭店为了提高速度招了两个厨师，每个厨师的工作一样，都是切菜，炒菜，这是集群。还有另一种方法提高效率，饭店招了一个切菜师傅，配合厨师，厨师不管切菜，只管炒菜了，和切菜师傅共同配合把菜做好，这叫分布式。

nginx

作用是反向代理和负载均衡

反向代理：请求真实是到servlet1的，但是系统中为了统一或者做比如单点登录，会在server2服务器上安装一个nginx，里面配置到server1的反向代理，那么之后请求url就可以写server2的地址，发出后到server2, server2会转发到server1上，类似一种代理的模式。

负载均衡：如果一个系统的请求很多，我们可以把请求转发到不同的服务器上，用来分流。就类似于接了一个水管放水，水流量很大时候，水压大很可能会让一个水管爆炸，这时候接三个水管，就没问题了（这三个水管就是一个集群）。类似的在nginx服务器中配了3个tomcat服务器，每个tomcat服务器上都部署了整个系统，那么当请求数大的时候，可以分发到不同的tomcat。（每个tomcat上部署同一个功能模块也叫集群）

rpc(远程过程调用)

对于分布式系统来讲，tomcat1上部署了用户模块，tomcat2上部署了订单模块，当用户下单时，请求到tomcat2,这时候可能要判断这个用户是否是vip，或者是否有优惠券，这些方法是在tomcat1用户模块上的，那么tomcat2调用tomcat1的服务获取这些信息，就叫rpc调用。

​ 常见的rpc框架：轻量级的hessian, 阿里dubbo（当当dubbox）, 新浪Motan, apache的Thrift，google的grpc, 百度的brpc, 腾讯的tars。

​ rpc调用底层涉及到对象的序列化，反序列化，http/tcp传输，网络异步传输netty。

消息中间件

mq消息中间件在分布式系统中的作用有很多，但是经常用到的还是异步解耦。

​ 比如天猫下单流程，当用户支付后，后台接口执行的操作可能包括：1 验签，2 支付密码校验，3 扣库存，4 用户积分增加等等操作，其实我们希望的是2操作执行成功后立即给用户结果提示，而不是等到后续各个操作完成后才去提示，因为后续的操作往往大部分是rpc调用，方法执行时间相对较长。另外对于下单支付这个操作，3和4是后续业务的需要，在设计上不能和下单支付本身出现强耦合度。所以这里我们可以引入mq解决，也就是说1和2执行完成后，生产者只需要通知下3和4，把后续的操作扔给消息队列，立即返回。这里的mq起到的作用一个是异步调用，一个是解耦。

NoSQL（不仅仅是sql）

NoSQL是所有非关系型数据库的统称，在分布式系统中用到很多，主要用来提高QPS(query per second)。

redis: 我们讲缓存，或者内存数据库，小巧强大，什么数据适合放在redis也就是缓存中，一个是经常查询的，需要频繁磁盘io的，例如有个快件系统，有个需求是当快件状态为异常时候，需要发送邮件提醒给系统管理员。接口入参是快件id，通常做法我们需要拿到id，去数据库查状态，然后发送，但是快件基数很大时候每天的问题件也可能会很多，接口调用频繁时候就需要改进做法，这时我们可以把快件状态信息放在redis里面，key是快件id, value是快进状态，每次进入接口时候直接redis里面取status就可以，速度很快。另一个是查询数据缓慢的，可以放在缓存中。

mongoDB: 可称为分布式文件数据库，可用来存储海量数据，它是NoSQL里面最像关系型数据库的，它的数据的存储形式可以就理解为json格式。之前曾经两次用到过mongoDB，一次是系统里面有个实时监控设备电流电压的功能，硬件设备实时会把数据同步到数据库里面，我们系统2-3s需要去拉次列表。另一个系统是一个轻型的行业IM工具，每天会有很大的聊天数据存储，我们直接用了mongoDB存储，后来系统相当稳定，从来没有出现过性能瓶颈。

为什么使用nosql

​ 通过第三方平台（如：Google,Facebook等）可以很容易的访问和抓取数据。用户的个人信息，社交网络，地理位置，用户生成的数据和用户操作日志已经成倍的增加。我们如果要对这些用户数据进行挖掘，那SQL数据库已经不适合这些应用了, NoSQL数据库的发展也却能很好的处理这些大的数据。

RDBMS vs NoSQL

★RDBMS

- 高度组织化结构化数据
- 结构化查询语言（SQL） (SQL)
- 数据和关系都存储在单独的表中。
- 数据操纵语言，数据定义语言
- 严格的一致性
- 基础事务

★NoSQL

- 代表着不仅仅是SQL
- 没有声明性查询语言
- 没有预定义的模式
-键 - 值对存储，列存储，文档存储，图形数据库
- 最终一致性，而非ACID属性
- 非结构化和不可预知的数据
- CAP定理
- 高性能，高可用性和可伸缩性

CAP定理

在计算机科学中, CAP定理（CAP theorem）, 又被称作 布鲁尔定理（Brewer’s theorem）, 它指出对于一个分布式计算系统来说，不可能同时满足以下三点：

一致性(Consistency)

• 所有节点在同一时间具有相同的数据

可用性(Availability)

• 保证每个请求不管成功或者失败都有响应

分隔容忍(Partition tolerance)

• 系统中任意信息的丢失或失败不会影响系统的继续运作

★CAP理论的核心是：

• 一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，最多只能同时较好的满足两个。

因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类：

• CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
• CP - 满足一致性，分区容忍性的系统，通常性能不是特别高。
• AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。

NoSQL的优缺点

★优点

- 高可扩展性

- 分布式计算

- 低成本

- 架构的灵活性，半结构化数据

- 没有复杂的关系

★缺点

- 没有标准化

- 有限的查询功能（到目前为止）

- 最终一致是不直观的程序

BASE

• BASE：Basically Available, Soft-state, Eventually Consistent。 由 Eric Brewer 定义。

CAP理论的核心是：

• 一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，最多只能同时较好的满足两个。

BASE是NoSQL数据库通常对可用性及一致性的弱要求原则：

• Basically Availble --基本可用
• Soft-state --软状态/柔性事务。 “Soft state” 可以理解为"无连接"的, 而 “Hard state” 是"面向连接"的
• Eventual Consistency --最终一致性；最终一致性， 也是是 ACID 的最终目的。

分布式系统

• 分布式系统（distributed system）由多台计算机和通信的软件组件通过计算机网络连接（本地网络或广域网）组成。

• 分布式系统是建立在网络之上的软件系统。正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。

• 网络和分布式系统之间的区别更多的在于高层软件（特别是操作系统），而不是硬件。

• 分布式系统可以应用在在不同的平台上如：Pc、工作站、局域网和广域网上等。

分布式计算的优点

可靠性（容错）

• 分布式计算系统中的一个重要的优点是可靠性。一台服务器的系统崩溃并不影响到其余的服务器。

可扩展性：

• 在分布式计算系统可以根据需要增加更多的机器。

资源共享：

• 共享数据是必不可少的应用，如银行，预订系统。

灵活性：

• 由于该系统是非常灵活的，它很容易安装，实施和调试新的服务。

更快的速度：

• 分布式计算系统可以有多台计算机的计算能力，使得它比其他系统有更快的处理速度。

开放系统：

• 由于它是开放的系统，本地或者远程都可以访问到该服务。

更高的性能：

• 相较于集中式计算机网络集群可以提供更高的性能（及更好的性价比）。

分布式计算的缺点

故障排除：

• 故障排除和诊断问题。

软件：

• 更少的软件支持是分布式计算系统的主要缺点。

网络：

• 网络基础设施的问题，包括：传输问题，高负载，信息丢失等。

安全性：

• 开发系统的特性让分布式计算系统存在着数据的安全性和共享的风险等问题。

Zookeeper和Eureka的区别

CAP 理论

C（Consistency）：数据一致性。分布式系统中，数据会有副本。由于网络或者机器故障等因素，可能有些副本数据写入正确，有些却写入错误或者失败，这样就导致了数据的不一致了。而满足数据一致性规则，就是保证所有数据都要同步。

A（Availability）：可用性。我们需要获取什么数据时，都能够正常的获取到想要的数据（当然，允许可接受范围内的网络延迟），也就是说，要保证任何时候请求数据都能够正常响应。

P（Partition Tolerance）：分区容错性。当网络通信发生故障时，集群仍然可用，不会因为某个节点挂了或者存在问题，而影响整个系统的正常运作。

对于分布式系统来说，出现网络分区是不可避免的，因此分区容错性是必须要具备的，也就是说，CAP三者，P是必须的，是个客观存在的事实，不可避免，也无法绕过。

Zookeeper 的 CP 原则

​ 对于 zookeeper 来说，它是 CP 的。也就是说，zookeeper 是保证数据的一致性的，但是这里还需要注意一点是，zookeeper 不是强一致的 。

​ 打个比方，现在客户端 A 提交一个写操作，zookeeper 在过半数节点操作成功之后就可以返回，但此时，客户端 B 的读操作请求的是 A 写曹操尚未同步到的节点，那么读取的就不是 A 最新提交的数据了。

​ 如何保证强一致性？

​ 我们可以在读取数据的时候先执行一下 sync 操作，即与 leader 节点先同步一下数据，再去取，这样才能保证数据的强一致性。

​ zookeeper 也有个缺陷 leader 节点，当 master 节点因为网络故障与其他节点失去联系时，剩余节点会重新进行 leader 选举。问题在于，选举 leader 的时间太长，30 ~ 120s, 且选举期间整个 zookeeper 集群都是不可用的，导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得 zookeeper 集群失去 master 节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。比如双十一当天，那就是灾难性的。

Eureka 的 AP 原则

​ 大规模网络部署时。当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接 down 掉不可用。

​ Eureka 在被设计的时候，就考虑到了这一点，因此在设计时优先保证可用性，这就是 AP 原则。Eureka 各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。

​ 而 Eureka 的客户端在向某个 Eureka 注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台 Eureka 还在，就能保证注册服务可用（即保证A原则），只不过查到的信息可能不是最新的（不保证C原则）。

​ 应用实例的注册信息在集群的所有节点间并不是强一致的，所以需要客户端能够支持负载均衡以及失败重试。在 Netflix 的生态中，ribbon 可以提供这个功能。

​ 因此， Eureka 可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像 zookeeper 那样使整个注册服务瘫痪。

总结

​ 作为服务注册中心，最重要的是要保证可用性，可以接收段时间内数据不一致的情况。个人觉得 Eureka 作为单纯的服务注册中心来说要比 zookeeper 更加“专业”一点。

Dubbo与注册中心Zookeeper的交互过程

Dubbo的Provider，Consumer在启动时都会创建一个注册中心，注册中心可以选择Zookeeper，Redis。常用的是Zookeeper

Dubbo里默认使用zkclient来操作zookeeper服务器，其对zookeeper原始客户单做了一定的封装，操作zookeeper时能便捷一些，比如不需要手动处理session超时，不需要重复注册watcher等等。

Dubbo启动时，Consumer和Provider都会把自身的URL格式化为字符串，然后注册到zookeeper相应节点下，作为一个临时节点，当连断开时，节点被删除。

Consumer在启动时，不仅仅会注册自身到 …/consumers/目录下，同时还会订阅…/providers目录，实时获取其上Provider的URL字符串信息。

ZookeeperRegistry 在实例化时，调用父类构造函数。在父类构造函数中，会创建一个定时任务，每隔5S执行retry( ) 方法。

Provider和Consumer注册的URL就属于临时节点，当连接断开时，Dubbo注册了zookeeper的StateListener，也就是状态监听器，当Dubbo里的zookeeper Client和Server重新连接上时，将之前注册的的URL添加入这几个失败集合中，然后重新注册和订阅。

订阅获取Providers的最新URL字符串，调用notify(…)方法，通知监听器

更新Dubbo内的Invoker相关数据，保证Consumer能实时感知到Provider的信息，保证PRC调用不会出错

总结

1. Provider和Consumer向Zookeeper注册临时节点，当连接断开时删除相应的注册节点。
2. Consumer订阅Providers节点的子节点，实时感知Provider的变化情况，实时同步自身的Invoker对象，保证RPC的可用性。