2020 年，從架構談起，到 Mesh 結束

作者 | 張羽辰（同昭） 阿里云交付專家

面向對象編程？函數式？模塊化設計？微服務？這些詞匯貌似都和架構這個 buzzword 有點關系，的確我們這個領域充滿了很多難以理解的詞匯，這些詞匯從英語翻譯到中文已經喪失了部分上下文，再隨著上下文的改變使得意義徹底扭曲，比如：引擎、框架、架構、應用、系統……誠然大家都或多或少對這些詞語達成共識，在工作中使用這些詞匯進行溝通，某時就是指“我們都懂的那個東西”，但是在我深入的想聊聊架構或者說軟件架構時，的確不得不問自己這個問題，我們到底是談論什么？

事實上，架構這個詞根據上下文所確定的范圍較為固定，建筑學上的架構指代房屋結構、整體設計、組合構成等，而這些 high-level 設計往往并不需要全面了解底層，就像使用 RestTemplate 進行 WebService 調用時，我們也不關心 socket 是在四層連接的一樣，因為細節被隱藏了。

但是，建筑學上的架構與軟件架構卻又極大的不同之處，問題出現在“軟件”這個詞上，按照 software 的詞解，ware 是指產品一樣的東西，而 soft 則強調易變，這是與 hardware 所對應的。我們希望“軟件”能夠進行快速的修改，應該能夠快速響應甲方或者客戶的需求，所以軟件架構必然不像建筑架構一樣，建筑一經建成，修改的成本極高，而軟件應該走對應的方向，發揮易于修改的特點。

“現在的大多數軟件非常像埃及金字塔，在彼此之間堆建了成千上萬的磚塊，缺乏結構完整性，只是靠蠻力和成千上萬的奴隸完成。” —— Alan Kay。

筆者認為，雖然這句話表達的意思我很贊同，但實際上，金字塔作為帝王的陵墓，是有著完整的設計邏輯，并且隨著好幾座金字塔的迭代的，以及逐漸完備的施工管理，后期金字塔是非常杰出的建筑代表，并作為地球上最高的人造建筑持續了好幾千年。關于金字塔是否由奴隸建造還是存有爭議。（圖片來自 Isabella Jusková @ Unsplash）。

作為工程師，我們一方面關注軟件產品的能力和行為，這往往是一個項目的起點，另一方面我們需要關注軟件的架構設計，因為我們希望設計有著彈性、易于維護、高性能、高可用的系統，更希望系統能夠不斷演進，而不是在未來被推倒重做。所以，回正我們的視野，當我們決心要設計一個好的架構時，我們需要明確，架構往往決定的是軟件的非功能性需求。這些非功能性需求有：

我們希望工程師一進入團隊就可以立刻開始進行研發工作，我們希望代碼易于閱讀與理解，同時開發環境足夠簡單統一，說到這里大家可以回想下當你進入項目時，學習上下文的痛苦。當我們開始采用 docker 輔助開發時，時任架構師提出了一個要求，只要一行命令就可以使用 docker 啟動本地測試環境，而且必須所有的微服務都要做到這一點。痛苦的改造完成后，三年后進入項目的同學只需要安裝好 docker，再在 ternimal 中運行一句 ./run-dev.sh 就能夠獲取一個具有完整依賴的本地環境，提效明顯。

如果系統的部署成本很高，那使用價值就不會很高了，我們很多企業都存在那種動也不敢動，改也不敢改，停也不敢停的系統，除了祈禱它別掛掉好像沒有別的辦法，或者很多企業都采用了 K8s 這種先進的編排系統，但是在應用部署和上線時，還是走的每周四變更的路子。現代的發布方式 AB、金絲雀、灰度無法采用是因為改造成本過高，或者沒有足夠的自動化測試來保證改動安全，更別提將發布做到 CI\CD 里面了。

DevOps 的初衷是建立一種縮短運維與研發距離的文化，讓出現問題后更容易處理，希望讓大家將視野放在產品上而不是限定自己的工種，這并不是期望運維的同學能夠成為 Java 專家，迅速的進行 heap 分析發現問題，我們強調的是運維時的閉環能力。在軟件產品層面，我們也希望產品是足夠獨立的、自治，可以獨立部署，能夠做到橫向擴展，有著完整的可觀測性，畢竟當今的硬件成本很多時候是遠遠小于人力的。

隨著時間的推移，給軟件增加新功能就會變的越來越難，越是運行長久的項目就會陷入重寫還是重構的苦惱。往往風險在與，修改代碼會增加破壞已有功能的風險，而且技術債也會越來越多難以償還，即使是重寫某些功能和模塊，我們也很難確定是否真的覆蓋到了所有的功能，簡而言之，don't break anything 的確很難做到。

以及最重要的一點：演進能力。良好的架構設計應該能讓系統處于易于演進的狀態，能夠實現給飛馳的汽車換輪胎的能力，而不會被框架、底層的某種數據庫、操作系統或者其他東西所綁架，但是這太難以做到了。的確，在項目進行技術選型時，因為某種數據庫的特性而有傾向，但是在上層設計中，我們必須保證不依賴于數據庫的特性，而將使用這些特性的地方放到底層細節中。我們也需要考慮，不使用 Spring 提供的 Dependency Injection，我們該如何組織我們的 beans，也要考慮將來系統的前端是 web 還是 mobile 還是都要支持？

這里引用 Robert C·Martin（Uncle Bob）的原語，“軟件產品是有兩方面的價值，一方面是實現功能的價值，另一方面是架構的價值，而架構的價值可能更重要一些，因為它代表著軟件 soft 的特性。”

本書例子過少，而且缺乏現有流行框架的重構或者改進建議，有點形而上，但是在方法論層面筆者還是認為值得一讀。

Robert C·Martin 對數據庫（特指 RDBMS）的態度很值得討論，首先他認為數據庫是一種細節，在架構中應該與業務解耦，他強調業務代碼與數據庫的無關性。同時在我們的代碼進行計算時，表格往往不是理想的數據結構，比如有些場景會使用樹、DAG 等等。可以回想一下，當你需要把一個樹存入數據庫時，你該如何實現？

隨著規模的擴大，單體應用的代碼改動成本會越來越大。很多時候我們微服務的架構實踐是存在誤區的，我們總認為流量經過某個 gateway 后直達某個服務，確忽視了服務之間調用的場景，理想的微服務架構應該是一張網，每個節點都是獨立的、自治的服務。

這個開幕雷擊雖然槽點滿滿，但并沒有降低社區對 Istio 的信心，反倒是漸漸發現這次的大改動使 Istio 變得有點好用了，可以在生產中采用而不需要付出太多代價了。當然，漂亮話永遠好說。

實踐微服務，作為架構師所考慮的東西遠遠大于只是實現業務，但是一旦鋪平道路，下來的研發與迭代將會更加順利。