好的系统是迭代出来的，个人对于系统设计原则的理解也从个人成长的迭代进度来考虑。
- 幂等原则
- 可重复原则
- 可扩展原则
- 可追溯原则
- 反馈原则
- 无状态原则
- 切分原则
- 备份原则
在最初根据任务来写 API 阶段时，主要考虑：
幂等原则
每个 API 重复访问结果一致。
如用 Restful API时 Put 请求修改资源指定修改后的结果是什么样，而不是根据当前资源进行 switch 类的切换。
可重复原则（DRY 原则）
开发可复用的逻辑块，而不是一直 Copy-Paste。
可扩展原则
当需求变化或使用技术进行变化的时候，都会引发代码的变动，如果能在写代码之初就能考虑到扩展性，那遇到变化的时候会有所准备。
可追溯原则
自己写完 API 一定要有观测、调试的方法，最基本的就是日志，日志的输出位置和分级就很重要。l
根据日志的输出可以追溯到某个业务链（Request-ID）执行逻辑是什么样的。
根据日志的分级，可以筛选出重要的和不重要的信息，如按以下原则：
- Info 的用于普通记录；
- Warning 的用于记录警告性的，原则上要引起注意，但可以不修复的日志；
- Error 级别的日志都是要修复处理的。
反馈原则
如 HTTP 返回，用状态码 + 辅助信息向请求者进行反馈，尤其是 4xx 的错误，返回具体直观的描述信息可以方便他人和自己定位问题。
但同时也要考虑隐私性，如返回用户不存在和用户密码错误可能会招致一些攻击。如果用输入验证码能 cover 住这些攻击的话就可以放开一些。
当自己有能力负责一个模块后，涉及到表的结构设计和整个系统如分布式的考虑，要考虑：
无状态原则
每个服务不记录自己请求的状态，这样可以方便地进行复制扩展。
当然，如果像 Sip 这样本身有状态的协议，就必须有状态了，需要从系统架构方面增加有会话状态的负载均衡来处理。
切分原则
当业务压力大或系统复杂的时候，就需要考虑按一定规则进行分片（分成多个微服务、或仅一个服务但各自处理不同）。
分片原则按不同的维度有不同的策略，如：
- 按地域切分（根据用户 IP 所在位置）
- 按系统切分（分服务，如订单系统、商品系统等）
- 按功能切分（可以分服务，也可以服务复制后将某 URL 固定定位到某服务下，如个人订单、商业订单等）
- 服务化原则（使用节点集群的服务化，用集群提供服务需要考虑：自动注册和发现，熔断、限流、降级，隔离和恢复等）
- 按读写原则切分，将热资源和冷资源进行切分，热资源使用更多的系统资源，或进行服务复制，冷资源使用更少的资源或复制
在表的设计上也能体现切分的原则。
备份原则
当服务变大的时候，新人很难很快地了解业务以及代码，这时就发现备份原则的重要性。
要注意将业务文档化，将配置信息文档化等等，以及还要考虑人才流失的人员备份。
网友评论