微服务系列概览

分布式和微服务的区别是什么？

分布式是把一个集中式系统拆分成多个系统，每一个系统单独对外提供部分功能，整个分布式系统整体对外提供一整套服务。对于访问分布式系统的用户来说，感知上就像访问一台计算机一样。

而分布式架构的具体实现有很多种，这其中包括了C/S架构、P2P架构、SOA架构、微服务架构、Serverless架构等

所以，微服务架构是分布式架构的一种。

C/S架构

C/S架构，就是Client/Server (C/S)架构，在这种架构中，客户端应用程序通过网络连接到一个或多个服务器，并向服务器发送请求以获取服务或数据。服务器负责处理客户端的请求并返回相应的结果。这种架构常见于Web应用程序、数据库系统等。

P2P架构

P2P，是Peer-To-Peer 的简称，翻译成"对等网络"或者"点对点网络"。P2P是一种分布式网络，网络的参与者共享他们所拥有的一部分硬件资源（处理能力、存储能力、网络连接能力、打印机等），这些共享资源需要由网络提供服务和内容，能被其它对等节点(Peer)直接访问而无需经过中间实体。在此网络中的参与者既是资源（服务和内容）提供者（Server），又是资源（服务和内容）获取者（Client）。

P2P打破了传统的C/S模式，在网络中的每个结点的地位都是对等的。每个结点既充当服务器，为其他结点提供服务，同时也享用其他结点提供的服务。

Serverless架构

Serverless，即无服务架构，是一种将应用程序逻辑交给云服务提供商管理的架构形式。

应用程序以函数的形式运行，通过事件驱动的方式触发。无服务架构将基础设施管理的责任交给云平台，开发人员可以专注于业务逻辑。无服务架构适用于快速开发、弹性扩展和按需计费的场景。例如阿里云，腾讯云等

微服务系统拆分有怎样的策略

微服务的拆分是一个复杂的过程，要考虑的因素有很多，其中必须要考虑的有业务领域、团队组织结构、技术架构、部署架构等多个方面。

首先最容易想到的就是按照业务功能进行拆分了。将具有不同功能的模块单独拆分出来作为一个微服务。比如用户服务、订单服务、物流服务等，每一个服务作为微服务部署，单独对外提供自己的能力。

第二点，不可忽视的就是微服务和组织架构之间的关系，按照康威定律来说，应用架构和组织架构应该是一一对应的。所以有的时候微服务的拆分也需要按照组织架构进行拆分，这样更加容易的进行微服务的开发与维护，能够做到最小成本沟通和最快速度的迭代。比如有些公司做了中台，那么就可能有单独的一些中台相关的微服务，如交易服务、店铺服务等。

第三，按照应用类型进行拆分。有一些应用主要处理在线业务，而有些系统专门处理离线业务，那么就可以把他们拆分开，让在线业务和离线业务分离，避免互相影响。

还有，按照技术架构拆分。比如不同的技术栈、使用不同的中间件体系，不同的开发语言等等。这些拆分开有利于独立维护。

微服务的循环依赖是什么

微服务之间的循环依赖是指在微服务架构中，两个或多个服务相互依赖对方的情况。这里的依赖其实就是互相调用。两个微服务互相调用，A调用B，B又反向调用A，或者A调用B，B调用C，C调用A，这都是循环依赖。

我们在做设计的时候应该尽量的避免循环依赖，因为循环依赖会导致以下这些问题：

1、流量放大：因为系统之间存在循环依赖，那么就会导致本来下单系统可能只有100 QPS，但是因为存在循环依赖，就会导致这个QPS被放大，因为100个请求调用到订单服务，订单服务就有100个请求调到库存服务，而库存服务又有100个请求再调到订单服务。就导致订单服务有200的QPS了。无形中被放大了流量。

2、性能问题：因为存在循环依赖，那么服务之间需要等待彼此的响应，就会无形中拖长请求的RT，让接口性能变的更慢。

3、互相影响：如果一个服务出现问题，这个问题可能会通过循环依赖影响到另一个服务。而一个服务中的错误可能通过依赖链传播到其他服务，增加了系统出现级联故障的风险。

4、发布困难：每当一个服务需要更新时，我们需要同时考虑他依赖了谁以及谁依赖了他。一般是被依赖的应用先发布。但是因为系统间存在循环依赖，那么在上一个新的功能的时候需要发布时，就会带来很大的问题，那就是谁先发的问题，而谁先发都会有问题。

那么如何有什么好的方法可以解决循环依赖吗？

首先，遇到循环依赖的问题，第一件事就是考虑设计的不合理性，一般来说系统会有自己的明确的职责，并且一张架构图中，一个系统一定是有属于他自己的位置的，一个系统又在上游，又在下游，那一定是设计的不合理，所以需要考虑做重新设计。

其次，像前面我们提到的例子，库存需要通知订单更新状态，这个过程我们可以把服务调用改成消息通信，通过异步消息来解耦调两个系统之间的相互依赖。这样就可以避免互相影响。

另外，比较常用的一种方式，那就是引入一个共享库，当出现循环依赖时候，可以考虑将共享部分抽取出来作为一个共享库，然后由各个相关服务共同引用这个库。通过在循环依赖的两个微服务中引用共享库，而不是直接调用对方的接口来操作数据。

什么是CAP理论

CAP理论（CAP Theorem），又称为布鲁尔定理（Brewer's Theorem），是由计算机科学家Eric Brewer在2000年提出的一个关于分布式系统的基本理论。CAP理论指出，在一个分布式系统中，不可能同时完全满足以下三个特性：

1. 一致性（Consistency）：所有节点在同一时间看到的数据是一致的，即每次读操作都能读到最新的写操作结果。

2. 可用性（Availability）：每个请求都能在合理的时间内得到非错误的响应，即系统始终可用。

3. 分区容错性（Partition Tolerance）：系统能够继续运行，即使任意数量的消息在网络分区（Partition）中丢失或延迟。

CAP理论的核心是，在分布式系统中，最多只能同时满足两个特性，而无法同时满足三个特性。

CAP理论的三大特性

1. 一致性（C）：

   • 数据在所有节点上是一致的。

   • 每次读操作都能读到最新的写操作结果。

   • 类似于单节点数据库的ACID特性中的一致性。

2. 可用性（A）：

   • 系统始终可用，所有的请求都能得到响应。

   • 即使部分节点出现故障，系统仍能继续提供服务。

3. 分区容错性（P）：

   • 系统能够容忍网络分区故障。

   • 即使网络中存在分区，系统仍能继续运行并提供服务。

但是在实际的分布式事务设计中，常见的策略包括：

1. 基于CP的设计：

   • 使用两阶段提交（2PC）或三阶段提交（3PC）协议来确保数据一致性。

   • 适用于对一致性要求高的场景，但在网络分区时可能会降低系统的可用性。

2. 基于AP的设计：

   • 使用最终一致性（Eventual Consistency）模型，允许数据在短时间内不一致，但最终会达到一致状态。

   • 适用于对可用性要求高的场景，例如电商网站的购物车系统。

3. 混合设计：

   • 根据业务需求，对不同部分的数据采用不同的策略。

   • 例如，核心交易数据采用CP设计，而非核心数据（如用户评论）采用AP设计。

分布式事务有哪些常见的实现方式

1.Saga模式

Saga模式将长事务拆分为一系列短事务，每个短事务完成后触发下一个事务，失败时执行补偿操作：

• 顺序执行：每个子事务顺序执行，如果其中某个子事务失败，执行相应的补偿事务。

• 并行执行：多个子事务可以并行执行，所有子事务成功后事务才算成功，如果某个子事务失败，执行相应的补偿事务。

Saga模式的优点是避免了长时间锁定资源，缺点是需要设计每个子事务的补偿逻辑。

2.两阶段提交协议（2PC，Two-Phase Commit）

两阶段提交协议是最经典的分布式事务协议，主要分为两个阶段：

• 准备阶段（Prepare Phase）：协调者向所有参与者发送准备请求，参与者执行事务并记录日志，但不提交。参与者将执行结果（准备成功或失败）返回给协调者。

• 提交阶段（Commit Phase）：如果所有参与者都准备成功，协调者发送提交请求，参与者提交事务；如果有任何参与者准备失败，协调者发送回滚请求，所有参与者回滚事务。

2PC的优点是实现简单，缺点是存在单点故障问题，且在网络分区或节点故障时可能会导致参与者长时间锁定资源。

3.三阶段提交协议（3PC，Three-Phase Commit）

三阶段提交协议是对两阶段提交协议的改进，增加了一个"预提交"阶段，减少了系统阻塞时间：

• 准备阶段（Prepare Phase）：与2PC相同，协调者向参与者发送准备请求。

• 预提交阶段（Pre-Commit Phase）：协调者发送预提交请求，参与者收到后可以立即回复并等待最终决定。

• 提交阶段（Commit Phase）：协调者根据所有参与者的回应，决定提交或回滚。

3PC的优点是减少了阻塞时间，但实现较为复杂。

4.基于数据库的分布式事务

一些现代数据库（如Google Spanner、CockroachDB等）提供了内置的分布式事务支持：

• 分布式锁：利用数据库的分布式锁机制，确保多个节点之间的事务一致性。

• 多版本并发控制（MVCC）：通过多版本并发控制实现高效的事务处理。

这种方式的优点是开发简单，缺点是依赖于特定数据库的实现。