架构演进：从集中到分布式的迭代之路
架构的演进始终围绕着业务增长带来的复杂度挑战，从最初的简单集中式到复杂的分布式，每一步都是为了更好地适配业务规模、团队协作和技术能力的提升。
一、单一应用架构：简单起步的集中式方案
核心特征
所有功能模块（如用户管理、订单处理、商品展示等）集中在一个应用中，打包成单一部署单元（如 WAR 包），运行在一台服务器上，共享同一个数据库。
适用场景
- 业务初期：用户量少（如日均几千访问）、功能简单（如小型企业官网、内部管理系统）。
- 团队规模小：1-3 人开发，无需复杂协作流程。
优势
- 开发部署高效：无需考虑跨服务通信，代码修改后直接打包部署，初期迭代速度快。
- 资源成本低：单服务器 + 单数据库即可支撑，硬件和运维成本极低。
局限
- 扩展性瓶颈：随着功能增加（如从 3 个模块增至 10 个模块），代码量激增（可能超 10 万行），模块间耦合严重（如一个模块的 bug 可能影响整个系统）。
- 性能风险：所有请求集中在一台服务器，用户量增长后（如日均访问超 10 万），容易出现 CPU 占用过高、数据库连接耗尽等单点故障。
- 协作困难：多人开发同一应用时，代码冲突频繁，需频繁合并分支，影响迭代效率。
二、垂直应用架构：按业务拆分的分散式尝试
核心特征
将单一应用按业务领域垂直拆分为多个独立应用，每个应用负责特定业务模块，独立部署在不同服务器，拥有自己的数据库。
演进动因
单一应用因 “功能耦合过紧、扩展困难” 无法应对业务增长（如用户量达 10 万 +，功能模块超 10 个），需通过拆分分散压力。
典型案例
以电商系统为例，拆分为：
- 用户中心：负责注册、登录、个人信息管理；
- 商品平台：负责商品上架、搜索、详情展示；
- 订单系统：负责下单、支付、物流跟踪。
优势
- 流量分散：不同业务的请求分流到各自服务器，避免单一服务器的性能瓶颈（如商品浏览的高并发不会影响订单支付）。
- 复杂度降低：每个应用仅聚焦一类业务，代码量减少（如单个应用从 10 万行降至 3-5 万行），维护难度降低。
- 团队并行：不同团队可独立负责一个垂直应用，减少跨团队协作冲突。
局限
- 数据冗余：同一核心数据（如用户信息）需在多个应用中存储（如用户中心、订单系统都存用户手机号），易出现数据不一致（如用户修改手机号后，订单系统未同步）。
- 重复开发：各应用可能存在相同逻辑（如日志打印、权限校验），导致 “一套代码多处分发”，修改时需同步更新所有应用，维护成本高。
- 协作低效：应用间需通过接口（如 HTTP）通信，但缺乏规范（如接口格式、版本管理），容易出现 “一个应用改接口，多个应用崩溃” 的问题。
三、分布式应用架构：提取公共服务的服务化转型
核心特征
从垂直应用中提取可复用的公共逻辑，封装为独立服务，供所有垂直应用调用，实现 “公共能力复用” 和 “数据集中管理”。
演进动因
垂直应用的 “数据冗余、重复开发” 问题随着业务进一步增长（如用户量超 100 万）愈发明显，需通过服务化解决复用和一致性问题。
关键变化
- 公共服务提取：将重复逻辑（如用户认证、支付接口、消息通知）抽为独立服务，例如：
- “用户服务”：统一提供用户信息查询、认证接口，所有应用通过调用该服务获取用户数据（避免数据冗余）；
- “支付服务”：对接支付宝、微信支付，所有应用通过该服务完成支付（避免重复对接）。
- 服务协同机制：引入服务注册中心（如 Zookeeper）管理服务地址，通过远程调用（如 RPC）实现应用与服务的通信。
优势
- 复用与降本：公共服务被所有应用共享，减少重复开发（如支付逻辑从 3 次开发减为 1 次），降低维护成本。
- 独立扩展：服务可根据自身负载单独扩容（如支付服务在大促期间单独增加服务器），资源利用率更高。
- 数据一致：核心数据由对应服务统一管理（如用户数据仅存于用户服务），避免多应用同步问题。
局限
- 复杂度上升：需解决服务注册发现、远程调用超时、分布式事务（如订单创建与库存扣减的一致性）等问题。
- 运维挑战：服务数量增加（如从 3 个垂直应用增至 10 个服务），需引入监控（如追踪服务调用链路）、部署工具（如容器化）支撑。
总结：演进的核心逻辑
架构演进的本质是 “拆分” 与 “协同” 的平衡 ：
- 从 “单一应用” 到 “垂直应用”：通过 “业务垂直拆分” 解决集中式的扩展性问题；
- 从 “垂直应用” 到 “分布式应用”：通过 “公共服务提取” 解决分散式的复用与一致性问题。
每一步演进都不是对前一步的否定，而是对业务规模的适配 —— 小型业务用单一应用足够高效，无需盲目追求分布式；大规模业务则需通过服务化提升灵活性
v1.3.10