Ch0: 前言

前言

建構一個大規模但依然可靠的系統是否可行？

直覺上來說，我們會預期(希望)一個大規模的系統是穩定且不會出錯的，

但是理論上其實是不可能的，因為大規模的系統必定會遇上“不靠譜”的人員，程式，硬體，網路...

那我們該怎麼做呢？

計算機之父馮．諾伊曼在 20 世紀初 40 年代末花費約兩年時間，

研究這個問題並得出一個結論：自複製自動機(Self-Reproducing Automata)

承認每一個零部件可能會出錯，在某個具體的零件可能會崩潰消亡，但是在系統中一定會出現，重新替代該零件，實現他的功能，以維持系統的整體穩定。

舉個例子：

“不可靠”可以理解成構成生命的大量細胞，由於熱力學擾動、生物複製差錯等等各種因素干擾，這些細胞可能會包潰。這些細胞本身並不可靠。 (系統內部個零件)

但生命(整個系統)之所以可靠，是因為生命(整個系統)一定會再產生可以重新代替的細胞，實踐他的功能，以維持生命(系統)的穩定。

從大型機(Mainframe)、原始分布式(Distributed)、大型單體(Monolithic)、服務導向(Service-Oriented)、微服務(Microservice)、服務網格(Service Mesh)到無服務(Serverless)，這些技術架構呈現從大到小的發展趨勢。

尤其近年微服務興起，湧現各個文章讚美微服務帶來的種種好處，包括：簡單部署，邏輯拆分更清楚，便於技術異構，易於伸縮拓展以得到更高的效能....

但這些好處應該只能算是錦上添花。

架構演進最重要的驅動力

架構演變最重要的驅動力，應該是為了方便某些服務能夠順利的從"死去"到"重生"。個體服務的生死更迭，是關係到整個系統能否可靠存續的關鍵因素。

確保系統生存的需求才是關鍵

例如：

一個單體架構的 Java 系統，每次更新、升級都必須要有固定的停機計畫，必須在特定的時間內才能按時開始，且必須按時結束(人少的時候)。如果出現非計畫的當機，就是生產事故。

但是程式的缺陷並不會“安排時間來出錯”，為了應付這種缺陷與變化，就必須不停的停機檢修。

Java 曾經制定了 OSGi 與 JVMTI Instrumentation 等複雜的 HotSwap 方案，以實現“給奔跑中的汽車更換輪胎”的做法。

但是微服務時代，可以先停掉 1/3 台機器，升級新的版本，測試後做金絲雀發布，一切理所當然。

到了無服務的架構下，甚至不需要關心服務所運行的基礎設施，連機器是哪台都不必知道，停機升級就更無須關注。

如果你的系統中的每個零件都符合“鳳凰”的特性，哪怕其中某個零件由一個“極不靠譜”的人員所開發，哪怕存在嚴重的內存泄露問題，哪怕最多只能服務三分鐘就會崩潰，只要在整體架構有做恰當且自動化的錯誤熔斷、服務淘汰和重建機制，從系統外部來觀察，依然可能呈現出穩定和健壯的能力