備注說明：相關(guān)總結(jié)屬于個(gè)人學(xué)習(xí)筆記，請(qǐng)勿商用，感興趣的可在極客時(shí)間訂閱該《喬新亮的CTO成長復(fù)盤》專欄學(xué)習(xí)，謝謝~

好的架構(gòu)設(shè)計(jì)，就像優(yōu)秀的組織協(xié)作一樣，既能幫助 IT 系統(tǒng)做好各模塊的專業(yè)分工，又能體現(xiàn)模塊間的協(xié)作精神。 對(duì)應(yīng)技術(shù)是“高內(nèi)聚、松耦合”、“單一職責(zé)原則”、“接口隔離原則”。

如果一名架構(gòu)師存在職業(yè)發(fā)展瓶頸，那么他的問題大概率是簡單的設(shè)計(jì)方法沒有執(zhí)行好，而不是復(fù)雜的設(shè)計(jì)方法沒學(xué)會(huì)。

• OMS（訂單管理系統(tǒng)）： 處理用戶訂單，負(fù)責(zé)調(diào)度
• WMS（倉庫管理系統(tǒng)）：負(fù)責(zé)倉儲(chǔ)管理
• TMS（運(yùn)輸管理系統(tǒng)）：安排物流運(yùn)輸。

“V” 字型設(shè)計(jì)
拆分是指將一個(gè)負(fù)責(zé)的功能按角色、按職責(zé)拆分，核心特征是單一模塊的功能既單純又簡單。

從零實(shí)現(xiàn)一個(gè)淘寶網(wǎng)拆分成：
訂單中心，用戶中心，商品中心，庫存中心

訂單中心還可以再拆分：
訂單創(chuàng)建，訂單查詢，訂單履約

不斷繼續(xù)拆分，直到能夠用簡潔優(yōu)雅的代碼去實(shí)現(xiàn)。

合并是指將類似的職責(zé)放在一個(gè)模塊完成，抽象出可重用、復(fù)用的部分，提升業(yè)務(wù)響應(yīng)效率。
比如訂單創(chuàng)建、訂單查詢都需要對(duì)數(shù)據(jù)庫進(jìn)行操作，那么與數(shù)據(jù)庫的交互就應(yīng)該統(tǒng)一封裝。

架構(gòu)是由元素（element）和關(guān)系（relationship）組成的。

• 「元素」：穩(wěn)定、可復(fù)用的部分應(yīng)該變成組件或應(yīng)用模塊，對(duì)應(yīng)著架構(gòu)中的
• 「關(guān)系」：不確定性的設(shè)計(jì)，則需要變成協(xié)作方式，為可能的擴(kuò)展作準(zhǔn)備

架構(gòu)師的基礎(chǔ)與核心能力：「專業(yè)分工」和「協(xié)作精神」

微服務(wù)基本的原則：讓系統(tǒng)的分工更明確、責(zé)任更清晰。
中臺(tái)：突出了“可重用部分的抽象”

中臺(tái)是一種企業(yè)級(jí)的架構(gòu)理念和方法論，側(cè)重于業(yè)務(wù)能力的沉淀和復(fù)用；
微服務(wù)是一種軟件架構(gòu)風(fēng)格，側(cè)重于服務(wù)的拆分和獨(dú)立部署。中臺(tái)可以基于微服務(wù)架構(gòu)來實(shí)現(xiàn)。

無論是微服務(wù)還是中臺(tái)，都有其巨大的實(shí)踐價(jià)值，但二者只是架構(gòu)設(shè)計(jì)核心原則的一種成熟的實(shí)踐模式和承載方式，不是解決架構(gòu)問題的“靈丹妙藥”。

架構(gòu)設(shè)計(jì)本質(zhì)上是一種“中庸思想”，如果單純考慮功能設(shè)計(jì)，我們的目標(biāo)只有一個(gè)：讓架構(gòu)響應(yīng)業(yè)務(wù)調(diào)整的速度更快。

保證各「元素」職責(zé)清晰的情況下，抽象出穩(wěn)定的功能或組件，用業(yè)務(wù)流程去串聯(lián)起來。

復(fù)雜架構(gòu)設(shè)計(jì)如何落地執(zhí)行

• 關(guān)鍵認(rèn)知：在個(gè)人視角里，整個(gè)世界都可以按照確定性內(nèi)容和不確定性內(nèi)容做簡單區(qū)分；
• 架構(gòu)將其抽象為元素和關(guān)系，元素對(duì)應(yīng)著確定性內(nèi)容的處理，是看待這個(gè)世界的穩(wěn)定視角；關(guān)系對(duì)應(yīng)著不確定性內(nèi)容的處理，是看待這個(gè)世界的響應(yīng)視角；
• 人類的理解能力有限。包含內(nèi)容過多的元素，會(huì)導(dǎo)致理解困難，需要將其拆分；
• 同理，將元素歸類的時(shí)候，也不能貪多，不然會(huì)導(dǎo)致理解困難。優(yōu)秀的架構(gòu)師，會(huì)將合理數(shù)量的元素進(jìn)行歸類，歸類后的整體一般被稱作 component 或 module，也可以直譯為“組件”。比如，我們永遠(yuǎn)以“元素?cái)?shù)量為 10 ”作為一個(gè)衡量點(diǎn)，只要一個(gè)組件包含的元素 / 職責(zé)超過 10 個(gè)，就要進(jìn)行拆分；
  -元素歸類一般采用 “V” 字型分析法，即流程分解為功能，功能聚合為組件；
• 如果組件明確了，意味著職責(zé)就建設(shè)好了，架構(gòu)的元素（element）建設(shè)問題就解決了。組件對(duì)外暴露的能力，我們統(tǒng)一稱之為服務(wù)；
• 那么，架構(gòu)的關(guān)系（relationship）建設(shè)問題該如何解決呢？穩(wěn)定的關(guān)系，用來表達(dá)確定性的交互，使用 SOA 架構(gòu)，做好服務(wù)調(diào)用就可以；不穩(wěn)定的關(guān)系，用來表達(dá)不確定性的交互，使用 EDA 架構(gòu)；
• 在每一個(gè)新需求到來時(shí)，尤其是大版本的更迭，架構(gòu)師需要介入產(chǎn)品經(jīng)理和程序員的溝通中，判斷新需求是否大幅增加了某些組件的復(fù)雜度，并決定是否調(diào)整組件職責(zé)，或?qū)ΜF(xiàn)有組件進(jìn)行拆分。所以，從實(shí)際的業(yè)務(wù)發(fā)展來看，組件的數(shù)量是逐步增長的，如果一開始就很多，基本屬于過度設(shè)計(jì)；如果業(yè)務(wù)復(fù)雜度已經(jīng)翻倍了，組件數(shù)量卻沒變，基本屬于缺乏設(shè)計(jì)。

將復(fù)雜問題拆解為簡單問題，逐一解決再合并，并將可復(fù)用的知識(shí)抽象，以實(shí)現(xiàn)舉一反三。