架构 | 聊聊我心中的架构设计观
【架構設計】| 總結/Edison Zhou
在各種面試場合，可能都會被問到“你對架構設計的理解”，我也在最近的轉正答辯中被技術委員會負責人問到，這里我重新整理一下思緒，聊聊我心中的的架構設計觀。
1系統的本質是什么？
作為一個技術人，恐怕會被經常問到系統架構設計的問題，即便是剛剛畢業的應屆生，可能也對6大設計原則 和 23種設計模式 了然于胸（雖然可能是感性認識較多）。
自認為自己還不算一名合格的系統架構師，但是對于系統架構設計的理解也在不斷的深入，今天斗膽聊聊我心中的系統架構設計觀。
要聊架構設計，就得先理解什么是系統？又或者說系統的本質是什么？
系統其實是由多個要素 及 連接關系 組成的共同體，它不僅局限于我們所熟悉的IT系統，它更是我們現實生活中的各種模型。但是，現實中我們往往首先看到的是要素，但是我們真正需要的修煉的是透過表現看清要素及其連接關系。
舉個例子，就拿一只表來說，可能一般的人只會觀察其中的表象即時針，秒針與表盤，但是有洞察力的人卻會透過表象去看其中的成百上千個零件要素及其連接關系，最終得到一個鐘表系統的模型。
系統論總結了要素之間的連接關系大致有這幾種：因果鏈、增強回路、調節回路 及?滯后效應。在這幾種關系中，最重要的就是 增強回路。
例如，潤總在《商業洞察力》中舉了一個例子，微軟食堂（不得不說，別人家的公司就是好，還有這么好的食堂）。微軟員工對于微軟食堂的口味厭倦了，但是供應商的動力卻不大，因此存在一條如下圖所示的調節回路。微軟人力部想到的辦法是改變系統模型，所謂改變系統模型就是就是改變系統中的結構模塊之間的關系，讓結果自己發生。因此，微軟選了兩家供應商，一家提供午餐，一家提供晚餐，每個季度員工評價是喜歡午餐還是晚餐，如果喜歡晚飯多，那么午餐和晚餐的供應商進行交換（要知道，做午餐比作晚餐利潤多）。如果連續兩個季度即半年午餐都勝出，那么更換晚餐供應商。可以看出，這個模型采用了競爭的機制，類似于“鯰魚效應”讓微軟食堂又煥發生機，成為了員工的最愛。從源頭來看，這是因為在調節回路的基礎上，改變系統模型增加了一條增強回路，從而激發了供應商的積極性。
一個好的系統（或模型），往往同時具有以上幾種關系，但都具有較為穩定的增強回路，在推動著增長的飛輪持續前進。
2架構設計核心認知
有了對系統的基礎認知，架構設計也就不難理解了，它們是類似的。
抽象地來看，架構也是由元素 和 關系組成的。
在架構設計中，較為穩定的、可復用的部分 會變成組件（Component）或 應用模塊（Module），對應著架構中的元素。
元素對應著確定性內容的處理，是看待這個世界的穩定視角；
在架構設計中，對模塊或服務的拆分，是考驗一個架構師的基本功，畢竟分而治之是降低復雜度的基本方法。但是，元素并不是拆分得越細越好，3個模塊能搞定的功能，非要寫10個模塊的過度設計，只能是給當前階段的發布計劃添亂。
而那些面向不確定性的設計，則會變成協作方式，為可能的擴展做準備，這對應著架構中的關系。
關系對應著不確定性內容的處理，是看待這個世界的響應視角；
穩定的關系，在架構中一般會用SOA、微服務架構來表示，做好服務調用即可；而不穩定的關系，則在架構中會會用EDA（事件驅動架構）來表示，做好異步處理（如發布訂閱、最終一致性等）即可。
3好的架構設計
抽象來看，好的架構設計跟優秀的組織協作一樣，既能幫助IT系統做好各模塊的專業分工，又能體現模塊間的協作精神。
從工程師到架構師，有一種能力是需要不斷提升的，那就是對復雜業務的拆分能力、對可復用部分的抽象能力、對拆分過程的顆粒度把握，以及對未來變化的考量和設計。
如何讓架構有足夠的“應變和適應能力”，則與架構師對業務的理解程度息息相關。
基于上面對架構設計的認知，我們或許可以這樣認為，對架構層面的【專業分工】和【協作精神】的理解，是架構師的基礎與核心的能力。
我們可以從近幾年火熱的微服務架構 和 企業中臺架構來理解：
微服務架構
我們都知道，在微服務架構中，每個服務的功能和數據處理是封裝在一起的（和SOA類似），服務治理、監控、調用?等基礎設施能力已經被封裝在了框架（如Spring Cloud）中使得開發團隊可以足夠聚焦業務實現。
可以看到在微服務體系下，微服務開發框架、K8s、Service Mesh、Multi Runtime的出現，技術架構部分中的很多職責已經被抽象出來，它們都在體現著一個基本的原則：讓系統的分工更明確、責任更清晰。
人類的理解能力有限。內容包含過多的元素，會導致理解困難，需要將其拆分；
有了專業的分工，也就是催生了服務的拆分，通常業界流行且認可的方法論就是DDD（領域驅動設計），通過劃分 核心域、通用域 與 支撐域，為微服務的拆分提供理論指導。
企業中臺架構
在一定時期內，一個企業的技術架構的功能或組件基本是穩定的，但是業務的運轉卻是動態變化的。因此，企業中臺架構又被搬上舞臺，它往往被賦予了快速響應市場變化的使命，其關鍵詞包括了：架構解耦、消除煙囪、能力復用...
中臺架構強調“企業級能力復用”，從架構的視角來看，它突出了“可重復部分的抽象”，阿里巴巴對組織結構調整，將職能型組織調整為可復用產品型組織—共享服務中心，建設微服務中臺為前臺業務提供快速接入的可復用能力。可以看到，它改變的是組織關系，映射到系統層面，它也體現著協作精神。
4康威定律
說完微服務架構 和 企業中臺架構，我們再來看看在半個世紀前的一篇文章，它就是康威定律。
?
在康威的這篇文章中，最有名的一句話就是：
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)
中文直譯大概的意思就是：設計系統的組織，其產生的設計等同于組織之內、組織之間的溝通結構。
看看下面的圖片，再想想Apple的產品、微軟的產品設計，就能形象生動的理解這句話。
用通俗的說法就是：組織形式等同系統設計。
一個系統的設計，其實也體現著團隊的組織形式。小而美的團隊注定比大而全的團隊的溝通效率要高，做事效率要快。
換句話說，你想要什么樣的系統，就搭建什么樣的團隊。如果你的團隊分成前端團隊，.NET/Java后端開發團隊，DBA團隊，運維團隊，你的系統就會長成下面的樣子：
相反，如果你的系統是按照業務邊界劃分的，大家按照一個業務目標去把自己的模塊做出小系統，小產品的話，你的大系統就會長成下面的樣子，即微服務的架構。
因此，按業務來劃分團隊，能讓團隊自然的自治內聚，明確的業務邊界會減少和外部的溝通成本，每個小團隊都對自己的模塊的整個生命周期負責，沒有邊界不清，沒有無效的扯皮。
此外，亞馬遜的Bezos有個逗趣的比喻，如果2個披薩不夠一個團隊吃的，那么這個團隊就太大了。事實上一般一個互聯網公司小產品的團隊差不多就是7人左右。
可以看到，康威定律所表述的基本原則也是元素及其連接關系，專業分工與協作精神，而這一切的出發點，都是為了降低成本 和 提高效益 以適應不斷變化的市場環境。
End總結
人類在解決很多復雜問題時，都會采用類似的思維流程：將復雜問題拆解為簡單問題，逐一解決再合并，并將可復用的知識抽象，以實現舉一反三。
從抽象來看，架構設計的本質在于解決元素及其之間的連接關系，朝著專業分工和協作精神的方向不斷演進，最終實現企業的降本增效的目的。
年終總結：Edison的2020年終總結
數字化轉型：我在傳統企業做數字化轉型
C#刷題：C#刷劍指Offer算法題系列文章目錄
.NET面試：.NET開發面試知識體系
.NET大會：2020年中國.NET開發者大會PDF資料
????掃碼關注EdisonTalk
?
??
?
總結
以上是生活随笔為你收集整理的架构 | 聊聊我心中的架构设计观的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 设计模式之中介者
- 下一篇： GeneralUpdate 2021.0