Java 后端架构演进：从单机到微服务的技术选型

核心优势

• 资源不竞争：应用和数据各用独立 CPU、内存、磁盘，互不影响；
• 扩展更灵活：应用不够用就加应用服务器，数据不够用就给数据服务器加内存；
• 维护更安全：数据备份时不影响应用，应用升级时数据服务器不受影响。

新增挑战

• 网络开销：应用与数据的通信依赖内网，相比单机 IPC 仍有延迟；
• 复杂度提升：需配置网络、数据库权限，考虑网络断连重试机制；
• 单点故障仍存在：任一服务器单独宕机，整个服务仍会不可用。

适用场景

中小型 Web 应用、企业级内部系统、业务增长期的过渡项目。典型如区域型电商、CRM 系统。

三、应用服务集群

通过部署多台应用服务器 + 负载均衡层，让应用服务具备高并发支撑和故障冗余能力，是从'能用'到'抗造'的核心模式。

本质是'横向扩展应用层'：

• 用多台相同的应用服务器组成集群，共同承接请求；
• 用负载均衡服务器（如 Nginx、LVS）作为流量入口，均匀分发请求；
• 所有应用服务器共享同一套数据服务层，确保数据一致性。

核心优势

• 高并发支撑：QPS 随服务器数量线性增长；
• 高可用性：某台服务器宕机后，负载均衡器自动剔除，请求分发到其他健康节点；
• 弹性扩展：添加新服务器即可扩容，无需停机；
• 资源隔离：某台服务器因 Bug 崩溃，不影响其他服务器。

新增缺点

• 复杂度陡增：需维护负载均衡层、会话共享层，运维成本翻倍；
• 网络开销叠加：请求经过多次跳转，延迟增加；
• 会话一致性挑战：若方案没做好，用户可能遇到登录失效或购物车丢失；
• 硬件成本上升：多台服务器 + 负载均衡，成本比单机高 3-5 倍。

适用场景

高并发互联网应用、关键业务系统、弹性伸缩场景。如电商平台、支付系统、短视频热点事件应对。

四、读写分离 / 主从分离架构

数据层的核心扩展方案——将写操作路由到主库，读操作路由到从库，解决单数据库在'读多写少'场景下的性能瓶颈。

核心逻辑：

• 主库：唯一负责写操作，生成数据变更日志；
• 从库：负责读操作，通过日志复制同步数据；
• 同步机制：主库推送日志给从库，保持数据一致。

核心优势

• 突破读性能瓶颈：从库可横向扩展，读吞吐量线性增长；
• 保护主库写性能：避免被大量读请求占用 CPU/IO；
• 高可用：主库宕机后可快速切换从库为新主库；
• 读请求隔离：不同业务的读请求可路由到不同从库。

新增缺点

• 架构复杂度陡增：需维护主从集群、同步机制、读写路由层；
• 主从延迟风险：同步延迟可能导致数据不一致，如刚下单看不到订单；
• 写操作仍有瓶颈：主库是唯一写节点，写请求激增时仍会过载。

适用场景

读多写少的高频业务（电商详情页、资讯阅读）、需高可用的数据场景（支付系统）、读请求需隔离的场景（报表统计）。

五、冷热分离架构（引入缓存）

基于'数据访问频率差异'的性能优化方案——将高频热数据存入高速缓存，低频冷数据保留在传统数据库。

要理解这个架构，首先要明确'冷热数据'的划分：

• 热数据：短时间内被高频访问的数据，占总数据量 5%-20%，但贡献 80% 以上访问量；
• 冷数据：长时间无访问或低频次访问的数据，占总数据量 80%-95%；
• 缓存层：专门存储热数据的高速组件，读写性能比数据库快 1-3 个数量级。

核心逻辑

用户访问数据时，优先查询缓存——命中则直接返回；未命中时再查数据库，并将结果写入缓存。

核心优势

• 性能飙升：热数据毫秒级响应，用户体验显著提升；
• 数据库减压：缓存承接大部分读请求，数据库稳定性大幅提升；
• 资源优化：冷数据迁移到低成本存储，降低整体成本；
• 弹性扩展：缓存层支持横向扩展，扩展性优于数据库。

新增缺点

• 架构复杂度陡增：需维护缓存集群、一致性同步逻辑；
• 缓存成本：基于内存存储，单位成本比磁盘高；
• 引入新问题：带来缓存一致性、击穿、失效、雪崩等挑战。

适用场景

读多写少的高频业务、数据热度差异大的场景、响应速度要求高的场景。如秒杀库存、热门商品详情、直播在线人数。

六、垂直分库架构

数据层按'业务领域'拆分的分布式方案——将单数据库中不同业务模块的表，拆分到多个独立的数据库实例中。

核心逻辑：

• 业务隔离：关联度低的业务表拆分到独立数据库；
• 资源独立：每个库拥有独立的 CPU、内存、连接池；
• 数据内聚：同一业务的表保留在同一数据库，维持关联关系。

核心优势

• 业务解耦：某一业务的表结构变更不影响其他业务；
• 性能大幅提升：单库数据量下降，磁盘 IO、索引查询效率提升；
• 弹性扩展：单个业务可独立扩容；
• 故障隔离：某一业务库宕机，仅影响相关业务。

新增缺点

• 架构复杂度陡增：需维护多业务库、跨库中间件、分布式事务；
• 跨库事务风险：可能出现短暂数据不一致；
• 跨库查询性能差：关联查询需中间件聚合，性能低于单库 JOIN；
• 数据迁移成本高：拆分时需编写迁移脚本并处理一致性。

七、微服务架构

业务驱动的分布式服务拆分模式——将传统单体应用按'业务领域边界'拆分为多个独立、可自治的小型服务。

核心特征：

• 业务独立：每个服务对应一个清晰的业务领域；
• 部署独立：升级或重启某服务不影响其他服务；
• 技术栈灵活：不同服务可选用不同技术栈；
• 数据私有：每个服务拥有独立的数据库。

核心优势

• 弹性扩展：按需扩展单个服务，资源利用率提升；
• 技术栈灵活：不同服务用最适合的技术；
• 故障隔离：某服务宕机仅影响对应功能；
• 团队高效协作：团队专注自己的服务，避免代码冲突；
• 快速迭代：单个服务发布周期短。

核心缺点

• 运维成本陡增：需维护数十个服务实例及治理组件；
• 分布式问题多：引入服务通信、分布式事务等问题，排查难度大；
• 开发门槛高：团队需掌握微服务全家桶；
• 跨服务调试难：一个请求跨多个服务调用，需查看多处日志；
• 一致性挑战：需接受最终一致并设计补偿方案。

适用场景

大型互联网应用、业务模块清晰且独立、需弹性扩展的业务、技术栈多样化需求。如淘宝、微信、企业 ERP。

八、容器编排架构

自动化管理大规模容器集群的核心方案——通过 Kubernetes 对分散的容器进行统一的部署、调度、扩展与故障自愈。

Kubernetes（k8s）是开源的容器编排与管理平台。当容器数量从几个增长到几百上千个时，手动管理会完全失控，需要编排工具作为智能管家。

核心优点

• 全自动化运维：从部署到故障自愈，无需人工干预；
• 资源利用率高：动态调度资源，利用率从虚拟机的 30% 提升到 60% 以上；
• 隔离性好：容器之间文件系统、网络互相隔离；
• 生态丰富：周边工具成熟，可快速搭建基础设施。

核心缺点

• 对研发团队要求极高：概念复杂，新人上手需时间；
• 运维门槛高：集群部署、故障排查需要专业技能；
• 过度设计风险：小规模服务下，复杂度远超收益。

九、技术选型

针对部分业务进行技术选型说明，覆盖缓存、数据库、非结构化存储、全文检索、文档型数据库、大数据平台六大维度。

缓存层：Redis Cluster / 云 Redis / Tair / Keewidb

定位：解决高并发读写与大容量缓存需求，保障高可用。

关系型 / 分布式数据库层：云 MySQL / PolarDB / TDSQL / TiDB / GBase

定位：满足事务强一致性、海量数据水平扩展、国产信创等不同场景需求。

非结构化数据存储：对象存储（OSS / COS / MinIO）

定位：专为图片、视频、文档等非结构化数据设计。

全文检索与分析：ES 集群（Elasticsearch）

定位：解决全文检索与大规模日志分析的性能瓶颈。

核心特性：近实时搜索、强大分词与查询、水平扩展、生态丰富。当需要高效全文检索或大规模日志分析时，ES 比传统数据库 LIKE 查询更高效。

文档型非结构化数据：MongoDB 集群

定位：适合 schema 灵活的非结构化数据存储与高并发读写。

核心特性：schema-free、水平扩展、复杂查询、高可用。当数据结构不固定或需要高并发写入 + 灵活查询时，MongoDB 比关系型数据库更轻量高效。

大数据存储与计算：Hadoop 集群 / MaxCompute / EMR / GFS

定位：解决 PB 级海量数据的存储、计算与分析问题。