微服务-基础知识(CAP、BASE)
单体与微服务
单体架构：项目所有功能都在一个 war 包 /jar 包里，像商城的订单、库存、会员、支付等服务，都打包在一起，部署在 Tomcat 服务器，数据存在 MySQL。
- 优点：开发简单，易于理解和维护；部署方便，只需部署一个应用包；测试容易，在一个环境就能完成。
- 缺点：可维护性差，代码量增大后，模块间耦合度高，修改一处可能影响多处；扩展性受限，无法针对特定功能单独扩展；可靠性低，一处故障就可能导致整个应用不可用 。
整个电商平台的所有功能，像用户浏览商品的前端界面、下单的订单服务、查询库存的库存服务、会员管理服务、支付服务，都被打包在一个 WAR 包里，部署在一台 Tomcat 服务器上，数据都存在一个 MySQL 数据库里。就好比开了一家小杂货店，所有商品、收银、库存记录都在一个小店铺里，老板一个人能管过来，但要是店里某一处（比如收银台）出问题，整个店可能就没法正常营业了，而且要是节日期间人特别多（订单量暴增），想只增加收银的 “能力” 也做不到，得把整个店铺都扩大，成本高还麻烦。
集群级垂直化（业务系统级的拆分）：为解决单体的问题，
- 横向加服务器，变成集群；
- 纵向按业务拆，订单、库存、会员、支付各成一个 WAR 包，分别部署到不同的服务器，数据库也对应拆成订单库、库存库等。这样业务耦合度降低，单个业务出问题，不影响其他，也方便针对热门业务（比如订单量暴增）单独扩展服务器。
- 优点：业务耦合度降低，单个业务系统故障对其他系统影响小；可以针对不同业务需求，独立扩展资源，提高资源利用率；便于不同业务模块的并行开发 。
- 缺点：系统间调用复杂度增加，需要考虑分布式通信和数据一致性问题；整体维护成本上升，要管理多个独立部署的系统 。
为了应对业务增长，横向增加了 Tomcat 服务器，变成多台服务器的集群；纵向按业务把订单、库存、会员、支付这些业务拆分开，每个业务都有自己的 WAR 包，分别部署在不同的 Tomcat 服务器上，数据库也对应拆成订单库、库存库、会员库、支付库。这就像把杂货店变成了有多个分区的大超市，订单区、库存区、会员服务区、支付区各自独立，一个区（比如订单区）人多了，就可以单独给这个区增加人手和场地（扩展服务器），一个区出问题，也不会影响其他区正常运作，但每个区内部还是有很多流程和功能混在一起。
SOA:核心是把通用、会被多个上层服务调用的业务，抽成独立基础服务，用 ESB（企业服务总线）连接。比如电商、运营系统都可能用订单、库存等服务。这样解决了 “信息孤岛”，让共享业务能复用，像会员服务，电商和运营系统都能调用。[即电商、运营都能调用订单、库存服务】
- 优点：解决信息孤岛问题，实现业务共享和复用，提高开发效率；业务灵活性高，能快速响应业务变化，便于新业务集成；提高系统的可扩展性，可独立扩展单个服务 。
- 缺点：架构复杂，建设和维护成本高，需要专业的 ESB 等技术支撑；服务治理难度大，需要管理服务间的依赖、版本、安全等 。
电商平台和运营系统（比如用于平台运营管理的系统）都需要用到订单、库存、会员等服务，于是把这些通用的、会被多个上层系统调用的业务，抽取成独立的基础服务，通过 ESB（企业服务总线）来连接各个服务。比如电商系统要下单，运营系统要统计会员数据，都可以调用对应的订单服务、会员服务。这样就解决了不同系统之间的 “信息孤岛” 问题，让订单、会员这些共享业务能被多个系统复用，不过服务之间的调用还是通过比较重的 ESB 来管理。
微服务：SOA 拆分的服务，还能按更细的业务功能拆，独立部署，降低耦合、提升容错。
比如订单服务还能拆得更细。微服务用 API 网关统一管理服务，服务间用 REST API 通信。但服务拆得太细，数量变多，构建、发布、运维就更复杂了。可以说 SOA 是微服务的 “超集”，多个微服务能组成一个 SOA 服务。
- 优点：高内聚低耦合，每个微服务专注单一功能，开发、测试、维护更方便；扩展性强，可针对不同微服务进行单独的资源扩展；技术选型灵活，不同微服务可根据需求选择不同技术栈。
- 缺点：
* 服务数量多，管理和监控复杂，运维难度大；
* 分布式系统带来的数据一致性、网络延迟等问题，增加开发复杂性；部署成本高，要管理多个微服务的部署和运行 。
SOA 拆分出来的服务，又按照更细的业务功能进行拆分和独立部署。比如订单服务，还能拆分成订单创建、订单查询等更细的微服务，每个微服务都有自己的数据库（或数据存储），通过 API 网关来统一管理服务，服务之间用 REST API 进行通信。就像把大超市的每个区又拆成了更小的独立小店，订单创建店、订单查询店等，各自独立运营，一家店出问题，不影响其他店，而且能根据具体需求（比如订单创建需求猛增），只给订单创建的微服务增加资源。但这样一来，服务数量变多，管理、发布、运维这些工作的复杂度也大大增加了。
微服务技术栈
- 配置管理：借助 Nacos、Config 等工具，统一管理微服务的配置信息，让所有微服务能便捷获取和使用配置，方便配置的集中维护与动态更新。
- 服务注册列表：通过注册中心，把所有微服务都注册进去，形成一个服务清单，这样其他微服务要调用服务时，能轻松找到目标服务。
- 网关处理请求：网关作为所有请求的入口，对进来的请求进行处理，可进行权限控制，判断请求是否有权限；也能设置白名单，白名单内的请求可通行；还能对请求进行路由，决定哪些请求转发到新系统。
- 熔断限流：当某个微服务请求量过大，负载过高时，熔断器会从关闭状态转为打开状态，此时请求会被拦截，返回 “系统繁忙，请稍等” 的提示。之后熔断器会每隔一段时间发送测试请求，查看服务是否恢复，此时处于半开状态，若服务负载正常了，熔断器就转回关闭状态，允许请求正常访问。
- 负载均衡策略：运用 Ribbon 等工具，制定规则，决定请求分发到哪台运行服务的机器上，让多台机器合理分担请求压力，避免单台机器负载过高。
- 流处理与消息总线：在消息队列之上添加了一层数据处理逻辑，原本是想实现用户能无缝切换不同的消息队列，但实际效果并不理想。
- 日志跟踪：利用生成的 Trace ID，对微服务之间的调用链路进行跟踪，像从订单服务到物流服务等不同微服务的调用关系，都能通过这个 Trace ID 清晰呈现，便于排查问题。
CAP&BASE
CAP
| 名称 | 详细说明 |
|---|---|
| Consistency（一致性） | 在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本） |
| Availability（可用性） | 在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性） |
| Partition tolerance（分区容忍性） | 一个分布式系统里面，节点组成的网络本来应该是连通的。然而可能因为一些故障，使得有些节点之间不连通了，整个网络就分成了几块区域，数据就散布在了这些不连通的区域中，这就叫分区。 当一个数据项只在一个节点中保存，那么分区出现后，和这个节点不连通的部分就访问不到这个数据了，这时分区就是无法容忍的。 提高分区容忍性的办法就是把数据项复制到多个节点上，容忍性就提高了。然而，要把数据复制到多个节点，就会带来一致性的问题，而要保证一致，每次写操作就都要等待全部节点写成功，而这等待又会带来可用性的问题 【复制多个副本，使得分区时保证该分区内部有足够多的数据，但是多副本会导致数据一致性问题（副本越多数据一致性问题越大，比如一个副本必然没有数据一致性问题） 解决：等待所有节点写入数据成功，但是这个又会导致可用性问题（即等待时候集群不可用） 】  |
高可用性：如果说某个节点故障了但是集群整体还可以运行 ，则说明保持了高可用性
BASE
BASE 理论是在 CAP 理论中一致性和可用性之间权衡的结果，源于大规模互联网分布式系统的实践总结，是从 CAP 定理逐步演化而来的 。
BASE 理论核心思想及举例
- 强一致性（Strong consistency）： 以银行转账为例，如果 A 给 B 转账 100 元，在强一致性要求下，转账操作完成后，A 的账户立即减少 100 元，B 的账户立即增加 100 元，任何节点查询到的 A 和 B 账户余额都是最新且一致的。但在大规模分布式系统中，要实现强一致性的成本很高。
- 最终一致性（Eventual consistency）：以电商的商品库存为例，当多个用户同时购买一件商品时，不同的下单请求可能会被分发到不同的服务器节点处理。在某一时刻，各个节点上显示的库存数量可能并不一致 。但经过一段时间，比如订单处理系统完成数据同步后，所有节点上显示的库存数量会达到一致 。
BASE 理论具体概念及举例
- 基本可用（Basically Available）：以电商平台的 “双 11” 大促活动为例，在流量洪峰时期，平台可能会出现部分页面加载缓慢，或者某些非核心功能（如商品评价晒单功能）暂时无法使用的情况，但核心的下单、支付功能依然可以正常使用，这就是保证了基本可用 。
- 软状态（Soft State）：以微博的点赞功能为例，当大量用户同时对一条热门微博点赞时，由于数据同步存在延迟，不同地区的用户在短时间内看到的点赞数可能不一样，这就是软状态。但随着时间推移，点赞数最终会趋于一致 。
- 最终一致性（Eventual Consistency）：以分布式数据库中的用户信息表为例，假设用户在不同的区域中心修改自己的联系方式，由于网络延迟等原因，各个区域中心数据库中的用户联系方式可能在短时间内不一致。但经过一段时间的数据同步后，所有区域中心数据库中该用户的联系方式都会更新为最新的状态，这就是最终一致性 。
基本可用：即保证基本/核心的功能可用即可，其他功能无需维持【比如手机只剩下打电话，抖音功能取消】
软状态：
