识别系统复杂性点

通过熟悉和理解需求，识别系统复杂性所在的地方，然后针对这些复杂点进行架构设计。

忌贪大求全

架构设计并不是要面面俱到，不需要每个架构都具备高性能、高可用、高扩展等特点，而是要识别出复杂点然后有针对性地解决问题。

• 我们的系统一定要做到每秒 TPS 10 万？
  如果系统的复杂度不是在性能这部分，TPS 做到 10 万并没有什么用。

• 淘宝的架构是这么做的，我们也要这么做？
  淘宝的架构是为了解决淘宝业务的复杂度而设计的，淘宝的业务复杂度并不就是我们的业务复杂度，绝大多数业务的用户量都不可能有淘宝那么大。

• Docker 现在很流行，我们的架构应该将 Docker 应用进来？
  Docker 不是万能的，只是为了解决资源重用和动态分配而设计的，如果我们的系统复杂度根本不是在这方面，引入 Docker 没有什么意义。

参考其他架构

多参考其他架构没问题，需要理解每个架构方案背后真实解决的复杂点，然后才能对比自己的业务复杂点，参考复杂点相似的方案。

案例分析

需求：我们需要设计一个大学的学生管理系统，其基本功能包括登录、注册、成绩管理、课程管理等。

分析理解需求，识别复杂度：

• 性能：一个学校的学生大约 1 ~ 2 万人，学生管理系统的访问频率并不高，平均每天单个学生的访问次数平均不到 1 次，因此性能这部分并不复杂，存储用 MySQL 完全能够胜任，缓存都可以不用，Web 服务器用 Nginx 绰绰有余。
• 可扩展性：学生管理系统的功能比较稳定，可扩展的空间并不大，因此可扩展性也不复杂。
• 高可用：学生管理系统即使宕机 2 小时，对学生管理工作影响并不大，因此可以不做负载均衡，更不用考虑异地多活这类复杂的方案了。但是，如果学生的数据全部丢失，修复是非常麻烦的，只能靠人工逐条修复，这个很难接受，因此需要考虑存储高可靠，这里就有点复杂了。我们需要考虑多种异常情况：机器故障、机房故障，针对机器故障，我们需要设计 MySQL 同机房主备方案；针对机房故障，我们需要设计 MySQL 跨机房同步方案。
• 安全性：学生管理系统存储的信息有一定的隐私性，例如学生的家庭情况，但并不是和金融相关的，也不包含强隐私的信息，因此安全性方面只要做 3 个事情就基本满足要求了：Nginx 提供 ACL 控制、用户账号密码管理、数据库访问权限控制。
• 成本：由于系统很简单，基本上几台服务器就能够搞定，对于一所大学来说完全不是问题，可以无需太多关注。
• 其他方面

通过我上面的分析，可以看到这个方案的主要复杂性体现在存储可靠性上，需要保证异常的时候，不要丢失所有数据即可（丢失几个或者几十个学生的信息问题不大），对应的架构如下：

--------来源《极客课程》∙ 学习摘要

最后

以上就是贤惠西牛为你收集整理的架构设计的目的识别系统复杂性点忌贪大求全参考其他架构案例分析的全部内容，希望文章能够帮你解决架构设计的目的识别系统复杂性点忌贪大求全参考其他架构案例分析所遇到的程序开发问题。

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