架構(gòu)師職責

架構(gòu)師不是一個人撞反，他需要建立高效卓越的體系，帶領(lǐng)團隊去攻城略地，在規(guī)定的時間內(nèi)完成項目。

架構(gòu)師需要能夠識別定義并確認需求，能夠進行系統(tǒng)分解形成整體架構(gòu)辕漂，能夠正確地技術(shù)選型，能夠制定技術(shù)規(guī)格說明并有效推動實施落地吩蔑。

按 TOGAF 的定義钮热，架構(gòu)師的職責是了解并關(guān)注實際上關(guān)系重大但未變得過載的一些關(guān)鍵細節(jié)和界面，架構(gòu)師的角色有：理解并解析需求烛芬，創(chuàng)建有用的模型隧期，確認、細化并擴展模型赘娄，管理架構(gòu)仆潮。

從業(yè)界來看對于架構(gòu)師的理解可以大概區(qū)分為：

• 企業(yè)架構(gòu)師：專注于企業(yè)總體 IT 架構(gòu)的設(shè)計。
• IT 架構(gòu)師-軟件產(chǎn)品架構(gòu)師：專注于軟件產(chǎn)品的研發(fā)遣臼。
• IT 架構(gòu)師-應(yīng)用架構(gòu)師：專注于結(jié)合企業(yè)需求性置，定制化 IT 解決方案；大部分需要交付的工作包括總體架構(gòu)揍堰、應(yīng)用架構(gòu)鹏浅、數(shù)據(jù)架構(gòu)嗅义，甚至部署架構(gòu)。
• IT 架構(gòu)師-技術(shù)架構(gòu)師：專注于基礎(chǔ)設(shè)施隐砸，某種軟硬件體系之碗，甚至云平臺，提交：產(chǎn)品建議季希、產(chǎn)品選型褪那、部署架構(gòu)、網(wǎng)絡(luò)方案式塌，甚至數(shù)據(jù)中心建設(shè)方案等博敬。

阿里內(nèi)部沒有在職位 title 上專門設(shè)置架構(gòu)師了，架構(gòu)師更多是以角色而存在峰尝，現(xiàn)在還留下可見的 title 有兩個：首席架構(gòu)師和解決方案架構(gòu)師偏窝，其中解決方案架構(gòu)師目前在大部分 BU 都有設(shè)置，特別是在阿里云和電商體系境析。

解決方案架構(gòu)師

工作方式理解

• 了解和挖掘客戶痛點囚枪，項目定義，現(xiàn)有環(huán)境管理劳淆；
• 梳理明確高階需求和非功能性需求；
• 客戶有什么資產(chǎn)默赂，星環(huán)（阿里電商操作系統(tǒng)）／阿里云等有什么解決方案沛鸵；
• 溝通，方案建議缆八，多次迭代曲掰，交付總體架構(gòu)；
• 架構(gòu)決策奈辰。

職責

1.從客戶視圖來看：

• 堅定客戶高層信心：利用架構(gòu)和解決方案能力栏妖，幫忙客戶選擇星環(huán)／阿里云平臺的信心。
• 解決客戶中層問題：利用星環(huán)／阿里云平臺服務(wù)+結(jié)合應(yīng)用架構(gòu)設(shè)計/解決方案能力奖恰，幫忙客戶解決業(yè)務(wù)問題吊趾，獲得業(yè)務(wù)價值。
• 引領(lǐng)客戶 IT 員工和阿里生態(tài)同學(xué)：技術(shù)引領(lǐng)瑟啃、方法引領(lǐng)论泛、產(chǎn)品引領(lǐng)。

2.從項目視圖看：

• 對接管理部門：匯報技術(shù)方案蛹屿，進度屁奏；技術(shù)溝通。
• 對接客戶 PM错负，項目 PM：協(xié)助項目計劃坟瓢，人員管理等勇边。負責所有技術(shù)交付物的指導(dǎo)。
• 對接業(yè)務(wù)部門和需求人員：了解和挖掘痛點折联，幫忙梳理高級業(yè)務(wù)需求粒褒，指導(dǎo)需求工藝。
• 對接開發(fā)：產(chǎn)品支持崭庸、技術(shù)指導(dǎo)怀浆、架構(gòu)指導(dǎo)。
• 對接測試：配合測試計劃和工藝制定怕享。配合性能測試或者非功能性測試执赡。
• 對接運維：產(chǎn)品支持，運維支持函筋。
• 對接配置&環(huán)境：產(chǎn)品支持沙合。
• 其他：阿里技術(shù)資源聚合。

3.從阿里內(nèi)部看：

• 銷售方案支持跌帐；
• 市場宣貫首懈；
• 客戶需求Facade；
• 解決方案沉淀谨敛。

架構(gòu)師職責明確了究履，那么有什么架構(gòu)思維可以指導(dǎo)架構(gòu)設(shè)計呢？請看下述的架構(gòu)思維脸狸。

架構(gòu)思維

自頂向下構(gòu)建架構(gòu)

要點主要如下：

1.首先定義問題最仑，而定義問題中最重要的是定義客戶的問題。定義問題炊甲，特別是識別出關(guān)鍵問題泥彤，關(guān)鍵問題是對客戶有體感，能夠解決客戶痛點卿啡，通過一定的數(shù)據(jù)化來衡量識別出來吟吝，關(guān)鍵問題要優(yōu)先給出解決方案。

2.問題定義務(wù)必加入時間維度颈娜，把手段/方案和問題定義區(qū)分開來剑逃。

3.問題定義中，需要對問題進行升層思考后再進行升維思考揭鳞，從而真正抓到問題的本質(zhì)炕贵，理清和挖掘清楚需求；要善用第一性原理思維進行分析思考問題野崇。

4.問題解決原則：先解決客戶的問題（使命）称开，然后才能解決自己的問題（愿景）；務(wù)必記住不是強調(diào)我們怎么樣，而是我們能為客戶具體解決什么問題鳖轰，然后才是我們變成什么清酥，從而怎么樣去更好得服務(wù)客戶。

5.善用多種方法對客戶問題進行分析蕴侣，轉(zhuǎn)換成我們產(chǎn)品或者平臺需要提供的能力焰轻，比如倉儲系統(tǒng) WMS 可以提供哪些商業(yè)能力。

6.對我們的現(xiàn)有的流程和能力模型進行梳理昆雀，找到需要提升的地方辱志，升層思考和升維思考真正明確提升部分。

7.定義指標狞膘，并能夠?qū)χ笜诉M行拆解揩懒，然后進行數(shù)學(xué)建模。

8.將抽象出來的能力訴求轉(zhuǎn)換成技術(shù)挑戰(zhàn)挽封，此步對于技術(shù)人員來說相當于找到了靶子已球，可以進行方案的設(shè)計了，需要結(jié)合自底向上的架構(gòu)推導(dǎo)方式辅愿。

9.創(chuàng)新可以是業(yè)務(wù)創(chuàng)新智亮，也可以是產(chǎn)品創(chuàng)新，也可以是技術(shù)創(chuàng)新点待，也可以是運營創(chuàng)新阔蛉，升層思考、升維思考癞埠，使用第一性原理思維馍忽、生物學(xué)（進化論--進化=變異+選擇+隔離、熵增定律燕差、分形和涌現(xiàn)）思維等哲科思維可以幫助我們在業(yè)務(wù)，產(chǎn)品坝冕，技術(shù)上發(fā)現(xiàn)不同的創(chuàng)新可能徒探。可以說哲科思維是架構(gòu)師的靈魂思維喂窟。

自底向上推導(dǎo)應(yīng)用架構(gòu)

先根據(jù)業(yè)務(wù)流程测暗，分解出系統(tǒng)時序圖，根據(jù)時序圖開始對模塊進行歸納磨澡，從而得到粒度更大的模塊碗啄，模塊的組合／聚合構(gòu)建整個系統(tǒng)架構(gòu)。

基本上應(yīng)用邏輯架構(gòu)的推導(dǎo)有4個子路徑稳摄，他們分別是：

1. 業(yè)務(wù)概念架構(gòu)：業(yè)務(wù)概念架構(gòu)來自于業(yè)務(wù)概念模型和業(yè)務(wù)流程稚字；
2. 系統(tǒng)模型：來自于業(yè)務(wù)概念模型；
3. 系統(tǒng)流程：來自業(yè)務(wù)流程；
4. 非功能性的系統(tǒng)支撐：來自對性能胆描、穩(wěn)定性瘫想、成本的需要。

效率昌讲、穩(wěn)定性国夜、性能是最影響邏輯架構(gòu)落地成物理架構(gòu)的三大主要因素，所以從邏輯架構(gòu)到物理架構(gòu)短绸，一定需要先對效率车吹、穩(wěn)定性和性能做出明確的量化要求。

自底向上重度依賴于演繹和歸納醋闭。

如果是產(chǎn)品方案已經(jīng)明確窄驹，程序員需要理解這個業(yè)務(wù)需求，并根據(jù)產(chǎn)品方案推導(dǎo)出架構(gòu)目尖，此時一般使用自底向上的方法馒吴，而領(lǐng)域建模就是這種自底向上的分析方法。

對于自底向上的分析方法瑟曲，如果提煉一下關(guān)鍵詞饮戳，會得到如下兩個關(guān)鍵詞：

1.演繹：演繹就是邏輯推導(dǎo)，越是底層的洞拨，越需要演繹：

• 從用例到業(yè)務(wù)模型就屬于演繹扯罐；
• 從業(yè)務(wù)模型到系統(tǒng)模型也屬于演繹；
• 根據(jù)目前的問題烦衣，推導(dǎo)出要實施某種穩(wěn)定性措施歹河，這是也是演繹。

2.歸納：這里的歸納是根據(jù)事物的某個維度來進行歸類花吟，越是高層的秸歧，越需要歸納：

• 問題空間模塊劃分屬于歸納；
• 邏輯架構(gòu)中有部分也屬于歸納衅澈；
• 根據(jù)一堆穩(wěn)定性問題键菱，歸納出，事前今布，事中经备，事后都需要做對應(yīng)的操作，是就是根據(jù)時間維度來進行歸納部默。

領(lǐng)域驅(qū)動設(shè)計架構(gòu)

大部分傳統(tǒng)架構(gòu)都是基于領(lǐng)域模型分析架構(gòu)侵蒙，典型的領(lǐng)域?qū)崿F(xiàn)模型設(shè)計可以參考DDD（領(lǐng)域驅(qū)動設(shè)計），詳細可以參考《實現(xiàn)領(lǐng)域驅(qū)動設(shè)計》這本書傅蹂，另外《UML和模式應(yīng)用》在領(lǐng)域建模實操方面比較好纷闺，前者偏理論了解，后者便于落地實踐。

領(lǐng)域劃分設(shè)計步驟：

1.對用戶需求場景分析急但，識別出業(yè)務(wù)全維度 Use Case澎媒；

2.分析模型魯棒圖，識別出業(yè)務(wù)場景中所有的實體對象波桩。魯棒圖 —— 是需求設(shè)計過程中使用的一種方法（魯棒性分析）戒努，通過魯棒分析法可以讓設(shè)計人員更清晰，更全面地了解需求镐躲。它通常使用在需求分析后及需求設(shè)計前做軟件架構(gòu)分析之用储玫，它主要注重于功能需求的設(shè)計分析工作。需求規(guī)格說明書為其輸入信息萤皂，設(shè)計模型為其輸出信息撒穷。它是從功能需求向設(shè)計方案過渡的第一步，重點是識別組成軟件系統(tǒng)的高級職責模塊裆熙、規(guī)劃模塊之間的關(guān)系端礼。魯棒圖包含三種圖形：邊界、控制入录、實體蛤奥，三個圖形如下：

image.png

3、領(lǐng)域劃分僚稿，將所有識別出的實體對象進行分類凡桥；

4、評估域劃分合理性蚀同，并進行優(yōu)化缅刽。

基于數(shù)據(jù)驅(qū)動設(shè)計架構(gòu)

隨著 IoT、大數(shù)據(jù)和人工智能的發(fā)展蠢络，以領(lǐng)域驅(qū)動的方式進行架構(gòu)往往滿足不了需求或者達不到預(yù)期的效果衰猛，在大數(shù)據(jù)時代，在大數(shù)據(jù)應(yīng)用場景刹孔，我們需要轉(zhuǎn)變思維腕侄，從領(lǐng)域分析升維到基于大數(shù)據(jù)統(tǒng)計分析結(jié)果來進行業(yè)務(wù)架構(gòu)、應(yīng)用架構(gòu)芦疏、數(shù)據(jù)架構(gòu)和技術(shù)架構(gòu)。這里需要架構(gòu)師具備數(shù)理統(tǒng)計分析的基礎(chǔ)和 BI 的能力微姊，以數(shù)據(jù)思維來架構(gòu)系統(tǒng)酸茴，典型的系統(tǒng)像阿里的數(shù)據(jù)分析平臺采云間和菜鳥的數(shù)據(jù)分析平臺 FBI。

上述四種思維兢交，往往在架構(gòu)設(shè)計中是融合使用的薪捍，需要根據(jù)業(yè)務(wù)或者系統(tǒng)的需求來選擇側(cè)重思維方式。

有了架構(gòu)思維的指導(dǎo)，具體有沒有通用／標準化的架構(gòu)框架以更好的執(zhí)行架構(gòu)設(shè)計酪穿？請看常見的架構(gòu)框架凳干。下述的架構(gòu)框架其實本身也包含了重要的一些架構(gòu)思維。

推薦一個Java高級技術(shù)進階群：976203838被济，文章運用到的架構(gòu)技術(shù)都會在群里分享救赐，都能免費下載。有興趣學(xué)習(xí)的猿猿可以加一下只磷。

常見架構(gòu)框架

TOGAF

TOGAF 是 The Open Group Architecture Framework 的縮寫经磅，它由 The Open Group 開發(fā)，The Open Group 是一個非盈利的技術(shù)行業(yè)聯(lián)盟钮追，它不斷更新和重申 TOGAF预厌。

TOGAF 強調(diào)商業(yè)目標作為架構(gòu)的驅(qū)動力，并提供了一個最佳實踐的儲藏庫元媚，其中包括 TOGAF 架構(gòu)開發(fā)方法（ADM）轧叽、TOGAF 架構(gòu)內(nèi)容框架、TOGAF 參考模型刊棕、架構(gòu)開發(fā)方法（ADM）指引和技術(shù)炭晒、企業(yè)連續(xù)統(tǒng)一體和 TOGAF 能力框架。

ADM

ADM是一個迭代的步驟順序以發(fā)展企業(yè)范圍的架構(gòu)的方法鞠绰。

image

架構(gòu)內(nèi)容框架

參考模型

ADM指引和技術(shù)

1腰埂、架構(gòu)迭代階段：

2、在不同水平運用ADM：

3蜈膨、利益相關(guān)者分類：

企業(yè)連續(xù)統(tǒng)一體

架構(gòu)指導(dǎo)及支持解決方案：基礎(chǔ) 通用系統(tǒng) 行業(yè)組織特定

能力框架

（更多內(nèi)容可以參考《TOGAF標準9.1版本》或者

https://www.opengroup.org/togaf）

Zachman

第一個最有影響力的框架方法論就是 Zachman 框架屿笼，它是 John Zachman 首次在1987年提出的。

Zachman 框架模型分兩個維度：橫向維度采用6W（what翁巍、how驴一、where、who灶壶、when肝断、why）進行組織，縱向維度反映了 IT 架構(gòu)層次驰凛，從上到下（Top-Down）胸懈，分別為范圍模型、企業(yè)模型恰响、系統(tǒng)模型趣钱、技術(shù)模型、詳細模型胚宦、功能模型首有。橫向結(jié)合6W燕垃，Zachman 框架分別由數(shù)據(jù)、功能井联、網(wǎng)絡(luò)卜壕、人員、時間烙常、動機分別對應(yīng)回答What轴捎、How、Where军掂、Who轮蜕、When 與 Why 這六個問題。

ITSA

ITSA誕生于1986年的惠普蝗锥，世界最早的企業(yè)架構(gòu)框架(IT戰(zhàn)略與架構(gòu))跃洛。建模原則就是“Everything you need, and nothing you don’t”，只放你要的東西终议。

DODAF

DODAF 是美國國防部架構(gòu)框架汇竭，是一個控制“EA開發(fā)、維護和決策生成”的組織機制穴张，是統(tǒng)一組織“團隊資源细燎、描述和控制EA活動”的總體結(jié)構(gòu)。

DODAF 涵蓋 DoD 的所有業(yè)務(wù)領(lǐng)域皂甘，定義了表示玻驻、描述、集成 DoD 范圍內(nèi)眾多架構(gòu)的標準方法偿枕，確保架構(gòu)描述可比較璧瞬、評估，提供了對 FoS (系統(tǒng)族)和 SoS (體系)進行理解渐夸、比較嗤锉、集成和互操作共同的架構(gòu)基礎(chǔ)，提供開發(fā)和表達架構(gòu)描述的規(guī)則和指南,但不指導(dǎo)如何實現(xiàn)墓塌。

DODAF 核心是8個視點和52個模型瘟忱。

1.全景視點 AV

與所有視點相關(guān)的體系結(jié)構(gòu)描述的頂層概貌。提供有關(guān)體系結(jié)構(gòu)描述的總體信息苫幢，諸如體系結(jié)構(gòu)描述的范圍和背景访诱。范圍包括體系結(jié)構(gòu)描述的專業(yè)領(lǐng)域和時間框架。背景由構(gòu)成體系結(jié)構(gòu)描述背景的相互關(guān)聯(lián)各種條件組成韩肝，包括條令盐数，戰(zhàn)術(shù)、技術(shù)和程序伞梯，相關(guān)目標和構(gòu)想的描述玫氢，作戰(zhàn)概念(CONOPS)，想定和環(huán)境條件谜诫。

2.能力視點CV

能力視點(CV)集中反映了與整體愿景相關(guān)的組織目標漾峡，這些愿景指在特定標準和條件下進行特定行動過程或是達成期望效果的能力，它們綜合使用各種手段和方式來完成一組任務(wù)喻旷。

CV 為體系結(jié)構(gòu)描述中闡述的能力提供了戰(zhàn)略背景和相應(yīng)的高層范圍生逸，比作戰(zhàn)概念圖中定義的基于想定的范圍更全面丈莺。

這些模型是高層的榔昔，用決策者易于理解的術(shù)語來描述能力，以便溝通能力演進方面戰(zhàn)略構(gòu)想毫捣。

3.作戰(zhàn)視點OV

作戰(zhàn)視點(OV)集中反映了完成 DoD 使命的機構(gòu)锋谐、任務(wù)或執(zhí)行的行動以及彼此間必須交換的信息遍尺。描述信息交換的種類、頻度涮拗、性質(zhì)乾戏，信息交換支持哪些任務(wù)和活動。

4.服務(wù)視點 SvcV

服務(wù)視點(SvcV)集中反映了為作戰(zhàn)行動提供支撐的系統(tǒng)三热、服務(wù)和相互交織的功能鼓择。DoD 流程包括作戰(zhàn)、業(yè)務(wù)就漾、情報和基礎(chǔ)設(shè)施功能呐能。SvcV 功能和服務(wù)資源及要素可以鏈接到 0V 中的體系結(jié)構(gòu)數(shù)據(jù)。這些系統(tǒng)功能和服務(wù)資源支撐作戰(zhàn)行動抑堡，促進信息交換摆出。

5.系統(tǒng)視點 SV

系統(tǒng)視點(SV)集中反映支持作戰(zhàn)行動中的自動化系統(tǒng)、相互交聯(lián)和其他系統(tǒng)功能的信息夷野。隨著對面向服務(wù)環(huán)境和云計算的重視懊蒸，在 DoDAF 的未來版本中也許不會有系統(tǒng)視點。

6.數(shù)信視點 DIV

數(shù)據(jù)和信息視點(DIV)悯搔，簡稱數(shù)信視點骑丸，反映了體系結(jié)構(gòu)描述中的業(yè)務(wù)信息需求和結(jié)構(gòu)化的業(yè)務(wù)流程規(guī)則。

描述體系結(jié)構(gòu)描述中與信息交換相關(guān)的信息妒貌，諸如屬性通危、特征和相互關(guān)系。
必要時灌曙，本視點模型中用到的數(shù)據(jù)需要由多個架構(gòu)團隊來共同考慮菊碟。

7.標準視點 StdV

標準視點(StdV)是用來管控系統(tǒng)各組成部分或要素的編排、交互和相互依賴的規(guī)則的最小集在刺。其目的是確保系統(tǒng)能滿足特定的一組操作需求逆害。

標準視點提供技術(shù)系統(tǒng)的實施指南头镊，以工程規(guī)范為基礎(chǔ)，確立通用的積木塊魄幕，開發(fā)產(chǎn)品線相艇。

包括一系列技術(shù)標準、執(zhí)行慣例纯陨、標準選項坛芽、規(guī)則和規(guī)范，這些標準在特定體系結(jié)構(gòu)描述中可以組成管控系統(tǒng)和系統(tǒng)/服務(wù)要素的文件(profile)翼抠。

8.項目視點 PV

項目視點(PV)集中反映了項目是如何有機地組織成一個釆辦項目的有序組合咙轩。
描述多個采辦項目之間關(guān)聯(lián)關(guān)系，每個采辦項目都負責交付特定系統(tǒng)或能力阴颖。

image

TOGAF活喊，Zachman，ITSA 和 DODAF 是非常不錯的架構(gòu)框架膘盖，尤其前兩者應(yīng)用很廣泛胧弛，TOGAF 還有專門的架構(gòu)認證。當我們掌握了這些框架侠畔，我們是不是需要一些架構(gòu)原則來指導(dǎo)更具體的設(shè)計结缚？請看下文。

推薦一個Java高級技術(shù)進階群：976203838软棺，文章運用到的架構(gòu)技術(shù)都會在群里分享红竭，都能免費下載。有興趣學(xué)習(xí)的猿猿可以加一下喘落。

架構(gòu)原則

設(shè)計原則就是架構(gòu)設(shè)計的指導(dǎo)思想茵宪，它指導(dǎo)我們?nèi)绾螌?shù)據(jù)和函數(shù)組織成類，如何將類鏈接起來成為組件和程序瘦棋。反向來說稀火，架構(gòu)的主要工作就是將軟件拆解為組件，設(shè)計原則指導(dǎo)我們?nèi)绾尾鸾舛呐蟆⒉鸾獾牧６然四⒔M件間依賴的方向、組件解耦的方式等沛慢。

設(shè)計原則有很多赡若，我們進行架構(gòu)設(shè)計的主導(dǎo)原則是 OCP（開閉原則），在類和代碼的層級上有：SRP（單一職責原則）团甲、LSP（里氏替換原則）逾冬、ISP（接口隔離原則）、DIP（依賴反轉(zhuǎn)原則）；在組件的層級上有：REP（復(fù)用身腻、發(fā)布等同原則）产还、CCP（共同閉包原則）、CRP（共同復(fù)用原則）嘀趟，處理組件依賴問題的三原則：無依賴環(huán)原則雕沉、穩(wěn)定依賴原則、穩(wěn)定抽象原則去件。

1.OCP（開閉原則）：設(shè)計良好的軟件應(yīng)該易于擴展，同時抗拒修改扰路。這是我們進行架構(gòu)設(shè)計的主導(dǎo)原則尤溜，其他的原則都為這條原則服務(wù)。

2.SRP（單一職責原則）：任何一個軟件模塊汗唱，都應(yīng)該有且只有一個被修改的原因宫莱，“被修改的原因“指系統(tǒng)的用戶或所有者，翻譯一下就是哩罪，任何模塊只對一個用戶的價值負責授霸，該原則指導(dǎo)我們?nèi)绾尾鸱纸M件。

舉個例子际插，CTO 和 COO 都要統(tǒng)計員工的工時碘耳，當前他們要求的統(tǒng)計方式可能是相同的，我們復(fù)用一套代碼框弛，這時 COO 說周末的工時統(tǒng)計要乘以二辛辨，按照這個需求修改完代碼，CTO 可能就要過來罵街了瑟枫。當然這是個非常淺顯的例子斗搞，實際項目中也有很多代碼服務(wù)于多個價值主體，這帶來很大的探秘成本和修改風險慷妙，另外僻焚，當一份代碼有多個所有者時，就會產(chǎn)生代碼合并沖突的問題膝擂。

3.LSP（里氏替換原則）：當用同一接口的不同實現(xiàn)互相替換時虑啤，系統(tǒng)的行為應(yīng)該保持不變。該原則指導(dǎo)的是接口與其實現(xiàn)方式猿挚。

你一定很疑惑咐旧，實現(xiàn)了同一個接口，他們的行為也肯定是一致的呀绩蜻，還真不一定铣墨。假設(shè)認為矩形的系統(tǒng)行為是：面積=寬*高，讓正方形實現(xiàn)矩形的接口办绝，在調(diào)用 setW 和 setH 時伊约，正方形做的其實是同一個事情姚淆，設(shè)置它的邊長。這時下邊的單元測試用矩形能通過屡律，用正方形就不行腌逢，實現(xiàn)同樣的接口，但是系統(tǒng)行為變了超埋，這是違反 LSP 的經(jīng)典案例搏讶。

4.ISP（接口隔離原則）：不依賴任何不需要的方法、類或組件霍殴。該原則指導(dǎo)我們的接口設(shè)計媒惕。當我們依賴一個接口但只用到了其中的部分方法時，其實我們已經(jīng)依賴了不需要的方法或類来庭，當這些方法或類有變更時妒蔚，會引起我們類的重新編譯，或者引起我們組件的重新部署月弛，這些都是不必要的肴盏。所以我們最好定義個小接口，把用到的方法拆出來帽衙。

5.DIP（依賴反轉(zhuǎn)原則）：指一種特定的解耦（傳統(tǒng)的依賴關(guān)系創(chuàng)建在高層次上菜皂，而具體的策略設(shè)置則應(yīng)用在低層次的模塊上）形式，使得高層次的模塊不依賴于低層次的模塊的實現(xiàn)細節(jié)佛寿，依賴關(guān)系被顛倒（反轉(zhuǎn)）幌墓，從而使得低層次模塊依賴于高層次模塊的需求抽象。

跨越組建邊界的依賴方向永遠與控制流的方向相反冀泻。該原則指導(dǎo)我們設(shè)計組件間依賴的方向常侣。

依賴反轉(zhuǎn)原則是個可操作性非常強的原則，當你要修改組件間的依賴方向時弹渔，將需要進行組件間通信的類抽象為接口胳施，接口放在邊界的哪邊，依賴就指向哪邊肢专。

6.REP（復(fù)用舞肆、發(fā)布等同原則）：軟件復(fù)用的最小粒度應(yīng)等同于其發(fā)布的最小粒度。直白地說博杖，就是要復(fù)用一段代碼就把它抽成組件椿胯，該原則指導(dǎo)我們組件拆分的粒度。

7.CCP（共同閉包原則）：為了相同目的而同時修改的類剃根，應(yīng)該放在同一個組件中哩盲。CCP 原則是 SRP 原則在組件層面的描述。該原則指導(dǎo)我們組件拆分的粒度。

對大部分應(yīng)用程序而言廉油，可維護性的重要性遠遠大于可復(fù)用性惠险，由同一個原因引起的代碼修改，最好在同一個組件中抒线，如果分散在多個組件中班巩，那么開發(fā)、提交嘶炭、部署的成本都會上升抱慌。

8.CRP（共同復(fù)用原則）：不要強迫一個組件依賴它不需要的東西。CRP 原則是 ISP原則在組件層面的描述眨猎。該原則指導(dǎo)我們組件拆分的粒度遥缕。

相信你一定有這種經(jīng)歷，集成了組件 A宵呛，但組件 A 依賴了組件 B、C夕凝。即使組件 B宝穗、C 你完全用不到，也不得不集成進來码秉。這是因為你只用到了組件 A 的部分能力逮矛，組件 A 中額外的能力帶來了額外的依賴。如果遵循共同復(fù)用原則转砖，你需要把 A 拆分须鼎，只保留你要用的部分。

REP府蔗、CCP晋控、CRP 三個原則之間存在彼此競爭的關(guān)系，REP 和 CCP 是黏合性原則姓赤，它們會讓組件變得更大赡译，而 CRP 原則是排除性原則，它會讓組件變小不铆。遵守REP蝌焚、CCP 而忽略 CRP，就會依賴了太多沒有用到的組件和類誓斥，而這些組件或類的變動會導(dǎo)致你自己的組件進行太多不必要的發(fā)布只洒；遵守 REP、CRP 而忽略 CCP劳坑，因為組件拆分的太細了毕谴，一個需求變更可能要改 n 個組件，帶來的成本也是巨大的。

除了上述設(shè)計原則析珊，還有一些重要的指導(dǎo)原則如下：

1.N+1設(shè)計：系統(tǒng)中的每個組件都應(yīng)做到?jīng)]有單點故障羡鸥；

2.回滾設(shè)計：確保系統(tǒng)可以向前兼容，在系統(tǒng)升級時應(yīng)能有辦法回滾版本忠寻；

3.禁用設(shè)計：應(yīng)該提供控制具體功能是否可用的配置惧浴，在系統(tǒng)出現(xiàn)故障時能夠快速下線功能；

4.監(jiān)控設(shè)計：在設(shè)計階段就要考慮監(jiān)控的手段奕剃，便于有效的排查問題衷旅，比如引入traceId、業(yè)務(wù)身份 Id 便于排查監(jiān)控問題纵朋；

5.多活數(shù)據(jù)中心設(shè)計：若系統(tǒng)需要極高的高可用柿顶，應(yīng)考慮在多地實施數(shù)據(jù)中心進行多活，至少在一個機房斷電的情況下系統(tǒng)依然可用操软；

6.采用成熟的技術(shù)：剛開發(fā)的或開源的技術(shù)往往存在很多隱藏的 bug嘁锯，出了問題沒有很好的商業(yè)支持可能會是一個災(zāi)難；

7.資源隔離設(shè)計：應(yīng)避免單一業(yè)務(wù)占用全部資源聂薪；

8.架構(gòu)水平擴展設(shè)計：系統(tǒng)只有做到能水平擴展家乘，才能有效避免瓶頸問題；

9.非核心則購買的原則：非核心功能若需要占用大量的研發(fā)資源才能解決藏澳，則考慮購買成熟的產(chǎn)品仁锯；

10.使用商用硬件：商用硬件能有效降低硬件故障的機率；

11.快速迭代：系統(tǒng)應(yīng)該快速開發(fā)小功能模塊翔悠，盡快上線進行驗證业崖，早日發(fā)現(xiàn)問題大大降低系統(tǒng)交付的風險；

12.無狀態(tài)設(shè)計：服務(wù)接口應(yīng)該做成無狀態(tài)的蓄愁，當前接口的訪問不依賴于接口上次訪問的狀態(tài)双炕。

架構(gòu)師知道了職責，具備很好的架構(gòu)思維撮抓，掌握了通用的架構(gòu)框架和方法論雄家，使用架構(gòu)原則進行架構(gòu)設(shè)計，不同的業(yè)務(wù)和系統(tǒng)要求不一樣胀滚，那么有沒有針對不同場景的系統(tǒng)架構(gòu)設(shè)計趟济？下文就針對分布式架構(gòu)演進、單元化架構(gòu)咽笼、面向服務(wù) SOA 架構(gòu)顷编、微服務(wù)架構(gòu)、Serverless 架構(gòu)進行介紹剑刑，以便于我們在實際運用中進行參考使用媳纬。

常見架構(gòu)

分布式架構(gòu)演進

初始階段架構(gòu)

特征：應(yīng)用程序双肤，數(shù)據(jù)庫，文件等所有資源都放在一臺服務(wù)器上钮惠。

應(yīng)用服務(wù)和數(shù)據(jù)服務(wù)以及文件服務(wù)分離

說明：好景不長茅糜，發(fā)現(xiàn)隨著系統(tǒng)訪問量的再度增加，webserver 機器的壓力在高峰期會上升到比較高素挽，這個時候開始考慮增加一臺 webserver蔑赘。

特征：應(yīng)用程序、數(shù)據(jù)庫预明、文件分別部署在獨立的資源上缩赛。

使用緩存改善性能

說明：系統(tǒng)訪問特點遵循二八定律，即80%的業(yè)務(wù)訪問集中在20%的數(shù)據(jù)上撰糠。緩存分為本地緩存 遠程分布式緩存酥馍，本地緩存訪問速度更快但緩存數(shù)據(jù)量有限，同時存在與應(yīng)用程序爭用內(nèi)存的情況阅酪。

特征：數(shù)據(jù)庫中訪問較集中的一小部分數(shù)據(jù)存儲在緩存服務(wù)器中旨袒，減少數(shù)據(jù)庫的訪問次數(shù)，降低數(shù)據(jù)庫的訪問壓力术辐。

使用“應(yīng)用服務(wù)器”集群

說明：在做完分庫分表這些工作后峦失，數(shù)據(jù)庫上的壓力已經(jīng)降到比較低了，又開始過著每天看著訪問量暴增的幸福生活了术吗。突然有一天，發(fā)現(xiàn)系統(tǒng)的訪問又開始有變慢的趨勢了帆精，這個時候首先查看數(shù)據(jù)庫较屿，壓力一切正常，之后查看 webserver卓练，發(fā)現(xiàn)apache 阻塞了很多的請求隘蝎， 而應(yīng)用服務(wù)器對每個請求也是比較快的，看來是請求數(shù)太高導(dǎo)致需要排隊等待襟企，響應(yīng)速度變慢嘱么。

特征：多臺服務(wù)器通過負載均衡同時向外部提供服務(wù)，解決單臺服務(wù)器處理能力和存儲空間上限的問題顽悼。

描述：使用集群是系統(tǒng)解決高并發(fā)曼振、海量數(shù)據(jù)問題的常用手段。通過向集群中追加資源蔚龙，提升系統(tǒng)的并發(fā)處理能力冰评，使得服務(wù)器的負載壓力不再成為整個系統(tǒng)的瓶頸。

數(shù)據(jù)庫讀寫分離

說明：享受了一段時間的系統(tǒng)訪問量高速增長的幸福后木羹，發(fā)現(xiàn)系統(tǒng)又開始變慢了甲雅，這次又是什么狀況呢解孙，經(jīng)過查找，發(fā)現(xiàn)數(shù)據(jù)庫寫入抛人、更新的這些操作的部分數(shù)據(jù)庫連接的資源競爭非常激烈弛姜，導(dǎo)致了系統(tǒng)變慢。

特征：數(shù)據(jù)庫引入主備部署妖枚。

描述：把數(shù)據(jù)庫劃分為讀庫和寫庫廷臼，通過引入主從數(shù)據(jù)庫服務(wù)，讀和寫操作在不同的數(shù)據(jù)庫服務(wù)處理盅惜，讀庫可以有多個中剩，通過同步機制把寫庫的數(shù)據(jù)同步到讀庫，對于需要查詢最新寫入數(shù)據(jù)場景抒寂，可以通過在緩存中多寫一份结啼，通過緩存獲得最新數(shù)據(jù)。

反向代理和CDN加速

特征：采用CDN和反向代理加快系統(tǒng)的訪問速度屈芜。

描述：為了應(yīng)付復(fù)雜的網(wǎng)絡(luò)環(huán)境和不同地區(qū)用戶的訪問郊愧，通過 CDN 和反向代理加快用戶訪問的速度，同時減輕后端服務(wù)器的負載壓力井佑。CDN 與反向代理的基本原理都是緩存属铁。

“分布式文件”系統(tǒng) 和 “分布式數(shù)據(jù)庫”

說明：隨著系統(tǒng)的不斷運行，數(shù)據(jù)量開始大幅度增長躬翁，這個時候發(fā)現(xiàn)分庫后查詢?nèi)匀粫行┞鼓ⅲ谑前凑辗謳斓乃枷腴_始做分表的工作

特征：數(shù)據(jù)庫采用分布式數(shù)據(jù)庫，文件系統(tǒng)采用分布式文件系統(tǒng)盒发。

描述：任何強大的單一服務(wù)器都滿足不了大型系統(tǒng)持續(xù)增長的業(yè)務(wù)需求例嘱，數(shù)據(jù)庫讀寫分離隨著業(yè)務(wù)的發(fā)展最終也將無法滿足需求，需要使用分布式數(shù)據(jù)庫及分布式文件系統(tǒng)來支撐宁舰。

分布式數(shù)據(jù)庫是系統(tǒng)數(shù)據(jù)庫拆分的最后方法拼卵，只有在單表數(shù)據(jù)規(guī)模非常龐大的時候才使用，更常用的數(shù)據(jù)庫拆分手段是業(yè)務(wù)分庫蛮艰，將不同的業(yè)務(wù)數(shù)據(jù)庫部署在不同的物理服務(wù)器上腋腮。

使用 NoSQL 和搜索引擎

特征：系統(tǒng)引入 NoSQL 數(shù)據(jù)庫及搜索引擎。

描述：隨著業(yè)務(wù)越來越復(fù)雜壤蚜，對數(shù)據(jù)存儲和檢索的需求也越來越復(fù)雜即寡，系統(tǒng)需要采用一些非關(guān)系型數(shù)據(jù)庫如 NoSQL 和分數(shù)據(jù)庫查詢技術(shù)如搜索引擎。

應(yīng)用服務(wù)器通過統(tǒng)一數(shù)據(jù)訪問模塊訪問各種數(shù)據(jù)袜刷，減輕應(yīng)用程序管理諸多數(shù)據(jù)源的麻煩嘿悬。

業(yè)務(wù)拆分

特征：系統(tǒng)上按照業(yè)務(wù)進行拆分改造，應(yīng)用服務(wù)器按照業(yè)務(wù)區(qū)分進行分別部署水泉。

描述：為了應(yīng)對日益復(fù)雜的業(yè)務(wù)場景善涨，通常使用分而治之的手段將整個系統(tǒng)業(yè)務(wù)分成不同的產(chǎn)品線窒盐，應(yīng)用之間通過超鏈接建立關(guān)系，也可以通過消息隊列進行數(shù)據(jù)分發(fā)钢拧，當然更多的還是通過訪問同一個數(shù)據(jù)存儲系統(tǒng)來構(gòu)成一個關(guān)聯(lián)的完整系統(tǒng)蟹漓。

縱向拆分：將一個大應(yīng)用拆分為多個小應(yīng)用，如果新業(yè)務(wù)較為獨立源内，那么就直接將其設(shè)計部署為一個獨立的 Web 應(yīng)用系統(tǒng)縱向拆分相對較為簡單葡粒，通過梳理業(yè)務(wù)，將較少相關(guān)的業(yè)務(wù)剝離即可膜钓。

橫向拆分：將復(fù)用的業(yè)務(wù)拆分出來嗽交，獨立部署為分布式服務(wù)，新增業(yè)務(wù)只需要調(diào)用這些分布式服務(wù)橫向拆分需要識別可復(fù)用的業(yè)務(wù)颂斜，設(shè)計服務(wù)接口夫壁，規(guī)范服務(wù)依賴關(guān)系。

分布式服務(wù)

特征：公共的應(yīng)用模塊被提取出來沃疮，部署在分布式服務(wù)器上供應(yīng)用服務(wù)器調(diào)用盒让。

描述：隨著業(yè)務(wù)越拆越小，應(yīng)用系統(tǒng)整體復(fù)雜程度呈指數(shù)級上升司蔬，由于所有應(yīng)用要和所有數(shù)據(jù)庫系統(tǒng)連接邑茄，最終導(dǎo)致數(shù)據(jù)庫連接資源不足，拒絕服務(wù)俊啼。

分布式服務(wù)的問題和挑戰(zhàn)：

(1) 當服務(wù)越來越多時肺缕，服務(wù)URL配置管理變得非常困難，F(xiàn)5硬件負載均衡器的單點壓力也越來越大授帕。

(2) 當進一步發(fā)展同木，服務(wù)間依賴關(guān)系變得錯蹤復(fù)雜，甚至分不清哪個應(yīng)用要在哪個應(yīng)用之前啟動豪墅，架構(gòu)師都不能完整的描述應(yīng)用的架構(gòu)關(guān)系。

(3) 服務(wù)的調(diào)用量越來越大黔寇，服務(wù)的容量問題就暴露出來偶器，這個服務(wù)需要多少機器支撐？什么時候該加機器缝裤？

(4) 服務(wù)多了屏轰，溝通成本也開始上升，調(diào)某個服務(wù)失敗該找誰憋飞？服務(wù)的參數(shù)都有什么約定霎苗？

(5) 一個服務(wù)有多個業(yè)務(wù)消費者，如何確保服務(wù)質(zhì)量榛做？

(6) 隨著服務(wù)的不停升級唁盏，總有些意想不到的事發(fā)生内狸，比如 cache 寫錯了導(dǎo)致內(nèi)存溢出，故障不可避免厘擂，每次核心服務(wù)一掛昆淡，影響一大片，人心慌慌刽严，如何控制故障的影響面昂灵？服務(wù)是否可以功能降級？或者資源劣化舞萄？

針對這些問題眨补，下述的單元化架構(gòu)，微服務(wù)架構(gòu)以及 Serveless 架構(gòu)可以一定程度解決倒脓，另外針對業(yè)務(wù)系統(tǒng)撑螺，需要做到業(yè)務(wù)與業(yè)務(wù)隔離、管理域和運行域分開把还、業(yè)務(wù)與平臺隔離方可解決上述問題实蓬。

單元化架構(gòu)

1、什么是單元化：單元化架構(gòu)是從并行計算領(lǐng)域發(fā)展而來吊履。在分布式服務(wù)設(shè)計領(lǐng)域当叭，一個單元（Cell）就是滿足某個分區(qū)所有業(yè)務(wù)操作的自包含的安裝感局。而一個分區(qū)（Shard），則是整體數(shù)據(jù)集的一個子集，如果你用尾號來劃分用戶焙格，那同樣尾號的那部分用戶就可以認為是一個分區(qū)。單元化就是將一個服務(wù)設(shè)計改造讓其符合單元特征的過程井氢。

2腾务、單元化的必要性：隨著硬件的不斷升級，計算機硬件能力已經(jīng)越來越強驴娃，CPU越來越快奏候，內(nèi)存越來越大，網(wǎng)絡(luò)越來越寬唇敞。這讓我們看到了在單臺機器上垂直擴展的機會蔗草。尤其是當你遇到一個性能要求和容量增長可以預(yù)期的業(yè)務(wù)，單元化給我們提供另外的機會疆柔，讓我們可以有效降低資源的使用咒精，提供更高性能的服務(wù)。

更高性能更低成本是我們的主要目標旷档，經(jīng)過單元化改造模叙，我們得以用更少（約二分之一）的機器，獲得了比原來更高（接近百倍）的性能鞋屈。性能的提升很大部分原因在于服務(wù)的本地化范咨，而服務(wù)的集成部署又進一步降低了資源的使用故觅。除了性能收益，還有很多收益湖蜕，比如更好的隔離性逻卖，包括請求隔離和資源隔離，比如更友好的升級昭抒，產(chǎn)品可以灰度發(fā)布等评也。單元化改造后對高峰的應(yīng)對以及擴容方式等問題的解決。

3灭返、如何做到單元化：先看下圖傳統(tǒng)的服務(wù)架構(gòu)盗迟，服務(wù)是分層的，每一層使用不同的分區(qū)算法熙含，每一層都有不同數(shù)量的節(jié)點罚缕，上層節(jié)點隨機選擇下層節(jié)點。

在單元化架構(gòu)下怎静，服務(wù)雖然分層劃分邮弹，但每個單元自成一體。按照層次來講的話蚓聘，所有層使用相同的分區(qū)算法腌乡，每一層都有相同數(shù)量的節(jié)點，上層節(jié)點也會訪問指定的下層節(jié)點夜牡。

SOA架構(gòu)

SOA（Service-Oriented Architecture与纽，面向服務(wù)的架構(gòu)）是一個組件模型，它將應(yīng)用程序的不同功能單元（稱為服務(wù)）通過這些服務(wù)之間定義良好的接口和契約聯(lián)系起來塘装。接口是采用中立的方式進行定義的急迂，它應(yīng)該獨立于實現(xiàn)服務(wù)的硬件平臺、操作系統(tǒng)和編程語言蹦肴。這使得構(gòu)建在各種各樣的系統(tǒng)中的服務(wù)可以以一種統(tǒng)一和通用的方式進行交互僚碎。面向服務(wù)架構(gòu)，它可以根據(jù)需求通過網(wǎng)絡(luò)對松散耦合的粗粒度應(yīng)用組件進行分布式部署阴幌、組合和使用勺阐。服務(wù)層是 SOA 的基礎(chǔ)，可以直接被應(yīng)用調(diào)用裂七，從而有效控制系統(tǒng)中與軟件代理交互的人為依賴性皆看。

SOA的實施具有幾個鮮明的基本特征仓坞。實施 SOA 的關(guān)鍵目標是實現(xiàn)企業(yè) IT 資產(chǎn)的最大化作用背零。要實現(xiàn)這一目標，就要在實施 SOA 的過程中牢記以下特征：

（1）可從企業(yè)外部訪問
（2）隨時可用
（3）粗粒度的服務(wù)接口分級
（4）松散耦合
（5）可重用的服務(wù)
（6）服務(wù)接口設(shè)計管理
（7）標準化的服務(wù)接口
（8）支持各種消息模式
（9）精確定義的服務(wù)契約

為了實現(xiàn) SOA无埃，企業(yè)需要一個服務(wù)架構(gòu)徙瓶，下圖顯示了一個例子：

在上圖中毛雇， 服務(wù)消費者（service consumer）可以通過發(fā)送消息來調(diào)用服務(wù)。這些消息由一個服務(wù)總線（service bus）轉(zhuǎn)換后發(fā)送給適當?shù)姆?wù)實現(xiàn)侦镇。這種服務(wù)架構(gòu)可以提供一個業(yè)務(wù)規(guī)則引（business rules engine）灵疮，該引擎容許業(yè)務(wù)規(guī)則被合并在一個服務(wù)里或多個服務(wù)里。這種架構(gòu)也提供了一個服務(wù)管理基礎(chǔ)（service management infrastructure）壳繁，用來管理服務(wù)震捣，類似審核，列表（billing）闹炉，日志等功能蒿赢。此外，該架構(gòu)給企業(yè)提供了靈活的業(yè)務(wù)流程渣触，更好地處理控制請求（regulatory requirement）羡棵，例如Sarbanes Oxley（SOX），并且可以在不影響其他服務(wù)的情況下更改某項服務(wù)嗅钻。

推薦一個Java高級技術(shù)進階群：976203838皂冰，文章運用到的架構(gòu)技術(shù)都會在群里分享，都能免費下載养篓。有興趣學(xué)習(xí)的猿猿可以加一下秃流。

微服務(wù)架構(gòu)

先來看看傳統(tǒng)的 web 開發(fā)方式，通過對比比較容易理解什么是 Microservice Architecture觉至。和 Microservice 相對應(yīng)的剔应，這種方式一般被稱為 Monolithic（單體式開發(fā)）。

所有的功能打包在一個 WAR包里语御，基本沒有外部依賴（除了容器）峻贮，部署在一個JEE容器（Tomcat，JBoss应闯，WebLogic）里纤控，包含了 DO/DAO，Service碉纺，UI 等所有邏輯船万。

優(yōu)點：

• 開發(fā)簡單，集中式管理骨田；
• 基本不會重復(fù)開發(fā)耿导；
• 功能都在本地，沒有分布式的管理和調(diào)用消耗态贤。

缺點：

• 效率低：開發(fā)都在同一個項目改代碼舱呻，相互等待，沖突不斷；
• 維護難：代碼功功能耦合在一起箱吕，新人不知道何從下手芥驳；
• 不靈活：構(gòu)建時間長，任何小修改都要重構(gòu)整個項目茬高，耗時兆旬；
• 穩(wěn)定性差：一個微小的問題，都可能導(dǎo)致整個應(yīng)用掛掉怎栽；
• 擴展性不夠：無法滿足高并發(fā)下的業(yè)務(wù)需求丽猬。

常見的系統(tǒng)架構(gòu)遵循的三個標準和業(yè)務(wù)驅(qū)動力：

• 提高敏捷性：及時響應(yīng)業(yè)務(wù)需求，促進企業(yè)發(fā)展熏瞄；
• 提升用戶體驗：提升用戶體驗宝鼓，減少用戶流失；
• 降低成本：降低增加產(chǎn)品巴刻、客戶或業(yè)務(wù)方案的成本愚铡。

基于微服務(wù)架構(gòu)的設(shè)計：

目的：有效的拆分應(yīng)用，實現(xiàn)敏捷開發(fā)和部署胡陪。

關(guān)于微服務(wù)的一個形象表達：

• X軸：運行多個負載均衡器之后的運行實例沥寥；
• Y軸：將應(yīng)用進一步分解為微服務(wù)（分庫）；
• Z軸：大數(shù)據(jù)量時柠座，將服務(wù)分區(qū)（分表）邑雅。

SOA和微服務(wù)的區(qū)別：

• SOA喜歡重用，微服務(wù)喜歡重寫妈经；
• SOA喜歡水平服務(wù)淮野，微服務(wù)喜歡垂直服務(wù)；
• SOA喜歡自上而下吹泡，微服務(wù)喜歡自下而上骤星。

Serverless 架構(gòu)

1、思想：無服務(wù)器是一種架構(gòu)理念爆哑，其核心思想是將提供服務(wù)資源的基礎(chǔ)設(shè)施抽象成各種服務(wù)洞难，以 API 接口的方式供給用戶按需調(diào)用，真正做到按需伸縮揭朝、按使用收費队贱。

2、優(yōu)勢：消除了對傳統(tǒng)的海量持續(xù)在線服務(wù)器組件的需求潭袱，降低了開發(fā)和運維的復(fù)雜性柱嫌，降低運營成本并縮短了業(yè)務(wù)系統(tǒng)的交付周期，使得用戶能夠?qū)Ｗ⒃趦r值密度更高的業(yè)務(wù)邏輯的開發(fā)上屯换。

3编丘、內(nèi)容：目前業(yè)界較為公認的無服務(wù)器架構(gòu)主要包括兩個方面，即提供計算資源的函數(shù)服務(wù)平臺 FaaS，以及提供托管云服務(wù)的后端服務(wù) BaaS瘪吏。

函數(shù)即服務(wù)（Function as a Service）：是一項基于事件驅(qū)動的函數(shù)托管計算服務(wù)。通過函數(shù)服務(wù)蜗巧，開發(fā)者只需要編寫業(yè)務(wù)函數(shù)代碼并設(shè)置運行的條件掌眠，無需配置和管理服務(wù)器等基礎(chǔ)設(shè)施，函數(shù)代碼運行在無狀態(tài)的容器中幕屹，由事件觸發(fā)且短暫易失蓝丙，并完全由第三方管理，基礎(chǔ)設(shè)施對應(yīng)用開發(fā)者完全透明望拖。函數(shù)以彈性渺尘、高可靠的方式運行，并且按實際執(zhí)行資源計費说敏，不執(zhí)行不產(chǎn)生費用鸥跟。

后端即服務(wù)（Backend as a Service）：BaaS 覆蓋了應(yīng)用可能依賴的所有第三方服務(wù)，如云數(shù)據(jù)庫盔沫、身份驗證医咨、對象存儲等服務(wù)，開發(fā)人員通過 API 和由 BaaS 服務(wù)商提供的 SDK架诞，能夠集成所需的所有后端功能拟淮，而無需構(gòu)建后端應(yīng)用，更不必管理虛擬機或容器等基礎(chǔ)設(shè)施谴忧，就能保證應(yīng)用的正常運行很泊。

三個less感覺很好：

• Codeless 對應(yīng)的是服務(wù)開發(fā)，實現(xiàn)了源代碼托管沾谓，你只需要關(guān)注你的代碼實現(xiàn)委造，而不需要關(guān)心你的代碼在哪，因為在整個開發(fā)過程中你都不會感受到代碼庫和代碼分支的存在均驶。
• Applicationless 對應(yīng)的是服務(wù)發(fā)布争涌，在服務(wù)化框架下，你的服務(wù)發(fā)布不再需要申請應(yīng)用辣恋，也不需要關(guān)注你的應(yīng)用在哪亮垫。
• Serverless 對應(yīng)的則是服務(wù)運維，有了 Serverless 化能力伟骨，你不再需要關(guān)注你的機器資源饮潦，Servlerless 會幫你搞定機器資源的彈性擴縮容。

架構(gòu)師在完成上述架構(gòu)設(shè)計后携狭，最終是需要協(xié)同利益相關(guān)方一起按項目化運作落地拿結(jié)果继蜡，那么應(yīng)該如何保證利益相關(guān)方在項目落地的滿意度，如何保證按照架構(gòu)很好的拿到項目成功的結(jié)果呢？架構(gòu)管理能力是架構(gòu)師非常重要的能力稀并。

架構(gòu)管理

架構(gòu)共贏模型

架構(gòu)結(jié)果管理

參考資料：

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

聲明：本文部分內(nèi)容參考阿里內(nèi)部和外部一些文章仅颇，詳情見上述參考資料；撰寫本文的重點是系統(tǒng)體系化地總結(jié)認識架構(gòu)師的工作碘举，以便于更好的互動學(xué)習(xí)和成長忘瓦，部分觀點是個人觀點。

推薦一個Java高級技術(shù)進階群：976203838引颈，文章運用到的架構(gòu)技術(shù)都會在群里分享耕皮，都能免費下載。有興趣學(xué)習(xí)的猿猿可以加一下蝙场。

免費領(lǐng)取傳送門：https://shimo.im/docs/BYMjlkYOqM08diLI

本文作者： 九摩
原文：如何帶領(lǐng)團隊“攻城略地”凌停？優(yōu)秀的架構(gòu)師這樣做