一、什麼是可擴展性？
Scalability is the property of a system to handle a growing amount of work by adding resources to the system.
可擴展性，意味著能夠通過向系統添加資源的方式應對不斷增加的工作量。而加資源有兩種方式：
-
縱向擴展（Vertical scaling）：即提升單機配置，對單台機器加內存、處理器、硬盤等硬件資源。投入足夠多的預算，就能砸出一台配置豪華的服務器
-
橫向擴展（Horizontal scaling）：即加機器，數量上從一台擴展到多台，多服務器形成拓撲結構。投入足夠多的預算，就能擁有一個機房，甚至遍佈全球的數據中心
對於系統設計而言，可擴展性要求系統能夠將加入進來的更多資源（如多核、多機）利用起來
二、貫穿系統設計的可擴展性鬥爭
一個用戶請求從客戶端出發，經過網絡傳輸，達到 Web 服務層，接著進入應用層，最後抵達數據層：
對應到系統設計中的各個邏輯層：
途徑的每一層都有其特定的可擴展性模式：
最後形成了如此複雜的系統架構：
其運作機制如下：
-
客戶端查 DNS 得到服務對應的 IP 地址，可能指向位於 Web 服務之前的 負載均衡器，也可能是 CDN，就近提供對象存儲中的靜態資源
-
湧向 Web 服務的請求被負載均衡器（比如 反向代理）按照既定策略分發給相應的 Web 服務器，進入應用層
-
請求到達應用層後，經過 Service Discovery、Service Mesh 等服務查詢機制找到目標 微服務，開始處理請求
-
數據請求會通過一系列讀/寫 API 最終轉到數據層，異步的操作還會進入 消息隊列 排隊，但最終都會抵達數據層
-
對熱點數據的請求會被數據庫之前的 緩存層 擋下來，其餘的落到數據庫，可能是經過 分庫分表、反範式優化，並由 複製機制 保證數據一致性的 SQL 數據庫，也可能是查詢性能更好的 NoSQL 數據庫，抑或對象存儲
其中，許多模式在解決一些問題的同時，又帶來了一些新的問題，因此，在系統設計中，大到 CAP 的抉擇，小到分發策略的制定，總在不停地進行 權衡取捨
三、商業化背景下的可擴展性要求
至此，系統設計中常用的擴展性模式都已經梳理清楚了
回過頭來再看可擴展性：
可擴展性，意味著能夠通過向系統添加資源的方式應對不斷增加的工作量
單從定義來看，一個系統只要能把加進來的資源利用起來，進而有能力承擔更多的工作量，那它就是可擴展的，這也確實是可擴展性的基本要求
然而，實際場景中（商業化背景下），我們對可擴展性提出了更高的要求：
[caption id="attachment_2154" align="alignnone" width="625"]
what does it mean to be scalable[/caption]
很多時候，無腦加資源確實能解決問題，但對於可擴展性而言，燒錢是可恥的：
Well, you can just throw hardware at the problem which is the thing that's thrown around our industry a lot. And I think it's a little bit of a shame, because it is just effectively like burning money.
也就是說，要求系統不僅能利用，而且要盡可能高效地利用加進來的資源，而不只是一味地靠加資源實現線性擴展
而利用率的衡量標準通常是單筆交���的成本（在非交易系統中可能是其它類似的業務指標）：
單筆交易成本 = 總成本 / 交易量
其中，成本分為固定成本和可變成本兩部分：
-
固定成本：前期工作和基礎設施、攤銷費用、資本成本、經營成本等
-
可變成本：能否按需使用、批量是否有折扣、確保資源可用（維護管理等）
因此，在商業化背景下，可擴展性要回答的問題是，加 1 台機器進來，能多支持多少業務量：
A typical question I would ask of anyone is if you add another node to your system how many more units of work or transactions or whatever do you get out of that.
不只是確信加機器能應對更多的工作量，還要精確地知道「更多」是多少，進而優化成本，精益求精
暫無評論，快來發表你的看法吧