不瞭解架構的本質，怎麼能打造一個有序的系統呢？

如今的軟件系統愈來愈複雜，固然相應地，架構的做用也愈來愈明顯。做爲開發人員，咱們天天都在和架構打交道，在這個過程當中，對於架構也常常會產生各類各樣的問題：

什麼是架構？架構都有哪些分類，分別解決什麼問題呢？
怎樣纔是一個好的架構設計？我怎麼才能成長爲一名優秀的架構師呢？
這些問題涉及咱們對架構的認識，也是學習和運用架構的開始。因此，今天，咱們就來深刻地分析架構的實質，讓你可以透徹地理解它。

架構的本質
物理學中有個很著名的「熵增定律」：一個封閉系統，都是從有序到無序，也就是它的熵（即混亂程度）會不斷地增長，最終系統會完全變得無序。

這個理論放在軟件系統的演化上，也是很是適用的。

一方面，隨着業務需求的增長，咱們會往系統裏不停地添加業務功能；另外一方面，隨着訪問量的不斷增長，咱們會不斷經過技術手段來增強系統非業務功能。若是事先不作良好的設計，隨着時間的推動，整個系統野蠻生長，就會逐漸碎片化，愈來愈無序，最終被推倒重來。

不過，天然界中的生物能夠經過和外界交互，主動進行新陳代謝，製造「負熵」，也就是下降混亂程度，來保證自身的有序性，繼續生存。好比，植物經過光合做用，把光能、二氧化碳和水合成有機物，以此滋養本身，延續生命。對於軟件系統，咱們也能夠主動地調整系統各個部分的關係，保證系統總體的有序性，來更好地適應不斷增加的業務和技術變化。這種系統內部關係的調整就是經過架構實現的，因此，架構的本質就是：

經過合理的內部編排，保證系統高度有序，可以不斷擴展，知足業務和技術的變化。
這裏包含兩層意思，咱們具體展開說下：

首先，架構的出發點是業務和技術在不斷複雜化，引發系統混亂，須要經過架構來保證有序。咱們知道架構這個詞來源於建築行業，那爲何建築行業須要「架構」呢？

搭一個草房子很簡單，能夠直接上手；蓋一個 2 層樓房，稍微複雜一些，但在工匠的經驗指導下，問題也不大；而蓋一座高樓，複雜性就大不同了，咱們須要考慮內部結構、承重、採光、排水、防雷抗震等，這就須要專業員事先作好總體的架構設計，並嚴格地按照設計來施工。

這裏，你能夠看到，建築裏的架構不是自然就有的，而是由於建築愈來愈複雜，咱們須要經過架構來管理這種複雜性，避免建造過程的失控。

軟件系統也是如此，從簡單的桌面應用發展到如今的大型互聯網平臺，這個過程當中，系統規模愈來愈大，業務和技術也愈來愈複雜。咱們一樣須要經過架構設計，消化複雜性帶來的混亂，使系統始終處於一個有序狀態，可以應對現有和未來的需求變化。

其次，架構實現從無序到有序，是經過合理的內部編排實現的，基本的手段，就是「分」與「合」，先把系統打散，而後將它們從新組合，造成更合理的關係。

具體地說，「分」就是把系統拆分爲各個子系統、模塊、組件。拆分的時候，首先要解決每一個部分的定位問題，而後根據定位，劃分彼此的邊界，最後實現合理的拆分，咱們比較熟悉的微服務架構，就是一種典型的拆分作法。

「合」就是基於業務流程和技術手段，把各個組件有機整合在一塊兒。好比說在微服務架構中，拆分爲具體微服務後，咱們須要對這些服務進行歸類和分層，有些屬於底層基礎服務，有些屬於上層聚合服務，還要儘量地實現服務的平臺化，好比咱們最近說的中臺，這些都是合的思想體現。

這個分與合的過程將系統的複雜性分解爲兩個層次：

首先，各個子系統承擔獨立的職責，內部包含了自身的複雜性。子系統的複雜性對外部是透明的，外部不用關心。
其次，子系統經過封裝後，簡化爲職責明確的一個點，所以，咱們只須要在合的過程當中，解決各個點之間的依賴關係，這樣就能夠定義出系統總體。
舉個例子，咱們都知道 GoF 的 23 個設計模式，在 Builder 模式中，它的主邏輯只須要給出各個部件的組裝關係便可，它不關心建立某個具體部件的內部邏輯，這個能夠交給工廠模式去實現。這裏，Builder 模式負責粗粒度的組裝邏輯，它承擔的是合的部分；工廠模式負責細粒度的構造邏輯，承擔的是分的部分，你們各自管理本身的複雜性。

經過合理的「分」與「合」，系統不是回到了原點，而是把原先鐵板一塊的系統變成一個富有彈性的結構化系統。這樣，系統的複雜性有效地分解了，系統的有序度大幅度地提高了。

固然，系統的複雜性是多方面的，有技術上和業務上的，架構也是一個體系，會有多種架構一塊兒來應對這些複雜性挑戰。那麼接下來，咱們就來具體看下。

架構的分類
按照不一樣的角度，架構能夠有不少分類，但通常來講，主要分爲業務架構、應用架構和技術架構。那麼，這些架構分別爲誰服務，解決什麼問題，相互之間是什麼關係呢？

回答這些問題前，咱們先來看下系統的落地過程。

系統首先由人來開發，而後由機器來運行，人和機器共同參與一個系統的落地。

對於負責開發的人來講，比較頭疼的是，業務太複雜，腦子想不清楚，即便當前勉強把業務邏輯轉化爲代碼，系統後續的維護也是問題。所以，開發人員的要求是系統概念清晰，業務邏輯容易理解，能夠直觀地進行代碼開發。

對於負責運行的機器來講，比較頭疼的是，外部請求併發量太大，致使機器扛不住，有的時候，硬件還會出問題。所以，它的要求是系統可以水平擴展，支持硬件容錯，保證系統的高性能和高可用。

這裏，開發的痛點主要由業務架構和應用架構來解決，機器的痛點主要由技術架構來解決。

爲何這麼說呢？咱們看下，這些架構具體都是作什麼用的。

簡單來講，業務架構就是講清楚核心業務的處理過程，定義各個業務模塊的相互關係，它從概念層面幫助咱們理解系統面臨哪些問題以及如何處理；而應用架構就是講清楚系統內部是怎麼組織的，有哪些應用，相互間是怎麼調用的，它從邏輯層面幫助咱們理解系統內部是如何分工與協做的。

技術架構就是講清楚系統由哪些硬件、操做系統和中間件組成，它們是如何和咱們開發的應用一塊兒配合，應對各類異常狀況，保持系統的穩定可用。因此，技術架構從物理層面幫助咱們理解系統是如何構造的，以及如何解決穩定性的問題。

這裏你能夠看到，業務架構、應用架構和技術架構，分別從概念、邏輯和物理層面定義一個系統。業務架構給出了業務模塊的劃分和依賴關係，這也大體決定了應用系統如何分工和協做，固然這不須要嚴格地一一對應，好比一個商品業務，可能對應 3 個應用，一個前臺商品展現應用、一個後臺商品管理應用，以及一個商品基礎服務，但這不影響咱們從邏輯上理解，一個業務場景，有哪些應用參與，而且它們是如何協做的。

而技術架構呢，經過保障應用的穩定運行，最終保證業務不出問題。好比在大促的時候，多個應用可能會受大流量衝擊，技術架構就要考慮怎麼經過技術手段，保障相關的應用可以處理高併發，從而保證大促順利進行。

這裏，我舉個拍電影的例子，來幫助你更直觀地理解這三種架構的關係：業務架構定義了這個電影的故事情節和場景安排；應用架構進一步定義有哪些角色，每一個角色有哪些職責，而且在每一個場景中，這些角色是如何互動的；技術架構最後肯定這些角色由誰來表演，物理場景上是怎麼佈置的，以此保證整個拍攝可以順利完成。

最後，我想強調一下：系統是人的系統，架構首先是爲人服務的。所以，業務概念清晰、應用分工合理、人好理解是第一位的。而後，咱們再考慮技術選型的問題，保證系統非功能性目標的實現。因此作架構設計時，通常是先考慮業務架構，再應用架構，最後是技術架構。

什麼是好的架構？
從上面的內容，咱們不難看出，一個好的架構必須知足兩方面挑戰：業務複雜性和技術複雜性。

1. 業務複雜性
   系統首先要知足當前的業務需求，在此基礎上，還要知足未來的業務需求，所以系統要能不斷地擴展變化，包括調整現有功能，以及增長新功能。

並且，系統的功能變化不能影響現有業務，不要一修改，就牽一髮動全身，處處出問題。所以，在架構設計上，要作到系統的柔性可擴展，可以根據業務變化作靈活的調整。

此外，市場不等人，上新業務要快，以前花了半年上了個業務，這回再上個相似的新業務，須要短期就能落地。所以，架構設計上，還要作到系統功能的可重用，這樣才能經過快速複用，實現業務敏捷和創新。

2. 技術複雜性
   要保證一個業務能正常運行，除了知足業務功能以外，還要保證這個系統穩定可用。

一個複雜系統是由不少部分組成的，如應用程序、服務器、數據庫、網絡、中間件等，均可能會出問題。那怎麼在出問題時，可以快速恢復系統或者讓備用系統頂上去呢？

還有流量問題，平時流量不大，少許機器就能夠處理，但在大促的時候，大量流量進來，系統是否是可以經過簡單地加機器方式就能支持呢？

此外還有低成本的問題，系統可否作到，使用廉價設備而不是高大上的 IOE 設備，使用免費的開源組件而不是昂貴的商業套件，使用虛擬化技術而不是物理機，而且在流量低谷和高峯的不一樣時期，讓系統可以彈性縮容和擴容呢？

這些都屬於技術性的挑戰，解決的是系統的非業務功能，也都是架構設計要支持的。

所以，一個好的架構設計既要知足業務的可擴展、可複用；也要知足系統的高可用、高性能和可伸縮，並儘可能採用低成本的方式落地。因此，對架構設計來講，技術和業務兩手都要抓，兩手都要硬。

那麼，一個優秀的架構師須要具有什麼樣的能力，才能設計一個好的架構呢？

什麼是好的架構師？
一個優秀的架構師，應具有很強的綜合能力，要內外兼修，「下得廚房，上得廳堂」，下面我來經過典型的架構方式，來介紹一名優秀架構師應該具有的能力：

一個駕校教練，一定開車技術好；一個游泳教練，一定游泳水平好，由於這些都是實踐性很強的工做。架構師也是同樣，TA 一定是一個出色的程序員，寫的一手好代碼。

在此基礎上，架構師要有技術的廣度（多領域知識）和深度（技術前瞻）。對主流公司的系統設計很是瞭解，知道優劣長短，碰到實際問題，很快就能提供多種方案供評估。

此外，架構師還須要有思惟的高度，具有抽象思惟能力。抽象思惟是架構師最重要的能力，架構師要善於把實物概念化並歸類。好比，面對一個大型的 B2C 網站，可以迅速抽象爲採購 -> 運營 -> 前臺搜索 -> 下單 -> 履單這幾大模塊，對系統分而治之。

架構師還須要有思惟的深度，可以透過問題看本質。透過問題看本質是由事物的表象到實質，往深層次挖掘。好比，看到一段 Java 代碼，知道它在 JVM（Java Virtual Machine，Java 虛擬機）中如何執行；一個跨網絡調用，知道數據是如何經過各類介質（好比網卡端口）到達目標位置。透過問題看本質，可使架構師可以敏銳地發現底層的真實狀況，以端到端閉環的方式去思考問題，可以識別系統的短板並解決它。

還有很重要的一點，能落地的架構纔是好架構，因此架構師還須要具有良好的溝通能力（感性），能確保各方對架構達成共識，願意採起一致的行動；而良好的平衡取捨能力（理性），能夠確保架構在現有資源約束下是最合理的，能讓理想最終照進現實。
參考資料

https://www.cnblogs.com/awzh2020/p/12513557.html

https://www.cnblogs.com/awzh2020/p/12513483.html

https://www.cnblogs.com/awzh2020/p/12496324.html

https://www.cnblogs.com/awzh2020/p/12496174.html

https://www.cnblogs.com/awzh2020/p/12489362.html

https://www.cnblogs.com/awzh2020/p/12485546.html

https://www.cnblogs.com/awzh2020/p/12482641.html

https://www.cnblogs.com/awzh2020/p/12513557.html
https://www.cnblogs.com/liudianjia/p/12513320.html
https://www.cnblogs.com/liudianjia/p/12513272.html
https://www.cnblogs.com/liudianjia/p/12495990.html
https://www.cnblogs.com/liudianjia/p/12488902.html
https://www.cnblogs.com/liudianjia/p/12484952.html
https://www.cnblogs.com/liudianjia/p/12479110.html

https://www.cnblogs.com/xiangcunjiaoshi/p/12485190.html

https://www.cnblogs.com/xiangcunjiaoshi/p/12482707.html

https://www.cnblogs.com/xiangcunjiaoshi/p/12492287.html

https://www.cnblogs.com/xiangcunjiaoshi/p/12492412.html

https://www.cnblogs.com/xiangcunjiaoshi/p/12507406.html

https://www.cnblogs.com/xiangcunjiaoshi/p/12513642.html

https://www.cnblogs.com/xiangcunjiaoshi/p/12513716.html