如何帶領團隊「攻城略地」？優秀的架構師這樣作

時間 2019-11-08

標籤如何帶領團隊攻城略地優秀架構師這樣简体版

原文原文鏈接

架構師職責

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

架構師須要可以識別定義並確認需求，可以進行系統分解造成總體架構，可以正確地技術選型，可以制定技術規格說明並有效推進實施落地。程序員

按 TOGAF 的定義，架構師的職責是瞭解並關注實際上關係重大但未變得過載的一些關鍵細節和界面，架構師的角色有：理解並解析需求，建立有用的模型，確認、細化並擴展模型，管理架構。web

從業界來看對於架構師的理解能夠大概區分爲：算法

企業架構師：專一於企業整體 IT 架構的設計。
IT 架構師-軟件產品架構師：專一於軟件產品的研發。
IT 架構師-應用架構師：專一於結合企業需求，定製化 IT 解決方案；大部分須要交付的工做包括整體架構、應用架構、數據架構，甚至部署架構。
IT 架構師-技術架構師：專一於基礎設施，某種軟硬件體系，甚至雲平臺，提交：產品建議、產品選型、部署架構、網絡方案，甚至數據中心建設方案等。

阿里內部沒有在職位 title 上專門設置架構師了，架構師更可能是以角色而存在，如今還留下可見的 title 有兩個：首席架構師和解決方案架構師，其中解決方案架構師目前在大部分 BU 都有設置，特別是在阿里雲和電商體系。數據庫

解決方案架構師apache

工做方式理解編程

瞭解和挖掘客戶痛點，項目定義，現有環境管理；
梳理明確高階需求和非功能性需求；
客戶有什麼資產，星環（阿里電商操做系統）／阿里雲等有什麼解決方案；
溝通，方案建議，屢次迭代，交付整體架構；
架構決策。

職責後端

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.分析模型魯棒圖，識別出業務場景中全部的實體對象。魯棒圖 —— 是需求設計過程當中使用的一種方法（魯棒性分析），經過魯棒分析法可讓設計人員更清晰，更全面地瞭解需求。它一般使用在需求分析後及需求設計前作軟件架構分析之用，它主要注重於功能需求的設計分析工做。需求規格說明書爲其輸入信息，設計模型爲其輸出信息。它是從功能需求向設計方案過渡的第一步，重點是識別組成軟件系統的高級職責模塊、規劃模塊之間的關係。魯棒圖包含三種圖形：邊界、控制、實體，三個圖形以下：

三、領域劃分，將全部識別出的實體對象進行分類；

四、評估域劃分合理性，並進行優化。

基於數據驅動設計架構

隨着 IoT、大數據和人工智能的發展，以領域驅動的方式進行架構每每知足不了需求或者達不到預期的效果，在大數據時代，在大數據應用場景，咱們須要轉變思惟，從領域分析升維到基於大數據統計分析結果來進行業務架構、應用架構、數據架構和技術架構。這裏須要架構師具有數理統計分析的基礎和 BI 的能力，以數據思惟來架構系統，典型的系統像阿里的數據分析平臺採雲間和菜鳥的數據分析平臺 FBI。

上述四種思惟，每每在架構設計中是融合使用的，須要根據業務或者系統的需求來選擇側重思惟方式。

有了架構思惟的指導，具體有沒有通用／標準化的架構框架以更好的執行架構設計？請看常見的架構框架。下述的架構框架其實自己也包含了重要的一些架構思惟。

推薦一個Java高級技術進階羣：976203838，文章運用到的架構技術都會在羣裏分享，都能免費下載。有興趣學習的猿猿能夠加一下。

常見架構框架

TOGAF

TOGAF 是 The Open Group Architecture Framework 的縮寫，它由 The Open Group 開發，The Open Group 是一個非盈利的技術行業聯盟，它不斷更新和重申 TOGAF。

TOGAF 強調商業目標做爲架構的驅動力，並提供了一個最佳實踐的儲藏庫，其中包括 TOGAF 架構開發方法（ADM）、TOGAF 架構內容框架、TOGAF 參考模型、架構開發方法（ADM）指引和技術、企業連續統一體和 TOGAF 能力框架。

ADM

ADM是一個迭代的步驟順序以發展企業範圍的架構的方法。

架構內容框架

參考模型

ADM指引和技術

一、架構迭代階段：

二、在不一樣水平運用ADM：

三、利益相關者分類：

企業連續統一體

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

能力框架

（更多內容能夠參考《TOGAF標準9.1版本》或者

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 還有專門的架構認證。當咱們掌握了這些框架，咱們是否是須要一些架構原則來指導更具體的設計？請看下文。

推薦一個Java高級技術進階羣：976203838，文章運用到的架構技術都會在羣裏分享，都能免費下載。有興趣學習的猿猿能夠加一下。

架構原則

設計原則就是架構設計的指導思想，它指導咱們如何將數據和函數組織成類，如何將類連接起來成爲組件和程序。反向來講，架構的主要工做就是將軟件拆解爲組件，設計原則指導咱們如何拆解、拆解的粒度、組件間依賴的方向、組件解耦的方式等。

設計原則有不少，咱們進行架構設計的主導原則是 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 架構能夠必定程度解決，另外針對業務系統，須要作到業務與業務隔離、管理域和運行域分開、業務與平臺隔離方可解決上述問題。

單元化架構

一、什麼是單元化：單元化架構是從並行計算領域發展而來。在分佈式服務設計領域，一個單元（Cell）就是知足某個分區全部業務操做的自包含的安裝。而一個分區（Shard），則是總體數據集的一個子集，若是你用尾號來劃分用戶，那一樣尾號的那部分用戶就能夠認爲是一個分區。單元化就是將一個服務設計改造讓其符合單元特徵的過程。

二、單元化的必要性：隨着硬件的不斷升級，計算機硬件能力已經愈來愈強，CPU愈來愈快，內存愈來愈大，網絡愈來愈寬。這讓咱們看到了在單臺機器上垂直擴展的機會。尤爲是當你遇到一個性能要求和容量增加能夠預期的業務，單元化給咱們提供另外的機會，讓咱們能夠有效下降資源的使用，提供更高性能的服務。

更高性能更低成本是咱們的主要目標，通過單元化改造，咱們得以用更少（約二分之一）的機器，得到了比原來更高（接近百倍）的性能。性能的提高很大部分緣由在於服務的本地化，而服務的集成部署又進一步下降了資源的使用。除了性能收益，還有不少收益，好比更好的隔離性，包括請求隔離和資源隔離，好比更友好的升級，產品能夠灰度發佈等。單元化改造後對高峯的應對以及擴容方式等問題的解決。

三、如何作到單元化：先看下圖傳統的服務架構，服務是分層的，每一層使用不一樣的分區算法，每一層都有不一樣數量的節點，上層節點隨機選擇下層節點。

在單元化架構下，服務雖然分層劃分，但每一個單元自成一體。按照層次來說的話，全部層使用相同的分區算法，每一層都有相同數量的節點，上層節點也會訪問指定的下層節點。

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），而且能夠在不影響其餘服務的狀況下更改某項服務。

推薦一個Java高級技術進階羣：976203838，文章運用到的架構技術都會在羣裏分享，都能免費下載。有興趣學習的猿猿能夠加一下。

微服務架構

先來看看傳統的 web 開發方式，經過對比比較容易理解什麼是 Microservice Architecture。和 Microservice 相對應的，這種方式通常被稱爲 Monolithic（單體式開發）。

全部的功能打包在一個 WAR包裏，基本沒有外部依賴（除了容器），部署在一個JEE容器（Tomcat，JBoss，WebLogic）裏，包含了 DO/DAO，Service，UI 等全部邏輯。

優勢：

開發簡單，集中式管理；
基本不會重複開發；
功能都在本地，沒有分佈式的管理和調用消耗。

缺點：

效率低：開發都在同一個項目改代碼，相互等待，衝突不斷；
維護難：代碼功功能耦合在一塊兒，新人不知道何從下手；
不靈活：構建時間長，任何小修改都要重構整個項目，耗時；
穩定性差：一個微小的問題，均可能致使整個應用掛掉；
擴展性不夠：沒法知足高併發下的業務需求。

常見的系統架構遵循的三個標準和業務驅動力：

提升敏捷性：及時響應業務需求，促進企業發展；
提高用戶體驗：提高用戶體驗，減小用戶流失；
下降成本：下降增長產品、客戶或業務方案的成本。

基於微服務架構的設計：

目的：有效的拆分應用，實現敏捷開發和部署。

關於微服務的一個形象表達：

X軸：運行多個負載均衡器以後的運行實例；
Y軸：將應用進一步分解爲微服務（分庫）；
Z軸：大數據量時，將服務分區（分表）。

SOA和微服務的區別：

SOA喜歡重用，微服務喜歡重寫；
SOA喜歡水平服務，微服務喜歡垂直服務；
SOA喜歡自上而下，微服務喜歡自下而上。

Serverless 架構

一、思想：無服務器是一種架構理念，其核心思想是將提供服務資源的基礎設施抽象成各類服務，以 API 接口的方式供給用戶按需調用，真正作到按需伸縮、按使用收費。

二、優點：消除了對傳統的海量持續在線服務器組件的需求，下降了開發和運維的複雜性，下降運營成本並縮短了業務系統的交付週期，使得用戶可以專一在價值密度更高的業務邏輯的開發上。

三、內容：目前業界較爲公認的無服務器架構主要包括兩個方面，即提供計算資源的函數服務平臺 FaaS，以及提供託管雲服務的後端服務 BaaS。

函數即服務（Function as a Service）：是一項基於事件驅動的函數託管計算服務。經過函數服務，開發者只須要編寫業務函數代碼並設置運行的條件，無需配置和管理服務器等基礎設施，函數代碼運行在無狀態的容器中，由事件觸發且短暫易失，並徹底由第三方管理，基礎設施對應用開發者徹底透明。函數以彈性、高可靠的方式運行，而且按實際執行資源計費，不執行不產生費用。

後端即服務（Backend as a Service）：BaaS 覆蓋了應用可能依賴的全部第三方服務，如雲數據庫、身份驗證、對象存儲等服務，開發人員經過 API 和由 BaaS 服務商提供的 SDK，可以集成所需的全部後端功能，而無需構建後端應用，更沒必要管理虛擬機或容器等基礎設施，就能保證應用的正常運行。

三個less感受很好：

Codeless 對應的是服務開發，實現了源代碼託管，你只須要關注你的代碼實現，而不須要關心你的代碼在哪，由於在整個開發過程當中你都不會感覺到代碼庫和代碼分支的存在。
Applicationless 對應的是服務發佈，在服務化框架下，你的服務發佈再也不須要申請應用，也不須要關注你的應用在哪。
Serverless 對應的則是服務運維，有了 Serverless 化能力，你再也不須要關注你的機器資源，Servlerless 會幫你搞定機器資源的彈性擴縮容。

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