架構設計六小原則

計算機軟件是一個復雜的系統。復雜的系統總是似而不同，在宏觀上類似，在細節的地方各有千秋。因為細節決定成敗，復雜的系統很難有屢試不爽的解法。盡管如此，解決的多了也會遺留一些經驗。這些經驗再加以重復驗證就形成了原則。這些原則有其特殊的歷史背景，不一定放之四海而皆準。但是不聽老人言，吃虧在眼前，在能自行頓悟之前建議能熟誦于胸，以防不測。

架構六則

  1、 狀態多具象,讀寫本不同。

   2、狀態常遷移，一致有成本。

   3、優化守本分，變化相對論。

   4、 熟誦六小計，錦囊隨身行。

狀態多具象

計算機數據分為正源和衍生兩種。正源數據指的是官方欽定的最原始的數據，所以有時候也叫原始數據。衍生數據是基于正源數據派生而來，對正源數據進行二次加工，是對正源數據的一個特殊的視角。常見的衍生數據生成方式有篩選、聚合、統計等等。有一些數據屬于衍生數據，但是并不那么直觀。一個例子是數據庫索引。數據庫索引是為了加速數據查詢而生成的特殊數據結構，是由數據庫表衍生出來的一份數據。另一個例子是網頁前端界面顯示。一般的網頁前端界面顯示的流程是這樣的：

1、后端服務器生成業務數據。 

2、業務數據變成與前端通訊的格式，比如json、xml等，通過網絡協議發送至網頁瀏覽器。

3、網頁代碼將數據變成特定的瀏覽器Javascript對象。

4、瀏覽器將Javascript對象變為計算機顯卡能識別的數據。

5、顯卡在顯示器上展示數據。

以上每一步流程都是數據的處理和加工過程。從每個加工組件的角度來看，輸入是正源數據，輸出是衍生數據。從上到下完整的來看，后端服務器上的是正源數據，其余數據都是衍生而來。

判斷數據是正源還是衍生的辦法很簡單：如果數據不見了，是否能夠基于其它數據重新生成出來。比如前面提到的數據庫索引數據。數據庫有索引的刪除和表的索引重建操作，表刪除了就沒有了，所以索引是衍生數據，數據庫表是正源數據。對于網頁顯示的例子，瀏覽器刷新之后，網頁顯示會先消失然后重新展示出來，但是如果后端服務器宕機就沒辦法再展示網頁了。所以前端顯示是衍生數據，后端數據是正源數據。

在架構設計中，因為衍生數據可以基于正源數據重復產生，衍生數據的容災度較高，恢復的方法較多。相對而言正源數據只有一份，損壞之后無法輕易恢復，因此需要針對業務對容災的需求進行精心的設計。

1.讀寫本不同

對于每個人來說，讀是一個內容輸入的過程，寫是一個內容輸出的過程。一般會認為這是兩種不同的個人能力，不一定同時都很優秀或者都不優秀，比如有人可能閱讀能力強但是寫作能力弱，也有可能寫作能力強但是閱讀能力弱。同理，計算機的讀寫也是兩個不同的行為。計算機的讀和寫的對象都是數據，但是讀操作是數據的輸入過程，寫操作是數據的輸出過程。這里提到的讀寫本不同的第一個不同點在于操作的不同。數據的輸入和輸出可能會面臨不同的吞吐量、延時、容災等需求，需要分別對待。

讀寫本不同的第二個不同點非常難以發覺，那就是數據有可能也是不同的。在狀態多具象一節里我們介紹了數據分為正源數據和衍生數據兩大類。之所以會有衍生數據的一個原因是數據的使用，即數據的讀取，可能需要有特殊的優化方式。為了讀性能的原因需要對正源數據做一些預處理，比如建索引。所以對于數據庫的例子來說寫的數據是正源數據，讀的數據是衍生數據，所以讀寫的操作是有可能基于兩份不同的數據進行的。

總結一下。讀寫的不同在于讀寫的數據不同以及數據的流向不同。在架構設計時需要將讀寫分開考慮，分開優化。

2.狀態常遷移

計算機程序會用到一些數據結構，比如List，Map，Set等等。在面向對象編程的過程中還會使用到類的對象。這些數據結構和對象其實都是一種狀態，計算機程序需要正確合理的維護這些狀態。

通常這些狀態都是在內存之中，機器一旦斷電就會全部消失。所以需要將這些內存信息保存到可持久化的存儲介質上，比如硬盤和網絡存儲。這個保存的過程其實是內存狀態的遷移過程。但是硬盤也會出現機械故障，造成數據丟失。因此更為穩妥的方法是不要將雞蛋放在一個籃子里，將硬盤的數據再備份到其它的地方。這個數據備份的過程也是狀態的遷移過程。

除了解決數據丟失的問題需要狀態遷移以外，狀態遷移也會被用來解決物理局限。一臺機器內存的大小是有限的，所以當內存里的數據大到裝不下的時候，需要將內存里的數據分散到其它機器上，這些機器作為一組集群提供一個分布式的數據結構。一臺機器的硬盤大小也是有上限的，同理，當硬盤不夠時也可以將硬盤數據分散到由一組集群組成的分布式文件系統里。對于應用程序來說，它還是在通過同樣的接口訪問數據結構或者文件系統，只不過這些內容可能分散在了網絡上的其它機器。

3.一致有成本

前面提到了狀態常遷移。如果遷移過程中數據出了問題怎么辦？比如在數據備份過程中網線斷了，或者數據中心停電了。這時候需要有一套應急措施來保證在基礎架構恢復之后再次啟動數據備份流程。數據的重發是一種成本。

數據的全部丟失比較容易處理，相對挑戰高一點的是數據部分丟失。比如在數據傳輸過程中掉了部分數據，或者由于宇宙射線的影響導致賬戶金額由正變負。這時候除了需要有數據重發功能以外還需要有數據正確性驗證的功能。數據的正確性驗證也是一種成本。

在分布式系統中還有一些更為復雜的情況。比如我們將數據備份至北上廣三個數據中心。當我們剛發出最新的數據備份指令的時候本地數據中心掉電，完全停止工作。這時候我們需要在北上廣三個數據中心中選擇一個來做業務的實時切換。那么我們怎么判斷選擇出來的數據中心有最新的數據呢？這個問題的難點在于我們需要判斷某些數據和一個無法訪問的數據是否一致。這個問題的解決需要數據的發送方和接收方一起通過既定的分布式協議來解決。

我們也可以把問題簡化一點。假設我們不需要判斷北上廣是否有最新的數據，我們只要選擇當中數據最多的一個就可以了。顯然可以嘗試通過兩兩比較的方式來判斷誰的數據更多。但是如果在比較的過程中網絡出現了隔斷，比如上海的數據中心成為了一個被隔離的信息孤島，這時該如何處理呢？分布式系統中還有更為少見的單向通訊故障，一般是在防火墻出現錯誤配置的時候會出現。假設北京可以訪問上海數據，上海可以訪問廣州數據，廣州可以訪問北京數據，但是上海不可以訪問北京，廣州不可以訪問上海，北京不可以訪問廣州。這時每個數據中心都知道剩下兩個數據中心的一個信息，但是不知道另一個的信息。這時候應該怎么判斷誰的信息更全面呢？這也需要分布式協議來解決。

更為悲觀的是理論科學家證明了在一定假設情況下，只要網絡集群有一個節點有可能出現故障，整個集群便不可能達到一致。這就是著名的FLP結論。我們會在之后詳細講解這個定理。因為機器會出故障，所以一致性的解決就不是成本高低的問題，而是不可能解決的問題了，換句話說想要達到一致性的成本是無限高。

所幸在實際操作過程中FLP論文中提到的假設是很容易通過一些方法來規避的，架構師還是有可能設計出一個具有一致性的軟件架構。這也表明一致性的解決還有一個很高的學習成本。

4.優化守本分

如章首所引，提前優化是萬惡之源。不提前的優化也需要注意。每個程序都有既定的功能，這就是在軟件工程里提到的功能性需求。程序還有一些對于運行效率相關的要求，比如吞吐量、響應時間等。這些的學名叫非功能性需求。優化是會改變程序的行為，但是這種改變只能影響非功能性需求，不能影響功能性需求。這是優化的一道紅線，不能僭越。優化守本分就是要守住這根紅線。

在實際過程中會出現無論怎么優化，非功能性需求都無法達到的情況，比如需要達到非常高的吞吐量。這時候會通過放棄一些業務的要求來簡化系統實現。常見的方法有最終一致性、事務補償等。這時候同時出現了系統優化和功能改變，但由于功能改變是因，系統優化是果，因果關系不同，并沒有違反原則。

5.變化相對論

辯證唯物主義認為，事物的運動發展是變與不變的統一。顯然變與不變的相對關系是一個偏哲學的問題。由于我們是介紹實踐為主，不深入做理論分析，所以在這里不做過多的闡述，只舉幾個例子。

一個例子是關系型數據庫的查詢。關系型數據庫訪問的方法一般是通過SQL結構化查詢語句。不同人會有不同的查詢內容和方式。在這種場景下數據庫里的數據是相對不變的，SQL查詢語句是變化的。但是隨著互聯網的發展，人們對查詢結果的實時性要求越來越高。比如在大型的搜索網站、電商或者新聞網站的搜索界面，當輸入一個查詢條件之后，網站會不斷的推送最新的查詢結果。在這種情況下查詢語句是不變的，數據是變化的。數據和查詢在這兩種情況下的實現也不相同。在傳統關系型數據庫的情況下，為了加快查詢結果，數據庫會對表建立索引。在實時查詢結果推送的情況下，數據系統會對查詢語句做索引。

另一個例子是對數據的操作。金融數據和所有數據一樣，一旦修改就變化的和以前不一樣了。這樣金融行業的審計人員怎么知道幾個月或者幾年前數據是怎樣的呢？一般為了應付審計，系統開發人員會在審計周期開始時做一個全量的數據拷貝，并將訪問權限設為只讀。這樣就有了一個不變的數據版本。這種設計下數據是一直在變化的。另一種系統設計的思路稍有不同。對數據的修改并不會改變數據，而是生成一份新的數據，或者說是數據的一個新的版本。在這種設計下數據是永遠不變的，變化的是數據的個數。這兩種設計都能解決同一個問題，但是難易程度不同，孰優孰劣高下立見。