|
架構師是一個既能掌控整體又能洞悉局部瓶頸并依據(jù)具體的業(yè)務場景給出解決方案的團隊領導型人物。看似完美的“人格模型”背后，是艱辛的探索。 今天，阿里巴巴技術專家九摩將多年經(jīng)驗，進行系統(tǒng)性地總結，幫助更多架構師在進階這條路上走得更“順暢”，姿態(tài)更“優(yōu)雅”。 架構師職責 架構師不是一個人，他需要建立高效卓越的體系，帶領團隊去攻城略地，在規(guī)定的時間內完成項目。 架構師需要能夠識別定義并確認需求，能夠進行系統(tǒng)分解形成整體架構，能夠正確地技術選型，能夠制定技術規(guī)格說明并有效推動實施落地。 按 TOGAF 的定義，架構師的職責是了解并關注實際上關系重大但未變得過載的一些關鍵細節(jié)和界面。 架構師的角色有：
從業(yè)界來看對于架構師的理解可以大概區(qū)分為：
阿里內部沒有在職位 Title 上專門設置架構師了，架構師更多是以角色而存在，現(xiàn)在還留下可見的 Title 有兩個：首席架構師和解決方案架構師。 其中解決方案架構師目前在大部分 BU 都有設置，特別是在阿里云和電商體系。 解決方案架構師 ①工作方式 工作方式理解：
②工作職責 從客戶視圖來看：
從項目視圖看：
從阿里內部看：
架構師職責明確了，那么有什么架構思維可以指導架構設計呢？請看下述的架構思維。 架構思維 自頂向下構建架構 要點主要如下：
自底向上推導應用架構 先根據(jù)業(yè)務流程，分解出系統(tǒng)時序圖，根據(jù)時序圖開始對模塊進行歸納，從而得到粒度更大的模塊，模塊的組合／聚合構建整個系統(tǒng)架構。 基本上應用邏輯架構的推導有 4 個子路徑，他們分別是：
效率、穩(wěn)定性、性能是最影響邏輯架構落地成物理架構的三大主要因素，所以從邏輯架構到物理架構，一定需要先對效率、穩(wěn)定性和性能做出明確的量化要求。 自底向上重度依賴于演繹和歸納。如果是產(chǎn)品方案已經(jīng)明確，程序員需要理解這個業(yè)務需求，并根據(jù)產(chǎn)品方案推導出架構，此時一般使用自底向上的方法，而領域建模就是這種自底向上的分析方法。 對于自底向上的分析方法，如果提煉一下關鍵詞，會得到如下兩個關鍵詞：
演繹就是邏輯推導，越是底層的，越需要演繹：
這里的歸納是根據(jù)事物的某個維度來進行歸類，越是高層的，越需要歸納：
領域驅動設計架構 大部分傳統(tǒng)架構都是基于領域模型分析架構，典型的領域實現(xiàn)模型設計可以參考 DDD（領域驅動設計），詳細可以參考《實現(xiàn)領域驅動設計》這本書。 另外《UML 和模式應用》在領域建模實操方面比較好，前者偏理論了解，后者便于落地實踐。 領域劃分設計步驟： ①對用戶需求場景分析，識別出業(yè)務全維度 Use Case。 ②分析模型魯棒圖，識別出業(yè)務場景中所有的實體對象。魯棒圖是需求設計過程中使用的一種方法（魯棒性分析），通過魯棒分析法可以讓設計人員更清晰，更全面地了解需求。 它通常使用在需求分析后及需求設計前做軟件架構分析之用，它主要注重于功能需求的設計分析工作。 需求規(guī)格說明書為其輸入信息，設計模型為其輸出信息。它是從功能需求向設計方案過渡的第一步，重點是識別組成軟件系統(tǒng)的高級職責模塊、規(guī)劃模塊之間的關系。 魯棒圖包含三種圖形：邊界、控制、實體，三個圖形如下： ③領域劃分，將所有識別出的實體對象進行分類。 ④評估域劃分合理性，并進行優(yōu)化。 基于數(shù)據(jù)驅動設計架構 隨著 IoT、大數(shù)據(jù)和人工智能的發(fā)展，以領域驅動的方式進行架構往往滿足不了需求或者達不到預期的效果。 在大數(shù)據(jù)時代，在大數(shù)據(jù)應用場景，我們需要轉變思維，從領域分析升維到基于大數(shù)據(jù)統(tǒng)計分析結果來進行業(yè)務架構、應用架構、數(shù)據(jù)架構和技術架構。 這里需要架構師具備數(shù)理統(tǒng)計分析的基礎和 BI 的能力，以數(shù)據(jù)思維來架構系統(tǒng)，典型的系統(tǒng)像阿里的數(shù)據(jù)分析平臺采云間和菜鳥的數(shù)據(jù)分析平臺 FBI。 上述四種思維，往往在架構設計中是融合使用的，需要根據(jù)業(yè)務或者系統(tǒng)的需求來選擇側重思維方式。 有了架構思維的指導，具體有沒有通用／標準化的架構框架以更好的執(zhí)行架構設計？請看常見的架構框架。下述的架構框架其實本身也包含了重要的一些架構思維。 常見架構框架 TOGAF TOGAF 是 The Open Group Architecture Framework 的縮寫，它由 The Open Group 開發(fā)，The Open Group 是一個非盈利的技術行業(yè)聯(lián)盟，它不斷更新和重申 TOGAF。 TOGAF 強調商業(yè)目標作為架構的驅動力，并提供了一個實踐的儲藏庫，其中包括 TOGAF 架構開發(fā)方法（ADM）、TOGAF 架構內容框架、TOGAF 參考模型、架構開發(fā)方法（ADM）指引和技術、企業(yè)連續(xù)統(tǒng)一體和 TOGAF 能力框架。 ①ADM ADM 是一個迭代的步驟順序以發(fā)展企業(yè)范圍的架構的方法。 ②架構內容框架 ③參考模型 ④ADM 指引和技術 架構迭代階段： 在不同水平運用 ADM： 利益相關者分類：
⑤企業(yè)連續(xù)統(tǒng)一體 架構指導及支持解決方案：基礎 ?通用系統(tǒng) ?行業(yè)?組織特定。
⑥能力框架
更多內容可以參考《TOGAF標準9.1版本》或者https://www./togaf。 Zachman 第一個具有影響力的框架方法論就是 Zachman 框架，它是 John Zachman 首次在 1987 年提出的。 Zachman 框架模型分兩個維度：
橫向結合 6W，Zachman 框架分別由數(shù)據(jù)、功能、網(wǎng)絡、人員、時間、動機分別對應回答 What、How、Where、Who、When 與 Why 這六個問題。
ITSA ITSA 誕生于 1986 年的惠普，是世界最早的企業(yè)架構框架(IT戰(zhàn)略與架構)。建模原則就是“Everything you need, and nothing you don’t”，只放你要的東西。
DODAF DODAF 是美國國防部架構框架，是一個控制“EA開發(fā)、維護和決策生成”的組織機制，是統(tǒng)一組織“團隊資源、描述和控制EA活動”的總體結構。 DODAF 涵蓋 DoD 的所有業(yè)務領域，定義了表示、描述、集成 DoD 范圍內眾多架構的標準方法。 確保架構描述可比較、評估，提供了對 FoS (系統(tǒng)族)和 SoS (體系)進行理解、比較、集成和互操作共同的架構基礎，提供開發(fā)和表達架構描述的規(guī)則和指南，但不指導如何實現(xiàn)。 DODAF 核心是 8 個視點和 52 個模型：
①全景視點 AV 與所有視點相關的體系結構描述的頂層概貌。它提供有關體系結構描述的總體信息，諸如體系結構描述的范圍和背景。范圍包括體系結構描述的專業(yè)領域和時間框架。 背景由構成體系結構描述背景的相互關聯(lián)各種條件組成，包括條令，戰(zhàn)術、技術和程序，相關目標和構想的描述，作戰(zhàn)概念(CONOPS)，想定和環(huán)境條件。
②能力視點 CV 能力視點(CV)集中反映了與整體愿景相關的組織目標，這些愿景指在特定標準和條件下進行特定行動過程或是達成期望效果的能力，它們綜合使用各種手段和方式來完成一組任務。 CV 為體系結構描述中闡述的能力提供了戰(zhàn)略背景和相應的高層范圍，比作戰(zhàn)概念圖中定義的基于想定的范圍更全面。 這些模型是高層的，用決策者易于理解的術語來描述能力，以便溝通能力演進方面戰(zhàn)略構想。
③作戰(zhàn)視點 OV 作戰(zhàn)視點(OV)集中反映了完成 DoD 使命的機構、任務或執(zhí)行的行動以及彼此間必須交換的信息。描述信息交換的種類、頻度、性質，信息交換支持哪些任務和活動。
④服務視點 SvcV 服務視點(SvcV)集中反映了為作戰(zhàn)行動提供支撐的系統(tǒng)、服務和相互交織的功能。DoD 流程包括作戰(zhàn)、業(yè)務、情報和基礎設施功能。 SvcV 功能和服務資源及要素可以鏈接到 0V 中的體系結構數(shù)據(jù)。這些系統(tǒng)功能和服務資源支撐作戰(zhàn)行動，促進信息交換。
⑤系統(tǒng)視點 SV 系統(tǒng)視點(SV)集中反映支持作戰(zhàn)行動中的自動化系統(tǒng)、相互交聯(lián)和其他系統(tǒng)功能的信息。 隨著對面向服務環(huán)境和云計算的重視，在 DoDAF 的未來版本中也許不會有系統(tǒng)視點。
⑥數(shù)信視點 DIV 數(shù)據(jù)和信息視點(DIV)，簡稱數(shù)信視點，反映了體系結構描述中的業(yè)務信息需求和結構化的業(yè)務流程規(guī)則。 描述體系結構描述中與信息交換相關的信息，諸如屬性、特征和相互關系。 必要時，本視點模型中用到的數(shù)據(jù)需要由多個架構團隊來共同考慮。
⑦標準視點 StdV 標準視點(StdV)是用來管控系統(tǒng)各組成部分或要素的編排、交互和相互依賴的規(guī)則的最小集。其目的是確保系統(tǒng)能滿足特定的一組操作需求。 標準視點提供技術系統(tǒng)的實施指南，以工程規(guī)范為基礎，確立通用的積木塊，開發(fā)產(chǎn)品線。 包括一系列技術標準、執(zhí)行慣例、標準選項、規(guī)則和規(guī)范，這些標準在特定體系結構描述中可以組成管控系統(tǒng)和系統(tǒng)/服務要素的文件(profile)。
⑧項目視點 PV 項目視點(PV)集中反映了項目是如何有機地組織成一個釆辦項目的有序組合。 描述多個采辦項目之間關聯(lián)關系，每個采辦項目都負責交付特定系統(tǒng)或能力。
TOGAF，Zachman，ITSA 和 DODAF 是非常不錯的架構框架，尤其前兩者應用很廣泛，TOGAF 還有專門的架構認證。 當我們掌握了這些框架，我們是不是需要一些架構原則來指導更具體的設計？請看下文。 架構原則 設計原則就是架構設計的指導思想，它指導我們如何將數(shù)據(jù)和函數(shù)組織成類，如何將類鏈接起來成為組件和程序。 反向來說，架構的主要工作就是將軟件拆解為組件，設計原則指導我們如何拆解、拆解的粒度、組件間依賴的方向、組件解耦的方式等。 設計原則有很多，我們進行架構設計的主導原則是 OCP（開閉原則），在類和代碼的層級上有：SRP（單一職責原則）、LSP（里氏替換原則）、ISP（接口隔離原則）、DIP（依賴反轉原則）。 在組件的層級上有：REP（復用、發(fā)布等同原則）、CCP（共同閉包原則）、CRP（共同復用原則），處理組件依賴問題的三原則：無依賴環(huán)原則、穩(wěn)定依賴原則、穩(wěn)定抽象原則。 ①OCP（開閉原則）：設計良好的軟件應該易于擴展，同時抗拒修改。這是我們進行架構設計的主導原則，其他的原則都為這條原則服務。 ②SRP（單一職責原則）：任何一個軟件模塊，都應該有且只有一個被修改的原因，“被修改的原因“指系統(tǒng)的用戶或所有者，翻譯一下就是，任何模塊只對一個用戶的價值負責，該原則指導我們如何拆分組件。 舉個例子，CTO 和 COO 都要統(tǒng)計員工的工時，當前他們要求的統(tǒng)計方式可能是相同的，我們復用一套代碼，這時 COO 說周末的工時統(tǒng)計要乘以二，按照這個需求修改完代碼，CTO 可能就要過來罵街了。 當然這是個非常淺顯的例子，實際項目中也有很多代碼服務于多個價值主體，這帶來很大的探秘成本和修改風險，另外，當一份代碼有多個所有者時，就會產(chǎn)生代碼合并沖突的問題。 ③LSP（里氏替換原則）：當用同一接口的不同實現(xiàn)互相替換時，系統(tǒng)的行為應該保持不變。該原則指導的是接口與其實現(xiàn)方式。 你一定很疑惑，實現(xiàn)了同一個接口，他們的行為也肯定是一致的呀，還真不一定。 假設認為矩形的系統(tǒng)行為是：面積=寬*高，讓正方形實現(xiàn)矩形的接口，在調用 setW 和 setH 時，正方形做的其實是同一個事情，設置它的邊長。 這時下邊的單元測試用矩形能通過，用正方形就不行，實現(xiàn)同樣的接口，但是系統(tǒng)行為變了，這是違反 LSP 的經(jīng)典案例。 Rectangle r = ... r.setW(5); r.setH(2); assert(r.area() == 10);④ISP（接口隔離原則）：不依賴任何不需要的方法、類或組件。該原則指導我們的接口設計。 當我們依賴一個接口但只用到了其中的部分方法時，其實我們已經(jīng)依賴了不需要的方法或類，當這些方法或類有變更時，會引起我們類的重新編譯，或者引起我們組件的重新部署，這些都是不必要的。所以我們最好定義個小接口，把用到的方法拆出來。 ⑤DIP（依賴反轉原則）：指一種特定的解耦（傳統(tǒng)的依賴關系創(chuàng)建在高層次上。而具體的策略設置則應用在低層次的模塊上）形式，使得高層次的模塊不依賴于低層次的模塊的實現(xiàn)細節(jié)，依賴關系被顛倒（反轉），從而使得低層次模塊依賴于高層次模塊的需求抽象。 跨越組建邊界的依賴方向永遠與控制流的方向相反。該原則指導我們設計組件間依賴的方向。 依賴反轉原則是個可操作性非常強的原則，當你要修改組件間的依賴方向時，將需要進行組件間通信的類抽象為接口，接口放在邊界的哪邊，依賴就指向哪邊。 ⑥REP（復用、發(fā)布等同原則）：軟件復用的最小粒度應等同于其發(fā)布的最小粒度。 直白地說，就是要復用一段代碼就把它抽成組件，該原則指導我們組件拆分的粒度。 ⑦CCP（共同閉包原則）：為了相同目的而同時修改的類，應該放在同一個組件中。 CCP 原則是 SRP 原則在組件層面的描述。該原則指導我們組件拆分的粒度。 對大部分應用程序而言，可維護性的重要性遠遠大于可復用性，由同一個原因引起的代碼修改，最好在同一個組件中，如果分散在多個組件中，那么開發(fā)、提交、部署的成本都會上升。 ⑧CRP（共同復用原則）：不要強迫一個組件依賴它不需要的東西。CRP 原則是 ISP原則在組件層面的描述。該原則指導我們組件拆分的粒度。 相信你一定有這種經(jīng)歷，集成了組件 A，但組件 A 依賴了組件 B、C。即使組件 B、C 你完全用不到，也不得不集成進來。 這是因為你只用到了組件 A 的部分能力，組件 A 中額外的能力帶來了額外的依賴。如果遵循共同復用原則，你需要把 A 拆分，只保留你要用的部分。 REP、CCP、CRP 三個原則之間存在彼此競爭的關系，REP 和 CCP 是黏合性原則，它們會讓組件變得更大，而 CRP 原則是排除性原則，它會讓組件變小。 遵守REP、CCP 而忽略 CRP，就會依賴了太多沒有用到的組件和類，而這些組件或類的變動會導致你自己的組件進行太多不必要的發(fā)布。 遵守 REP、CRP 而忽略 CCP，因為組件拆分的太細了，一個需求變更可能要改 n 個組件，帶來的成本也是巨大的。
除了上述設計原則，還有一些重要的指導原則如下：
架構師知道了職責，具備很好的架構思維，掌握了通用的架構框架和方法論，使用架構原則進行架構設計，不同的業(yè)務和系統(tǒng)要求不一樣，那么有沒有針對不同場景的系統(tǒng)架構設計？ 下文就針對分布式架構演進、單元化架構、面向服務 SOA 架構、微服務架構、Serverless 架構進行介紹，以便于我們在實際運用中進行參考使用。 常見架構 分布式架構演進 ①初始階段架構
特征：應用程序，數(shù)據(jù)庫，文件等所有資源都放在一臺服務器上。 ②應用服務和數(shù)據(jù)服務以及文件服務分離
說明：好景不長，發(fā)現(xiàn)隨著系統(tǒng)訪問量的再度增加，Web Server 機器的壓力在高峰期會上升到比較高，這個時候開始考慮增加一臺 Web Server。 特征：應用程序、數(shù)據(jù)庫、文件分別部署在獨立的資源上。 ③使用緩存改善性能
說明：系統(tǒng)訪問特點遵循二八定律，即 80% 的業(yè)務訪問集中在 20% 的數(shù)據(jù)上。 緩存分為本地緩存和遠程分布式緩存，本地緩存訪問速度更快但緩存數(shù)據(jù)量有限，同時存在與應用程序爭用內存的情況。 特征：數(shù)據(jù)庫中訪問較集中的一小部分數(shù)據(jù)存儲在緩存服務器中，減少數(shù)據(jù)庫的訪問次數(shù)，降低數(shù)據(jù)庫的訪問壓力。 ③使用“應用服務器”集群
說明：在做完分庫分表這些工作后，數(shù)據(jù)庫上的壓力已經(jīng)降到比較低了，又開始過著每天看著訪問量暴增的幸福生活了。 突然有一天，發(fā)現(xiàn)系統(tǒng)的訪問又開始有變慢的趨勢了，這個時候首先查看數(shù)據(jù)庫，壓力一切正常。 之后查看 Web Server，發(fā)現(xiàn) Apache 阻塞了很多的請求， 而應用服務器對每個請求也是比較快的，看來是請求數(shù)太高導致需要排隊等待，響應速度變慢。 特征：多臺服務器通過負載均衡同時向外部提供服務，解決單臺服務器處理能力和存儲空間上限的問題。 描述：使用集群是系統(tǒng)解決高并發(fā)、海量數(shù)據(jù)問題的常用手段。通過向集群中追加資源，提升系統(tǒng)的并發(fā)處理能力，使得服務器的負載壓力不再成為整個系統(tǒng)的瓶頸。 ④數(shù)據(jù)庫讀寫分離
說明：享受了一段時間的系統(tǒng)訪問量高速增長的幸福后，發(fā)現(xiàn)系統(tǒng)又開始變慢了，這次又是什么狀況呢？經(jīng)過查找，發(fā)現(xiàn)數(shù)據(jù)庫寫入、更新的這些操作的部分數(shù)據(jù)庫連接的資源競爭非常激烈，導致了系統(tǒng)變慢。 特征：數(shù)據(jù)庫引入主備部署。 描述：把數(shù)據(jù)庫劃分為讀庫和寫庫，通過引入主從數(shù)據(jù)庫服務，讀和寫操作在不同的數(shù)據(jù)庫服務處理。 讀庫可以有多個，通過同步機制把寫庫的數(shù)據(jù)同步到讀庫，對于需要查詢最新寫入數(shù)據(jù)場景，可以通過在緩存中多寫一份，通過緩存獲得最新數(shù)據(jù)。 ⑤反向代理和 CDN 加速
特征：采用 CDN 和反向代理加快系統(tǒng)的訪問速度。 描述：為了應付復雜的網(wǎng)絡環(huán)境和不同地區(qū)用戶的訪問，通過 CDN 和反向代理加快用戶訪問的速度，同時減輕后端服務器的負載壓力。CDN 與反向代理的基本原理都是緩存。 ⑥“分布式文件”系統(tǒng) 和 “分布式數(shù)據(jù)庫”
說明：隨著系統(tǒng)的不斷運行，數(shù)據(jù)量開始大幅度增長，這個時候發(fā)現(xiàn)分庫后查詢仍然會有些慢，于是按照分庫的思想開始做分表的工作。 特征：數(shù)據(jù)庫采用分布式數(shù)據(jù)庫，文件系統(tǒng)采用分布式文件系統(tǒng)。 描述：任何強大的單一服務器都滿足不了大型系統(tǒng)持續(xù)增長的業(yè)務需求，數(shù)據(jù)庫讀寫分離隨著業(yè)務的發(fā)展最終也將無法滿足需求，需要使用分布式數(shù)據(jù)庫及分布式文件系統(tǒng)來支撐。 分布式數(shù)據(jù)庫是系統(tǒng)數(shù)據(jù)庫拆分的最后方法，只有在單表數(shù)據(jù)規(guī)模非常龐大的時候才使用，更常用的數(shù)據(jù)庫拆分手段是業(yè)務分庫，將不同的業(yè)務數(shù)據(jù)庫部署在不同的物理服務器上。 ⑦使用 NoSQL 和搜索引擎
特征：系統(tǒng)引入 NoSQL 數(shù)據(jù)庫及搜索引擎。 描述：隨著業(yè)務越來越復雜，對數(shù)據(jù)存儲和檢索的需求也越來越復雜，系統(tǒng)需要采用一些非關系型數(shù)據(jù)庫如 NoSQL 和分數(shù)據(jù)庫查詢技術如搜索引擎。 應用服務器通過統(tǒng)一數(shù)據(jù)訪問模塊訪問各種數(shù)據(jù)，減輕應用程序管理諸多數(shù)據(jù)源的麻煩。 ⑧業(yè)務拆分
特征：系統(tǒng)上按照業(yè)務進行拆分改造，應用服務器按照業(yè)務區(qū)分進行分別部署。 描述：為了應對日益復雜的業(yè)務場景，通常使用分而治之的手段將整個系統(tǒng)業(yè)務分成不同的產(chǎn)品線，應用之間通過超鏈接建立關系，也可以通過消息隊列進行數(shù)據(jù)分發(fā)，當然更多的還是通過訪問同一個數(shù)據(jù)存儲系統(tǒng)來構成一個關聯(lián)的完整系統(tǒng)。 縱向拆分：將一個大應用拆分為多個小應用，如果新業(yè)務較為獨立，那么就直接將其設計部署為一個獨立的 Web 應用系統(tǒng)，縱向拆分相對較為簡單，通過梳理業(yè)務，將較少相關的業(yè)務剝離即可。 橫向拆分：將復用的業(yè)務拆分出來，獨立部署為分布式服務，新增業(yè)務只需要調用這些分布式服務橫向拆分需要識別可復用的業(yè)務，設計服務接口，規(guī)范服務依賴關系。 ⑨分布式服務
特征：公共的應用模塊被提取出來，部署在分布式服務器上供應用服務器調用。 描述：隨著業(yè)務越拆越小，應用系統(tǒng)整體復雜程度呈指數(shù)級上升，由于所有應用要和所有數(shù)據(jù)庫系統(tǒng)連接，最終導致數(shù)據(jù)庫連接資源不足，拒絕服務。 ⑩分布式服務的問題和挑戰(zhàn)：
針對這些問題，下述的單元化架構，微服務架構以及 Serveless 架構可以一定程度解決，另外針對業(yè)務系統(tǒng)，需要做到業(yè)務與業(yè)務隔離、管理域和運行域分開、業(yè)務與平臺隔離方可解決上述問題。 單元化架構 ①什么是單元化：單元化架構是從并行計算領域發(fā)展而來。在分布式服務設計領域，一個單元（Cell）就是滿足某個分區(qū)所有業(yè)務操作的自包含的安裝。 而一個分區(qū)（Shard），則是整體數(shù)據(jù)集的一個子集，如果你用尾號來劃分用戶，那同樣尾號的那部分用戶就可以認為是一個分區(qū)。單元化就是將一個服務設計改造讓其符合單元特征的過程。 ②單元化的必要性：隨著硬件的不斷升級，計算機硬件能力已經(jīng)越來越強，CPU 越來越快，內存越來越大，網(wǎng)絡越來越寬。這讓我們看到了在單臺機器上垂直擴展的機會。 尤其是當你遇到一個性能要求和容量增長可以預期的業(yè)務，單元化給我們提供另外的機會，讓我們可以有效降低資源的使用，提供更高性能的服務。 更高性能更低成本是我們的主要目標，經(jīng)過單元化改造，我們得以用更少（約二分之一）的機器，獲得了比原來更高（接近百倍）的性能。 性能的提升很大部分原因在于服務的本地化，而服務的集成部署又進一步降低了資源的使用。 除了性能收益，還有很多收益，比如更好的隔離性，包括請求隔離和資源隔離，比如更友好的升級，產(chǎn)品可以灰度發(fā)布等。單元化改造后對高峰的應對以及擴容方式等問題的解決。 ③如何做到單元化：先看下圖傳統(tǒng)的服務架構，服務是分層的，每一層使用不同的分區(qū)算法，每一層都有不同數(shù)量的節(jié)點，上層節(jié)點隨機選擇下層節(jié)點。
再看下圖單元化架構，其為性能和隔離性而設計，上層節(jié)點訪問指定下層節(jié)點。
在單元化架構下，服務雖然分層劃分，但每個單元自成一體。按照層次來講的話，所有層使用相同的分區(qū)算法，每一層都有相同數(shù)量的節(jié)點，上層節(jié)點也會訪問指定的下層節(jié)點。 SOA 架構 SOA（Service-Oriented Architecture，面向服務的架構）是一個組件模型，它將應用程序的不同功能單元（稱為服務）通過這些服務之間定義良好的接口和契約聯(lián)系起來。 接口是采用中立的方式進行定義的，它應該獨立于實現(xiàn)服務的硬件平臺、操作系統(tǒng)和編程語言。 這使得構建在各種各樣的系統(tǒng)中的服務可以以一種統(tǒng)一和通用的方式進行交互。 面向服務架構，它可以根據(jù)需求通過網(wǎng)絡對松散耦合的粗粒度應用組件進行分布式部署、組合和使用。 服務層是 SOA 的基礎，可以直接被應用調用，從而有效控制系統(tǒng)中與軟件代理交互的人為依賴性。 SOA 的實施具有幾個鮮明的基本特征。實施 SOA 的關鍵目標是實現(xiàn)企業(yè) IT 資產(chǎn)的最大化作用。 要實現(xiàn)這一目標，就要在實施 SOA 的過程中牢記以下特征：
為了實現(xiàn) SOA，企業(yè)需要一個服務架構，下圖顯示了一個例子：
在上圖中， 服務消費者（service consumer）可以通過發(fā)送消息來調用服務。這些消息由一個服務總線（service bus）轉換后發(fā)送給適當?shù)姆諏崿F(xiàn)。 這種服務架構可以提供一個業(yè)務規(guī)則引擎（business rules engine），該引擎容許業(yè)務規(guī)則被合并在一個服務里或多個服務里。 這種架構也提供了一個服務管理基礎（service management infrastructure），用來管理服務，類似審核，列表（billing），日志等功能。 此外，該架構給企業(yè)提供了靈活的業(yè)務流程，更好地處理控制請求（regulatory requirement），例如 Sarbanes Oxley（SOX），并且可以在不影響其他服務的情況下更改某項服務。 微服務架構 先來看看傳統(tǒng)的 Web 開發(fā)方式，通過對比比較容易理解什么是 Microservice Architecture。 和 Microservice 相對應的，這種方式一般被稱為 Monolithic（單體式開發(fā)）。 所有的功能打包在一個 WAR 包里，基本沒有外部依賴（除了容器），部署在一個 JEE 容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI 等所有邏輯。
優(yōu)點：
缺點：
常見的系統(tǒng)架構遵循的三個標準和業(yè)務驅動力：
基于微服務架構的設計：
關于微服務的一個形象表達：
SOA 和微服務的區(qū)別：
Serverless 架構 ①思想：無服務器是一種架構理念，其核心思想是將提供服務資源的基礎設施抽象成各種服務，以 API 接口的方式供給用戶按需調用，真正做到按需伸縮、按使用收費。 ②優(yōu)勢：消除了對傳統(tǒng)的海量持續(xù)在線服務器組件的需求，降低了開發(fā)和運維的復雜性，降低運營成本并縮短了業(yè)務系統(tǒng)的交付周期，使得用戶能夠專注在價值密度更高的業(yè)務邏輯的開發(fā)上。 ③內容：目前業(yè)界較為公認的無服務器架構主要包括兩個方面，即提供計算資源的函數(shù)服務平臺 FaaS，以及提供托管云服務的后端服務 BaaS。 函數(shù)即服務（Function as a Service）：是一項基于事件驅動的函數(shù)托管計算服務。 通過函數(shù)服務，開發(fā)者只需要編寫業(yè)務函數(shù)代碼并設置運行的條件，無需配置和管理服務器等基礎設施，函數(shù)代碼運行在無狀態(tài)的容器中，由事件觸發(fā)且短暫易失，并完全由第三方管理，基礎設施對應用開發(fā)者完全透明。 函數(shù)以彈性、高可靠的方式運行，并且按實際執(zhí)行資源計費，不執(zhí)行不產(chǎn)生費用。 后端即服務（Backend as a Service）：BaaS 覆蓋了應用可能依賴的所有第三方服務，如云數(shù)據(jù)庫、身份驗證、對象存儲等服務。 開發(fā)人員通過 API 和由 BaaS 服務商提供的 SDK，能夠集成所需的所有后端功能，而無需構建后端應用，更不必管理虛擬機或容器等基礎設施，就能保證應用的正常運行。
三個 less 感覺很好：
架構師在完成上述架構設計后，最終是需要協(xié)同利益相關方一起按項目化運作落地拿結果。 那么應該如何保證利益相關方在項目落地的滿意度，如何保證按照架構很好的拿到項目成功的結果呢？架構管理能力是架構師非常重要的能力。 架構管理 架構共贏模型：
架構結果管理：
參考資料：
聲明：本文部分內容參考阿里內部和外部一些文章，詳情見上述參考資料；撰寫本文的重點是系統(tǒng)體系化地總結認識架構師的工作，以便于更好的互動學習和成長，部分觀點是個人觀點。 作者：九摩 |
|
|
