系统设计的10考虑

1.考虑一：负负得正

如果把错误的逻辑改对了反而可能引起问题。

这种问题要避免最好的时机是初版设计和开发阶段就避免。除了设计阶段逻辑要清晰，代码要做好审查、加上单体测试等测试手段外，可以将中间结果用debug日志打印。建议自测阶段多用debug级别日志跑几遍，进行观察。

2.考虑二：终态设计

在分布式系统中，由于系统是分布在不同机器上的。还可能有一种状态叫：超时。成功、失败。

超时不是终态，而是一种中间状态：最终有可能下游是成功了，也有可能是失败了。这时候我们需要在超时之后推定一种状态，推定成功或者失败。究竟是成功还是失败因功能而异。

比如付款操作，需要推定失败。如果不知道是否成功就推定是成功的，那用户可能没有付款就拿到了商品或者享受了服务，商家就会资金损失。推定失败让用户再次支付，最终通过查询或者对账发现用户实际是支付成功的，可以再把钱给用户退回去，保证交易的公平性。

退款恰恰相反，需要推定成功。告诉用户，钱退给你了。最终通过查询或者对账发现实际是退款失败了，可以系统重新发起退款，直到真正退成功为止。

后台管理系统也很需要这种终态设计。比如发布系统，发布了一个功能，发布系统如果出现了问题，这次发布没有结束。用户可能没有办法进行下一次发布。这时候可以设置超时自动结束，防止未结束的流程始终在那里。

3.考虑三：长尾效应

常见的有服务过载和队列过长。如果长尾处理不好，有可能上游判定超时，导致请求失败，影响正确性。需要系统处理好超时和重试。

4.考虑四：存储周期

数据库、应用系统的磁盘都是宝贵的资源。数据不能无限期存储不做清理。清理的周期是一个重要的考虑方面。因为这涉及对用户的承诺。

对数据库来说，比如交易库数据半年清理一次。那就要跟用户说清楚半年以上的交易不允许退款。因为原交易已经不在数据库，而是归档到大数据了。

对磁盘来说，如果应用日志是30天清理一次。那就要跟用户达成一致，非重大问题30天以上的不予追溯。为什么这里说重大问题呢，其实很多公司磁盘清理了，数据在hbase等大数据设备里还是有留存的。只是查询没有磁盘日志便利。

5.考虑五：AKF扩展

AKF扩展立方体（Scalability Cube）。

X轴 —— 代表无差别的克隆服务和数据，工作可以很均匀的分散在不同的服务实例上；

Y轴 —— 关注应用中职责的划分，比如数据类型，交易执行类型的划分；

Z轴 —— 关注服务和数据的优先级划分，如分地域划分。

X轴拆分就是通过加机器水平拆分，就是横向扩展；Y轴拆分就是按业务逻辑垂直拆分；Z轴拆分就是按照算法进行分片，这个算法比如按地域，不同地域访问不同的分片或者服务。

举个例子，比如一般公司的redis集群会有一个团队来进行统一维护。redis集群有主有从，数据都是一样的，多副本容灾，这是X轴水平的拆分。一个公司很多业务，redis团队会对不同的业务提供不同的集群，这是Y轴垂直拆分；集群内部数据会通过sharding做分片，这是Z轴算法拆分。

6.考虑六：服务自治

当一个服务的逻辑单元由自身的领域边界内所控制，不受其他外界条件的影响（外界条件带有不可预测性），且运行环境是自身可控，完全自给自足，我们认为这个服务是自治的。

在系统设计时，要考虑服务上线后，对于问题要自感知、自修复、自优化、自运维及自安全。

7.考虑七：应急预案

SOP（Standard Operating Procedure三个单词中首字母的大写 ）即标准作业程序，就是将某一事件的标准操作步骤和要求以统一的格式描述出来，用来指导和规范日常的工作。

EOP（Emergency Operating Procedure三个单词中首字母的大写 ）即应急操作流程，用于规范应急操作过程中的流程及操作步骤。确保人员可以迅速启动，确保有序、有效地组织实施各项应对措施。

这两种操作流程需要平时就整理好，避免紧急情况下思虑不周导致操作时的二次故障。

8.考虑八：故障隔离

领域拆分隔离方面

• ACL防止损坏层

• 有界上下文

• 提炼核心、支撑和通用域

• 分层架构

• CRUD增删改查简单架构

• CQRS命令查询隔离

• 依赖消弱控

服务部署隔离方面

• 环境拆分

• 机房隔离

• 通道隔离

• 单元化

• 泳道

• 热点隔离

• 读写隔离

• 容器隔离

• 拆库拆表

• 动静隔离

• 非核心流量隔离

服务间交互隔离方面

• 超时熔断

• 失败率超限降级

• 服务内资源隔离方面

• 线程池隔离

• 信号量隔离

9.考虑九：风险巡检

核心系统稳定之后，更多的从边缘进行优化，避免影响核心系统的稳定。风险巡检是优化的重要方面。常见的有以下内容。

• 请求系统错误统计

• 请求业务错误统计

• 请求内部错误统计

• 慢查询统计巡检

• 数据一致性巡检

• 流程执行情况巡检

10.考虑十一严格准入

做需求有个常识，对于用户输入的每个字段都需要和产品经理讨论一下：什么类型、长度多少、允许的字符集范围、格式是否合法。这么做一方面是设计问题，包括产品设计、数据库设计，还有一部分是安全问题：一个数值型的字段肯定比一个粗放的文本型字段被攻击的可能性小，起码不会传到后端之后被当成脚本被执行。

操作合理性准入也是考虑的重要方面。比如一个普通用户不能编辑另一个用户的个人信息。比如i申请公司服务器，一次申请1万台机器。比如流量准入，一台机器以超快的速度频繁访问一个网站的资讯信息，就可能不是真实用户操作而是爬虫。以上都会对系统安全性产生极大的影响。

最后

以上就是老实大山为你收集整理的系统设计的10考虑的全部内容，希望文章能够帮你解决系统设计的10考虑所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。