浅聊分布式架构设计

主流架构模型-SOA架构

SOA 全称（Service Oriented Architecture）， “面向服务的架构”，是一种架构设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在与操作系统进程中。各个服务之间通过网络调用。和SOA 相提并论的一个概念 ESB（企业服务总线），简单地说ESB 就是一根管道，用来连接各个服务节点。为了集成不同系统，不同协议的服务，ESB 做了消息的转化解释和路由工作，让不同的服务互联互通；

分布式架构的基本理论 CAP、BASE 以及应用

谈 CAP、BASE 理论之前，先要了解下分布式一致性的这个问题 ，对于不同业务的产品，我们对数据一致性的要求是不一样的，比如 12306，他要求的是数据的严格一致性，不能说把票卖给用户以后发现没有座位了；比如银行转账， 通过银行转账的时候，一般会收到一个提示：转账申请将会在 24 小时内到账；实际上这个场景满足的是,最终钱只要汇出去了即可，同时如果钱没汇出去要保证资金 不丢失；所以说，用户在使用不同的产品的时候对数据一致性的要求是不一样的

关于分布式一致性问题

在分布式系统中要解决的一个重要问题就是数据的复制。 在我们的日常开发经验中，相信很多开发人员都遇到过这样的问题：在做数据库读写分离的场景中，假设客户端 C1 将系统中的一个值 K 由 V1 更新为 V2，但客户端 C2 无法 立即读取到 K 的最新值，需要在一段时间之后才能读取 到。这很正常，因为数据库复制之间存在延时。

所谓的分布式一致性问题，是指在分布式环境中引入数据 复制机制之后，不同数据节点之间可能出现的，并无法依靠计算机应用程序自身解决的数据不一致的情况。简单讲，数据一致性就是指在对一个副本数据进行更新的时候，必须确保也能够更新其他的副本，否则不同副本之间的数据将不一致。那么如何去解决这个问题？按照正常的思路，我们可能会想，既然是因为网络延迟导致的问题，那么我们可以把同步动作进行阻塞，用户 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（eXtended Architecture）(什么是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 理论的核心思想是：即使无法做到强一致性，但每个 应用都可以根据自身业务特点，采用适当的方式来使系统 达到最终一致性

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

避免单点故障

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

应用的高可用性

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

微服务架构

微服务架构和SOA架构类似,微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。
组件表示一个可以独立更换和升级的单元，就像 PC 中的 CPU、内存、显卡、硬盘一样，独立且可以更换升级而不 影响其他单元。如果我们把 PC 作为组件以服务的方式构建，那么这台 PC 只需要维护主板和一些必要的外部设备。CPU、内存、硬盘都是以组件方式提供服务，PC 需要调用 CPU 做计算处理，只需要知道 CPU 这个组件的地址即可。

SOA 和微服务架构的差别

1. 微服务不再强调传统 SOA 架构里面比较重的 ESB 企业服务总线，同时 SOA 的思想进入到单个业务系统内部实现真正的组件化
2. Docker 容器技术的出现,为微服务提供了更便利的条件，比如更小的部署单元，每个服务可以通过类似 Node 或者 Spring Boot 等技术跑在自己的进程中
3. SOA 注重的是系统集成方面，而微服务关注的是完全分离

微服务的特征

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