在談到選擇服務部署的架構，為了避免機器壞掉而造成服務暫停、甚至是資料流失時，我們常會考慮要將服務部署在多台機上，這樣當其中一台失效時，我們的服務和資料都還能活的好好的。

然而，超過一台機器的部署架構，就是所謂的「分散式系統」了，既然是分散式系統，就不免俗的要帶入 CAP 理論來評估，也就會將複雜性提高一個數量級。

所以我的問題是，如果我們的服務規模沒有這麼大，真的有必要使用分散式系統嗎？

什麼是 CAP 理論？

我們先來聊聊 CAP 理論，所謂的 CAP 是三個屬性的首字母集合：Consistency（一致性）、Availability（可用性）、Partition Tolerance（分區容錯性）。其核心所說的是一個分散式系統無法同時滿足這三個屬性，只能夠在這中挑兩個：不是 CA 就是 CP 或 AP。

一致性和可用性很好理解，就是整個系統向不同節點取得的資料是否一致、是否在任何時間送出請求都能得到回覆。

但分區容錯性就稍稍有點難理解了，這裡的「分區」（Partition）現象指的是不同節點間無法互相溝通，可能是中間的網路斷了，也可能是某台機器壞了，最終造成分區。

*分區現象

當一有分區的現象產生，這兩個 Partition 的資料就沒有辦法同步，若此時我們分別向兩個 Partition 取得資料，就可能會有資料不一致的問題。

如果要保持一致，我們就得等這兩個分區的斷線恢復，讓資料同步之後再提供服務，那也就意味可用性被犧牲了。

然而糟糕的是，我們沒有辦法避免分區的產生，因為網路會不會斷、機器會不會壞，都是我們所無法控制的。

*CAP 理論

所以在 Partition Tolerance 無法被捨棄的情況下，我們便無法選擇 CA 這個同時滿足一致性和可用性的選項，只能夠在 CP 和 AP 中挑一個。

從需求下手看部署架構

如果我們部署服務的時候，選擇了分散式的架構，就會面臨種種問題需要做考慮，像是資料同步問題、節點間的狀態怎麼互相傳遞、機器故障時的導流問題等等，複雜度比集中式的架構高了非常多。

如同我們在聊簡單原則時提過，如果沒有必要，應該挑簡單的方式去做。

那麼是否有真的要做分散式系統的必要性呢？我們可以簡單排查看看：

1. 有沒有高流量和擴展的需求？我們的日活用戶能夠達到上千、甚至上萬嗎？或是有沒有短時間高併發的流量，如限時購票系統等等

2. 服務是否分散在多個地理位置？而且因為地理位置的差異而造成延遲的影響巨大，受波及的用戶也有一定的數量

3. 有和客戶簽約，要達 99.99% 甚至更多的可用時間，而必須要實作 HA（高可用）的架構？

如果我們要做的服務都不需滿足以上任何一點需求，真的沒有必要將服務部署在分散式系統上。就我的經驗中，因為資料放在多處，而需要處理資料不一致的問題，遠比單機故障後的處理麻煩的多。

一台後端伺服器、一台資料庫，甚至合併成一台機器很可能就已經足夠。

尤其在小團隊開發的中小型規模產品下，大部分的情況都只需要集中式的伺服器就足夠做各種運算和儲存了。就算在可見的未來有流量增加、運算量增加，我們也可以透過提高伺服器的規格來應對。

若是真的有伺服器故障的情況發生，其實也能透過增加監控和告警的的機制通知我們來手動進行處理。畢竟，就算分散式的系統也是會發生故障的，也就依然要有相似的流程來處理。