架构设计原则：高可用、可扩展、安全、性能、成本
各位同学，咱们今天聊点实在的。
做CRM系统，说白了就是在跟“不确定性”打交道。用户量会涨、业务逻辑会变、安全威胁会升级、老板还会天天盯着预算。所以，设计原则不是挂在墙上的口号，而是你写每一行代码、选每一个中间件时，脑子里要绷紧的那根弦。
我个人习惯，把这五个原则当成一个“五边形战士”。缺了哪一块，系统都容易出问题。下面我一个一个拆开讲。
一、高可用性原则：别让用户“等”你
高可用，说白了就是“别挂”。CRM挂了，销售没法跟单，客服没法查客户，那可不是小事。
我遇到过最惨的一次，凌晨三点数据库主库磁盘满了，整个系统瘫痪了四个小时。嗯，从那以后，我对高可用有了刻骨铭心的理解。
核心目标： 99.99% 可用性（一年宕机不超过 52 分钟）
怎么做？我总结了三板斧：
- 冗余部署： 应用层至少双节点，Nginx + Keepalived 做负载均衡。数据库主从切换，别让单点成为瓶颈。
- 熔断与降级： 比如客户查询量突然暴增，别让整个系统崩掉。我习惯用 Sentinel 或 Hystrix，把非核心功能（比如历史报表）先降级，保住核心的“客户查询”和“订单创建”。
- 故障自愈： 别等人去重启。K8s 的 liveness probe 和 readiness probe 一定要配好。我曾经见过一个团队，服务器挂了半小时没人发现，就是因为没配健康检查。
避坑指南： 我曾经以为数据库主从同步就万事大吉，结果一次网络抖动导致同步延迟了 10 秒，用户刚创建的客户，刷新后居然没了。后来我加了半同步复制，才解决了这个问题。
二、可扩展性原则：别让业务“卡”住
CRM 最怕什么？业务部门说“我要加个字段”，你发现数据库表结构动不了。或者用户量从 1000 涨到 10 万，系统直接响应超时。
可扩展性，说白了就是“留一手”。
我一般从三个维度考虑：
- 水平扩展： 应用层无状态设计，加机器就能扛流量。Session 不要存本地，扔到 Redis 里。
- 数据分片： 客户表按租户 ID 分库，或者按时间分表。我习惯用 ShardingSphere，配置简单，对业务代码侵入小。
- 业务扩展： 用 SPI 或者插件机制。比如客户状态机，别写死 if-else，用策略模式 + 配置中心。你想想看，如果业务方突然要加一个“潜在客户转商机”的流程，你改代码上线要多久？
我的经验： 可扩展性不是一蹴而就的。我建议先做“垂直拆分”，把客户、订单、工单拆成独立服务。等业务再复杂了，再考虑“水平拆分”。别一开始就搞微服务，容易把自己绕进去。
三、安全性原则：别让数据“裸奔”
CRM 里存的是什么？客户姓名、电话、地址、交易记录。这些数据泄露了，公司可能直接被告到破产。
安全性，我把它分成三层：
| 层级 | 要点 | 我踩过的坑 |
|---|---|---|
| 传输层 | 全站 HTTPS，API 接口加签名校验 | 曾经有个接口没做签名，被爬虫抓走了 10 万条客户数据 |
| 存储层 | 敏感字段加密存储（AES-256），数据库脱敏查询 | 有一次 DBA 直接查了明文手机号，被审计发现了 |
| 访问层 | RBAC 权限模型，最小权限原则 | 销售能看到全公司的客户，这其实是不合理的 |
特别注意： 我曾经见过一个团队，把数据库密码直接写在配置文件里，还上传到了 Git 仓库。嗯，这属于“自杀式”操作。一定要用配置中心或者密钥管理服务（KMS）。
四、性能优化原则：别让用户“烦”
CRM 页面加载超过 3 秒，销售可能就直接关掉了。性能优化，说白了就是“快”。
我习惯从“端到端”去排查：
- 前端： 首屏加载用 SSR 或者骨架屏。列表页不要一次性查 1000 条数据，分页 + 虚拟滚动。
- 后端： 接口响应时间控制在 200ms 以内。热点数据（比如客户基本信息）用 Redis 缓存，缓存穿透用布隆过滤器。
- 数据库： 慢查询是杀手。我习惯在 MySQL 里开 slow_query_log，每周分析一次。索引不是越多越好，联合索引要遵循最左前缀原则。
一个小技巧： 我曾经优化过一个客户列表接口，从 3 秒降到了 50 毫秒。怎么做的？把原来的“查客户 + 查订单 + 查工单”三次查询，改成了“一次 JOIN + 一次 Redis 缓存”。你想想看，有时候不是技术不行，是思路没打开。
五、成本控制原则：别让老板“哭”
做架构设计，不能只追求技术上的完美，还得算账。云服务器、数据库实例、带宽、存储，哪样不要钱？
成本控制，我总结了三个字：“抠、省、混”。
- 抠： 非核心业务用低配实例。比如日志分析服务，用 2C4G 的机器就够了，别上 8C16G。
- 省： 冷数据归档。超过一年的历史订单，从 MySQL 迁移到 TiDB 或者对象存储（OSS），查询频率低，存储成本能降 70%。
- 混： 混合部署。比如把 CRM 应用和内部管理系统混布在同一台物理机上，只要做好资源隔离（cgroup），能省不少钱。
我的建议： 成本控制不是让你牺牲性能。我习惯在架构评审时，加一个“成本评估”环节。比如，这个功能用 Redis 缓存能省多少数据库 IO？值不值得多花一台 Redis 实例的钱？算清楚再动手。
总结一下
这五个原则，其实是一个整体。高可用让你睡得着觉，可扩展让你不怕业务增长，安全性让你不背锅，性能优化让你不被用户骂，成本控制让你不被老板骂。
嗯，做架构设计，说白了就是“戴着镣铐跳舞”。但只要你把这五条原则刻在脑子里，跳出来的舞，一定不会太难看。
下一章，咱们聊聊具体的“技术选型与架构分层”。到时候见。