亿级分布式系统架构演进实战（二）- 横向扩展（服务无状态化） ...

亿级分布式系统架构演进实战（一）- 总体概要
服务无状态化详细计划

目的：确保服务实例完全无状态，可任意扩缩容

---

1. 会话存储改造（Session Management）

核心问题：传统单体应用中，用户会话存储在服务实例内存，无法支持多实例负载平衡。
办理方案：

1. 用户请求 → [LB] → 任意实例 → 会话数据统一存储 → [分布式存储]

复制代码

使用分布式会话存储，避免横向扩展后多节点会话信息不能共享问题，如用户登录会话。
1.1 分布式会话存储选型比较

方案实现方式适用场景Redis Cluster会话数据以Key-Value情势存储，支持TTL过期、高可用高并发、强一致性要求（生产首选）Memcached多节点分布式缓存，协议简单需要极低延迟但允许短暂数据丢失的场景Database会话数据存入MySQL/PostgreSQL小规模系统，需强事务保障（不推荐高并发） 本项目选择的是Redis Cluster来实现分布式会话存储。
会话管理可优化方向：
• 数据压缩：采用Zstandard/LZ4压缩会话数据（淘汰30%存储占用）

1. 技术方案
2. ​     压缩场景： 仅对会话中大于1KB的字段（如用户画像、历史记录）启用压缩。
3.      ​压缩算法选择：
4.          ​LZ4：适用于文本类数据（压缩率20%-30%）
5.          ​Zstandard：适用于二进制数据（压缩率30%-40%）            
6.      生产级优化
7.          监控压缩率：在Redis写入时记录原始大小和压缩后大小，低于20%压缩率触发告警。
8.          动态降级：当CPU使用率超过80%时，自动关闭压缩功能。

复制代码

• 安全加密：敏感会话字段（如UserID）使用AES-GCM加密存储
     • 分片策略：采用Redis Cluster分片，避免单点热门

1. 原生分片机制
2. ​   哈希槽分配：16384个槽位自动分配到集群节点。
3.    ​客户端路由：使用CRC16算法计算键名哈希值，定位目标分片。

复制代码

• 容灾机制：跨机房部署Redis Cluster（如3机房部署，每个分片3副本）
这个看情况去选择，开始可以先选择简单的主从布局去代替即可。
   

1. 数据同步一致性保障
2.   ​写入流程：
3.     客户端写入本地机房Master节点
4.     Master异步复制到其他两个机房的Slave节点
5.     超过半数的节点ACK后返回客户端成功
6. ​  故障恢复：
7.     机房级故障时，通过Raft协议选举新Master
8.     数据修复：使用NCDC（Network-Constrained Data Consistency）算法保证最终一致性

复制代码

1.2 会话迁移策略

场景：旧系统迁移到无状态架构时的会话兼容
（PS 实在这步只是为了在生产情况验证程序的准确性，认真完成后业务允许的话直接停机切换最彻底）
• 双写过渡：

• 新会话写入Redis Cluster
  
• 旧会话保存在本地内存（Tomcat Session）
  
• 通过Nginx路由新请求到无状态实例
  

• 灰度切流：
• 按用户ID范围逐步迁移（如尾号0~9分批切换）
• 监控会话丢失率（要求<0.01%）
     1.3 会话安全

• 防偷取：
• Cookie设置HttpOnly、Secure、SameSite属性
• 动态Token刷新机制（每5分钟更新Session ID）
• 防篡改：
• 会话数据署名（HMAC-SHA256）
• 客户端IP绑定（检测IP变更时强制重新认证）

---

2. 配置外置（Externalized Configuration）

核心问题：配置硬编码或本地文件导致实例间不一致，无法动态见效。
2.1 动态配置中央选型

工具核心能力生产建议Nacos支持配置推送、版本汗青、灰度发布，集成Spring Cloud Alibaba推荐（阿里生产验证）Spring Cloud Config与Spring生态无缝集成，支持Git/SVN存储旧系统迁移场景Consul服务发现与配置管理一体化，强一致性保证多语言混合技术栈 本项目选择的是Nacos作为服务的配置中央
配置分类管理：
• 情况配置（Env）：数据库地址、缓存集群节点（区分dev/test/prod）
• 业务规则（Biz）：限流阈值、开关配置（如促销运动开关）
• 安全配置（Security）：密钥、白名单IP（加密存储）
2.2 灰度发布策略

• 按应用分组：

1. 新配置 → 10%的实例组（如Canary组） → 监控1小时 → 全量发布  

复制代码

• 按用户分桶：

1. if (userId % 100 < 5) {  // 5%用户灰度  
2.     applyNewConfig();  
3. }  

复制代码

• 回滚机制：
• 自动回滚：配置更新后错误率上升5%则自动回退
• 版本快照：保存最近10个版本，支持一键回滚
2.3 配置安全

Nacos如果没有修改源码做不了这么细，可以选择每个情况搭建一个Nacos这样的方式。
• 权限分级：
• 开发人员：只读测试情况配置
• 运维人员：可修改生产情况非敏感配置
• 安全管理员：管理密钥类配置
• 审计追踪：
• 记录配置修改人、时间、旧值/新值
• 集成LDAP/AD账号体系

---

3. 资源管理（Resource Management）

核心问题：服务实例依靠本地资源（文件、缓存），导致状态残留。
3.1 文件存储外迁

• 对象存储方案：
存储范例使用场景示例热数据频仍访问的文件（如图片缩略图）阿里云OSS标准存储冷数据归档日志、备份文件阿里云OSS归档存储/Glacier临时文件处置处罚中生成的文件（需定时清理）本地SSD + CronJob清理 • 上传优化：
• 客户端直传OSS（淘汰服务端带宽压力）
• 分片上传（支持大文件断点续传）
3.2 内存缓存管理

这项改造实在跟服务无状态话这个目的是没有什么关联性的，本地内存的作用是提拔性能，这里是顺便优化了，你们可以根据情况自行选择。
• 本地缓存策略：
缓存范例使用场景镌汰策略Caffeine高频读、数据量小（如用户底子信息）LRU + 最大条目数限制Guava兼容旧系统基于权重镌汰 本项目本地缓存使用的是Caffeine
• 防缓存滥用：
• 限制最大内存占比（如JVM堆的20%）
• 监控缓存命中率（低于70%时告警）
3.3 临时资源清理

• 临时文件：
• 定时使命（Cron）清理超过24小时的/tmp文件
• 使用内存文件系统（如tmpfs）加速处置处罚
• 线程池管理：
• 禁止使用全局静态线程池（导致内存走漏）
• 统一由Spring Bean管理，应用关闭时自动烧毁

---

4. 生产级实行步骤

• 架构评估：
  • 识别现有状态：会话存储位置、本地配置文件、资源依靠
  • 确定技术栈：Redis版本、配置中央选型、存储迁移工具
  
• 灰度迁移：
  • 阶段1：新会话写入Redis，同时保存本地Session（双写）
  • 阶段2：配置中央逐步替换本地配置文件
  • 阶段3：文件存储迁移到OSS，删除本地存储逻辑
  
• 验证与监控：
  • 自动化测试：模拟实例重启，验证会话不丢失
  • 监控看板：会话存储延迟、配置推送成功率、临时文件磁盘占用
  
• 全量切换：
  • 旧服务下线：确保所有流量切至无状态实例
  • 资源清理：关闭本地Session存储，删除冗余配置
  

---

5. 升级效果

总结：
1、利用redis存储服务会话信息
2、利用nacos config 实现服务配置信息管理
3、利用OSS做文件上传、读取
以上应用服务可以实现无状态话，当应用服务达到性能瓶颈的时间，可通过横向增长节点，然后利用nginx的负载平衡调理，实现性能增长。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。