高可用、可扩展与可维护
一、可用性：冗余、故障隔离、熔断
高可用的目标是在部分故障时仍能对外提供服务。冗余：无单点——关键组件多副本、多可用区/多机房，故障时由健康节点接管；注意冗余不是无限堆机器，要配合健康检查与流量调度。故障隔离：把故障限制在局部，不雪崩——服务/进程/线程隔离、舱壁模式、限流与降级，避免一个慢或挂拖垮全局。熔断：当下游或依赖持续失败时主动断开调用、快速失败或走降级路径，避免无效重试放大压力；恢复时再试探性放开。三者结合：冗余保「有备可用」，隔离保「故障不扩散」，熔断保「不往死里打」。
二、扩展性：水平/垂直、无状态
扩展性指在负载增加时通过增加资源维持或提升能力。垂直扩展（scale up）：单机加 CPU/内存/磁盘，简单但有上限、成本曲线陡。水平扩展（scale out）：加机器/实例数，理论上可线性扩展，但要求应用支持——无状态或状态外置（会话与数据存到共享存储或中间件），才能让请求任意路由到任意实例；有状态则需考虑分片与一致性。设计时优先考虑水平扩展与无状态，为未来流量留空间；对强状态场景则显式设计分片与一致性策略。
垂直：单机加资源，简单有上限。水平：加实例，可线性扩展，需无状态或状态外置。
- 优先设计为可水平扩展
无状态：请求可路由到任意实例；状态外置（会话/缓存/DB）。有状态：需分片与一致性设计。
- 会话、缓存、DB 的边界要清晰
三、可维护性：可观测、可部署、可测试
可维护性决定了问题能否快速定位、变更能否安全发布、行为能否被验证。可观测：日志、指标、链路追踪（logging, metrics, tracing）让「发生了什么、在哪一环、指标是否异常」可查；要有统一采集与查询、告警与 On-call。可部署：自动化构建、测试、发布与回滚；环境一致、发布可重复、失败可快速回退。可测试：单元/集成/端到端测试、环境可复现、关键路径可自动化验证；架构上支持 mock 与隔离依赖。三者缺一不可：不可观测则排障靠猜，不可部署则发布高风险，不可测试则改动不敢动。
日志、指标、链路；发生了什么、在哪一环、是否异常；告警与 On-call。
- 排障的基础
自动化构建、测试、发布、回滚；环境一致、发布可重复。
- 发布安全与频率
单元/集成/E2E、环境可复现、关键路径可自动化；mock 与依赖隔离。
- 改动敢动、回归可验
四、CAP 与一致性模型在决策中的运用
CAP：在分区（Partition）发生时，无法同时保证一致性（Consistency）、可用性（Availability）与分区容忍（Partition tolerance）；实践中网络分区无法避免，所以往往是在C 与 A 之间权衡：CP 系统在分区时牺牲可用性保一致（如强一致存储）；AP 系统在分区时牺牲强一致保可用（如多数 NoSQL、最终一致）。一致性模型：强一致、最终一致、读己之所写等，对应不同业务场景——金融扣款往往要强一致或可补偿，而计数、缓存可接受最终一致。架构决策时要显式写出「这里选哪种一致性与可用性取舍」，并和业务与合规对齐。
要点： 可用性靠冗余（无单点）、故障隔离（不雪崩）、熔断（快速失败/降级）；扩展性靠水平扩展与无状态/状态外置；可维护性靠可观测、可部署、可测试；CAP在分区下在 C 与 A 间权衡，一致性模型要与业务与合规对齐。
反例：单点无冗余、有状态难扩、无观测排障靠猜。
某服务单机单实例，机器一挂全挂；某系统把会话和大量状态放在本地，加机器也扩不上去。某次故障排查花了半天，因为日志分散、没有链路、指标不全，只能靠猜。还有发布全靠手工、没有自动化测试与回滚，改一次心惊胆战。正确做法：关键路径冗余与健康检查、故障隔离与熔断；设计时考虑无状态与水平扩展、状态外置与分片策略；建立日志/指标/链路与告警、自动化部署与测试。高可用、可扩展、可维护的目的是在变化与故障下可持续交付。
小结： 可用性通过冗余、故障隔离、熔断实现；扩展性通过水平扩展与无状态/状态外置设计；可维护性通过可观测、可部署、可测试保障；CAP与一致性模型要在架构决策中显式权衡并与业务对齐。下一章讲技术选型与技术债务：选型维度、自研/采购/开源、技术债的识别与偿还。
五、小结
高可用、可扩展与可维护是非功能需求在架构上的落地。用冗余、隔离、熔断提升可用性；用水平扩展与无状态支撑扩展性；用可观测、可部署、可测试保障可维护性；用CAP 与一致性模型做显式权衡。下一章讲技术选型与技术债务：选型维度、何时自研/采购/开源、技术债的识别与偿还策略。