wordpress 门户网站哈尔滨网站制作公司
亿级分布式系统架构演进实战（一）- 总体概要
服务无状态化详细设计
目标：确保服务实例完全无状态，可任意扩缩容
1. 会话存储改造（Session Management）
核心问题：传统单体应用中，用户会话存储在服务实例内存，无法支持多实例负载均衡。
解决方案：
用户请求 → [LB] → 任意实例 → 会话数据统一存储 → [分布式存储]
使用分布式会话存储，避免横向扩展后多节点会话信息不能共享问题，如用户登录会话。
1.1 分布式会话存储选型比较
| 方案 | 实现方式 | 适用场景 |
|---|---|---|
| Redis Cluster | 会话数据以Key-Value形式存储，支持TTL过期、高可用 | 高并发、强一致性要求（生产首选） |
| Memcached | 多节点分布式缓存，协议简单 | 需要极低延迟但允许短暂数据丢失的场景 |
| Database | 会话数据存入MySQL/PostgreSQL | 小规模系统，需强事务保障（不推荐高并发） |
本项目选择的是Redis Cluster来实现分布式会话存储。
会话管理可优化方向：
• 数据压缩：采用Zstandard/LZ4压缩会话数据（减少30%存储占用）
技术方案
压缩场景： 仅对会话中大于1KB的字段（如用户画像、历史记录）启用压缩。压缩算法选择：LZ4：适用于文本类数据（压缩率20%-30%）Zstandard：适用于二进制数据（压缩率30%-40%） 生产级优化监控压缩率：在Redis写入时记录原始大小和压缩后大小，低于20%压缩率触发告警。动态降级：当CPU使用率超过80%时，自动关闭压缩功能。
• 安全加密：敏感会话字段（如UserID）使用AES-GCM加密存储
• 分片策略：采用Redis Cluster分片，避免单点热点
原生分片机制
哈希槽分配：16384个槽位自动分配到集群节点。客户端路由：使用CRC16算法计算键名哈希值，定位目标分片。
• 容灾机制：跨机房部署Redis Cluster（如3机房部署，每个分片3副本）
这个看情况去选择，开始可以先选择简单的主从结构去代替即可。
数据同步一致性保障写入流程：客户端写入本地机房Master节点Master异步复制到其他两个机房的Slave节点超过半数的节点ACK后返回客户端成功
故障恢复：机房级故障时，通过Raft协议选举新Master数据修复：使用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 灰度发布策略
• 按应用分组：
新配置 → 10%的实例组（如Canary组） → 监控1小时 → 全量发布
• 按用户分桶：
if (userId % 100 < 5) { // 5%用户灰度 applyNewConfig();
}
• 回滚机制：
• 自动回滚：配置更新后错误率上升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的负载均衡调度，实现性能增加。
