主流分布式系统架构分析.pdf

《主流分布式系统架构分析.pdf》由会员分享，可在线阅读，更多相关《主流分布式系统架构分析.pdf（15页珍藏版）》请在三一文库上搜索。

1、1 主流分布式系统架构分析 2 目 录 一、前言 3 二、 SOA 架构解析 3 三、微服务（Microservices）架构解析 7 四、 SOA 和微服务架构的差别 9 五、服务网格（Service Mesh）架构解析. 9 六、分布式架构的基本理论. 11 七、分布式架构下的高可用设计. 15 八、总结 19 3 一、前言 本文我们来聊一聊目前主流的分布式架构和分布式架构中常见理论以及如何才能设计出高可用的分 布式架构好了。分布式架构中，SOA 和微服务架构是最常见两种分布式架构，而且目前服务网格的 概念也越来越火了。那我们本文就先从这些常见架构开始。 二、SOA 架构解析 SOA 全称

2、是 : Service Oriented Architecture，中文释义为“面向服务的架构”，它是一种设计理 念，其中包含多个服务，服务之间通过相互依赖最终提供一系列完整的功能。各个服务通常以独立 的形式部署运行，服务之间通过网络进行调用。架构图如下： 4 跟 SOA 相提并论的还有一个ESB(企业服务总线 )，简单来说ESB 就是一根管道， 用来连接各个服 务节点。 ESB 的存在是为了集成基于不同协议的不同服务，ESB 做了消息的转化、 解释以及路由的工 作，以此来让不同的服务互联互通; 随着我们业务的越来越复杂，会发现服务越来越多， SOA 架构下， 它们的调用关系会变成如下形式：

3、5 很显然，这样不是我们所想要的， 那这时候如果我们引入ESB 的概念，项目调用就又会很清晰，如下： 6 SOA 所要解决的核心问题 系统间的集成: 我们站在系统的角度来看，首先要解决各个系统间的通信问题，目的是将原先系统间 散乱、无规划的网状结构，梳理成规整、可治理的星形结构，这步的实现往往需要引入一些概念和规 范，比如ESB、以及技术规范、服务管理规范; 这一步解决的核心问题是【有序】。 系统的服务化: 我们站在功能的角度，需要把业务逻辑抽象成可复用、可组装的服务， 从而通过服务 的编排实现业务的快速再生，目的是要把原先固有的业务功能抽象设计为通用的业务服务、实现业务 逻辑的快速复用 ;这

4、步要解决的核心问题是【复用】。 业务的服务化: 我们站在企业的角度，要把企业职能抽象成可复用、可组装的服务， 就要把原先职能 化的企业架构转变为服务化的企业架构，以便进一步提升企业的对外服务的能力。“前面两步都是从 7 技术层面来解决系统调用、系统功能复用的问题”。而本步骤，则是以业务驱动把一个业务单元封装 成一项服务。要解决的核心问题是【高效】。 三、微服务（ Microservices）架构解析 微服务架构和SOA 架构非常类似 ,微服务只是SOA 的升华，只不过微服务架构强调的是“业务需 要彻底的组件化及服务化”，原单个业务系统会被拆分为多个可以独立开发、设计、部署运行的小应 用。这些小

5、应用间通过服务化完成交互和集成。组件表示的就是一个可以独立更换和升级的单元， 就像PC 中的 CPU、内存、显卡、硬盘一样， 独立且可以更换升级而不影响其他单元。若我们把PC 中的各个组件以服务的方式构建，那么这台PC 只需要维护主板（可以理解为ESB）和一些必要的 外部设备就可以。 CPU 、内存、硬盘等都是以组件方式提供服务，例如PC 需要调用CPU 做计算处 理，只需知道CPU 这个组件的地址就可以了。 8 微服务的特征 1.通过服务实现组件化 2.按业务能力来划分服务和开发团队 3.去中心化 4.基础设施自动化 (devops 、自动化部署 ) 9 四、SOA 和微服务架构的差别 微服

6、务不再强调传统SOA 架构里面比较重的ESB企业服务总线，同时以SOA 的思想进入到单个 业务系统内部实现真正的组件化。 Docker 容器技术的出现，为微服务提供了非常便利的条件，比如更小的部署单元，每个服务可以 通过类似Spring Boot 或者 Node 等技术独立运行。 还有一个点大家应该可以分析出来，SOA 注重的是系统集成，而微服务关注的是完全分离。 五、服务网格（ Service Mesh）架构解析 17 年年底，非侵入式的Service Mesh 技术慢慢走向了成熟。Service Mesh ，中文释义“服务网 格”，作为服务间通信的基础设施层在系统中存在。如果要用一句话来解

7、释什么叫Service Mesh， 我们可以将它比作是应用程序或者说微服务间的TCP/IP 层，负责服务间的网络调用、熔断、限流和 监控。我们都知道在编写应用程序时程序猿一般都无须关心TCP/IP 这一层（比如提供HTTP 协议 的 Restful 应用），同样如果使用服务网格我们也就不需要关系服务间的那些原来是由应用程序或者 其他框架实现的事情(熔断、限流、监控等)，现在只要交给Service Mesh 就可以了。服务网格架构 图如下： 10 目前流行的Service Mesh 开源软件有Linkerd 、 Envoy 和 Istio ， 而最近Buoyant （开源 Linkerd 的公司

8、）又发布了基于Kubernetes 的 Service Mesh 开源项目Conduit 。 关于微服务和服务网格的区别，我这样理解：微服务更注重服务之间的生态，专注于服务治理等方 面，而服务网格更专注于服务之间的通信，以及和DevOps 更好的结合等。 服务网格的特征 1.应用程序间通讯的中间层 2.轻量级网络代理 3.应用程序无感知 4.解耦应用程序的重试/ 超时、监控、追踪和服务发现 11 六、分布式架构的基本理论 在说 CAP、BASE 理论之前， 我们先要了解下分布式一致性的问题。实际上对于不同业务的服务， 我们对数据一致性的要求是不一样的，如12306 ，它要求数据的严格一致性，不

9、能把票卖给用户以 后却发现没有座位了;再比如银行转账，我们通过银行转账的时候，一般都会收到一个提示: 转账申 请将会在24 小时内到账。 实际上这个场景满足的是最终钱只要转账成功了即可，同时如果钱没汇出 去还要保证资金不丢失。所以说，用户在使用不同的服务的时候对数据一致性的要求是不一样的。 关于分布式一致性问题 分布式系统中要解决的一个非常重要的问题就是数据的复制。在我们的日常开发经验中，相信大多 数开发人员都遇过这样的问题: 在做数据库读写分离的场景中，假设客户端A 将系统中的一个值V 由 V1 变更为V2， 但客户端B 无法立即读取到V 的最新值，e 而需要在一段时间之后才能读取到。 这再

10、正常不过了，因为数据库复制之间存是在延时的。 12 所谓分布式一致性的问题，就是指在分布式环境中引入数据复制机制后，不同数据节点之间可能会 出现的、且无法依靠计算机应用程序自身解决的数据不一致的情况。简单来说，数据一致性就是指 在对一个副本数据进行变更的时候，必须确保也能够更新其它的副本，否则不同副本之间的数据将出 现不一致。那么如何去解决这个问题呢？按照正常的思路，我们可能会想到既然是网络延迟导致的 问题，那么我们就把同步动作进行阻塞，用户2 在查询的时候必须要等数据同步完成以后再来做。 13 但这个方案会非常影响性能。如果同步的数据比较多或比较频繁，那么阻塞操作可能会导致整个新系 统不可用

11、。故我们没有办法找到一种既能够满足数据一致性、又不影响系统性能的方案，所以就诞 生了一个一致性的级别: 1.强一致性: 这种一致性级别是最符合用户直觉的，它要求系统写入的是什么，读出来的也要是什么， 用户体验好，但实现起来往往对系统的性能影响较大。 2.弱一致性: 这种一致性级别约束了系统在写入成功后，不保证立即可以读到写入的值，也不保证多 久之后数据能够达到一致， 但会尽可能地保证到某个时间级别(如秒级别 )后， 数据能够达到一致状态。 3.最终一致性: 最终一致性其实是弱一致性的一个特例，系统会保证在一定时间内，能够达到数据一致 的状态。这里之所以将最终一致性单独提出来，是因为它是弱一致性

12、中非常推崇的一种一致性模型， 也是业界在大型分布式系统的数据一致性上用的比较多的一致性模型。 CAP 理论 它是一个经典的分布式系统理论。CAP 理论告诉我们: 一个分布式系统不可能同时满足一致性 (C:Consistency)、可用性 (A:Availability)及分区容错性 (P:Partition tolerance) 这三个基本要求，最 多只能同时满足其中两项。CAP 理论在互联网界有着广泛的知名度，也被称为“帽子理论” ，它是 由 Eric Brewer 教授在2000 年举行的ACM 研讨会提出的一个著名猜想 : 一致性 (Consistency)、可 用性 (Availabi

13、lity)、分区容错(Partition-tolerance)三者无法在分布式系统中被同时满足，并且最多 只能满足两个 ! 一致性: 所有节点上的数据时刻保持同步 可用性: 每个请求都能接收一个响应，无论响应成功或失败 14 分区容错: 系统应该持续提供服务，即使系统内部(某个节点分区 )有消息丢失。比如交换机失败、网 址网络被分成几个子网，形成脑裂、服务器发生网络延迟或死机，导致某些server 与集群中的其他 机器失去联系。 分区是导致分布式系统可靠性问题的固有特性，从本质上来看，CAP 理论的准确描述不应该是从3 个特性中选取两个，所以我们只能被迫适应，根本没有选择权。CAP 并不是一个

14、普适性原理和指导 思想，它仅适用于原子读写的NoSql 场景中，并不适用于数据库系统。 BASE 理论 从前面的分析中我们知道: 在分布式 (数据库分片或分库存在的多个实例上)前提下， CAP 理论并不 适合数据库事务 (因为更新一些错误的数据而导致的失败，无论使用什么高可用方案都是徒劳的，因 为数据发生了无法修正的错误)。 此外 XA 事务虽然保证了数据库在分布式系统下的ACID ( 原子性、 一致性、隔离性、持久性)特性，但同时也带来了一些性能方面的代价，对于并发和响应时间要求都 比较高的电商平台来说，是很难接受的。 eBay 尝试了另外一条完全不同的路，放宽了数据库事务的ACID 要求，

15、提出了一套名为BASE 的 新准则。 BASE 全称为Basically Available,Soft-state,Eventually Consistent. 系统基本可用、 软状 态、数据最终一致性。相对于CAP 来说，它大大降低了我们对系统的要求。 Basically Available(基本可用 ) 表示在分布式系统出现不可预知的故障时，允许瞬时部分可用性 1.比如我们在淘宝上搜索商品，正常情况下是在0.5s 内返回查询结果，但是由于后端的系统故障导致 查询响应时间变成了2s 15 2.再比如数据库采用分片模式，100W 个用户数据分在5 个数据库实例上，如果破坏了一个实例，那 么可用

16、性还有 80% ，也就是80% 的用户都可以登录，系统仍然可用 3.电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级 服务。这就是损失部分可用性的体现 Soft-state(软状态 ). 表示系统中的数据存在中间状态，并且这个中间状态的存在不会影响系统的整体可用性，也就是 表示系统允许在不同节点的数据副本之间进行数据同步过程中存在延时 ; 比如订单状态， 有一个待支 付、支付中、支付成功、支付失败，那么支付中就是一个中间状态，这个中间状态在支付成功以 后，在支付表中的状态同步给订单状态之前，中间会存在一个时间内的不一致。 Eventually consistent(数据的最终一致性) 表示的是所有数据副本在一段时间的同步后最终都能达到一个一致的状态，因此最终一致性的本 质是要保证数据最终达到一致，而不需要实时保证系统数据的强一致 BASE 理论的核心思想是: 即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适 当的方式来使系统达到最终一致性。 七、分布式架构下的高可用设计 避免单点故障 1.负载均衡技术 (failover/选址 / 硬件负载 / 软件负载 /去中心化的软件负载(gossip(redis- cluster) 2.热备 (linux HA)