第三章 架构设计原则：可扩展性、高可用、安全性、易用性
说实话，我刚入行那会儿，觉得架构设计就是画几个框框，连几根线。后来吃了几次亏才明白——原则是保命的。今天聊的这四条原则，我每个都踩过坑，你想想看，是不是也遇到过类似情况？
3.1 可扩展性：别让架构卡住增长
可扩展性说白了，就是系统能不能跟着业务一起长。我见过一个KMS，上线时美滋滋，用户一多直接挂掉。原因很简单——所有元数据都塞在一个表里，连分库分表都没做。
我习惯从三个维度评估可扩展性：
- 存储层：文档分片、索引分片、元数据分库。早期用单机MongoDB，后面得切到分布式。
- 计算层：全文检索引擎（如Elasticsearch）可以动态加节点。我在项目中遇到过，搜索引擎集群从3节点扩到10节点，业务零感知。
- 接口层：无状态API + 负载均衡。别把会话信息绑死在某台机器上。
嗯，这里要注意：可扩展性不是一上来就搞分布式。我记得有一次给一个只有几十人的团队做咨询，对方要求直接上Kubernetes + 微服务。我说先别急，单体+读写分离就能撑到几百人，过度设计才是最大的成本。
3.2 高可用：数据不能丢，服务不能断
高可用这件事，我在职业生涯里见过太多惨案。最惨的一次，某KMS因为单点故障，全公司停工两小时，老板在会议室拍桌子。从那以后，我对HA（高可用）有了执念。
常见的方案其实就几种，我整理了个表给你看：
| 层级 | 实现方式 | 典型RTO | 成本 |
|---|---|---|---|
| 存储层 | 主从复制 + 自动故障转移 | 30秒-2分钟 | 中 |
| 计算层 | 多活集群 + session共享 | 秒级 | 高 |
| 接入层 | 多DNS + 健康检查 | 1-5分钟 | 低 |
| 数据备份 | 增量备份 + 异地容灾 | 1-4小时 | 高 |
我个人的做法：优先保证数据层的高可用。应用层挂了还能重启，数据丢了就完了。你想想看，如果用户写了一篇知识文档，结果保存后查不到，那信任感直接崩掉。
3.3 安全性：KM的核心是信任
安全性其实是个系统工程。我见过不少团队，只做了登录认证就认为安全了。结果呢？内部员工通过API遍历所有文档，或者SQL注入把知识库全删了。
KMS安全的三条底线：
- 认证与授权分离：谁可以登录 ≠ 谁可以看文档。我用的是RBAC（基于角色的访问控制），角色粒度可以到「只读」「编辑」「管理」。
- 数据加密：传输层用HTTPS，存储层至少AES-256。敏感字段（如）单独加密存储。
- 审计日志：谁在什么时候看了什么文档，必须可追溯。我曾在项目中被要求提供半年前的访问记录，幸好日志保留策略足够长。
另外，接口层面要防爬虫、防DDoS。我习惯用限流 + IP白名单 + API 三重加固。你想想看，如果外部攻击者能直接搜到公司内部的「薪资调整方案」，那乐子就大了。
3.4 易用性：用户不会为难受的设计买单
易用性这条，很多技术人会忽略。我见过一个KMS，功能很强大，但搜索框要输入SQL语句才能查文档。结果除了开发团队，其他部门没人用。最后项目废了。
好的易用性=低学习成本+低操作成本。我的原则：
- 搜索要像Google一样快：输入关键字，一秒内出结果。后台用Elasticsearch + 分词插件，前端加上模糊匹配。
- 界面不要超过3层：用户打开目录→看到文档列表→点开阅读。如果还要点「展开子目录→选择分类→筛选标签→再展开」——用户直接关浏览器了。
- 文档编辑用Markdown就够了：别搞复杂的富文本编辑器。我在项目中试过好几个，最终都换回Markdown + 预览，简洁且稳定。
嗯，还有一个细节：移动端适配。现在很多人用手机查知识库。如果页面在手机上挤成一团，等于把用户往外推。
3.5 四条原则如何协同？
你可能觉得这些原则互相矛盾。比如高可用需要冗余，但成本高了；安全性做太严，易用性就差了。确实，我经常要在这四个维度之间找平衡。
下面这张图是我的常用框架，你先感受一下：
我个人习惯用这个框架来评审设计方案。每次检查一个点，比如：
- 「这个方案如果用户量翻10倍，还能扛吗？」（可扩展性）
- 「主库挂了怎么办？切换时间能不能接受？」（高可用）
- 「搜索接口有没有做限流？密钥怎么存储？」（安全性）
- 「新员工第一次用，需要培训吗？」（易用性）
四个问题问下来，80%的设计缺陷都能暴露。我有个同事说这叫「四问评审法」，其实哪有那么玄，就是多问自己几个为什么。