😊你好，我是小航，一个正在变秃、变强的文艺倾年。
🔔本文分享【系统架构师】2025论文《系统可靠性设计》，期待与你一同探索、学习、进步，一起卷起来叭！
目录
项目介绍
背景介绍
- 时间：2021年3月启动，2022年3月上线
- 参与方：我单位与某省公安厅联合研发
- 目标：解决数据全生命周期（存储/传输/使用/共享）安全问题
- 核心价值：通过性能优化保障系统高并发处理能力
- 用户群体：省市县三级公务员
系统模块
| 模块名称 | 功能描述 |
|---|---|
| 资源模块 | 数据源管理（Oracle/Flink/Spark/文件），支持数据接入、导出及脱敏任务调度 |
| 敏感属性模块 | 自动发现敏感字段，支持自定义敏感属性与人工复核 |
| 脱敏规则模块 | 策略组合配置（含算法版本控制），支持DES/AES/RSA/遮掩/移位等原子脱敏算法 |
| 脱敏模块 | 执行可逆/不可逆脱敏，支持同步/异步任务处理 |
| 权限模块 | RBAC权限控制（省市县三级用户角色分级） |
| 审计模块 | 操作日志记录与合规审查 |
技术栈
- 核心框架：Spring Cloud
- 缓存中间件：Redis（LRU淘汰策略）
- 数据库：Oracle/Neo4j/Spark + RAID6固态硬盘阵列
性能优化技术
2.1 负载均衡技术
| 技术组件 | 实现方案 | 效果 |
|---|---|---|
| Nginx集群 | 前置反向代理+路由模式隔离内外网 | 支持1000+并发连接 |
| 最小连接算法 | 动态分配请求至空闲节点 | 提升资源利用率30% |
| 故障转移 | 自动隔离异常节点 | 服务可用性达99.9% |
2.2 缓存技术
- 缓存策略 ：
- 数据类型：脱敏规则/用户登录信息/字典配置
- 淘汰机制：LRU（最近最少使用）
- 一致性保障：读时回填、写时淘汰
- 性能提升 ：
- 数据库访问量减少60%
- 页面加载时间缩短至200ms以内
2.3 数据库优化
| 优化措施 | 技术实现 | 性能指标 |
|---|---|---|
| 主从复制 | 一主三从架构，读写分离 | 写压力降低70% |
| RAID6阵列 | 固态硬盘+双盘容错 | 随机读写IOPS提升4倍 |
| 连接池管理 | 封装读写分离连接池 | 事务响应时间≤50ms |
摘要
2021年3月，我单位联合某省公安厅研发《数据脱敏管理系统》。系统以数据脱敏功能为核心，分为资源模块、敏感属性模块、脱敏规则模块、脱敏模块、权限模块、审计模块。在项目中，我担任系统架构师职务，负责架构设计工作。
本文以该系统为例，主要论述了web技术性能优化在项目中的具体运用。着重介绍负载均衡技术、缓存技术以及数据库主从部署三种技术。通过负载均衡技术结合服务器集群，提高系统的并发能力；缓存技术基于redis内存数据库，降低系统数据库压力，提高数据脱敏速度；数据库主从部署实现读写分离，极大缓解了数据库的负载瓶颈。最终项目成功上线，获得用户一致好评。
正文
笔者在一个专为政企建设信息系统的集成商任职，过往成果有《某省厅网技综合平台》等。2021年3月，我单位联合某省厅研发了《数据脱敏管理系统》项目（以下简称"系统"），解决了数据在其生命周期的传输、存储、使用、共享环节的安全问题，保护了数据安全性和可用性。系统以数据脱敏功能为核心，主要分为资源模块、敏感属性模块、脱敏规则模块、脱敏模块、权限模块、审计模块等。资源模块主要负责识别和维护所有需要进行数据脱敏的数据源，支持用户根据需求接入和导出数据至不同数据源（如oracle、neo4j、spark源、文本文件等），并负责将抽取的数据发送到敏感属性模块进行属性分析；敏感属性模块负责自动发现数据中的敏感字段，支持用户自定义敏感属性等；脱敏规则模块根据不同敏感属性，灵活组合不同脱敏策略，并做好版本控制；数据脱敏模块按用户指定或预定义脱敏策略，对数据实施可逆、不可逆脱敏；权限模块主要是系统安全管理员定义不同角色对应不同模块的权限，对省市县三级用户实行权限控制；审计模块用于安全审计员对系统操作的监督核查。在这个项目中，我担任系统架构师的职务，主要负责系统的架构设计相关工作。
系统需要支撑省厅所辖公务员对数据的脱敏，为保证系统的性能和可靠性，对系统进行性能优化显得尤为重要。传统的基于单块架构的数据脱敏管理系统早已无法支撑日益增长的用户需求，存在严重的性能问题，且很难进行扩展，因此该系统在架构设计中必须考虑到Web应用系统性能优化技术的应用。常见的性能优化策略有：1.负载均衡技术。通过请求转发、监测异常实例、服务故障转移、自动隔离异常主机保障服务高可用性。通过添加实例至服务集群的方式，提高系统的可扩展性。通过负载均衡策略实现流量均衡；2.缓存技术。通过将读写比很高、很少变化的数据写入缓存中，能够起到减少数据访问时间和计算时间的作用，同时能够降低数据库访问压力；3.数据库主从部署技术。使用一主多从，实现读写分离，减轻主库访问压力，同时防止单一主机的数据丢失，提高数据安全性，还能让不同从库使用不同存储引擎，以适应不同的应用需求。
系统分为前端web服务、平台保障服务、业务服务，在开发过程中，我们运用了多种性能优化技术。这里重点以负载均衡技术、缓存技术、数据库主从部署为例，介绍本系统Web性能优化的方案和达到的效果。
-
负载均衡技术。前端web服务主要提供给用户可使用的界面，分为前置nginx负载均衡服务器、前端网站Nginx集群。当用户通过网络访问系统时，首先会访问到前置的Nginx负载均衡服务器，负载均衡服务器会将请求转发到前端网站的Nginx集群，前端网站通过发起http请求来和后端交互，具体是通过Ajax方式来调用后端REST API接口。用户访问网站通过前置的nginx负载均衡服务器来转发到前端网站集群，以起到将用户请求进行分流的作用。当前端网站集群中的部分服务发生故障时，系统仍可正常地对外提供服务。前置nginx负载均衡服务器使用软件反向代理的方式来实现负载均衡，部署为路由模式，系统内部网络与外部网络分属于不同的逻辑网络，以实现系统内部与外部网络的隔离，保护系统安全。在负载均衡算法选择上，为了实现连接最优分配，使用了最小连接法，每当用户请求来临时，任务分发单元会将任务平滑分给最小连接数的节点，这样的架构以廉价、透明的方式扩展了服务器和网络带宽，能够极大提升系统的并发量，同时保证前端整体的稳定性和可靠性。
-
缓存技术。通过对系统业务的分析，发现后端业务服务在进行相关的业务逻辑操作时，存在一部分数据使用频率很高但不会经常变化，如系统基本设置信息、用户登录信息等。这一部分数据如果每次使用都直接请求数据库，将会给数据库服务带来非常大的开销。为了解决这一问题，我们选择了redis作为缓存数据库，采用LRU缓存淘汰策略。在系统启动时，将脱敏规则从专用数据库中读出并缓存在redis中，用户登录时，也会将登录信息缓存在redis中，当服务再次使用到这部分信息时，便可直接从效率更高的redis中读取。对于部分在一定时间内不会变化的数据，如脱敏字典信息、敏感属性配置信息、脱敏策略信息、频繁脱敏的数据表等，也进行缓存。为了解决数据库和缓存一致性的问题，当读取数据时，会先读取redis缓存的数据，如果redis缓存不存在所要的数据，则从原数据库中读取，并将数据同步更新到redis缓存；当写回数据时，将数据直接写入到数据库中，并同步淘汰缓存中的数据。通过缓存技术，极大地提升了系统的性能，并且缓解了页面加载缓慢的问题。
-
数据库主从部署技术。系统使用缓存后，大部分读操作都可直接通过缓存完成，但仍然有部分读操作（未命中或缓存过期）和全部写操作需要访问数据库。当系统用户达到一定规模后，数据库因负载压力过高而成为整个系统瓶颈。对于数据脱敏系统来说，后端数据库存储的性能是极其重要的，所有用户的操作记录，所用脱敏字典策略（周期更新），部分脱敏后的数据（大部分脱敏数据对接到其他系统存储处理）都存储在数据库中。这里要求数据库读写有非常强的性能，考虑到业务读多写少，为了解决数据库的读性能瓶颈，本系统采用主从式部署数据库，实现读写分离架构。业务数据在写数据时，访问主数据库，主数据库通过主从复制机制将数据同步更新到从数据库，当业务服务需要读取数据时，就可以通过从数据库获得数据。业务服务通过使用专门的数据持久层访问模块（封装了读写连接池，读连接池能够实现故障自动转移）来访问读写分离后的数据库，使数据库读写分离对应用透明。为了缓解由磁盘硬件带来的性能瓶颈，数据库所依赖的硬件存储采用raid6的固态硬盘阵列，能够在硬件方面提升数据库的随机读写性能。通过主从数据库设计，提高数据库的运行效率。
在这次系统性能优化设计中，还使用了很多性能优化策略，如使用消息队列进行削峰，使用hystrix组件实现服务降级等，这里就不再一一赘述。系统经过性能测试、负载测试、压力测试、稳定性测试后，自2022年3月上线已运行三年有余，在数据生命周期的存储、传输、使用和共享环节投入使用，截至目前已脱敏3万余次，脱敏数据量达到103T，获得了单位领导同事和客户的一致好评。日常使用过程中最高出现过300余用户同时进行脱敏的情况，基本未出现请求超时，拒绝服务的情况，满足了数据脱敏系统的基本性能需求。
实践证明，数据脱敏系统顺利上线，并且稳定运行，与系统采用了充分的性能优化设计密不可分。经过这次数据脱敏系统性能优化方法的实施，我也看到了身上的不足之处，在未来还会不断更新知识，积累经验，完善本系统各方面的设计，在下次实施中使整个系统更加好用，更好的为用户服务，为社会服务。
📌 [ 笔者 ] 文艺倾年
📃 [ 更新 ] 2025.5.15
❌ [ 勘误 ] /* 暂无 */
📜 [ 声明 ] 由于作者水平有限，本文有错误和不准确之处在所难免，
本人也很想知道这些错误，恳望读者批评指正！