后端系统设计是什么？后端系统设计的思考架构

本篇详细解说本收录在 E+ 的后端系统设计专题

在前一篇的前端系统设计的思考架构文中，我们谈了前端系统设计可以用的思考框架，在这一篇我们将谈后端系统设计可以用的思考架构。特别备注，这篇会谈的后端系统设计，是指一般软体工程师、后端工程师，或者全端工程师会要做的系统设计。

不论是在实际工作或者面试，如果在做系统设计时，你不知该如何下手，相信这篇可以给你一个基本的思考架构。

后端系统设计的思考架构

在做后端系统设计时，我们推荐可以用三步骤来协助思考，这三步骤分别是

需求探索 (Requirements)
架构建立 (Architecture)
深入设计 (Deep dive)

如同在前端篇谈到的，要设计出适当的系统，会需要先厘清需求，才能确保解决到对的问题。而在定义完需求后，接着要根据需求来建立系统的架构，在这阶段要确保整体架构能呼应需求。最后针对系统的特性 (例如需要高可用，或者高一致性) 来深入设计。

让我们进一步来看这个架构的三步骤分别可以如何运用。

需求探索 (Requirements)

不论在实际工作，或者在后端系统设计的面试，经常会遇到需求没有清楚定义的时候。从工作的角度看，产品经理会从产品的角度出发提需求，然后许多需求需要深入考虑技术可行性，这时就会需要由工程端进一步提问题厘清，透过多个角度，把整个系统设计地更完整。

而从面试的角度看，因为面试官会想检验候选人是否具备探索需求、厘清需求的能力，往往在面试最开始，不会把所有讯息完整跟候选人说，这时会需要候选人主动提厘清的问题，来确保有解决到最关键的问题。

不论在工作或面试，当遇到一个需求，如果没有厘清，会是工程师的大忌。先前 Meta 主任工程师 Ryan Peterman 分享到，初阶工程师会抱怨产品经理的叙述不够清楚；资深工程师则会主动协助把不清楚的地方理清楚。如果想要往资深迈进，有任何模糊不清处的地方，务必要在最开始就厘清。

当然，如果从面试的角度来说，因为时间有限，尽量可以在最开头的五分钟，把关键点问清楚。通常这会分成两个区块，分别是功能需求，以及非功能需求。

功能需求

功能需求是从使用者的角度来看，可以使用「使用者要能够...」做为开头句来思考。可以从产品的角度来思考，产品要提供给使用者什么功能。同时可以思考有哪些功能是必要的，哪些是相对次要的。

例如以设计一个动态墙系统来说，贴文、追踪等功能是一定需要，但是按赞、通知可能不一定在最开始就是必要的。假如你没有办法确定哪个是必要的，就提出厘清问题把它确定下来。

非功能需求

而非功能需求则是从系统的角度来看，可以使用「系统要能够...」做为开头句来思考。在思考非功能需求时，可以把这类需求理解成品质。举例来说，「高可用性」是系统设计中很常会有的非功能需求，在一个系统中，就算可用性很低，也仍能够达到其功能，只是会让人觉得品质很差；而当能够照顾好非功能需求，就会让人觉得系统的品质好。

常见的非功能需求包含：

例如有多少使用者，要扩展到什么量级?
对于延迟 (latency) 的要求是什么?
可用性或一致性之中，比较看重哪一个?

但要特别注意，在一个系统中，可能不同的子系统，会有不同的非功能需求的要求。举例来说，举例来说，在一个电商系统当中，商品展示的部分会需要高可用，但一致性要求可能还好；而在订单部分为了避免重复下单，会需要高一致性，这种情况可用性可以相对被牺牲。

所以尽可能厘清时，不要通则地说「这个系统要高可用」，而是要去厘清功能需求中，不同的功能分别有哪些特性，并依照这些特性，来思考子系统要满足哪些非功能需求。

另外，在厘清非功能需求时，也要确保是足够明确的。举例来说，「系统要高可用」是相对抽象不具体的，比较好的描述会是这个系统的可用性要达到几个 9。

什么不在讨论范围中 (out of scope)

除了讨论功能与非功能需求，列清楚什么不在讨论范围内 (out of scope) 也是非常重要的。在现实工作中，很多系统中的非主要元件，很可能早就有现成的能使用。

举例来说，权限相关的问题，很可能公司已经有可以用的现成 SDK 可以串。因此在现实工作中，这些就不会是讨论重点。同样的道理，在面试中也有很多不是该系统的重点面向，这时不推荐大家花时间在那些面向的讨论 (毕竟面试时间有限的)。

进一步说，在面试当中，去讨论什么在范围、什么不再范围，可以展示出「自己有排定优先顺序的能力」，这会加分很多，因此特别推荐在面试时，可以特别拉出来跟面试官确认，例如可以说「从刚刚的厘清中，我认为以下这些对这个系统来说，不是最重要的，或许我们可以先不用深入谈。不知你觉得这样如何?」。

本文为 E+ 成长计划的深度内容，截取前三分之一开放免费阅读。欢迎加入 E+ 成长计划阅读完整版本 (点此了解 E+ 的详细介绍)