阿里妹導讀：架構師是一個既能掌控整體又能洞悉局部瓶頸并依據具體的業務場景給出解決方案的團隊領導型人物。看似完美的“人格模型”背后，是艱辛的探索。今天，阿里巴巴技術專家九摩將多年經驗，進行系統性地總結，幫助更多架構師在進階這條路上走得更“順暢”，姿態更“優雅”。

架構師職責

架構師不是一個人，他需要建立高效卓越的體系，帶領團隊去攻城略地，在規定的時間內完成項目。

架構師需要能夠識別定義并確認需求，能夠進行系統分解形成整體架構，能夠正確地技術選型，能夠制定技術規格說明并有效推動實施落地。

按 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、利益相關者分類：

?

?

企業連續統一體

架構指導及支持解決方案：基礎 通用系統 行業組織特定

能力框架

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 會幫你搞定機器資源的彈性擴縮容。

架構師在完成上述架構設計后，最終是需要協同利益相關方一起按項目化運作落地拿結果，那么應該如何保證利益相關方在項目落地的滿意度，如何保證按照架構很好的拿到項目成功的結果呢？架構管理能力是架構師非常重要的能力。

架構管理

架構共贏模型

架構結果管理

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的如何带领团队“攻城略地”？优秀的架构师这样做的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。