一個系統走向分散式，一定有其不得不為的理由。Scalability是最常見的理由之一。

我先簡單的將Scalabilty的需求分成兩種：

• Data Scalability: 單台機器的容量不足以(經濟的)承載所有資料，所以需要分散。如：NoSQL
• Computing Scalability: 單台機器的運算能力不足以(經濟的)及時完成運算，所以需要分散。如：科學運算。

在之後幾天，我會試著就這兩種需求來解析其中會遇到的問題與常見解法。

不管是哪一種需求，在決定採用分散式架構時，就幾乎註定要接受一些犧牲：

• 犧牲效率：網路延遲 與 節點間的協調，都會降低執行效率。
• 犧牲AP彈性：有些在單機上能執行的運算，無法輕易在分散式環境中完成。
• 犧牲維護維運能力：分散式架構的問題常常很難重現，也很難追蹤。

另外，跟單機系統一樣，也有一些系統設計上的tradeoffs

• CPU使用效率優化 或是 IO效率優化
• 讀取優化 或是 寫入優化
• Throughput優化 或是 Latency優化
• 資料一致性 或是 資料可得性

選擇了不同的tradeoff，就會有不同的系統架構。
下次我們就來談一下，哪些面向的設計決策，會塑造出不同特質的分散式系統。