這個架構能實現嗎？
近來一直在做一個產品的架構升級，架構升級的前期工作是對舊架構現存的問題進行梳理，考慮新架構的設計如何規避舊架構的坑，完善舊架構支持不佳的缺陷。終于完成了新架構設計，在給開發工程師講解時，還會遇到開發的疑惑：新架構真能實現舊架構上支持的特別困難或別扭的場景么，如此等等。一個架構從設計到實現，到底要做些什么，關注些什么?
那么我們就從下面這個問題開始梳理吧。
架構做什么
查了下維基百科(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.
要明白做什么，首先需要考慮目標是什么?軟件架構的目標是要設計軟件系統來解決問題，所以架構要做的事從抽象的維度上看，就是：
- 根據問題域，界定系統的邊界
- 對系統進行切分，切分的目的是分工與協作(并行，以獲得效率)
- 被切分的各部分之間建立交互與溝通原則與機制
- 將部分連接合并成一個整體，完成系統的目標
更具體一些來說，架構做得就是結構設計，在不同維度和層次上：
- 高維度：是系統、子系統或服務的切分與交互結構
- 中維度：是系統或服務內部的模塊劃分
- 低緯度：是代碼結構、數據結構、表結構
當在架構升級這樣的事情中，架構師的職責之一是要交付“一種架構”，而這“一種架構”的載體現在通常又會以某種文檔的形式出現。所以，很容易誤解架構師的工作就是寫文檔，實際上架構師的交付成果是一整套決策流，交付載體通常體現成了文檔。在這個過程中，架構師的首要工作就是保證在架構方案執行中，整個開發團隊的實施效果與決策保持一致。即使在這個過程發現了實施與決策的沖突，就又需要重新協調溝通討論以取得新的一致。
當系統規模比較小時，比如架構師一個人就能把全部的設計決策在交付期限內開發完成，這就省卻了很多的溝通協調討論成本。五年前，我就曾這樣做過一個小系統的架構升級改造，但后來的系統越來越大，慢慢就需要幾十人的團隊來分工協作，如何保證架構設計中的決策在架構執行過程中保持一致，這成為了架構工作的真正難點所在。
架構關注點
架構設計的決策流一旦落在了文檔的載體上，它實際就是一個靜態的東西了。而真正的架構執行過程卻是動態的。在這個動態過程中，架構師需要定期地去對系統的狀態做快照，觀察是否有出現需要解決的問題，而這些問題就是技術層面的架構關注點。
一些問題也許是架構執行中新出現的，在當初的架構設計中未能考慮到，需要對此做分析判斷，并形成新的決策。而另一些問題，也許是執行過程中的走樣，導致和當初的決策形成了偏差。架構師需要考慮所有這些關注點，并和開發工程師找到解決這些關注點的各種選項，在適當的時候根據真實環境的情景去采取合適的行動。有時，我們稱這些行動叫作：重構或優化。當一個舊系統長期沒有這樣的行動，積累久了后，我們將迫不得已采取另外一種行動，我們稱之為 —— 架構升級。
軟件系統或架構，不像建筑物會因為時間的流逝而自然耗損腐壞，它只會因為變化而腐壞。一開始清晰整潔的架構與實現隨著需求的變化而不斷變得渾濁、混亂。信息與計算機科學都愛借用一個物理學的術語「熵」，它表達體系的混亂程度，而軟件系統的「熵」很容易不經意間隨著需求的變化而變得更高。
軟件系統「熵」有個臨界值，當達到并超過臨界值后，軟件系統的生命也基本到頭了。這時，我們就要采取那個迫不得已的行動了。圖例展示了軟件系統「熵」值的生命周期變化。
所以，近年流行的微服務架構有個很大的優勢，服務粒度合適，服務物理隔離，單個服務的「熵」增問題被局限在單個微服務內部。單個微服務的替換與重構成本十分有限，使得「熵」增問題局部化，不容易傳染全局，以致失控。當然這有個前提，就是微服務的拆分和接口交互要合理，合理的檢驗標準就是隨需求變化，總是實現變化或接口新增，而非總是調整接口交互。
架構始于系統生命之初，并伴隨系統生命周期全程。每次需求變化帶來的變動都應進行一次或大或小的重新架構過程。架構的關注點在于控制軟件系統變動時「熵」值的變化。
架構等效性
架構升級中一開始的疑惑：這個新架構能實現么?其實，這根本不是一個值得疑惑的問題。
相對于建筑架構，軟件架構過程其實更像是城市的規劃與演變過程，有一定歷史的城市，慢慢都會演變出所謂的“舊城”和“新城”，新城相對于舊城，就是一次架構升級的過程。城市規劃師會對城市的分區、功能劃分進行重新定位和規劃。一個舊城所擁有的所有功能，如：社區、學校、醫院、商業中心，你難道能想象新城會沒有嗎?或者說“實現”不了嗎?
所以，如果一個單體應用能實現的功能，換成微服務架構肯定也可以實現，只是編寫代碼的方式不同。不同架構在功能的可實現性上其實是完全相同的，我稱之為：架構等效性。不同的地方在于哪里呢?如前所述，切分方式不同導致的分工協作完全不同，因此獲得的效率與付出的成本也會不同。
架構升級，僅僅是一次系統的重新布局與規劃，成本與效率的重新計算與設計，熵的重新分布與管理。
【本文是51CTO專欄作者胡峰的原創文章，轉載請聯系作者本人獲取授權】
