作者：HannahLin
起源：medium
有幻想，有干货，微信搜寻 【大迁世界】 关注这个在凌晨还在刷碗的刷碗智。
本文 GitHub https://github.com/qq449245884/xiaozhi 已收录，有一线大厂面试残缺考点、材料以及我的系列文章。
前阵子在与敌人一起策划的后端开发线上分享会 BESG 有成员分享了 TinyURL 的零碎设计 (System Design)，刚好也看到了出名 YouTuber Terry 对于 Google 零碎设计面试的影片，理解到在美国的资讯业，不管你是前端、后端、材料工程师还是 DevOps，System Design 零碎设计简直都是面试时的必考题。
有人可能会感觉，反正那是国外的情况，我在国内找前端的工作，不须要会零碎设计也能够录取吧？是没错，以目前国内的前端业界来看，面试大多是不会考零碎设计的，然而其实学习零碎设计并不仅是为了应酬面试，更是学习如何应酬简单零碎的能力，也是从 Junior 开发者过渡到 Senior 开发者的要害。就算身为前端开发者，也会须要面对越来越简单的零碎，学会根本的零碎设计思维除了能让你更理解零碎的整体架构外，同时也增强在开发时和其余角色沟通与合作的能力。
我是一个刚要进入社会，筹备开始本人第一份正职的菜鸟工程师，次要 focus 在 Web 前端技术，但也热衷于学习后端开发与云端技术。我想透过这篇文章，以本人是前端开发者的角度登程，去介绍我认为前端开发者也该领有的根本零碎设计思维，也就是说次要会介绍零碎设计最表层的元素，而不会去深入探讨每一个技术的深刻实作，指标在广而不在深。
要晓得零碎设计是一门十分十分十分複杂的技术（说了三次，应该理解到底多複杂了😂），相对不是我这样的菜鸡能够精通的，因而这篇文应该会蛮入门也蛮浅的，次要目标是心愿和我一样刚入行的前端开发者在看完文章后，也能领有最根本的零碎设计思维，除了解决 UI 画面与浏览器相干的眉眉角角外，应该也要了解一个合格的零碎在背地是怎麽运作的。
本篇文章的流程会是这样的，首先我会把我认为零碎设计的重要元素列出来，并对每个元素进行更近一步的介绍，等读者有了大略的认知后，再分享我认为在面对零碎设计时能够採用的思维走向，最初再以一个理论的零碎设计范例依照先前介绍的思维走向来解决问题。
以分散式零碎为设计指标
尽管咱们晓得分散式绝对于单机来说简单许多，在单机都解决不好的情况上来碰分散式零碎简直是死路一条，不过单机的 Vertical Scaling 是有侷限性的，并且 Single Point Of Failure 的问题也让零碎充斥危险，要建设一个“牢靠的大型零碎”，採用分散式架构仿佛是无奈防止了。况且在遇到零碎设计面试问题时，通常都会预设要设计的零碎是高流量的，毕竟设计一个只能接受低流量的零碎是毫无意义的，因而本篇文章探讨的零碎设计都会以分散式零碎为出发点。
咱们心愿设计进去的零碎能领有哪些个性？
Scalability 可扩展性
当零碎遇到的流量慢慢变大时，咱们会心愿零碎的服务器或贮存空间也可能跟著扩大，来防止无奈负荷的情况。
用文言一点的形式来比喻的话，想像明天你跟 4 个敌人约好要出去玩，你们租了 Toyota 的四人座 Vios，不过另外 2 集体看到你们要出去玩，就保持要你们带上他们，当然当初 6 集体是塞不下小小的 Vios 的，你们只好换租能够载 6 人的 Luxgen U6。
这就很像是零碎设计 垂直扩大 (Vertical Scaling) 的概念，藉由晋升单机 CPU 或内存来晋升效力。然而这样的晋升是有限度的，想像越来越多敌人想跟你们一起出去玩，你说到了 30 集体，你还能够换包游览车，那 300 个呢？（别跟我说包火车）这时可能就得放弃全副人都挤一台车的形式，改为租用多台游览车来载运所有人。这在零碎设计上称作 程度扩大(Horizontal Scaling)，用多台机器来分流解决单机可能无奈负荷的流量，达到零碎的可扩展性。
Reliability 可靠性
可靠性代表一个零碎在它开始执行之后到某个工夫点，零碎失常执行的机率，也就是零碎无故障执行的概率。
Availability 可用性
可用性是一个容易跟可靠性搞混的指标，它的定义为零碎在面对各种异样时能够正确提供服务的能力，更谨严的定义为“零碎服务不中断运行工夫占理论运行工夫的比例。””如果以公式来看：
Availability % = (available time / total time) *100
因而可用性跟容错性是相关联的，在单机架构下，机器炸了，使用者也 access 不到服务了，而分散式的情况下即便有机器 shutdown，也会由其余机器马上递补上，对用户来说服务始终是可用的，这也是为什麽说分散式零碎能够晋升可用性的起因。
Reliability 与 Availability 这两个指标经常让人搞混，一个 reliable 的零碎通常也会是一个 available 的零碎，Availability 尽管能够透过分散式零碎的冗馀电脑 (redundant) 来达成，但却不能保障这个零碎是 reliable 的。
Efficiency 高效率
代表这个零碎的效率如何，个别常见的指标有零碎的提早 (Latency) 与吞吐量(Throughput).
Latency 提早：执行一个操作要花费的“工夫长度”。以我本人较相熟的 web 畛域来说，Latency 指的是使用者发出请求后，期待 server 接管申请，进行解决后回传给使用者的总破费工夫。
Throughput 吞吐量：以一个工夫区间作为单位，单位工夫内能够执行“几次”操作，或运算的“次数”。同样以 web 来举例，Throughput 指的是单位工夫内服务器能够接管的申请量。
要建构一个高效率的零碎，咱们会心愿零碎能够达到 Low Latency 与 High Throughput。
Manageability 可管理性
故名思义，代表一个零碎是不是方便管理，是不是能疾速迭代新性能？是不是可能疾速追踪 bug？或是能不能把 infrastructure 抽象化，让利用工程师能够专一在程式逻辑的开发。
System Design Common Components & Topics
无论是面对零碎设计的题目或是本人在思考零碎的架构，有些技术是建构分散式零碎时十分重要的元素，理解这些元素将会使咱们对于分散式零碎更加理解，在零碎设计时也更得心应手，这些常见的元素有：
Load Balancer
Web Server
Database (SQL vs NoSQL)
Schema Design
Caching
Replication
Partitions
Sharding
Read/Write Splitting
Algorithm
Queue
Consistent Hashing
Proxy
CAP Theorem
如果要每个技术或概念都介绍的话应该得花不少篇幅，因而这边如果读者对某些概念不相熟，就麻烦自行钻研囉！
面对零碎设计时的思维走向
零碎设计是一个开放式的问题，没有所谓肯定正确且规范的解法，不论哪种办法简直都会带来 trade off，所以我接下来提供的思维走向兴许不是最好最规范的，也不肯定实用于所有的情景，但我认为它能够帮忙咱们疾速建构出零碎的根本雏形与软硬体需要，如果你对系统设计毫无想法，无妨试试看参考这个思维走向，再依据本人的需要去做细部的调整。
Step.1 弄清零碎需要
这是最根本却也是最重要的一步，弄清零碎的需要后，你才晓得本人到底要设计什麽，如果是在零碎设计的面试，这也是应该要尽早跟面试官确定的事。零碎需要一般来说能够分为两种类型：
- Functional Requirements
- Non-Functional Requirements
Functional Requirements 代表零碎该要有的性能，以 YouTube 零碎举例，使用者能够创立本人的频道，也能够去订阅他人的频道，在订阅频道公布新影片时会收到告诉…等等你想得到的各种性能，都算在 Functional Requirements 的领域裡。
Non-Functional Requirements 顾名思义是一些跟零碎性能较无间接关连的需要，例如零碎须要有高可用性、零碎提早须要非常低、须要严格的材料一致性…等等。
Step.2 对于零碎流量、容量、网络带宽等指标的粗略计算
对系统的流量、贮存空间、网络做初步的估算，对于前面要思考 scaling、caching、load balancing 时是有帮忙的，再者对这些指标进行评估，也让咱们能够更好的把握零碎的资源老本。
同样以设计 YouTube 来举例，咱们能够先估算零碎大概会有多少使用者，其中又有多少 DAU (Daily Activated User)，估算一天大概会有几部影片上传，影片建设跟读取的比例是多少…等等，这是比拟偏差零碎流量的考量。
下一步能够估算零碎的贮存容量，例如每年贮存影片的总容量大概是多少？贮存的材料会存活多久？如果零碎有实作 Caching，Memory 的用量又大略是多少？
而最初网络贷款也是咱们能够当时预估的指标。
如果读者不晓得怎麽计算这些指标也不要放心，在下一个章节会以设计 Instagram 为范例跑一次零碎设计流程，到时候会示范估算这些指标的形式。
Step.3 定义 System Interface
当咱们釐清零碎的需要后，就能够依照需要来粗略规划系统的 API，这也能够让咱们确认先前订出的零碎需要并没有定义谬误。这时能够先思考零碎要採用哪种 API 架构，例如 REST APIs、SOAP、GraphQL，再来能够简略定义出有哪些 API endpoints，以 YouTube 来举例：
uploadVideo(user_id, video_content, video_location, user_location, ……)
addVideoToFavorite(user_id, video_id, timestamp, …….)
Step.4 定义 Data Model | DB Schema
在 System Design 的前段及早定义出 DB Schema 将帮忙咱们更分明零碎的材料流，咱们应该分明不同 Entities 之间是怎麽互动与沟通的，以 YouTube 为例，Data Model 可能是这样子：
User: UserID, Name, Email, DoB, CreationDate, LastLogin, ….
Video: VideoID,VideoLink, VideoLocation, NumberOfLikes, TimeStamp, …
.….
在这个阶段也能够先思考到底零碎适宜哪种资料库？RDBMS 还是 NoSQL ? 还有使用者上传的影片与图片，又适宜贮存在哪呢？
Step.5 High-level design
这步骤是零碎的 High-level 设计，能够在一张图表画出零碎大略由哪些 Components 组成，因为先前步骤曾经确定了零碎需要，也对流量做了初步估算，所以在这个步骤咱们能够设计零碎需不需要做分流、读写拆散，以 YouTube 的例子来说，咱们可能还须要一个分散式的档案贮存零碎来寄存影片。
Step.6 System Detailed design
先实现 high-level 的零碎设计，接下来才进入零碎的 detailed design，如果是面对零碎面试，在工夫无限的情况下，能够针对后面 high-level design 画出的架构图裡挑出两三个 components 来阐明就好，而这边倡议能够跟著面试官的疏导走。（如果不是在面试，当然你就有大把工夫能够好好对每个环节做 detailed 的设计了）
针对特定的 component 或 topic，咱们能够提供两三种可行的办法，并思考它们各自的优缺点，这也是个开放性的问题，重要的是你要能分明每种形式的 trade off，并找出最“适宜”本人零碎的做法。
- 在须要存取大量材料的状况下，咱们该怎麽把材料做 partition 并且存到不同资料库伺服器裡 ?
- 咱们应该在零碎的哪些 layer 退出快取服务 ?
- 零碎中哪些局部比拟须要做 load balancing ?
Step.7 找到零碎可能瓶颈或 trade off 并尝试给出解决方案
如果是在零碎设计的面试中，在做完零碎架构设计之后，能够针对本人设计的零碎提出一些可能的瓶颈，毕竟没有所谓完满的零碎架构，可能讲出本人所设计的零碎有哪些缺点或瓶颈，代表你对系统整体的把握度是高的，兴许在面试官的眼中是加分的行为（不过这边可能得留神挖坑给本人跳的情况）。
尝试设计一个 Instagram 吧！
尽管晓得了面对零碎设计能够採取的思路，但我置信各位读者看到这裡还是感觉非常形象吧？那不如咱们就依照后面的思考步骤理论设计一个 IG 零碎领会看看吧！（上面代称这个零碎为“Fake IG”好了😆）
（大家应该都晓得 IG 是什麽吧！？🤔）
Step.1 理清零碎需要
后面有提到能够针对“Functional Requirements”与“Non-Functional Requirements”来辨别零碎需要
Functional Requirements:
- 使用者能够上传照片、影片，另外也能够读取与下载
- 使用者能够追踪其余使用者以观看最新贴文
- 使用者能够依据 tags 来搜查文章
- 当使用者刷新页面后，零碎会依据使用者追踪的人显示该些用户的最新贴文
Non-Functional Requirements:
- Fake IG 零碎须要具备高可用性（high availability）
- 刷新页面看最新贴文时能够容许短暂的提早
- 在某些情况下，零碎的一致性能够就义，例如使用者贴文的爱心数量（每个使用者看到的数量即便不一样，也不会造成什麽影响）
- 零碎心愿能够领有高可靠性（high reliability），使用者上传的照片、影片不可能遗失
咱们都晓得实际上 IG 的性能相对比下面列出来的还要多，例如在照片上标记其余使用者、限时动静…等等，这些较进阶的性能能够本人思考要不要列出。（设计出基本功能比拟重要）
Step.2 对于零碎流量、容量、网络带宽等指标的粗略计算
对于零碎的流量，咱们能够先假如高一点，毕竟设计能面对高流量的零碎才有意思。假如咱们的 Fake IG 零碎的使用者总人数有 5000 万人，当然裡面不乏许多早就没在应用的幽灵用户，所以这边假如每天依然沉闷的用户（daily active users, DAU）有 100 万人。
接下来咱们先疏忽使用者能够上传影片这个行为，先限定使用者只可能上传照片，不然要思考的因素切实太多了。假如一天大概有 150 万张照片会被上传，均匀一张照片的档案大小为 250 KB，那麽贮存一天中新上传的照片总共须要的容量为
1.5M * 250KB ~= 375GB
如果将工夫拉远来看，10 年下来寄存照片须要的容量为
375GB 365(days) 10 ~= 1368.75TB
当你在前面的步骤定义好 DB Schema 后，也能够再回过头来用同样的形式估算资料库要贮存的材料总大小，例如咱们的零碎肯定会有贮存用户资讯的 User Table，而它的栏位与空间如下
UserID (4 bytes) + Name (20 bytes) + Email (32 bytes) + Birthday (4 bytes) + CreationDate (4 bytes) = 64 bytes
先前有假如 Fake IG 的使用者总人数有 5000 万人，因而贮存用户资讯的 total storage 约为：
50M* 64 ~=3.2GB
其余的 DB Schema 与上传图片应用的 Network Bandwidth 也能够採用相似的办法估算须要的容量。
Step.3 定义 System Interface
规划系统 API 的步骤，因为是一个非常开放式的问题，答案也不太会影响接下来的步骤因而这边就不多花篇幅阐明。
Step.4 定义 Data Model | DB Schema
定义出 Data Model 能够让咱们分明数据的关联与数据的流动，在将来要做 data sharding 或 partitioning 时也会比拟容易。在 Fake IG 零碎中，咱们先假如只须要先思考使用者与用户上传的照片就好（不然我这边会写不完，还请高抬贵手），在学生期间非常认真修资料库课程的你可能会马上画出以下的数据库关联图
画完图后你可能会感觉这个 use case 还蛮适宜应用如 MySQL 的 RDBMS 的，毕竟数据是有 join 的需要的。不过 RDBMS 在 Scaling 上是十分十分複杂且艰难的，例如数据一致性的解决形式也与单机时大不相同。而应用 NoSQL 其实也是可行的，尽管可能须要一些额定的 table 来贮存数据的关联（例如 UserPhoto），不过在 Scaling 上却较为简单。我也没方法通知你，应用 RDBMS 还是 NoSQL 好，它们各有各的优缺点也有各自实用的机会，因而这个问题也算是开放式的，应该在多深刻理解后再做出抉择。
另外像照片影片这种资源，个别会须要像是 AWS S3 这样的 Distributed File Storage，而在咱们的数据库中则只存图片或影片在 file storage 的 link 还有其余的 meatdata。
Step.5 High-level design
当然咱们也不肯定要画出整个零碎的架构图，尤其是在面试的话，咱们得在无限的工夫内尽量 focus 在零碎的重点局部，以 Fake IG 来说咱们先试着设计使用者上传照片与读取照片的性能。
以 high-level 的角度来看 Fake IG 的照片零碎，大抵上会有两种情境，也就是用户上传照片与读取照片，所以咱们会须要一台 application server 来解决使用者的读写 requests，另外会须要一个如 AWS S3 一样的分散式 file Storage 来贮存照片，另外也会再开一个 database 来贮存照片相干的 metadata。
Step.6 System Detailed design
不过认真思考就会晓得上传照片相比读取照片所消耗的工夫会多出更多，因为上传照片可能波及了硬盘的写入，也不像读取一样能够加一层快照层。通常 web server 是有连线数量的限度的，如果上传照片的过程太耗时，可能会占用 web server 的连线申请，导致要读取照片的 request 被卡住，造成响应的提早。要解决这个 bottleneck 的其中一种形式就是将读取与上传拆成两个独立的 server 来别离解决申请，而负责上传照片的 server 还能搭配 message queue 来消化申请。这样的做法还有一个益处就是两个服务能够按照需要各自 Scale 与 Opimize。
对于 Availability 与 Reliability，也能够思考为零碎的各个 component 退出 replica service，这样 horizontal scaling 的后果是能够防止 single point of failure，在其中一个服务节点挂掉时仍能放弃零碎可用性，搭配 Load Balancer 也能够做到流量的分流，升高零碎的提早。
提到 Load Balancer，它的目标是达成 horizontal scaling，不过它也可能会有 single point of failure 的危险，因而 replica 也能够利用在它下面。就算是只须要一个 instance 来运作的服务，也能够为其建设 redundant secondary copy，这个 copy 不会 serve 任何的流量，却能够当作备胎，在主服务挂掉时立刻取代它的工作成为 master node。
同样的 Scaling 思维也实用于贮存服务例如 Fake IG 应用的 File Storage 与 Database，毕竟咱们不心愿零碎呈现档案或材料遗失的情况，因而能够为 Database 与 File Storage 加 backup server，让数据也能够防止单点生效后遗失的问题。
不过还是得呐喊一下，加 replica services 未必能改善所有性能或其余的瓶颈，再来老本也是须要考量的一个元素，因而还是得按照需要审慎评估是否须要 scaling，需要的话也要审慎评估 scaling 的水平。
更进一步能够思考 database 数据是不是须要 Partitioning 或 Sharding，前者是在同一个数据库中将 table 拆成数个小 table，后者则是将 table 放到数个数据库中。
Partitioning 的 table 与 schema 可能会扭转，Sharding 的 schema 则是雷同，但扩散在不同数据库中，Partitioning 是为了扩散单表的压力，Sharding 则是扩散单库的压力，实际上还是要按照需要找出适宜以后零碎的形式。
以 Fake IG 来说，如果真要抉择我可能会抉择比拟容易扩大的 Sharding，不过 Sharding 也带来相当多的问题例如横跨不同 shards 的 transaction、rollback、schema change、join、每个 shard db 还要另外去做 backup……等等。
如果抉择了 Sharding 的形式，那麽 Shard 时依赖的 key 就很重要了，一般来说能够分为 Range-based 与 Hash 两种形式（如果齐全不晓得 Sharding 的读者能够参考我之前的笔记文章），假如咱们以 userId 来作为 shard 的 key，那可能会呈现 hot user 造成某一个数据库 loading 过重的问题（想想那些在 IG 上追踪人数破亿的寰球巨星，一天不晓得会有多少使用者去浏览他们的文章呢，那麽存取这些明星数据的数据库可能流量就会比其余 instance 还要大很多）。
总之我感觉 Sharding 的複杂度还有坑真的是挺多的，兴许在一开始得先思考分明零碎是不是真的须要 Sharding，如果在面试提出要做 Sharding 或 Partitioning，也要做好万全筹备，免得只是挖更多坑给本人跳。
当然 Caching 也是一个必然要思考的机制，因为 Fake IG 会产生许多图片，而这些资源非常适合暂存在离 end users 更靠近的 CDN 裡。除了 CDN Cache，也能够在数据库前加一个例如 Memcache 的快照服务器，用来暂存一些较常被抓取的材料。
对于到底要存哪些数据到快照这个问题，咱们不可能把所数据都放到快照裡，依据“80–20 Rule”，80% 的流量可能都来自于 20% 的 hot data，因而咱们能够找出较常被 user 存取的 20% photo 与 metadata 数据存到缓存中。
而快照是须要一些革除策略（cache eviction policy）的，不然有限增长的情况下很容易就没有快照空间了。在 Fake IG 零碎中，我感觉 LRU Cache（Least Recently Used Cache）就还蛮适宜的，当要革除快取空间时，能够先从近期起码被存取的数据开始移除。
总结
尽管说身为前端开发者，在求职过程甚至是整个职涯都有可能不会碰到零碎设计相干的问题，不过因为我将本人定义为杂食性的软体工程师，遇到有趣味、有挑战性的技术我都想学，再加上本人始终有个不切实际的硅谷梦，所以仍然坚信本人将来某一天也会遇到零碎设计的挑战。而本人也确实在接触这些内容后对整个零碎利用架构有了更进一步的理解，所以我十分举荐前端开发者也能够尝试理解最根底的零碎设计。
原文：https://medium.com/starbugs/%…
交换
有幻想，有干货，微信搜寻 【大迁世界】 关注这个在凌晨还在刷碗的刷碗智。
本文 GitHub https://github.com/qq44924588… 已收录，有一线大厂面试残缺考点、材料以及我的系列文章。