主流分布式架构的风流韵事...

1、前言

​　　上篇文章，咱们聊到了分布式架构的演进过程，那本文咱们就来聊一聊目前主流的分布式架构和分布式架构中常见理论以及如何才能设计出高可用的分布式架构好了。分布式架构中，SOA和微服务架构是最多见两种分布式架构，并且目前服务网格的概念也愈来愈火了。那咱们本文就先从这些常见架构开始。

2、SOA架构解析

​　　SOA 全称是: Service Oriented Architecture，中文释义为 “面向服务的架构”，它是一种设计理念，其中包含多个服务， 服务之间经过相互依赖最终提供一系列完整的功能。各个服务一般以独立的形式部署运行，服务之间 经过网络进行调用。架构图以下：

​　　跟 SOA 相提并论的还有一个概念叫 ESB(企业服务总线)，简单来讲 ESB 就是一根管道，用来链接各个服务节点。ESB的存在是为了集成基于不一样协议的不一样服务，ESB 作了消息的转化、解释以及路由的工做，以此来让不一样的服务互联互通; 随着咱们业务的愈来愈复杂，会发现服务愈来愈多，SOA架构下，它们的调用关系会变成以下形式：

　　很显然，这样不是咱们所想要的，那这时候若是咱们引入ESB的概念，项目调用就又会很清晰，以下：

SOA所要解决的核心问题

• 系统间的集成 : 咱们站在系统的角度来看，首先要解决各个系统间的通讯问题，目的是将原先系统间散乱、无规划的网状结构，梳理成规整、可治理的星形结构，这步的实现每每须要引入一些概念和规范，好比 ESB、以及技术规范、服务管理规范。这一步解决的核心问题是【有序】。
• 系统的服务化 : 咱们站在功能的角度，须要把业务逻辑抽象成可复用、可组装的服务，从而经过服务的编排实现业务的快速再生，目的是要把原先固有的业务功能抽象设计为通用的业务服务、实现业务逻辑的快速复用;这步要解决的核心问题是【复用】。
• 业务的服务化 : 咱们站在企业的角度，要把企业职能抽象成可复用、可组装的服务，就要把原先职能化的企业架构转变为服务化的企业架构，以便进一步提高企业的对外服务的能力。“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。而本步骤，则是以业务驱动把一个业务单元封装成一项服务。要解决的核心问题是 【高效】。

3、微服务（MicroServices）架构解析

​　　微服务架构和 SOA 架构很是相似,微服务只是 SOA 的升华，只不过微服务架构强调的是“业务须要完全的组件化及服务化”，原先单个业务系统会被拆分为多个能够独立开发、设计、部署运行的小应用。这些小应用间经过服务化完成交互和集成。 组件表示的就是一个能够独立更换和升级的单元，就像 PC 中的 CPU、内存、显卡、硬盘同样，独立且能够更换升级而不影响其余单元。若咱们把 PC 中的各个组件以服务的方式构建，那么这台 PC 只须要维护主板（能够理解为ESB）和一些必要的外部设备就能够。CPU、内存、硬盘等都是以组件方式提供服务，例如PC 须要调用 CPU 作计算处理，只需知道 CPU 这个组件的地址就能够了。

微服务的特征

1. 经过服务实现组件化
2. 按业务能力来划分服务和开发团队
3. 去中心化
4. 基础设施自动化(devops、自动化部署)

4、SOA 和微服务架构的差异

​　　微服务再也不强调传统SOA架构里面比较重的ESB企业服务总线，同时以 SOA 的思想进入到单个业务系统内部实现真正的组件化。

​　　Docker 容器技术的出现，为微服务提供了很是便利的条件，好比更小的部署单元，每一个服务能够经过相似 Spring Boot 或者 Node 等技术独立运行。

​ 　　还有一个点你们应该能够分析出来，SOA 注重的是系统集成，而微服务关注的是彻底分离。

5、服务网格（Service Mesh）架构解析

​　　17 年年末，非侵入式的 Service Mesh 技术慢慢走向了成熟。Service Mesh ，中文释义“服务网格”，又叫服务边车，做为服务间通讯的基础设施层在系统中存在。若是要用一句话来解释什么叫 Service Mesh，咱们能够将它比做是应用程序或者说微服务间的 TCP/IP层，负责服务间的网络调用、熔断、限流和监控。咱们都知道在编写应用程序时程序猿通常都无须关心 TCP/IP 这一层（好比提供 HTTP 协议的 Restful 应用），一样若是使用服务网格咱们也就不须要关系服务间的那些原来是由应用程序或者其余框架实现的事情(熔断、限流、监控等)，如今只要交给 Service Mesh 就能够了。服务网格架构图以下：

​　　目前流行的 Service Mesh 开源软件有 Linkerd、Envoy 和 Istio，而最近 Buoyant（开源 Linkerd 的公司）又发布了基于 Kubernetes 的 Service Mesh 开源项目 Conduit。

​　　关于微服务和服务网格的区别，我这样理解：微服务更注重服务之间的生态，专一于服务治理等方面，而服务网格更专一于服务之间的通讯，以及和 DevOps 更好的结合等。

服务网格的特征

1. 应用程序间通信的中间层
2. 轻量级网络代理
3. 应用程序无感知
4. 解耦应用程序的重试/超时、监控、追踪和服务发现

6、分布式架构的基本理论

​　　在说 CAP、BASE 理论以前，咱们先要了解下分布式一致性的问题。 实际上对于不一样业务的服务，咱们对数据一致性的要求是不同的，如 12306，它要求数据的严格一致性， 不能把票卖给用户之后却发现没有座位了 ; 再好比银行转帐， 咱们经过银行转帐的时候，通常都会收到一个提示 : 转帐申请将会在 24 小时内到帐。实际上这个场景知足的是最终钱只要转帐成功了便可，同时若是钱没汇出去还要保证资金不丢失。因此说，用户在使用不一样的服务的时候对数据一致性的要求是不同的。

关于分布式一致性问题

​　　分布式系统中要解决的一个很是重要的问题就是数据的复制。 在咱们的平常开发经验中，相信大多数开发人员都遇过这样的问题 : 在作数据库读写分离的场景中，假设客户端 A 将系统中的一个值 V 由 V1 变动为 V2，但客户端 B 没法当即读取到 V 的最新值，而须要在一段时间以后才能读取到。这再正常不过了，由于数据库复制之间存是在延时的。

​　　所谓分布式一致性的问题，就是指在分布式环境中引入数据复制机制后，不一样数据节点之间可能会出现的、且没法依靠计算机应用程序自身解决的数据不一致的状况。简单来讲， 数据一致性就是指在对一个副本数据进行变动的时候，必须确保也可以更新其它的副本，不然不一样副本之间的数据将出现不一致。 那么如何去解决这个问题呢？按照正常的思路，咱们可能会想到既然是网络延迟致使的问题，那么咱们就把同步动做进行阻塞，用户 2 在查询的时候必需要等数据同步完成之后再来作。但这个方案会很是影响性能。若是同步的数据比较多或比较频繁，那么阻塞操做可能会致使整个新系统不可用。故咱们没有办法找到一种既可以知足数据一致性、 又不影响系统性能的方案，因此就诞生了一个一致性的级别:

1. 强一致性 : 这种一致性级别是最符合用户直觉的，它要求系统写入的是什么，读出来的也要是什么，用户体验好，但实现起来每每对系统的性能影响较大。
2. 弱一致性 : 这种一致性级别约束了系统在写入成功后， 不保证当即能够读到写入的值，也不保证多久以后数据 可以达到一致，但会尽量地保证到某个时间级别(如秒级别)后，数据可以达到一致状态。
3. 最终一致性 : 最终一致性实际上是弱一致性的一个特例，系统会保证在必定时间内，可以达到数据一致的状态。这里之因此将最终一致性单独提出来，是由于它是弱一致性中很是推崇的一种一致性模型，也是业界在大型分布式系统的数据一致性上用的比较多的一致性模型。

CAP 理论

​　　它是一个经典的分布式系统理论。CAP 理论告诉咱们 : 一个分布式系统不可能同时知足一致性(C:Consistency)、可用性(A:Availability)及分区容错性(P:Partition tolerance) 这三个基本要求，最多只能同时知足其中两项。CAP 理论在互联网界有着普遍的知名度，也被称为“帽子理论”，它是 由 Eric Brewer 教授在 2000 年举行的 ACM 研讨会提出的 一个著名猜测: 一致性(Consistency)、可用性(Availability)、分区容错 (Partition-tolerance)三者没法在分布式系统中被同时知足，而且最多只能知足两个!

• 一致性 : 全部节点上的数据时刻保持同步
• 可用性 : 每一个请求都能接收一个响应，不管响应成功或失败
• 分区容错 : 系统应该持续提供服务，即便系统内部(某个节点分区)有消息丢失。好比交换机失败、网址网络被分红几个子网，造成脑裂、服务器发生网络延迟或死机，致使某些 server 与集群中的其余机器失去联系。

　　分区是致使分布式系统可靠性问题的固有特性，从本质上来看，CAP 理论的准确描述不该该是从 3 个特性中选取两个，因此咱们只能被迫适应，根本没有选择权。CAP 并非一个普适性原理和指导思想，它仅适用于原子读写的 NoSql 场景中，并不适用于数据库系统。

BASE 理论

​　　从前面的分析中咱们知道 : 在分布式(数据库分片或分库存在的多个实例上)前提下，CAP 理论并不适合数据库事务(由于更新一些错误的数据而致使的失败，不管使用什么高可用方案都是徒劳的，由于数据发生了没法修正的错误)。 此外 XA 事务虽然保证了数据库在分布式系统下的 ACID (原子性、一致性、隔离性、持久性)特性，但同时也带来了一 些性能方面的代价，对于并发和响应时间要求都比较高的电商平台来讲，是很难接受的。

​　　eBay 尝试了另一条彻底不一样的路，放宽了数据库事务的 ACID 要求，提出了一套名为 BASE 的新准则。BASE 全称为 Basically Available,Soft-state,Eventually Consistent. 系统基本可用、软状态、数据最终一致性。相对于 CAP 来讲，它大大下降了咱们对系统的要求。

Basically Available(基本可用)

​ 表示在分布式系统出现不可预 知的故障时，容许瞬时部分可用性

1. 好比咱们在淘宝上搜索商品，正常状况下是在 0.5s 内返回查询结果，可是因为后端的系统故障致使查询响应时间变成了 2s。
2. 再好比数据库采用分片模式，100W 个用户数据分在 5 个数据库实例上，若是破坏了一个实例，那么可用性还 有 80%，也就是 80%的用户均可以登陆，系统仍然可用。
3. 电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现。

Soft-state(软状态).

​　　表示系统中的数据存在中间状态，并 且这个中间状态的存在不会影响系统的总体可用性，也就是表示系统容许在不一样节点的数据副本之间进行数据同步过程当中存在延时; 好比订单状态，有一个待支付、支付中、 支付成功、支付失败， 那么支付中就是一个中间状态，这 个中间状态在支付成功之后，在支付表中的状态同步给订单状态以前，中间会存在一个时间内的不一致。

Eventually consistent(数据的最终一致性)

​　　表示的是全部数据副本在一段时间的同步后最终都能达到一个一致的状态，所以最终一致性的本质是要保证数据最终达到一致， 而不须要实时保证系统数据的强一致。

​BASE 理论的核心思想是 : 即便没法作到强一致性，但每一个应用均可以根据自身业务特色，采用适当的方式来使系统达到最终一致性。

7、分布式架构下的高可用设计

避免单点故障

1. 负载均衡技术(failover/选址/硬件负载/ 软件负载/去中心化的软件负载(gossip(redis- cluster)))
2. 热备(linux HA)
3. 多机房(同城灾备、异地灾备)

应用的高可用性

1. 故障监控(系统监控(cpu、内存)/链路监控/日志监 控) 自动预警
2. 应用的容错设计、(服务降级、限流)自我保护能力
3. 数据量(数据分片、读写分离)

分布式架构下的可伸缩设计

1. 垂直伸缩
2. 提高硬件能力
3. 水平伸缩
4. 增长服务器

加速静态内容访问速度的 CDN

​　　CDN 全称是 Content Delivery Network，中文释义是内容分发网络。CDN 的做用是把用户须要的内容分发到离用户最近的地方进行响应，这样用户可以快速获取所须要的内容。 CDN 本质上就是一种网络缓存技术，可以把一些相对稳定的资源放到距离最终用户较近的地方，一方面能够节省整个广域网的带宽消耗，另一方面也能够提高用户的访问速度、改善用户体验。现实系统中咱们通常会把静态的文件(图片、脚本、静态页面等)放到 CDN 中。

1. 当用户访问网站页面上的内容 URL，通过本地 DNS 系统解析，DNS 系统最终会将域名的解析权交给 CNAME 指向的 CDN 专用 DNS 服务器。

2. CDN 的 DNS 服务器将 CDN 的全局负载均衡设备 IP 地址返回用户。

3. 用户向 CDN 的全局负载均衡设备发起内容 URL 访问请求。

4. CDN全局负载均衡设备根据用户IP地址，以及用户请求的内容URL， 选择一台用户所属区域的区域负载均衡设备，告诉用户向这台设备发起请求。

5. 区域负载均衡设备会为用户选择一台合适的缓存服务器提供服务。

   选择的依据包括 : 根据用户 IP 地址，判断哪一台服务器距离用户最近。根据用户所请求的 URL 中携带的内容名称，判断哪一台服务器上有用户所需内容;查询各个服务器当前的负载状况，判断哪一台服务器上有服务能力。基于以上条件的综合分析以后，区域负载均衡设备会向全局负载均衡设备返回一台缓存服务器的 IP 地址。

6. 局负载均衡设备把服务器的 IP 地址返回给用户。

   用户向缓存服务器发起请求，缓存服务器响应用户请求，将用户所需内容返回到用户终端。若是这台缓存服务器上并无用户想要的内容，而区域均衡设备依然将它分配给了用户，那么这台服务器就要向它的上一级缓存服务器请求内容，直到追溯到包含该内容的源服务器并将内容拉到本地。

什么状况下用 CDN？

​　　最适合的是那些不会常常变化的内容，好比图片，js 文件， CSS 文件，图片文件包括程序模板中CSS 文件中用到的背景图片，还有就是做为网站内容组成部分的那些图片等等。

灰度发布

​　　咱们的应用即便通过了测试部门的测试，也仍然很难全面覆盖用户的使用场景，为了保证万无一失，咱们在进行发布的时候通常都会采用灰度发布，也就是会对新应用进行分批发布，逐步扩大新应用在整个及集群中的比例直到最后所有完成。灰度发布是说针对新应用在用户体验方面彻底无感知。

​　　灰度发布系统的做用在于，能够根据本身的配置，来将用 户的流量导到新上线的系统上，来快速验证新的功能， 而一旦出问题，也能够立刻的回滚发布，简单的说，就是一套 A/B Test 系统。

8、总结

​　　经过本文，咱们就对主流的SOA架构、微服务架构、服务网格架构作了解析，而后知道了分布式架构中的几个基本理论，而后还分析了如何设计出高可用的分布式架构，有木有棒棒哒~ 下篇文章，咱们来经过实例来分析如何基于DDD开发咱们的微服务系统。期待不？评论区等你哟~