阿裡妹導讀：架構師是一個既能掌控整體又能洞悉局部瓶頸并依據具體的業務場景給出解決方案的團隊上司型人物。看似完美的“人格模型”背後，是艱辛的探索。今天，阿裡巴巴技術專家九摩将多年經驗，進行系統性地總結，幫助更多架構師在進階這條路上走得更“順暢”，姿态更“優雅”。
架構師職責
架構師不是一個人，他需要建立高效卓越的體系，帶領團隊去攻城略地，在規定的時間内完成項目。
架構師需要能夠識别定義并确認需求，能夠進行系統分解形成整體架構，能夠正确地技術選型，能夠制定技術規格說明并有效推動實施落地。
按 TOGAF 的定義，架構師的職責是了解并關注實際上關系重大但未變得過載的一些關鍵細節和界面，架構師的角色有：了解并解析需求，建立有用的模型，确認、細化并擴充模型，管理架構。
從業界來看對于架構師的了解可以大概區分為：
- 企業架構師：專注于企業總體 IT 架構的設計。
- IT 架構師-軟體産品架構師：專注于軟體産品的研發。
- IT 架構師-應用架構師：專注于結合企業需求，定制化 IT 解決方案；大部分需要傳遞的工作包括總體架構、應用架構、資料架構，甚至部署架構。
- IT 架構師-技術架構師：專注于基礎設施，某種軟硬體體系，甚至雲平台，送出：産品建議、産品選型、部署架構、網絡方案，甚至資料中心建設方案等。
阿裡内部沒有在職位 title 上專門設定架構師了，架構師更多是以角色而存在，現在還留下可見的 title 有兩個：首席架構師和解決方案架構師，其中解決方案架構師目前在大部分 BU 都有設定，特别是在阿裡雲和電商體系。
解決方案架構師
工作方式了解
- 了解和挖掘客戶痛點，項目定義，現有環境管理；
- 梳理明确高階需求和非功能性需求；
- 客戶有什麼資産，星環（阿裡電商作業系統）／阿裡雲等有什麼解決方案；
- 溝通，方案建議，多次疊代，傳遞總體架構；
- 架構決策。
職責
1.從客戶視圖來看：
- 堅定客戶高層信心：利用架構和解決方案能力，幫忙客戶選擇星環／阿裡雲平台的信心。
- 解決客戶中層問題：利用星環／阿裡雲平台服務+結合應用架構設計/解決方案能力，幫忙客戶解決業務問題，獲得業務價值。
- 引領客戶 IT 員工和阿裡生态同學：技術引領、方法引領、産品引領。
2.從項目視圖看：
- 對接管理部門：彙報技術方案，進度；技術溝通。
- 對接客戶 PM，項目 PM：協助項目計劃，人員管理等。負責所有技術傳遞物的指導。
- 對接業務部門和需求人員：了解和挖掘痛點，幫忙梳理進階業務需求，指導需求工藝。
- 對接開發：産品支援、技術指導、架構指導。
- 對接測試：配合測試計劃和工藝制定。配合性能測試或者非功能性測試。
- 對接運維：産品支援，運維支援。
- 對接配置&環境：産品支援。
- 其他：阿裡技術資源聚合。
3.從阿裡内部看：
- 銷售方案支援；
- 市場宣貫；
- 客戶需求Facade；
- 解決方案沉澱。
架構師職責明确了，那麼有什麼架構思維可以指導架構設計呢？請看下述的架構思維。
架構思維
自頂向下建構架構
要點主要如下：
1.首先定義問題，而定義問題中最重要的是定義客戶的問題。定義問題，特别是識别出關鍵問題，關鍵問題是對客戶有體感，能夠解決客戶痛點，通過一定的資料化來衡量識别出來，關鍵問題要優先給出解決方案。
2.問題定義務必加入時間次元，把手段/方案和問題定義區分開來。
3.問題定義中，需要對問題進行升層思考後再進行升維思考，進而真正抓到問題的本質，理清和挖掘清楚需求；要善用第一性原理思維進行分析思考問題。
4.問題解決原則：先解決客戶的問題（使命），然後才能解決自己的問題（願景）；務必記住不是強調我們怎麼樣，而是我們能為客戶具體解決什麼問題，然後才是我們變成什麼，進而怎麼樣去更好得服務客戶。
5.善用多種方法對客戶問題進行分析，轉換成我們産品或者平台需要提供的能力，比如倉儲系統 WMS 可以提供哪些商業能力。
6.對我們的現有的流程和能力模型進行梳理，找到需要提升的地方，升層思考和升維思考真正明确提升部分。
7.定義名額，并能夠對名額進行拆解，然後進行數學模組化。
8.将抽象出來的能力訴求轉換成技術挑戰，此步對于技術人員來說相當于找到了靶子，可以進行方案的設計了，需要結合自底向上的架構推導方式。
9.創新可以是業務創新，也可以是産品創新，也可以是技術創新，也可以是營運創新，升層思考、升維思考，使用第一性原理思維、生物學（進化論--進化=變異+選擇+隔離、熵增定律、分形和湧現）思維等哲科思維可以幫助我們在業務，産品，技術上發現不同的創新可能。可以說哲科思維是架構師的靈魂思維。
自底向上推導應用架構
先根據業務流程，分解出系統時序圖，根據時序圖開始對子產品進行歸納，進而得到粒度更大的子產品，子產品的組合／聚合建構整個系統架構。
基本上應用邏輯架構的推導有4個子路徑，他們分别是：
- 業務概念架構：業務概念架構來自于業務概念模型和業務流程；
- 系統模型：來自于業務概念模型；
- 系統流程：來自業務流程；
- 非功能性的系統支撐：來自對性能、穩定性、成本的需要。
效率、穩定性、性能是最影響邏輯架構落地成實體架構的三大主要因素，是以從邏輯架構到實體架構，一定需要先對效率、穩定性和性能做出明确的量化要求。
自底向上重度依賴于演繹和歸納。
如果是産品方案已經明确，程式員需要了解這個業務需求，并根據産品方案推導出架構，此時一般使用自底向上的方法，而領域模組化就是這種自底向上的分析方法。
對于自底向上的分析方法，如果提煉一下關鍵詞，會得到如下兩個關鍵詞：
1.演繹：演繹就是邏輯推導，越是底層的，越需要演繹：
- 從用例到業務模型就屬于演繹；
- 從業務模型到系統模型也屬于演繹；
- 根據目前的問題，推導出要實施某種穩定性措施，這是也是演繹。
2.歸納：這裡的歸納是根據事物的某個次元來進行歸類，越是高層的，越需要歸納：
- 問題空間子產品劃分屬于歸納；
- 邏輯架構中有部分也屬于歸納；
- 根據一堆穩定性問題，歸納出，事前，事中，事後都需要做對應的操作，是就是根據時間次元來進行歸納。
領域驅動設計架構
大部分傳統架構都是基于領域模型分析架構，典型的領域實作模型設計可以參考DDD（領域驅動設計），詳細可以參考《實作領域驅動設計》這本書，另外《UML和模式應用》在領域模組化實操方面比較好，前者偏理論了解，後者便于落地實踐。
領域劃分設計步驟：
1.對使用者需求場景分析，識别出業務全次元 Use Case；
2.分析模型魯棒圖，識别出業務場景中所有的實體對象。魯棒圖 —— 是需求設計過程中使用的一種方法（魯棒性分析），通過魯棒分析法可以讓設計人員更清晰，更全面地了解需求。它通常使用在需求分析後及需求設計前做軟體架構分析之用，它主要注重于功能需求的設計分析工作。需求規格說明書為其輸入資訊，設計模型為其輸出資訊。它是從功能需求向設計方案過渡的第一步，重點是識别組成軟體系統的進階職責子產品、規劃子產品之間的關系。魯棒圖包含三種圖形：邊界、控制、實體，三個圖形如下：
3、領域劃分，将所有識别出的實體對象進行分類；
4、評估域劃分合理性，并進行優化。
基于資料驅動設計架構
随着 IoT、大資料和人工智能的發展，以領域驅動的方式進行架構往往滿足不了需求或者達不到預期的效果，在大資料時代，在大資料應用場景，我們需要轉變思維，從領域分析升維到基于大資料統計分析結果來進行業務架構、應用架構、資料架構和技術架構。這裡需要架構師具備數理統計分析的基礎和 BI 的能力，以資料思維來架構系統，典型的系統像阿裡的資料分析平台采雲間和菜鳥的資料分析平台 FBI。
上述四種思維，往往在架構設計中是融合使用的，需要根據業務或者系統的需求來選擇側重思維方式。
有了架構思維的指導，具體有沒有通用／标準化的架構架構以更好的執行架構設計？請看常見的架構架構。下述的架構架構其實本身也包含了重要的一些架構思維。
常見架構架構
TOGAF
TOGAF 是 The Open Group Architecture Framework 的縮寫，它由 The Open Group 開發，The Open Group 是一個非盈利的技術行業聯盟，它不斷更新和重申 TOGAF。
TOGAF 強調商業目标作為架構的驅動力，并提供了一個最佳實踐的儲藏庫，其中包括 TOGAF 架構開發方法（ADM）、TOGAF 架構内容架構、TOGAF 參考模型、架構開發方法（ADM）指引和技術、企業連續統一體和 TOGAF 能力架構。
ADM
ADM是一個疊代的步驟順序以發展企業範圍的架構的方法。
架構内容架構
參考模型
ADM指引和技術
1、架構疊代階段：
2、在不同水準運用ADM：
3、利益相關者分類：
企業連續統一體
架構指導及支援解決方案：基礎 通用系統 行業組織特定
能力架構
（更多内容可以參考《TOGAF标準9.1版本》或者
https://www.opengroup.org/togaf）
Zachman
第一個最有影響力的架構方法論就是 Zachman 架構，它是 John Zachman 首次在1987年提出的。
Zachman 架構模型分兩個次元：橫向次元采用6W（what、how、where、who、when、why）進行組織，縱向次元反映了 IT 架構層次，從上到下（Top-Down），分别為範圍模型、企業模型、系統模型、技術模型、詳細模型、功能模型。橫向結合6W，Zachman 架構分别由資料、功能、網絡、人員、時間、動機分别對應回答What、How、Where、Who、When 與 Why 這六個問題。
ITSA
ITSA誕生于1986年的惠普，世界最早的企業架構架構(IT戰略與架構)。模組化原則就是“Everything you need, and nothing you don’t”，隻放你要的東西。
DODAF
DODAF 是美國國防部架構架構，是一個控制“EA開發、維護和決策生成”的組織機制，是統一組織“團隊資源、描述和控制EA活動”的總體結構。
DODAF 涵蓋 DoD 的所有業務領域，定義了表示、描述、內建 DoD 範圍内衆多架構的标準方法，確定架構描述可比較、評估，提供了對 FoS (系統族)和 SoS (體系)進行了解、比較、內建和互操作共同的架構基礎，提供開發和表達架構描述的規則和指南,但不指導如何實作。
DODAF 核心是8個視點和52個模型。
1.全景視點 AV
與所有視點相關的體系結構描述的頂層概貌。提供有關體系結構描述的總體資訊，諸如體系結構描述的範圍和背景。範圍包括體系結構描述的專業領域和時間架構。背景由構成體系結構描述背景的互相關聯各種條件組成，包括條令，戰術、技術和程式，相關目标和構想的描述，作戰概念(CONOPS)，想定和環境條件。
2.能力視點CV
能力視點(CV)集中反映了與整體願景相關的組織目标，這些願景指在特定标準和條件下進行特定行動過程或是達成期望效果的能力，它們綜合使用各種手段和方式來完成一組任務。
CV 為體系結構描述中闡述的能力提供了戰略背景和相應的高層範圍，比作戰概念圖中定義的基于想定的範圍更全面。
這些模型是高層的，用決策者易于了解的術語來描述能力，以便溝通能力演進方面戰略構想。
3.作戰視點OV
作戰視點(OV)集中反映了完成 DoD 使命的機構、任務或執行的行動以及彼此間必須交換的資訊。描述資訊交換的種類、頻度、性質，資訊交換支援哪些任務和活動。
4.服務視點 SvcV
服務視點(SvcV)集中反映了為作戰行動提供支撐的系統、服務和互相交織的功能。DoD 流程包括作戰、業務、情報和基礎設施功能。SvcV 功能和服務資源及要素可以連結到 0V 中的體系結構資料。這些系統功能和服務資源支撐作戰行動，促進資訊交換。
5.系統視點 SV
系統視點(SV)集中反映支援作戰行動中的自動化系統、互相交聯和其他系統功能的資訊。随着對面向服務環境和雲計算的重視，在 DoDAF 的未來版本中也許不會有系統視點。
6.數信視點 DIV
資料和資訊視點(DIV)，簡稱數信視點，反映了體系結構描述中的業務資訊需求和結構化的業務流程規則。
描述體系結構描述中與資訊交換相關的資訊，諸如屬性、特征和互相關系。
必要時，本視點模型中用到的資料需要由多個架構團隊來共同考慮。
7.标準視點 StdV
标準視點(StdV)是用來管控系統各組成部分或要素的編排、互動和互相依賴的規則的最小集。其目的是確定系統能滿足特定的一組操作需求。
标準視點提供技術系統的實施指南，以工程規範為基礎，确立通用的積木塊，開發産品線。
包括一系列技術标準、執行慣例、标準選項、規則和規範，這些标準在特定體系結構描述中可以組成管控系統和系統/服務要素的檔案(profile)。
8.項目視點 PV
項目視點(PV)集中反映了項目是如何有機地組織成一個釆辦項目的有序組合。
描述多個采辦項目之間關聯關系，每個采辦項目都負責傳遞特定系統或能力。
TOGAF，Zachman，ITSA 和 DODAF 是非常不錯的架構架構，尤其前兩者應用很廣泛，TOGAF 還有專門的架構認證。當我們掌握了這些架構，我們是不是需要一些架構原則來指導更具體的設計？請看下文。
架構原則
設計原則就是架構設計的指導思想，它指導我們如何将資料和函數組織成類，如何将類連結起來成為元件和程式。反向來說，架構的主要工作就是将軟體拆解為元件，設計原則指導我們如何拆解、拆解的粒度、元件間依賴的方向、元件解耦的方式等。
設計原則有很多，我們進行架構設計的主導原則是 OCP（開閉原則），在類和代碼的層級上有：SRP（單一職責原則）、LSP（裡氏替換原則）、ISP（接口隔離原則）、DIP（依賴反轉原則）；在元件的層級上有：REP（複用、釋出等同原則）、CCP（共同閉包原則）、CRP（共同複用原則），處理元件依賴問題的三原則：無依賴環原則、穩定依賴原則、穩定抽象原則。
1.OCP（開閉原則）：設計良好的軟體應該易于擴充，同時抗拒修改。這是我們進行架構設計的主導原則，其他的原則都為這條原則服務。
2.SRP（單一職責原則）：任何一個軟體子產品，都應該有且隻有一個被修改的原因，“被修改的原因“指系統的使用者或所有者，翻譯一下就是，任何子產品隻對一個使用者的價值負責，該原則指導我們如何拆分元件。
舉個例子，CTO 和 COO 都要統計員工的工時，目前他們要求的統計方式可能是相同的，我們複用一套代碼，這時 COO 說周末的工時統計要乘以二，按照這個需求修改完代碼，CTO 可能就要過來罵街了。當然這是個非常淺顯的例子，實際項目中也有很多代碼服務于多個價值主體，這帶來很大的探秘成本和修改風險，另外，當一份代碼有多個所有者時，就會産生代碼合并沖突的問題。
3.LSP（裡氏替換原則）：當用同一接口的不同實作互相替換時，系統的行為應該保持不變。該原則指導的是接口與其實作方式。
你一定很疑惑，實作了同一個接口，他們的行為也肯定是一緻的呀，還真不一定。假設認為矩形的系統行為是：面積=寬*高，讓正方形實作矩形的接口，在調用 setW 和 setH 時，正方形做的其實是同一個事情，設定它的邊長。這時下邊的單元測試用矩形能通過，用正方形就不行，實作同樣的接口，但是系統行為變了，這是違反 LSP 的經典案例。
4.ISP（接口隔離原則）：不依賴任何不需要的方法、類或元件。該原則指導我們的接口設計。當我們依賴一個接口但隻用到了其中的部分方法時，其實我們已經依賴了不需要的方法或類，當這些方法或類有變更時，會引起我們類的重新編譯，或者引起我們元件的重新部署，這些都是不必要的。是以我們最好定義個小接口，把用到的方法拆出來。
5.DIP（依賴反轉原則）：指一種特定的解耦（傳統的依賴關系建立在高層次上，而具體的政策設定則應用在低層次的子產品上）形式，使得高層次的子產品不依賴于低層次的子產品的實作細節，依賴關系被颠倒（反轉），進而使得低層次子產品依賴于高層次子產品的需求抽象。
跨越組建邊界的依賴方向永遠與控制流的方向相反。該原則指導我們設計元件間依賴的方向。
依賴反轉原則是個可操作性非常強的原則，當你要修改元件間的依賴方向時，将需要進行元件間通信的類抽象為接口，接口放在邊界的哪邊，依賴就指向哪邊。
6.REP（複用、釋出等同原則）：軟體複用的最小粒度應等同于其釋出的最小粒度。直白地說，就是要複用一段代碼就把它抽成元件，該原則指導我們元件拆分的粒度。
7.CCP（共同閉包原則）：為了相同目的而同時修改的類，應該放在同一個元件中。CCP 原則是 SRP 原則在元件層面的描述。該原則指導我們元件拆分的粒度。
對大部分應用程式而言，可維護性的重要性遠遠大于可複用性，由同一個原因引起的代碼修改，最好在同一個元件中，如果分散在多個元件中，那麼開發、送出、部署的成本都會上升。
8.CRP（共同複用原則）：不要強迫一個元件依賴它不需要的東西。CRP 原則是 ISP原則在元件層面的描述。該原則指導我們元件拆分的粒度。
相信你一定有這種經曆，內建了元件 A，但元件 A 依賴了元件 B、C。即使元件 B、C 你完全用不到，也不得不內建進來。這是因為你隻用到了元件 A 的部分能力，元件 A 中額外的能力帶來了額外的依賴。如果遵循共同複用原則，你需要把 A 拆分，隻保留你要用的部分。
REP、CCP、CRP 三個原則之間存在彼此競争的關系，REP 和 CCP 是黏合性原則，它們會讓元件變得更大，而 CRP 原則是排除性原則，它會讓元件變小。遵守REP、CCP 而忽略 CRP，就會依賴了太多沒有用到的元件和類，而這些元件或類的變動會導緻你自己的元件進行太多不必要的釋出；遵守 REP、CRP 而忽略 CCP，因為元件拆分的太細了，一個需求變更可能要改 n 個元件，帶來的成本也是巨大的。
除了上述設計原則，還有一些重要的指導原則如下：
1.N+1設計：系統中的每個元件都應做到沒有單點故障；
2.復原設計：確定系統可以向前相容，在系統更新時應能有辦法復原版本；
3.禁用設計：應該提供控制具體功能是否可用的配置，在系統出現故障時能夠快速下線功能；
4.監控設計：在設計階段就要考慮監控的手段，便于有效的排查問題，比如引入traceId、業務身份 Id 便于排查監控問題；
5.多活資料中心設計：若系統需要極高的高可用，應考慮在多地實施資料中心進行多活，至少在一個機房斷電的情況下系統依然可用；
6.采用成熟的技術：剛開發的或開源的技術往往存在很多隐藏的 bug，出了問題沒有很好的商業支援可能會是一個災難；
7.資源隔離設計：應避免單一業務占用全部資源；
8.架構水準擴充設計：系統隻有做到能水準擴充，才能有效避免瓶頸問題；
9.非核心則購買的原則：非核心功能若需要占用大量的研發資源才能解決，則考慮購買成熟的産品；
10.使用商用硬體：商用硬體能有效降低硬體故障的機率；
11.快速疊代：系統應該快速開發小功能子產品，盡快上線進行驗證，早日發現問題大大降低系統傳遞的風險；
12.無狀态設計：服務接口應該做成無狀态的，目前接口的通路不依賴于接口上次通路的狀态。
架構師知道了職責，具備很好的架構思維，掌握了通用的架構架構和方法論，使用架構原則進行架構設計，不同的業務和系統要求不一樣，那麼有沒有針對不同場景的系統架構設計？下文就針對分布式架構演進、單元化架構、面向服務 SOA 架構、微服務架構、Serverless 架構進行介紹，以便于我們在實際運用中進行參考使用。
常見架構
分布式架構演進
初始階段架構
特征：應用程式，資料庫，檔案等所有資源都放在一台伺服器上。
應用服務和資料服務以及檔案服務分離
說明：好景不長，發現随着系統通路量的再度增加，webserver 機器的壓力在高峰期會上升到比較高，這個時候開始考慮增加一台 webserver。
特征：應用程式、資料庫、檔案分别部署在獨立的資源上。
使用緩存改善性能
說明：系統通路特點遵循二八定律，即80%的業務通路集中在20%的資料上。緩存分為本地緩存 遠端分布式緩存，本地緩存通路速度更快但緩存資料量有限，同時存在與應用程式争用記憶體的情況。
特征：資料庫中通路較集中的一小部分資料存儲在緩存伺服器中，減少資料庫的通路次數，降低資料庫的通路壓力。
使用“應用伺服器”叢集
說明：在做完分庫分表這些工作後，資料庫上的壓力已經降到比較低了，又開始過着每天看着通路量暴增的幸福生活了。突然有一天，發現系統的通路又開始有變慢的趨勢了，這個時候首先檢視資料庫，壓力一切正常，之後檢視 webserver，發現apache 阻塞了很多的請求， 而應用伺服器對每個請求也是比較快的，看來是請求數太高導緻需要排隊等待，響應速度變慢。
特征：多台伺服器通過負載均衡同時向外部提供服務，解決單台伺服器處理能力和存儲空間上限的問題。
描述：使用叢集是系統解決高并發、海量資料問題的常用手段。通過向叢集中追加資源，提升系統的并發處理能力，使得伺服器的負載壓力不再成為整個系統的瓶頸。
資料庫讀寫分離
說明：享受了一段時間的系統通路量高速增長的幸福後，發現系統又開始變慢了，這次又是什麼狀況呢，經過查找，發現資料庫寫入、更新的這些操作的部分資料庫連接配接的資源競争非常激烈，導緻了系統變慢。
特征：資料庫引入主備部署。
描述：把資料庫劃分為讀庫和寫庫，通過引入主從資料庫服務，讀和寫操作在不同的資料庫服務處理，讀庫可以有多個，通過同步機制把寫庫的資料同步到讀庫，對于需要查詢最新寫入資料場景，可以通過在緩存中多寫一份，通過緩存獲得最新資料。
反向代理和CDN加速
特征：采用CDN和反向代理加快系統的通路速度。
描述：為了應付複雜的網絡環境和不同地區使用者的通路，通過 CDN 和反向代理加快使用者通路的速度，同時減輕後端伺服器的負載壓力。CDN 與反向代理的基本原理都是緩存。
“分布式檔案”系統 和 “分布式資料庫”
說明：随着系統的不斷運作，資料量開始大幅度增長，這個時候發現分庫後查詢仍然會有些慢，于是按照分庫的思想開始做分表的工作
特征：資料庫采用分布式資料庫，檔案系統采用分布式檔案系統。
描述：任何強大的單一伺服器都滿足不了大型系統持續增長的業務需求，資料庫讀寫分離随着業務的發展最終也将無法滿足需求，需要使用分布式資料庫及分布式檔案系統來支撐。
分布式資料庫是系統資料庫拆分的最後方法，隻有在單表資料規模非常龐大的時候才使用，更常用的資料庫拆分手段是業務分庫，将不同的業務資料庫部署在不同的實體伺服器上。
使用 NoSQL 和搜尋引擎
特征：系統引入 NoSQL 資料庫及搜尋引擎。
描述：随着業務越來越複雜，對資料存儲和檢索的需求也越來越複雜，系統需要采用一些非關系型資料庫如 NoSQL 和分資料庫查詢技術如搜尋引擎。
應用伺服器通過統一資料通路子產品通路各種資料，減輕應用程式管理諸多資料源的麻煩。
業務拆分
特征：系統上按照業務進行拆分改造，應用伺服器按照業務區分進行分别部署。
描述：為了應對日益複雜的業務場景，通常使用分而治之的手段将整個系統業務分成不同的産品線，應用之間通過超連結建立關系，也可以通過消息隊列進行資料分發，當然更多的還是通過通路同一個資料存儲系統來構成一個關聯的完整系統。
縱向拆分：将一個大應用拆分為多個小應用，如果新業務較為獨立，那麼就直接将其設計部署為一個獨立的 Web 應用系統縱向拆分相對較為簡單，通過梳理業務，将較少相關的業務剝離即可。
橫向拆分：将複用的業務拆分出來，獨立部署為分布式服務，新增業務隻需要調用這些分布式服務橫向拆分需要識别可複用的業務，設計服務接口，規範服務依賴關系。
分布式服務
特征：公共的應用子產品被提取出來，部署在分布式伺服器上供應用伺服器調用。
描述：随着業務越拆越小，應用系統整體複雜程度呈指數級上升，由于所有應用要和所有資料庫系統連接配接，最終導緻資料庫連接配接資源不足，拒絕服務。
分布式服務的問題和挑戰：
(1) 當服務越來越多時，服務URL配置管理變得非常困難，F5硬體負載均衡器的單點壓力也越來越大。
(2) 當進一步發展，服務間依賴關系變得錯蹤複雜，甚至分不清哪個應用要在哪個應用之前啟動，架構師都不能完整的描述應用的架構關系。
(3) 服務的調用量越來越大，服務的容量問題就暴露出來，這個服務需要多少機器支撐？什麼時候該加機器？
(4) 服務多了，溝通成本也開始上升，調某個服務失敗該找誰？服務的參數都有什麼約定？
(5) 一個服務有多個業務消費者，如何確定服務品質？
(6) 随着服務的不停更新，總有些意想不到的事發生，比如 cache 寫錯了導緻記憶體溢出，故障不可避免，每次核心服務一挂，影響一大片，人心慌慌，如何控制故障的影響面？服務是否可以功能降級？或者資源劣化？
針對這些問題，下述的單元化架構，微服務架構以及 Serveless 架構可以一定程度解決，另外針對業務系統，需要做到業務與業務隔離、管理域和運作域分開、業務與平台隔離方可解決上述問題。
單元化架構
1、什麼是單元化：單元化架構是從并行計算領域發展而來。在分布式服務設計領域，一個單元（Cell）就是滿足某個分區所有業務操作的自包含的安裝。而一個分區（Shard），則是整體資料集的一個子集，如果你用尾号來劃分使用者，那同樣尾号的那部分使用者就可以認為是一個分區。單元化就是将一個服務設計改造讓其符合單元特征的過程。
2、單元化的必要性：随着硬體的不斷更新，計算機硬體能力已經越來越強，CPU越來越快，記憶體越來越大，網絡越來越寬。這讓我們看到了在單台機器上垂直擴充的機會。尤其是當你遇到一個性能要求和容量增長可以預期的業務，單元化給我們提供另外的機會，讓我們可以有效降低資源的使用，提供更高性能的服務。
更高性能更低成本是我們的主要目标，經過單元化改造，我們得以用更少（約二分之一）的機器，獲得了比原來更高（接近百倍）的性能。性能的提升很大部分原因在于服務的本地化，而服務的內建部署又進一步降低了資源的使用。除了性能收益，還有很多收益，比如更好的隔離性，包括請求隔離和資源隔離，比如更友好的更新，産品可以灰階釋出等。單元化改造後對高峰的應對以及擴容方式等問題的解決。
3、如何做到單元化：先看下圖傳統的服務架構，服務是分層的，每一層使用不同的分區算法，每一層都有不同數量的節點，上層節點随機選擇下層節點。
在單元化架構下，服務雖然分層劃分，但每個單元自成一體。按照層次來講的話，所有層使用相同的分區算法，每一層都有相同數量的節點，上層節點也會通路指定的下層節點。
SOA架構
SOA（Service-Oriented Architecture，面向服務的架構）是一個元件模型，它将應用程式的不同功能單元（稱為服務）通過這些服務之間定義良好的接口和契約聯系起來。接口是采用中立的方式進行定義的，它應該獨立于實作服務的硬體平台、作業系統和程式設計語言。這使得建構在各種各樣的系統中的服務可以以一種統一和通用的方式進行互動。面向服務架構，它可以根據需求通過網絡對松散耦合的粗粒度應用元件進行分布式部署、組合和使用。服務層是 SOA 的基礎，可以直接被應用調用，進而有效控制系統中與軟體代理互動的人為依賴性。
SOA的實施具有幾個鮮明的基本特征。實施 SOA 的關鍵目标是實作企業 IT 資産的最大化作用。要實作這一目标，就要在實施 SOA 的過程中牢記以下特征：
（1）可從企業外部通路
（2）随時可用
（3）粗粒度的服務接口分級
（4）松散耦合
（5）可重用的服務
（6）服務接口設計管理
（7）标準化的服務接口
（8）支援各種消息模式
（9）精确定義的服務契約
為了實作 SOA，企業需要一個服務架構，下圖顯示了一個例子：
在上圖中， 服務消費者（service consumer）可以通過發送消息來調用服務。這些消息由一個服務總線（service bus）轉換後發送給适當的服務實作。這種服務架構可以提供一個業務規則引（business rules engine），該引擎容許業務規則被合并在一個服務裡或多個服務裡。這種架構也提供了一個服務管理基礎（service management infrastructure），用來管理服務，類似稽核，清單（billing），日志等功能。此外，該架構給企業提供了靈活的業務流程，更好地處理控制請求（regulatory requirement），例如Sarbanes Oxley（SOX），并且可以在不影響其他服務的情況下更改某項服務。
微服務架構
先來看看傳統的 web 開發方式，通過對比比較容易了解什麼是 Microservice Architecture。和 Microservice 相對應的，這種方式一般被稱為 Monolithic（單體式開發）。
所有的功能打包在一個 WAR包裡，基本沒有外部依賴（除了容器），部署在一個JEE容器（Tomcat，JBoss，WebLogic）裡，包含了 DO/DAO，Service，UI 等所有邏輯。
優點：
- 開發簡單，集中式管理；
- 基本不會重複開發；
- 功能都在本地，沒有分布式的管理和調用消耗。
缺點：
- 效率低：開發都在同一個項目改代碼，互相等待，沖突不斷；
- 維護難：代碼功功能耦合在一起，新人不知道何從下手；
- 不靈活：建構時間長，任何小修改都要重構整個項目，耗時；
- 穩定性差：一個微小的問題，都可能導緻整個應用挂掉；
- 擴充性不夠：無法滿足高并發下的業務需求。
常見的系統架構遵循的三個标準和業務驅動力：
- 提高靈活性：及時響應業務需求，促進企業發展；
- 提升使用者體驗：提升使用者體驗，減少使用者流失；
- 降低成本：降低增加産品、客戶或業務方案的成本。
基于微服務架構的設計：
目的：有效的拆分應用，實作靈活開發和部署。
關于微服務的一個形象表達：
- X軸：運作多個負載均衡器之後的運作執行個體；
- Y軸：将應用進一步分解為微服務（分庫）；
- Z軸：大資料量時，将服務分區（分表）。
SOA和微服務的差別：
- SOA喜歡重用，微服務喜歡重寫；
- SOA喜歡水準服務，微服務喜歡垂直服務；
- SOA喜歡自上而下，微服務喜歡自下而上。
Serverless 架構
1、思想：無伺服器是一種架構理念，其核心思想是将提供服務資源的基礎設施抽象成各種服務，以 API 接口的方式供給使用者按需調用，真正做到按需伸縮、按使用收費。
2、優勢：消除了對傳統的海量持續線上伺服器元件的需求，降低了開發和運維的複雜性，降低營運成本并縮短了業務系統的傳遞周期，使得使用者能夠專注在價值密度更高的業務邏輯的開發上。
3、内容：目前業界較為公認的無伺服器架構主要包括兩個方面，即提供計算資源的函數服務平台 FaaS，以及提供托管雲服務的後端服務 BaaS。
函數即服務（Function as a Service）：是一項基于事件驅動的函數托管計算服務。通過函數服務，開發者隻需要編寫業務函數代碼并設定運作的條件，無需配置和管理伺服器等基礎設施，函數代碼運作在無狀态的容器中，由事件觸發且短暫易失，并完全由第三方管理，基礎設施對應用開發者完全透明。函數以彈性、高可靠的方式運作，并且按實際執行資源計費，不執行不産生費用。
後端即服務（Backend as a Service）：BaaS 覆寫了應用可能依賴的所有第三方服務，如雲資料庫、身份驗證、對象存儲等服務，開發人員通過 API 和由 BaaS 服務商提供的 SDK，能夠內建所需的所有後端功能，而無需建構後端應用，更不必管理虛拟機或容器等基礎設施，就能保證應用的正常運作。
三個less感覺很好：
- Codeless 對應的是服務開發，實作了源代碼托管，你隻需要關注你的代碼實作，而不需要關心你的代碼在哪，因為在整個開發過程中你都不會感受到代碼庫和代碼分支的存在。
- Applicationless 對應的是服務釋出，在服務化架構下，你的服務釋出不再需要申請應用，也不需要關注你的應用在哪。
- Serverless 對應的則是服務運維，有了 Serverless 化能力，你不再需要關注你的機器資源，Servlerless 會幫你搞定機器資源的彈性擴縮容。
架構師在完成上述架構設計後，最終是需要協同利益相關方一起按項目化運作落地拿結果，那麼應該如何保證利益相關方在項目落地的滿意度，如何保證按照架構很好的拿到項目成功的結果呢？架構管理能力是架構師非常重要的能力。
架構管理
架構共赢模型
架構結果管理
參考資料：
https://developer.alipay.com/article/8538 https://www.cnblogs.com/wintersun/p/8972949.html https://www.atatech.org/articles/95466 https://www.atatech.org/articles/104688 https://yuque.antfin-inc.com/tmf/documents/how-to-desigin-domain聲明：本文部分内容參考阿裡内部和外部一些文章，詳情見上述參考資料；撰寫本文的重點是系統體系化地總結認識架構師的工作，以便于更好的互動學習和成長，部分觀點是個人觀點。
原文釋出時間為： 2019-07-3
本文作者： 九摩
本文來自雲栖社群合作夥伴“
阿裡技術”，了解相關資訊可以關注“
”。