近來一直在做一個產品的架構升級，架構升級的前期工作是對舊架構現存的問題進行梳理，考慮新架構的設計如何規避舊架構的坑，完善舊架構支持不佳的缺陷。終於完成了新架構設計，在給開發工程師講解時，還會遇到開發的疑惑：新架構真能實現舊架構上支持的特別困難或彆扭的場景麽，如此等等。一個架構從設計到實現，到底要做些 ...
近來一直在做一個產品的架構升級，架構升級的前期工作是對舊架構現存的問題進行梳理，考慮新架構的設計如何規避舊架構的坑，完善舊架構支持不佳的缺陷。終於完成了新架構設計，在給開發工程師講解時，還會遇到開發的疑惑：新架構真能實現舊架構上支持的特別困難或彆扭的場景麽，如此等等。一個架構從設計到實現，到底要做些什麼，關註些什麼？
那麼我們就從下麵這個問題開始梳理吧。
架構做什麼
查了下維基百科（Wikipedia）架構（Architecture）一詞最早源自建築學術語，後來被電腦科學領域所借用。
架構是規劃、設計和構建建築及其物理結構的過程與產物。在電腦工程中，架構是描述功能、組織和電腦系統實現的一組規則與方法。
Architecture is both the process and the product of planning, designing, and constructing buildings and other physical structures. In computer engineering, "computer architecture" is a set of rules and methods that describe the functionality, organization, and implementation of computer systems.
要明白做什麼，首先需要考慮目標是什麼？軟體架構的目標是要設計軟體系統來解決問題，所以架構要做的事從抽象的維度上看，就是：
- 根據問題域，界定系統的邊界
- 對系統進行切分，切分的目的是分工與協作（並行，以獲得效率）
- 被切分的各部分之間建立交互與溝通原則與機制
- 將部分連接合併成一個整體，完成系統的目標
更具體一些來說，架構做得就是結構設計，在不同維度和層次上：
- 高維度：是系統、子系統或服務的切分與交互結構
- 中維度：是系統或服務內部的模塊劃分
- 低緯度：是代碼結構、數據結構、表結構
當在架構升級這樣的事情中，架構師的職責之一是要交付“一種架構”，而這“一種架構”的載體現在通常又會以某種文檔的形式出現。所以，很容易誤解架構師的工作就是寫文檔，實際上架構師的交付成果是一整套決策流，交付載體通常體現成了文檔。在這個過程中，架構師的首要工作就是保證在架構方案執行中，整個開發團隊的實施效果與決策保持一致。即使在這個過程發現了實施與決策的衝突，就又需要重新協調溝通討論以取得新的一致。
當系統規模比較小時，比如架構師一個人就能把全部的設計決策在交付期限內開發完成，這就省卻了很多的溝通協調討論成本。五年前，我就曾這樣做過一個小系統的架構升級改造，但後來的系統越來越大，慢慢就需要幾十人的團隊來分工協作，如何保證架構設計中的決策在架構執行過程中保持一致，這成為了架構工作的真正難點所在。
架構關註點
架構設計的決策流一旦落在了文檔的載體上，它實際就是一個靜態的東西了。而真正的架構執行過程卻是動態的。在這個動態過程中，架構師需要定期地去對系統的狀態做快照，觀察是否有出現需要解決的問題，而這些問題就是技術層面的架構關註點。
一些問題也許是架構執行中新出現的，在當初的架構設計中未能考慮到，需要對此做分析判斷，並形成新的決策。而另一些問題，也許是執行過程中的走樣，導致和當初的決策形成了偏差。架構師需要考慮所有這些關註點，並和開發工程師找到解決這些關註點的各種選項，在適當的時候根據真實環境的情景去採取合適的行動。有時，我們稱這些行動叫作：重構或優化。當一個舊系統長期沒有這樣的行動，積累久了後，我們將迫不得已採取另外一種行動，我們稱之為 —— 架構升級。
軟體系統或架構，不像建築物會因為時間的流逝而自然耗損腐壞，它只會因為變化而腐壞。一開始清晰整潔的架構與實現隨著需求的變化而不斷變得渾濁、混亂。信息與電腦科學都愛借用一個物理學的術語「熵」，它表達體系的混亂程度，而軟體系統的「熵」很容易不經意間隨著需求的變化而變得更高。
軟體系統「熵」有個臨界值，當達到並超過臨界值後，軟體系統的生命也基本到頭了。這時，我們就要採取那個迫不得已的行動了。圖例展示了軟體系統「熵」值的生命周期變化。
所以，近年流行的微服務架構有個很大的優勢，服務粒度合適，服務物理隔離，單個服務的「熵」增問題被局限在單個微服務內部。單個微服務的替換與重構成本十分有限，使得「熵」增問題局部化，不容易傳染全局，以致失控。當然這有個前提，就是微服務的拆分和介面交互要合理，合理的檢驗標準就是隨需求變化，總是實現變化或介面新增，而非總是調整介面交互。
架構始於系統生命之初，並伴隨系統生命周期全程。每次需求變化帶來的變動都應進行一次或大或小的重新架構過程。架構的關註點在於控制軟體系統變動時「熵」值的變化。
架構等效性
架構升級中一開始的疑惑：這個新架構能實現麽？其實，這根本不是一個值得疑惑的問題。
相對於建築架構，軟體架構過程其實更像是城市的規劃與演變過程，有一定歷史的城市，慢慢都會演變出所謂的“舊城”和“新城”，新城相對於舊城，就是一次架構升級的過程。城市規劃師會對城市的分區、功能劃分進行重新定位和規劃。一個舊城所擁有的所有功能，如：社區、學校、醫院、商業中心，你難道能想象新城會沒有嗎？或者說“實現”不了嗎？
所以，如果一個單體應用能實現的功能，換成微服務架構肯定也可以實現，只是編寫代碼的方式不同。不同架構在功能的可實現性上其實是完全相同的，我稱之為：架構等效性。不同的地方在於哪裡呢？如前所述，切分方式不同導致的分工協作完全不同，因此獲得的效率與付出的成本也會不同。
架構升級，僅僅是一次系統的重新佈局與規劃，成本與效率的重新計算與設計，熵的重新分佈與管理。
...
架構就是關於系統的決策流。
架構關註系統「熵」的變化。
架構都是等效的，不同的是成本和效率。
新城區（架構）活動的人（需求）多了，也是要堵車（...）的。
寫點文字，畫點畫兒，記錄成長瞬間。
微信公眾號「瞬息之間」，既然遇見，不如一起成長。
