架構的本質
物理學中有個很著名的“熵增定律”：一個封閉系統，都是從有序到無序，也就是它的熵（即混亂程度）會不斷地增加，最終系統會徹底變得無序。這個理論放在軟件系統的演化上，也是非常適用的。一方面，隨着業務需求的增加，我們會往系統裏不停地添加業務功能；另一方面，隨着訪問量的不斷增加，我們會不斷通過技術手段來加強系統非業務性功能。如果事先不做良好的設計，隨着時間的推進，整個系統野蠻生長，就會逐漸碎片化，越來越無序，最終被推倒重來。
這一點筆者很有體會，當你的編程技術能力遠大於能實現的功能後，會考慮代碼的優化和性能，而有時需求的疊加和不會預先告知以及需求的緊迫性會造成代碼的混亂。
不過，自然界中的生物可以通過和外界交互，主動進行新陳代謝，製造“負熵”，也就是降低混亂程度，來保證自身的有序性，繼續生存。比如，植物通過光合作用，把光能、二氧化碳和水合成有機物，以此滋養自己，延續生命。對於軟件系統，我們也可以主動地調整系統各個部分的關係，保證系統整體的有序性，來更好地適應不斷增長的業務和技術變化。這種系統內部關係的調整就是通過架構實現的，所以，架構的本質就是：
通過合理的內部編排，保證系統高度有序，能夠不斷擴展，滿足業務和技術的變化。
首先，架構的出發點是業務和技術在不斷複雜化，引起系統混亂，需要通過架構來保證有序。
軟件系統也是如此，從簡單的桌面應用發展到現在的大型互聯網平臺，這個過程中，系統規模越來越大，業務和技術也越來越複雜。我們同樣需要通過架構設計，消化複雜性帶來的混亂，使系統始終處於一個有序狀態，能夠應對現有和將來的需求變化。
其次，架構實現從無序到有序，是通過合理的內部編排實現的，基本的手段，就是“分”與“合”，先把系統打散，然後將它們重新組合，形成更合理的關係。
具體地說，“分”就是把系統拆分爲各個子系統、模塊、組件。拆分的時候，首先要解決每個部分的定位問題，然後根據定位，劃分彼此的邊界，最後實現合理的拆分，我們比較熟悉的微服務架構，就是一種典型的拆分做法。
“合”就是基於業務流程和技術手段，把各個組件有機整合在一起。比如說在微服務架構中，拆分爲具體微服務後，我們需要對這些服務進行歸類和分層，有些屬於底層基礎服務，有些屬於上層聚合服務，還要儘可能地實現服務的平臺化，比如我們最近說的中臺，這些都是合的思想體現。
這個分與合的過程將系統的複雜性分解爲兩個層次：首先，各個子系統承擔獨立的職責，內部包含了自身的複雜性。子系統的複雜性對外部是透明的，外部不用關心。其次，子系統通過封裝後，簡化爲職責明確的一個點，因此，我們只需要在合的過程中，解決各個點之間的依賴關係，這樣就可以定義出系統整體。
舉個例子，我們都知道 GoF 的 23 個設計模式，在 Builder 模式中，它的主邏輯只需要給出各個部件的組裝關係即可，它不關心創建某個具體部件的內部邏輯，這個可以交給工廠模式去實現。這裏，Builder 模式負責粗粒度的組裝邏輯，它承擔的是合的部分；工廠模式負責細粒度的構造邏輯，承擔的是分的部分，大家各自管理自己的複雜性。
通過合理的“分”與“合”，系統不是回到了原點，而是把原先鐵板一塊的系統變成一個富有彈性的結構化系統。這樣，系統的複雜性有效地分解了，系統的有序度大幅度地提升了。
架構的分類
按照不同的角度，架構可以有很多分類，但一般來說，主要分爲業務架構、應用架構和技術架構。那麼，這些架構分別爲誰服務，解決什麼問題，相互之間是什麼關係呢？