架構(gòu)師是一個(gè)既能掌控整體又能洞悉局部瓶頸并依據(jù)具體的業(yè)務(wù)場(chǎng)景給出解決方案的團(tuán)隊(duì)領(lǐng)導(dǎo)型人物上遥。看似完美的“人格模型”背后争涌，是艱辛的探索粉楚。今天，阿里巴巴技術(shù)專家九摩將多年經(jīng)驗(yàn)亮垫，進(jìn)行系統(tǒng)性地總結(jié)模软，幫助更多架構(gòu)師在進(jìn)階這條路上走得更“順暢”，姿態(tài)更“優(yōu)雅”饮潦。
架構(gòu)師職責(zé)
架構(gòu)師不是一個(gè)人燃异，他需要建立高效卓越的體系，帶領(lǐng)團(tuán)隊(duì)去攻城略地继蜡，在規(guī)定的時(shí)間內(nèi)完成項(xiàng)目回俐。
架構(gòu)師需要能夠識(shí)別定義并確認(rèn)需求逛腿，能夠進(jìn)行系統(tǒng)分解形成整體架構(gòu)，能夠正確地技術(shù)選型仅颇，能夠制定技術(shù)規(guī)格說明并有效推動(dòng)實(shí)施落地忘瓦。
按 TOGAF 的定義，架構(gòu)師的職責(zé)是了解并關(guān)注實(shí)際上關(guān)系重大但未變得過載的一些關(guān)鍵細(xì)節(jié)和界面耕皮，架構(gòu)師的角色有：理解并解析需求明场，創(chuàng)建有用的模型汽摹，確認(rèn)逼泣、細(xì)化并擴(kuò)展模型拉庶，管理架構(gòu)秃励。
從業(yè)界來看對(duì)于架構(gòu)師的理解可以大概區(qū)分為：
企業(yè)架構(gòu)師：專注于企業(yè)總體 IT 架構(gòu)的設(shè)計(jì)皆尔。
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è)施闹击，某種軟硬件體系镶蹋，甚至云平臺(tái)，提交：產(chǎn)品建議拂酣、產(chǎn)品選型仲义、部署架構(gòu)埃撵、網(wǎng)絡(luò)方案饺谬，甚至數(shù)據(jù)中心建設(shè)方案等募寨。
阿里內(nèi)部沒有在職位 title 上專門設(shè)置架構(gòu)師，架構(gòu)師更多是以角色而存在格郁，現(xiàn)在還留下可見的 title 有兩個(gè)：首席架構(gòu)師和解決方案架構(gòu)師，其中解決方案架構(gòu)師目前在大部分 BU 都有設(shè)置决采，特別是在阿里云和電商體系拇厢。
解決方案架構(gòu)師
工作方式理解：
了解和挖掘客戶痛點(diǎn)孝偎，項(xiàng)目定義，現(xiàn)有環(huán)境管理势决；
梳理明確高階需求和非功能性需求；
客戶有什么資產(chǎn)据悔，星環(huán)（阿里電商操作系統(tǒng)）／阿里云等有什么解決方案；
溝通菠隆，方案建議，多次迭代破衔，交付總體架構(gòu)；
架構(gòu)決策读第。
職責(zé)：
1、從客戶視圖來看
堅(jiān)定客戶高層信心：利用架構(gòu)和解決方案能力吴汪，幫忙客戶選擇星環(huán)／阿里云平臺(tái)的信心杆融；
解決客戶中層問題：利用星環(huán)／阿里云平臺(tái)服務(wù)+結(jié)合應(yīng)用架構(gòu)設(shè)計(jì)/解決方案能力臀晃，幫忙客戶解決業(yè)務(wù)問題徽惋，獲得業(yè)務(wù)價(jià)值踢京；
引領(lǐng)客戶 IT 員工和阿里生態(tài)同學(xué)：技術(shù)引領(lǐng)、方法引領(lǐng)蹈丸、產(chǎn)品引領(lǐng)。
2荸百、從項(xiàng)目視圖看
對(duì)接管理部門：匯報(bào)技術(shù)方案，進(jìn)度更鲁；技術(shù)溝通；
對(duì)接客戶 PM媒至，項(xiàng)目 PM：協(xié)助項(xiàng)目計(jì)劃驯绎，人員管理等。負(fù)責(zé)所有技術(shù)交付物的指導(dǎo)拴孤；
對(duì)接業(yè)務(wù)部門和需求人員：了解和挖掘痛點(diǎn)，幫忙梳理高級(jí)業(yè)務(wù)需求，指導(dǎo)需求工藝化漆；
對(duì)接開發(fā)：產(chǎn)品支持、技術(shù)指導(dǎo)疙教、架構(gòu)指導(dǎo)；
對(duì)接測(cè)試：配合測(cè)試計(jì)劃和工藝制定。配合性能測(cè)試或者非功能性測(cè)試理疙；
對(duì)接運(yùn)維：產(chǎn)品支持，運(yùn)維支持赃梧；
對(duì)接配置&環(huán)境：產(chǎn)品支持物咳；
其他：阿里技術(shù)資源聚合。
3、從阿里內(nèi)部看
銷售方案支持晴弃；
市場(chǎng)宣貫际邻；
客戶需求Facade缨恒；
解決方案沉淀。
架構(gòu)師職責(zé)明確了萧锉，那么有什么架構(gòu)思維可以指導(dǎo)架構(gòu)設(shè)計(jì)呢？請(qǐng)看下述的架構(gòu)思維。
架構(gòu)思維1波附、自頂向下構(gòu)建架構(gòu)
要點(diǎn)主要如下：
1）首先定義問題财饥，而定義問題中最重要的是定義客戶的問題。定義問題谦炒，特別是識(shí)別出關(guān)鍵問題，關(guān)鍵問題是對(duì)客戶有體感裸删，能夠解決客戶痛點(diǎn)诺凡，通過一定的數(shù)據(jù)化來衡量識(shí)別出來鞋邑，關(guān)鍵問題要優(yōu)先給出解決方案逾一。
2）問題定義務(wù)必加入時(shí)間維度，把手段/方案和問題定義區(qū)分開來鄙早。
3）問題定義中，需要對(duì)問題進(jìn)行升層思考后再進(jìn)行升維思考扩灯，從而真正抓到問題的本質(zhì)，理清和挖掘清楚需求捻撑；要善用第一性原理思維進(jìn)行分析思考問題。
4）問題解決原則：先解決客戶的問題（使命），然后才能解決自己的問題（愿景）；務(wù)必記住不是強(qiáng)調(diào)我們?cè)趺礃咏奥荩俏覀兡転榭蛻艟唧w解決什么問題吸奴，然后才是我們變成什么考润，從而怎么樣去更好得服務(wù)客戶。
5）善用多種方法對(duì)客戶問題進(jìn)行分析，轉(zhuǎn)換成我們產(chǎn)品或者平臺(tái)需要提供的能力粥脚，比如倉儲(chǔ)系統(tǒng) WMS 可以提供哪些商業(yè)能力。
6）對(duì)我們的現(xiàn)有的流程和能力模型進(jìn)行梳理纤怒，找到需要提升的地方泊窘，升層思考和升維思考真正明確提升部分。
7）定義指標(biāo)像寒，并能夠?qū)χ笜?biāo)進(jìn)行拆解州既，然后進(jìn)行數(shù)學(xué)建模萝映。
8）將抽象出來的能力訴求轉(zhuǎn)換成技術(shù)挑戰(zhàn)吴叶，此步對(duì)于技術(shù)人員來說相當(dāng)于找到了靶子，可以進(jìn)行方案的設(shè)計(jì)了序臂，需要結(jié)合自底向上的架構(gòu)推導(dǎo)方式蚌卤。
9）創(chuàng)新可以是業(yè)務(wù)創(chuàng)新，也可以是產(chǎn)品創(chuàng)新奥秆，也可以是技術(shù)創(chuàng)新逊彭，也可以是運(yùn)營創(chuàng)新，升層思考构订、升維思考侮叮，使用第一性原理思維、生物學(xué)（進(jìn)化論--進(jìn)化=變異+選擇+隔離悼瘾、熵增定律囊榜、分形和涌現(xiàn)）思維等哲科思維可以幫助我們?cè)跇I(yè)務(wù)，產(chǎn)品亥宿，技術(shù)上發(fā)現(xiàn)不同的創(chuàng)新可能卸勺。可以說哲科思維是架構(gòu)師的靈魂思維烫扼。
2曙求、自底向上推導(dǎo)應(yīng)用架構(gòu)
先根據(jù)業(yè)務(wù)流程，分解出系統(tǒng)時(shí)序圖映企，根據(jù)時(shí)序圖開始對(duì)模塊進(jìn)行歸納悟狱，從而得到粒度更大的模塊，模塊的組合／聚合構(gòu)建整個(gè)系統(tǒng)架構(gòu)堰氓。
基本上應(yīng)用邏輯架構(gòu)的推導(dǎo)有4個(gè)子路徑挤渐，他們分別是：
業(yè)務(wù)概念架構(gòu)：業(yè)務(wù)概念架構(gòu)來自于業(yè)務(wù)概念模型和業(yè)務(wù)流程；
系統(tǒng)模型：來自于業(yè)務(wù)概念模型豆赏；
系統(tǒng)流程：來自業(yè)務(wù)流程挣菲；
非功能性的系統(tǒng)支撐：來自對(duì)性能富稻、穩(wěn)定性、成本的需要白胀。
效率椭赋、穩(wěn)定性、性能是最影響邏輯架構(gòu)落地成物理架構(gòu)的三大主要因素或杠，所以從邏輯架構(gòu)到物理架構(gòu)哪怔，一定需要先對(duì)效率、穩(wěn)定性和性能做出明確的量化要求向抢。
自底向上重度依賴于演繹和歸納认境。
如果是產(chǎn)品方案已經(jīng)明確，程序員需要理解這個(gè)業(yè)務(wù)需求挟鸠，并根據(jù)產(chǎn)品方案推導(dǎo)出架構(gòu)叉信，此時(shí)一般使用自底向上的方法，而領(lǐng)域建模就是這種自底向上的分析方法艘希。
對(duì)于自底向上的分析方法硼身，如果提煉一下關(guān)鍵詞，會(huì)得到如下兩個(gè)關(guān)鍵詞：
1）演繹：演繹就是邏輯推導(dǎo)覆享，越是底層的佳遂，越需要演繹：
從用例到業(yè)務(wù)模型就屬于演繹；
從業(yè)務(wù)模型到系統(tǒng)模型也屬于演繹撒顿；
根據(jù)目前的問題丑罪，推導(dǎo)出要實(shí)施某種穩(wěn)定性措施，這是也是演繹凤壁。
2）歸納：這里的歸納是根據(jù)事物的某個(gè)維度來進(jìn)行歸類吩屹，越是高層的，越需要?dú)w納：
問題空間模塊劃分屬于歸納客扎；
邏輯架構(gòu)中有部分也屬于歸納祟峦；
根據(jù)一堆穩(wěn)定性問題罚斗，歸納出徙鱼，事前，事中针姿，事后都需要做對(duì)應(yīng)的操作袱吆，是就是根據(jù)時(shí)間維度來進(jìn)行歸納。
3距淫、領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)架構(gòu)
大部分傳統(tǒng)架構(gòu)都是基于領(lǐng)域模型分析架構(gòu)绞绒，典型的領(lǐng)域?qū)崿F(xiàn)模型設(shè)計(jì)可以參考DDD（領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)），詳細(xì)可以參考《實(shí)現(xiàn)領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》這本書榕暇，另外《UML和模式應(yīng)用》在領(lǐng)域建模實(shí)操方面比較好蓬衡，前者偏理論了解喻杈，后者便于落地實(shí)踐。
領(lǐng)域劃分設(shè)計(jì)步驟：
1狰晚、對(duì)用戶需求場(chǎng)景分析筒饰，識(shí)別出業(yè)務(wù)全維度 Use Case。
2壁晒、分析模型魯棒圖瓷们，識(shí)別出業(yè)務(wù)場(chǎng)景中所有的實(shí)體對(duì)象。魯棒圖 —— 是需求設(shè)計(jì)過程中使用的一種方法（魯棒性分析）秒咐，通過魯棒分析法可以讓設(shè)計(jì)人員更清晰谬晕，更全面地了解需求。它通常使用在需求分析后及需求設(shè)計(jì)前做軟件架構(gòu)分析之用携取，它主要注重于功能需求的設(shè)計(jì)分析工作攒钳。需求規(guī)格說明書為其輸入信息，設(shè)計(jì)模型為其輸出信息雷滋。它是從功能需求向設(shè)計(jì)方案過渡的第一步夕玩，重點(diǎn)是識(shí)別組成軟件系統(tǒng)的高級(jí)職責(zé)模塊、規(guī)劃模塊之間的關(guān)系惊豺。魯棒圖包含三種圖形：邊界燎孟、控制、實(shí)體尸昧，三個(gè)圖形如下：
3揩页、領(lǐng)域劃分，將所有識(shí)別出的實(shí)體對(duì)象進(jìn)行分類烹俗。
4爆侣、評(píng)估域劃分合理性，并進(jìn)行優(yōu)化幢妄。
4兔仰、基于數(shù)據(jù)驅(qū)動(dòng)設(shè)計(jì)架構(gòu)
隨著 IoT、大數(shù)據(jù)和人工智能的發(fā)展蕉鸳，以領(lǐng)域驅(qū)動(dòng)的方式進(jìn)行架構(gòu)往往滿足不了需求或者達(dá)不到預(yù)期的效果乎赴，在大數(shù)據(jù)時(shí)代，在大數(shù)據(jù)應(yīng)用場(chǎng)景潮尝，我們需要轉(zhuǎn)變思維榕吼，從領(lǐng)域分析升維到基于大數(shù)據(jù)統(tǒng)計(jì)分析結(jié)果來進(jìn)行業(yè)務(wù)架構(gòu)、應(yīng)用架構(gòu)勉失、數(shù)據(jù)架構(gòu)和技術(shù)架構(gòu)羹蚣。這里需要架構(gòu)師具備數(shù)理統(tǒng)計(jì)分析的基礎(chǔ)和 BI 的能力，以數(shù)據(jù)思維來架構(gòu)系統(tǒng)乱凿，典型的系統(tǒng)像阿里的數(shù)據(jù)分析平臺(tái)采云間和菜鳥的數(shù)據(jù)分析平臺(tái) FBI顽素。
上述四種思維咽弦，往往在架構(gòu)設(shè)計(jì)中是融合使用的，需要根據(jù)業(yè)務(wù)或者系統(tǒng)的需求來選擇側(cè)重思維方式胁出。
有了架構(gòu)思維的指導(dǎo)离唬，具體有沒有通用／標(biāo)準(zhǔn)化的架構(gòu)框架以更好的執(zhí)行架構(gòu)設(shè)計(jì)？請(qǐng)看常見的架構(gòu)框架划鸽。下述的架構(gòu)框架其實(shí)本身也包含了重要的一些架構(gòu)思維输莺。
常見架構(gòu)框架1、TOGAF
TOGAF 是 The Open Group Architecture Framework 的縮寫裸诽，它由 The Open Group 開發(fā)嫂用，The Open Group 是一個(gè)非盈利的技術(shù)行業(yè)聯(lián)盟，它不斷更新和重申 TOGAF丈冬。
TOGAF 強(qiáng)調(diào)商業(yè)目標(biāo)作為架構(gòu)的驅(qū)動(dòng)力嘱函，并提供了一個(gè)最佳實(shí)踐的儲(chǔ)藏庫，其中包括 TOGAF 架構(gòu)開發(fā)方法（ADM）埂蕊、TOGAF 架構(gòu)內(nèi)容框架往弓、TOGAF 參考模型、架構(gòu)開發(fā)方法（ADM）指引和技術(shù)蓄氧、企業(yè)連續(xù)統(tǒng)一體和 TOGAF 能力框架函似。
1、ADM
ADM是一個(gè)迭代的步驟順序以發(fā)展企業(yè)范圍的架構(gòu)的方法喉童。
2撇寞、架構(gòu)內(nèi)容框架
3、參考模型
4堂氯、ADM指引和技術(shù)
1）架構(gòu)迭代階段：
2）在不同水平運(yùn)用ADM：
3）利益相關(guān)者分類：
5蔑担、企業(yè)連續(xù)統(tǒng)一體
架構(gòu)指導(dǎo)及支持解決方案：基礎(chǔ) ?通用系統(tǒng) ?行業(yè)?組織特定
6、能力框架
（更多內(nèi)容可以參考《TOGAF標(biāo)準(zhǔn)9.1版本》或者https://www.opengroup.org/togaf）
2咽白、Zachman
第一個(gè)最有影響力的框架方法論就是 Zachman 框架啤握，它是 John Zachman 首次在1987年提出的。
Zachman 框架模型分兩個(gè)維度：橫向維度采用6W（what晶框、how排抬、where、who三妈、when畜埋、why）進(jìn)行組織，縱向維度反映了 IT 架構(gòu)層次畴蒲，從上到下（Top-Down），分別為范圍模型对室、企業(yè)模型模燥、系統(tǒng)模型咖祭、技術(shù)模型、詳細(xì)模型蔫骂、功能模型么翰。橫向結(jié)合6W，Zachman 框架分別由數(shù)據(jù)辽旋、功能浩嫌、網(wǎng)絡(luò)、人員补胚、時(shí)間码耐、動(dòng)機(jī)分別對(duì)應(yīng)回答What、How溶其、Where骚腥、Who、When 與 Why 這六個(gè)問題瓶逃。
3束铭、ITSA
ITSA誕生于1986年的惠普，世界最早的企業(yè)架構(gòu)框架(IT戰(zhàn)略與架構(gòu))厢绝。建模原則就是“Everything you need, and nothing you don’t”契沫，只放你要的東西。
4昔汉、DODAF
DODAF 是美國國防部架構(gòu)框架埠褪，是一個(gè)控制“EA開發(fā)、維護(hù)和決策生成”的組織機(jī)制挤庇，是統(tǒng)一組織“團(tuán)隊(duì)資源钞速、描述和控制EA活動(dòng)”的總體結(jié)構(gòu)。
DODAF 涵蓋 DoD 的所有業(yè)務(wù)領(lǐng)域嫡秕，定義了表示渴语、描述、集成 DoD 范圍內(nèi)眾多架構(gòu)的標(biāo)準(zhǔn)方法昆咽，確保架構(gòu)描述可比較驾凶、評(píng)估，提供了對(duì) FoS (系統(tǒng)族)和 SoS (體系)進(jìn)行理解掷酗、比較调违、集成和互操作共同的架構(gòu)基礎(chǔ)，提供開發(fā)和表達(dá)架構(gòu)描述的規(guī)則和指南,但不指導(dǎo)如何實(shí)現(xiàn)泻轰。
DODAF 核心是8個(gè)視點(diǎn)和52個(gè)模型技肩。
1、全景視點(diǎn) AV
與所有視點(diǎn)相關(guān)的體系結(jié)構(gòu)描述的頂層概貌浮声。提供有關(guān)體系結(jié)構(gòu)描述的總體信息虚婿，諸如體系結(jié)構(gòu)描述的范圍和背景旋奢。范圍包括體系結(jié)構(gòu)描述的專業(yè)領(lǐng)域和時(shí)間框架。背景由構(gòu)成體系結(jié)構(gòu)描述背景的相互關(guān)聯(lián)各種條件組成然痊，包括條令至朗，戰(zhàn)術(shù)、技術(shù)和程序剧浸，相關(guān)目標(biāo)和構(gòu)想的描述锹引，作戰(zhàn)概念(CONOPS)，想定和環(huán)境條件唆香。
2嫌变、能力視點(diǎn)CV
能力視點(diǎn)(CV)集中反映了與整體愿景相關(guān)的組織目標(biāo)，這些愿景指在特定標(biāo)準(zhǔn)和條件下進(jìn)行特定行動(dòng)過程或是達(dá)成期望效果的能力袋马，它們綜合使用各種手段和方式來完成一組任務(wù)初澎。
CV 為體系結(jié)構(gòu)描述中闡述的能力提供了戰(zhàn)略背景和相應(yīng)的高層范圍，比作戰(zhàn)概念圖中定義的基于想定的范圍更全面虑凛。
這些模型是高層的碑宴，用決策者易于理解的術(shù)語來描述能力，以便溝通能力演進(jìn)方面戰(zhàn)略構(gòu)想桑谍。
3延柠、作戰(zhàn)視點(diǎn)OV
作戰(zhàn)視點(diǎn)(OV)集中反映了完成 DoD 使命的機(jī)構(gòu)、任務(wù)或執(zhí)行的行動(dòng)以及彼此間必須交換的信息锣披。描述信息交換的種類贞间、頻度、性質(zhì)雹仿，信息交換支持哪些任務(wù)和活動(dòng)增热。
4、服務(wù)視點(diǎn) SvcV
服務(wù)視點(diǎn)(SvcV)集中反映了為作戰(zhàn)行動(dòng)提供支撐的系統(tǒng)胧辽、服務(wù)和相互交織的功能峻仇。DoD 流程包括作戰(zhàn)、業(yè)務(wù)邑商、情報(bào)和基礎(chǔ)設(shè)施功能摄咆。SvcV 功能和服務(wù)資源及要素可以鏈接到 0V 中的體系結(jié)構(gòu)數(shù)據(jù)。這些系統(tǒng)功能和服務(wù)資源支撐作戰(zhàn)行動(dòng)人断，促進(jìn)信息交換吭从。
5、系統(tǒng)視點(diǎn) SV
系統(tǒng)視點(diǎn)(SV)集中反映支持作戰(zhàn)行動(dòng)中的自動(dòng)化系統(tǒng)恶迈、相互交聯(lián)和其他系統(tǒng)功能的信息涩金。隨著對(duì)面向服務(wù)環(huán)境和云計(jì)算的重視，在 DoDAF 的未來版本中也許不會(huì)有系統(tǒng)視點(diǎn)。
6鸭廷、數(shù)信視點(diǎn) DIV
數(shù)據(jù)和信息視點(diǎn)(DIV)枣抱，簡稱數(shù)信視點(diǎn)熔吗，反映了體系結(jié)構(gòu)描述中的業(yè)務(wù)信息需求和結(jié)構(gòu)化的業(yè)務(wù)流程規(guī)則辆床。
描述體系結(jié)構(gòu)描述中與信息交換相關(guān)的信息，諸如屬性桅狠、特征和相互關(guān)系讼载。
必要時(shí)，本視點(diǎn)模型中用到的數(shù)據(jù)需要由多個(gè)架構(gòu)團(tuán)隊(duì)來共同考慮中跌。
7咨堤、標(biāo)準(zhǔn)視點(diǎn) StdV
標(biāo)準(zhǔn)視點(diǎn)(StdV)是用來管控系統(tǒng)各組成部分或要素的編排、交互和相互依賴的規(guī)則的最小集漩符。其目的是確保系統(tǒng)能滿足特定的一組操作需求一喘。
標(biāo)準(zhǔn)視點(diǎn)提供技術(shù)系統(tǒng)的實(shí)施指南，以工程規(guī)范為基礎(chǔ)嗜暴，確立通用的積木塊凸克，開發(fā)產(chǎn)品線。
包括一系列技術(shù)標(biāo)準(zhǔn)闷沥、執(zhí)行慣例萎战、標(biāo)準(zhǔn)選項(xiàng)、規(guī)則和規(guī)范舆逃，這些標(biāo)準(zhǔn)在特定體系結(jié)構(gòu)描述中可以組成管控系統(tǒng)和系統(tǒng)/服務(wù)要素的文件(profile)蚂维。
8、項(xiàng)目視點(diǎn) PV
項(xiàng)目視點(diǎn)(PV)集中反映了項(xiàng)目是如何有機(jī)地組織成一個(gè)釆辦項(xiàng)目的有序組合路狮。
描述多個(gè)采辦項(xiàng)目之間關(guān)聯(lián)關(guān)系虫啥，每個(gè)采辦項(xiàng)目都負(fù)責(zé)交付特定系統(tǒng)或能力。
TOGAF奄妨，Zachman涂籽，ITSA 和 DODAF 是非常不錯(cuò)的架構(gòu)框架，尤其前兩者應(yīng)用很廣泛展蒂，TOGAF 還有專門的架構(gòu)認(rèn)證又活。當(dāng)我們掌握了這些框架，我們是不是需要一些架構(gòu)原則來指導(dǎo)更具體的設(shè)計(jì)锰悼？請(qǐng)看下文柳骄。
架構(gòu)原則
設(shè)計(jì)原則就是架構(gòu)設(shè)計(jì)的指導(dǎo)思想，它指導(dǎo)我們?nèi)绾螌?shù)據(jù)和函數(shù)組織成類箕般，如何將類鏈接起來成為組件和程序耐薯。反向來說，架構(gòu)的主要工作就是將軟件拆解為組件，設(shè)計(jì)原則指導(dǎo)我們?nèi)绾尾鸾馇酢⒉鸾獾牧６忍遐恕⒔M件間依賴的方向、組件解耦的方式等臼婆。
設(shè)計(jì)原則有很多抒痒，我們進(jìn)行架構(gòu)設(shè)計(jì)的主導(dǎo)原則是 OCP（開閉原則），在類和代碼的層級(jí)上有：SRP（單一職責(zé)原則）颁褂、LSP（里氏替換原則）故响、ISP（接口隔離原則）、DIP（依賴反轉(zhuǎn)原則）颁独；在組件的層級(jí)上有：REP（復(fù)用彩届、發(fā)布等同原則）、CCP（共同閉包原則）誓酒、CRP（共同復(fù)用原則）樟蠕，處理組件依賴問題的三原則：無依賴環(huán)原則、穩(wěn)定依賴原則靠柑、穩(wěn)定抽象原則寨辩。
1、設(shè)計(jì)原則
1病往、OCP（開閉原則）：設(shè)計(jì)良好的軟件應(yīng)該易于擴(kuò)展捣染，同時(shí)抗拒修改。這是我們進(jìn)行架構(gòu)設(shè)計(jì)的主導(dǎo)原則停巷，其他的原則都為這條原則服務(wù)耍攘。
2、SRP（單一職責(zé)原則）：任何一個(gè)軟件模塊畔勤，都應(yīng)該有且只有一個(gè)被修改的原因蕾各，“被修改的原因“指系統(tǒng)的用戶或所有者，翻譯一下就是庆揪，任何模塊只對(duì)一個(gè)用戶的價(jià)值負(fù)責(zé)式曲，該原則指導(dǎo)我們?nèi)绾尾鸱纸M件。
舉個(gè)例子缸榛，CTO 和 COO 都要統(tǒng)計(jì)員工的工時(shí)吝羞，當(dāng)前他們要求的統(tǒng)計(jì)方式可能是相同的，我們復(fù)用一套代碼内颗，這時(shí) COO 說周末的工時(shí)統(tǒng)計(jì)要乘以二钧排，按照這個(gè)需求修改完代碼，CTO 可能就要過來罵街了均澳。當(dāng)然這是個(gè)非常淺顯的例子恨溜，實(shí)際項(xiàng)目中也有很多代碼服務(wù)于多個(gè)價(jià)值主體符衔，這帶來很大的探秘成本和修改風(fēng)險(xiǎn)，另外糟袁，當(dāng)一份代碼有多個(gè)所有者時(shí)判族，就會(huì)產(chǎn)生代碼合并沖突的問題。
3项戴、LSP（里氏替換原則）：當(dāng)用同一接口的不同實(shí)現(xiàn)互相替換時(shí)形帮，系統(tǒng)的行為應(yīng)該保持不變。該原則指導(dǎo)的是接口與其實(shí)現(xiàn)方式肯尺。
你一定很疑惑沃缘，實(shí)現(xiàn)了同一個(gè)接口躯枢，他們的行為也肯定是一致的呀则吟，還真不一定。假設(shè)認(rèn)為矩形的系統(tǒng)行為是：面積=寬*高锄蹂，讓正方形實(shí)現(xiàn)矩形的接口氓仲，在調(diào)用 setW 和 setH 時(shí)载城，正方形做的其實(shí)是同一個(gè)事情蹲缠，設(shè)置它的邊長。這時(shí)下邊的單元測(cè)試用矩形能通過幔荒，用正方形就不行朝抖，實(shí)現(xiàn)同樣的接口啥箭，但是系統(tǒng)行為變了，這是違反 LSP 的經(jīng)典案例治宣。
Rectangle r = ... r.setW(5); r.setH(2); assert(r.area() == 10);
4急侥、ISP（接口隔離原則）：不依賴任何不需要的方法、類或組件侮邀。該原則指導(dǎo)我們的接口設(shè)計(jì)坏怪。當(dāng)我們依賴一個(gè)接口但只用到了其中的部分方法時(shí)，其實(shí)我們已經(jīng)依賴了不需要的方法或類绊茧，當(dāng)這些方法或類有變更時(shí)铝宵，會(huì)引起我們類的重新編譯，或者引起我們組件的重新部署华畏，這些都是不必要的鹏秋。所以我們最好定義個(gè)小接口，把用到的方法拆出來亡笑。
5侣夷、DIP（依賴反轉(zhuǎn)原則）：指一種特定的解耦（傳統(tǒng)的依賴關(guān)系創(chuàng)建在高層次上，而具體的策略設(shè)置則應(yīng)用在低層次的模塊上）形式况芒，使得高層次的模塊不依賴于低層次的模塊的實(shí)現(xiàn)細(xì)節(jié)惜纸，依賴關(guān)系被顛倒（反轉(zhuǎn)）叶撒，從而使得低層次模塊依賴于高層次模塊的需求抽象。
跨越組建邊界的依賴方向永遠(yuǎn)與控制流的方向相反耐版。該原則指導(dǎo)我們?cè)O(shè)計(jì)組件間依賴的方向祠够。
依賴反轉(zhuǎn)原則是個(gè)可操作性非常強(qiáng)的原則，當(dāng)你要修改組件間的依賴方向時(shí)粪牲，將需要進(jìn)行組件間通信的類抽象為接口古瓤，接口放在邊界的哪邊，依賴就指向哪邊腺阳。
6落君、REP（復(fù)用、發(fā)布等同原則）：軟件復(fù)用的最小粒度應(yīng)等同于其發(fā)布的最小粒度亭引。直白地說绎速，就是要復(fù)用一段代碼就把它抽成組件，該原則指導(dǎo)我們組件拆分的粒度焙蚓。
7纹冤、CCP（共同閉包原則）：為了相同目的而同時(shí)修改的類，應(yīng)該放在同一個(gè)組件中购公。CCP 原則是 SRP 原則在組件層面的描述萌京。該原則指導(dǎo)我們組件拆分的粒度。
對(duì)大部分應(yīng)用程序而言宏浩，可維護(hù)性的重要性遠(yuǎn)遠(yuǎn)大于可復(fù)用性知残，由同一個(gè)原因引起的代碼修改，最好在同一個(gè)組件中比庄，如果分散在多個(gè)組件中求妹，那么開發(fā)、提交印蔗、部署的成本都會(huì)上升扒最。
8、CRP（共同復(fù)用原則）：不要強(qiáng)迫一個(gè)組件依賴它不需要的東西华嘹。CRP 原則是 ISP原則在組件層面的描述吧趣。該原則指導(dǎo)我們組件拆分的粒度。
相信你一定有這種經(jīng)歷耙厚，集成了組件 A强挫，但組件 A 依賴了組件 B、C薛躬。即使組件 B俯渤、C 你完全用不到，也不得不集成進(jìn)來型宝。這是因?yàn)槟阒挥玫搅私M件 A 的部分能力八匠，組件 A 中額外的能力帶來了額外的依賴絮爷。如果遵循共同復(fù)用原則，你需要把 A 拆分梨树，只保留你要用的部分坑夯。
REP、CCP抡四、CRP 三個(gè)原則之間存在彼此競(jìng)爭的關(guān)系柜蜈，REP 和 CCP 是黏合性原則，它們會(huì)讓組件變得更大指巡，而 CRP 原則是排除性原則淑履，它會(huì)讓組件變小。遵守REP藻雪、CCP 而忽略 CRP秘噪，就會(huì)依賴了太多沒有用到的組件和類，而這些組件或類的變動(dòng)會(huì)導(dǎo)致你自己的組件進(jìn)行太多不必要的發(fā)布阔涉；遵守 REP缆娃、CRP 而忽略 CCP，因?yàn)榻M件拆分的太細(xì)了瑰排，一個(gè)需求變更可能要改 n 個(gè)組件，帶來的成本也是巨大的暖侨。
除了上述設(shè)計(jì)原則椭住，還有一些重要的指導(dǎo)原則如下：
2、指導(dǎo)原則
1字逗、N+1設(shè)計(jì)：系統(tǒng)中的每個(gè)組件都應(yīng)做到?jīng)]有單點(diǎn)故障京郑；
2、回滾設(shè)計(jì)：確保系統(tǒng)可以向前兼容葫掉，在系統(tǒng)升級(jí)時(shí)應(yīng)能有辦法回滾版本些举；
3、禁用設(shè)計(jì)：應(yīng)該提供控制具體功能是否可用的配置俭厚，在系統(tǒng)出現(xiàn)故障時(shí)能夠快速下線功能户魏；
4、監(jiān)控設(shè)計(jì)：在設(shè)計(jì)階段就要考慮監(jiān)控的手段挪挤，便于有效的排查問題叼丑，比如引入traceId、業(yè)務(wù)身份 Id 便于排查監(jiān)控問題扛门；
5鸠信、多活數(shù)據(jù)中心設(shè)計(jì)：若系統(tǒng)需要極高的高可用，應(yīng)考慮在多地實(shí)施數(shù)據(jù)中心進(jìn)行多活论寨，至少在一個(gè)機(jī)房斷電的情況下系統(tǒng)依然可用星立；
6爽茴、采用成熟的技術(shù)：剛開發(fā)的或開源的技術(shù)往往存在很多隱藏的 bug，出了問題沒有很好的商業(yè)支持可能會(huì)是一個(gè)災(zāi)難绰垂；
7闹啦、資源隔離設(shè)計(jì)：應(yīng)避免單一業(yè)務(wù)占用全部資源；
8辕坝、架構(gòu)水平擴(kuò)展設(shè)計(jì)：系統(tǒng)只有做到能水平擴(kuò)展窍奋，才能有效避免瓶頸問題；
9酱畅、非核心則購買的原則：非核心功能若需要占用大量的研發(fā)資源才能解決琳袄，則考慮購買成熟的產(chǎn)品；
10纺酸、使用商用硬件：商用硬件能有效降低硬件故障的機(jī)率窖逗；
11、快速迭代：系統(tǒng)應(yīng)該快速開發(fā)小功能模塊餐蔬，盡快上線進(jìn)行驗(yàn)證碎紊，早日發(fā)現(xiàn)問題大大降低系統(tǒng)交付的風(fēng)險(xiǎn)；
12樊诺、無狀態(tài)設(shè)計(jì)：服務(wù)接口應(yīng)該做成無狀態(tài)的仗考，當(dāng)前接口的訪問不依賴于接口上次訪問的狀態(tài)。
架構(gòu)師知道了職責(zé)词爬，具備很好的架構(gòu)思維秃嗜，掌握了通用的架構(gòu)框架和方法論，使用架構(gòu)原則進(jìn)行架構(gòu)設(shè)計(jì)顿膨，不同的業(yè)務(wù)和系統(tǒng)要求不一樣锅锨，那么有沒有針對(duì)不同場(chǎng)景的系統(tǒng)架構(gòu)設(shè)計(jì)？下文就針對(duì)分布式架構(gòu)演進(jìn)恋沃、單元化架構(gòu)必搞、面向服務(wù) SOA 架構(gòu)、微服務(wù)架構(gòu)囊咏、Serverless 架構(gòu)進(jìn)行介紹恕洲，以便于我們?cè)趯?shí)際運(yùn)用中進(jìn)行參考使用。
常見架構(gòu)1匆笤、分布式架構(gòu)演進(jìn)
1研侣、 初始階段架構(gòu)
特征：應(yīng)用程序，數(shù)據(jù)庫炮捧，文件等所有資源都放在一臺(tái)服務(wù)器上庶诡。
2、應(yīng)用服務(wù)和數(shù)據(jù)服務(wù)以及文件服務(wù)分離
說明：好景不長咆课，發(fā)現(xiàn)隨著系統(tǒng)訪問量的再度增加末誓，webserver 機(jī)器的壓力在高峰期會(huì)上升到比較高扯俱，這個(gè)時(shí)候開始考慮增加一臺(tái) webserver。
特征：應(yīng)用程序喇澡、數(shù)據(jù)庫迅栅、文件分別部署在獨(dú)立的資源上。
3晴玖、使用緩存改善性能
說明：系統(tǒng)訪問特點(diǎn)遵循二八定律读存，即80%的業(yè)務(wù)訪問集中在20%的數(shù)據(jù)上。緩存分為本地緩存 遠(yuǎn)程分布式緩存呕屎，本地緩存訪問速度更快但緩存數(shù)據(jù)量有限让簿，同時(shí)存在與應(yīng)用程序爭用內(nèi)存的情況。
特征：數(shù)據(jù)庫中訪問較集中的一小部分?jǐn)?shù)據(jù)存儲(chǔ)在緩存服務(wù)器中秀睛，減少數(shù)據(jù)庫的訪問次數(shù)尔当，降低數(shù)據(jù)庫的訪問壓力。
4蹂安、使用“應(yīng)用服務(wù)器”集群
說明：在做完分庫分表這些工作后椭迎，數(shù)據(jù)庫上的壓力已經(jīng)降到比較低了，又開始過著每天看著訪問量暴增的幸福生活了田盈。突然有一天畜号，發(fā)現(xiàn)系統(tǒng)的訪問又開始有變慢的趨勢(shì)了，這個(gè)時(shí)候首先查看數(shù)據(jù)庫缠黍，壓力一切正常弄兜，之后查看 webserver，發(fā)現(xiàn)apache 阻塞了很多的請(qǐng)求瓷式， 而應(yīng)用服務(wù)器對(duì)每個(gè)請(qǐng)求也是比較快的，看來是請(qǐng)求數(shù)太高導(dǎo)致需要排隊(duì)等待语泽，響應(yīng)速度變慢贸典。
特征：多臺(tái)服務(wù)器通過負(fù)載均衡同時(shí)向外部提供服務(wù)，解決單臺(tái)服務(wù)器處理能力和存儲(chǔ)空間上限的問題踱卵。
描述：使用集群是系統(tǒng)解決高并發(fā)廊驼、海量數(shù)據(jù)問題的常用手段。通過向集群中追加資源惋砂，提升系統(tǒng)的并發(fā)處理能力妒挎，使得服務(wù)器的負(fù)載壓力不再成為整個(gè)系統(tǒng)的瓶頸。
5西饵、數(shù)據(jù)庫讀寫分離
說明：享受了一段時(shí)間的系統(tǒng)訪問量高速增長的幸福后酝掩，發(fā)現(xiàn)系統(tǒng)又開始變慢了，這次又是什么狀況呢眷柔，經(jīng)過查找期虾，發(fā)現(xiàn)數(shù)據(jù)庫寫入原朝、更新的這些操作的部分?jǐn)?shù)據(jù)庫連接的資源競(jìng)爭非常激烈，導(dǎo)致了系統(tǒng)變慢镶苞。
特征：數(shù)據(jù)庫引入主備部署喳坠。
描述：把數(shù)據(jù)庫劃分為讀庫和寫庫，通過引入主從數(shù)據(jù)庫服務(wù)茂蚓，讀和寫操作在不同的數(shù)據(jù)庫服務(wù)處理壕鹉，讀庫可以有多個(gè)，通過同步機(jī)制把寫庫的數(shù)據(jù)同步到讀庫聋涨，對(duì)于需要查詢最新寫入數(shù)據(jù)場(chǎng)景晾浴，可以通過在緩存中多寫一份，通過緩存獲得最新數(shù)據(jù)牛郑。
6怠肋、反向代理和CDN加速
特征：采用CDN和反向代理加快系統(tǒng)的訪問速度。
描述：為了應(yīng)付復(fù)雜的網(wǎng)絡(luò)環(huán)境和不同地區(qū)用戶的訪問淹朋，通過 CDN 和反向代理加快用戶訪問的速度笙各，同時(shí)減輕后端服務(wù)器的負(fù)載壓力。CDN 與反向代理的基本原理都是緩存础芍。
7杈抢、“分布式文件”系統(tǒng) 和 “分布式數(shù)據(jù)庫”
說明：隨著系統(tǒng)的不斷運(yùn)行，數(shù)據(jù)量開始大幅度增長仑性，這個(gè)時(shí)候發(fā)現(xiàn)分庫后查詢?nèi)匀粫?huì)有些慢惶楼，于是按照分庫的思想開始做分表的工作
特征：數(shù)據(jù)庫采用分布式數(shù)據(jù)庫，文件系統(tǒng)采用分布式文件系統(tǒng)诊杆。
描述：任何強(qiá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í)候才使用，更常用的數(shù)據(jù)庫拆分手段是業(yè)務(wù)分庫淘这，將不同的業(yè)務(wù)數(shù)據(jù)庫部署在不同的物理服務(wù)器上剥扣。
8、使用 NoSQL 和搜索引擎
特征：系統(tǒng)引入 NoSQL 數(shù)據(jù)庫及搜索引擎铝穷。
描述：隨著業(yè)務(wù)越來越復(fù)雜钠怯，對(duì)數(shù)據(jù)存儲(chǔ)和檢索的需求也越來越復(fù)雜，系統(tǒng)需要采用一些非關(guān)系型數(shù)據(jù)庫如 NoSQL 和分?jǐn)?shù)據(jù)庫查詢技術(shù)如搜索引擎曙聂。
應(yīng)用服務(wù)器通過統(tǒng)一數(shù)據(jù)訪問模塊訪問各種數(shù)據(jù)晦炊，減輕應(yīng)用程序管理諸多數(shù)據(jù)源的麻煩。
9、業(yè)務(wù)拆分
特征：系統(tǒng)上按照業(yè)務(wù)進(jìn)行拆分改造刽锤，應(yīng)用服務(wù)器按照業(yè)務(wù)區(qū)分進(jìn)行分別部署镊尺。
描述：為了應(yīng)對(duì)日益復(fù)雜的業(yè)務(wù)場(chǎng)景，通常使用分而治之的手段將整個(gè)系統(tǒng)業(yè)務(wù)分成不同的產(chǎn)品線并思，應(yīng)用之間通過超鏈接建立關(guān)系庐氮，也可以通過消息隊(duì)列進(jìn)行數(shù)據(jù)分發(fā)，當(dāng)然更多的還是通過訪問同一個(gè)數(shù)據(jù)存儲(chǔ)系統(tǒng)來構(gòu)成一個(gè)關(guān)聯(lián)的完整系統(tǒng)宋彼。
縱向拆分：將一個(gè)大應(yīng)用拆分為多個(gè)小應(yīng)用弄砍，如果新業(yè)務(wù)較為獨(dú)立，那么就直接將其設(shè)計(jì)部署為一個(gè)獨(dú)立的 Web 應(yīng)用系統(tǒng)縱向拆分相對(duì)較為簡單输涕，通過梳理業(yè)務(wù)音婶，將較少相關(guān)的業(yè)務(wù)剝離即可。
橫向拆分：將復(fù)用的業(yè)務(wù)拆分出來莱坎，獨(dú)立部署為分布式服務(wù)衣式，新增業(yè)務(wù)只需要調(diào)用這些分布式服務(wù)橫向拆分需要識(shí)別可復(fù)用的業(yè)務(wù)，設(shè)計(jì)服務(wù)接口檐什，規(guī)范服務(wù)依賴關(guān)系碴卧。
10、分布式服務(wù)
特征：公共的應(yīng)用模塊被提取出來乃正，部署在分布式服務(wù)器上供應(yīng)用服務(wù)器調(diào)用住册。
描述：隨著業(yè)務(wù)越拆越小，應(yīng)用系統(tǒng)整體復(fù)雜程度呈指數(shù)級(jí)上升瓮具，由于所有應(yīng)用要和所有數(shù)據(jù)庫系統(tǒng)連接荧飞，最終導(dǎo)致數(shù)據(jù)庫連接資源不足，拒絕服務(wù)名党。
分布式服務(wù)的問題和挑戰(zhàn)：
當(dāng)服務(wù)越來越多時(shí)叹阔，服務(wù)URL配置管理變得非常困難，F(xiàn)5硬件負(fù)載均衡器的單點(diǎn)壓力也越來越大传睹。
當(dāng)進(jìn)一步發(fā)展条获，服務(wù)間依賴關(guān)系變得錯(cuò)蹤復(fù)雜，甚至分不清哪個(gè)應(yīng)用要在哪個(gè)應(yīng)用之前啟動(dòng)蒋歌，架構(gòu)師都不能完整的描述應(yīng)用的架構(gòu)關(guān)系。
服務(wù)的調(diào)用量越來越大委煤，服務(wù)的容量問題就暴露出來堂油，這個(gè)服務(wù)需要多少機(jī)器支撐？什么時(shí)候該加機(jī)器碧绞？
服務(wù)多了府框，溝通成本也開始上升，調(diào)某個(gè)服務(wù)失敗該找誰讥邻？服務(wù)的參數(shù)都有什么約定迫靖？
一個(gè)服務(wù)有多個(gè)業(yè)務(wù)消費(fèi)者院峡，如何確保服務(wù)質(zhì)量？
隨著服務(wù)的不停升級(jí)系宜，總有些意想不到的事發(fā)生照激，比如 cache 寫錯(cuò)了導(dǎo)致內(nèi)存溢出，故障不可避免盹牧，每次核心服務(wù)一掛俩垃，影響一大片，人心慌慌汰寓，如何控制故障的影響面口柳？服務(wù)是否可以功能降級(jí)？或者資源劣化有滑？
針對(duì)這些問題跃闹，下述的單元化架構(gòu)，微服務(wù)架構(gòu)以及 Serveless 架構(gòu)可以一定程度解決毛好，另外針對(duì)業(yè)務(wù)系統(tǒng)望艺，需要做到業(yè)務(wù)與業(yè)務(wù)隔離、管理域和運(yùn)行域分開睛榄、業(yè)務(wù)與平臺(tái)隔離方可解決上述問題荣茫。
2、單元化架構(gòu)
1场靴、什么是單元化：單元化架構(gòu)是從并行計(jì)算領(lǐng)域發(fā)展而來啡莉。在分布式服務(wù)設(shè)計(jì)領(lǐng)域，一個(gè)單元（Cell）就是滿足某個(gè)分區(qū)所有業(yè)務(wù)操作的自包含的安裝旨剥。而一個(gè)分區(qū)（Shard）咧欣，則是整體數(shù)據(jù)集的一個(gè)子集，如果你用尾號(hào)來劃分用戶轨帜，那同樣尾號(hào)的那部分用戶就可以認(rèn)為是一個(gè)分區(qū)魄咕。單元化就是將一個(gè)服務(wù)設(shè)計(jì)改造讓其符合單元特征的過程。
2蚌父、單元化的必要性：隨著硬件的不斷升級(jí)哮兰，計(jì)算機(jī)硬件能力已經(jīng)越來越強(qiáng)，CPU越來越快苟弛，內(nèi)存越來越大喝滞，網(wǎng)絡(luò)越來越寬。這讓我們看到了在單臺(tái)機(jī)器上垂直擴(kuò)展的機(jī)會(huì)膏秫。尤其是當(dāng)你遇到一個(gè)性能要求和容量增長可以預(yù)期的業(yè)務(wù)右遭，單元化給我們提供另外的機(jī)會(huì)，讓我們可以有效降低資源的使用，提供更高性能的服務(wù)窘哈。
更高性能更低成本是我們的主要目標(biāo)吹榴，經(jīng)過單元化改造，我們得以用更少（約二分之一）的機(jī)器滚婉，獲得了比原來更高（接近百倍）的性能图筹。性能的提升很大部分原因在于服務(wù)的本地化，而服務(wù)的集成部署又進(jìn)一步降低了資源的使用满哪。除了性能收益婿斥，還有很多收益，比如更好的隔離性哨鸭，包括請(qǐng)求隔離和資源隔離民宿，比如更友好的升級(jí)，產(chǎn)品可以灰度發(fā)布等像鸡。單元化改造后對(duì)高峰的應(yīng)對(duì)以及擴(kuò)容方式等問題的解決活鹰。
3、如何做到單元化：先看下圖傳統(tǒng)的服務(wù)架構(gòu)只估，服務(wù)是分層的志群，每一層使用不同的分區(qū)算法，每一層都有不同數(shù)量的節(jié)點(diǎn)蛔钙，上層節(jié)點(diǎn)隨機(jī)選擇下層節(jié)點(diǎn)锌云。
再看下圖單元化架構(gòu)，其為性能和隔離性而設(shè)計(jì)吁脱，上層節(jié)點(diǎn)訪問指定下層節(jié)點(diǎn)桑涎。
在單元化架構(gòu)下，服務(wù)雖然分層劃分兼贡，但每個(gè)單元自成一體攻冷。按照層次來講的話，所有層使用相同的分區(qū)算法遍希，每一層都有相同數(shù)量的節(jié)點(diǎn)等曼，上層節(jié)點(diǎn)也會(huì)訪問指定的下層節(jié)點(diǎn)。
3凿蒜、SOA架構(gòu)
SOA（Service-Oriented Architecture禁谦，面向服務(wù)的架構(gòu)）是一個(gè)組件模型，它將應(yīng)用程序的不同功能單元（稱為服務(wù)）通過這些服務(wù)之間定義良好的接口和契約聯(lián)系起來废封。接口是采用中立的方式進(jìn)行定義的枷畏，它應(yīng)該獨(dú)立于實(shí)現(xiàn)服務(wù)的硬件平臺(tái)、操作系統(tǒng)和編程語言虱饿。這使得構(gòu)建在各種各樣的系統(tǒng)中的服務(wù)可以以一種統(tǒng)一和通用的方式進(jìn)行交互。面向服務(wù)架構(gòu)，它可以根據(jù)需求通過網(wǎng)絡(luò)對(duì)松散耦合的粗粒度應(yīng)用組件進(jìn)行分布式部署氮发、組合和使用渴肉。服務(wù)層是 SOA 的基礎(chǔ)，可以直接被應(yīng)用調(diào)用爽冕，從而有效控制系統(tǒng)中與軟件代理交互的人為依賴性仇祭。
SOA的實(shí)施具有幾個(gè)鮮明的基本特征。實(shí)施 SOA 的關(guān)鍵目標(biāo)是實(shí)現(xiàn)企業(yè) IT 資產(chǎn)的最大化作用颈畸。要實(shí)現(xiàn)這一目標(biāo)乌奇，就要在實(shí)施 SOA 的過程中牢記以下特征：
可從企業(yè)外部訪問；
隨時(shí)可用眯娱；
粗粒度的服務(wù)接口分級(jí)礁苗；
松散耦合；
可重用的服務(wù)徙缴；
服務(wù)接口設(shè)計(jì)管理试伙；
標(biāo)準(zhǔn)化的服務(wù)接口；
支持各種消息模式于样；
精確定義的服務(wù)契約疏叨。
為了實(shí)現(xiàn) SOA，企業(yè)需要一個(gè)服務(wù)架構(gòu)穿剖，下圖顯示了一個(gè)例子：
在上圖中蚤蔓， 服務(wù)消費(fèi)者（service consumer）可以通過發(fā)送消息來調(diào)用服務(wù)。這些消息由一個(gè)服務(wù)總線（service bus）轉(zhuǎn)換后發(fā)送給適當(dāng)?shù)姆?wù)實(shí)現(xiàn)糊余。這種服務(wù)架構(gòu)可以提供一個(gè)業(yè)務(wù)規(guī)則引（business rules engine）秀又，該引擎容許業(yè)務(wù)規(guī)則被合并在一個(gè)服務(wù)里或多個(gè)服務(wù)里。這種架構(gòu)也提供了一個(gè)服務(wù)管理基礎(chǔ)（service management infrastructure）啄刹，用來管理服務(wù)涮坐，類似審核，列表（billing）誓军，日志等功能袱讹。
此外，該架構(gòu)給企業(yè)提供了靈活的業(yè)務(wù)流程昵时，更好地處理控制請(qǐng)求（regulatory requirement）捷雕，例如Sarbanes Oxley（SOX），并且可以在不影響其他服務(wù)的情況下更改某項(xiàng)服務(wù)壹甥。
4救巷、微服務(wù)架構(gòu)
先來看看傳統(tǒng)的 web 開發(fā)方式，通過對(duì)比比較容易理解什么是 Microservice Architecture句柠。和 Microservice 相對(duì)應(yīng)的浦译，這種方式一般被稱為 Monolithic（單體式開發(fā)）棒假。
所有的功能打包在一個(gè) WAR包里，基本沒有外部依賴（除了容器）精盅，部署在一個(gè)JEE容器（Tomcat帽哑，JBoss，WebLogic）里叹俏，包含了 DO/DAO妻枕，Service，UI 等所有邏輯粘驰。
1屡谐、優(yōu)點(diǎn)：
開發(fā)簡單，集中式管理蝌数；
基本不會(huì)重復(fù)開發(fā)愕掏；
功能都在本地，沒有分布式的管理和調(diào)用消耗籽前。
2亭珍、缺點(diǎn)：
效率低：開發(fā)都在同一個(gè)項(xiàng)目改代碼，相互等待枝哄，沖突不斷肄梨；
維護(hù)難：代碼功功能耦合在一起，新人不知道何從下手挠锥；
不靈活：構(gòu)建時(shí)間長众羡，任何小修改都要重構(gòu)整個(gè)項(xiàng)目，耗時(shí)蓖租；
穩(wěn)定性差：一個(gè)微小的問題粱侣，都可能導(dǎo)致整個(gè)應(yīng)用掛掉；
擴(kuò)展性不夠：無法滿足高并發(fā)下的業(yè)務(wù)需求蓖宦。
3齐婴、常見的系統(tǒng)架構(gòu)遵循的三個(gè)標(biāo)準(zhǔn)和業(yè)務(wù)驅(qū)動(dòng)力：
提高敏捷性：及時(shí)響應(yīng)業(yè)務(wù)需求，促進(jìn)企業(yè)發(fā)展稠茂；
提升用戶體驗(yàn)：提升用戶體驗(yàn)柠偶，減少用戶流失；
降低成本：降低增加產(chǎn)品睬关、客戶或業(yè)務(wù)方案的成本诱担。
4淮捆、基于微服務(wù)架構(gòu)的設(shè)計(jì)：
目的：有效的拆分應(yīng)用毅弧，實(shí)現(xiàn)敏捷開發(fā)和部署。
關(guān)于微服務(wù)的一個(gè)形象表達(dá)：
X軸：運(yùn)行多個(gè)負(fù)載均衡器之后的運(yùn)行實(shí)例巨坊；
Y軸：將應(yīng)用進(jìn)一步分解為微服務(wù)（分庫）丐箩；
Z軸：大數(shù)據(jù)量時(shí)摇邦，將服務(wù)分區(qū)（分表）恤煞。
5、SOA和微服務(wù)的區(qū)別：
SOA喜歡重用涎嚼，微服務(wù)喜歡重寫阱州；
SOA喜歡水平服務(wù)，微服務(wù)喜歡垂直服務(wù)法梯；
SOA喜歡自上而下，微服務(wù)喜歡自下而上犀概。
5立哑、Serverless架構(gòu)
1、思想：無服務(wù)器是一種架構(gòu)理念姻灶，其核心思想是將提供服務(wù)資源的基礎(chǔ)設(shè)施抽象成各種服務(wù)铛绰，以 API 接口的方式供給用戶按需調(diào)用，真正做到按需伸縮产喉、按使用收費(fèi)捂掰。
2、優(yōu)勢(shì)：消除了對(duì)傳統(tǒng)的海量持續(xù)在線服務(wù)器組件的需求曾沈，降低了開發(fā)和運(yùn)維的復(fù)雜性这嚣，降低運(yùn)營成本并縮短了業(yè)務(wù)系統(tǒng)的交付周期，使得用戶能夠?qū)Ｗ⒃趦r(jià)值密度更高的業(yè)務(wù)邏輯的開發(fā)上塞俱。
3姐帚、內(nèi)容：目前業(yè)界較為公認(rèn)的無服務(wù)器架構(gòu)主要包括兩個(gè)方面，即提供計(jì)算資源的函數(shù)服務(wù)平臺(tái) FaaS障涯，以及提供托管云服務(wù)的后端服務(wù) BaaS罐旗。
函數(shù)即服務(wù)（Function as a Service）：是一項(xiàng)基于事件驅(qū)動(dòng)的函數(shù)托管計(jì)算服務(wù)。通過函數(shù)服務(wù)唯蝶，開發(fā)者只需要編寫業(yè)務(wù)函數(shù)代碼并設(shè)置運(yùn)行的條件九秀，無需配置和管理服務(wù)器等基礎(chǔ)設(shè)施，函數(shù)代碼運(yùn)行在無狀態(tài)的容器中粘我，由事件觸發(fā)且短暫易失鼓蜒，并完全由第三方管理，基礎(chǔ)設(shè)施對(duì)應(yīng)用開發(fā)者完全透明涂滴。函數(shù)以彈性友酱、高可靠的方式運(yùn)行，并且按實(shí)際執(zhí)行資源計(jì)費(fèi)柔纵，不執(zhí)行不產(chǎn)生費(fèi)用缔杉。
后端即服務(wù)（Backend as a Service）：BaaS 覆蓋了應(yīng)用可能依賴的所有第三方服務(wù)，如云數(shù)據(jù)庫搁料、身份驗(yàn)證或详、對(duì)象存儲(chǔ)等服務(wù)系羞，開發(fā)人員通過 API 和由 BaaS 服務(wù)商提供的 SDK，能夠集成所需的所有后端功能霸琴，而無需構(gòu)建后端應(yīng)用椒振，更不必管理虛擬機(jī)或容器等基礎(chǔ)設(shè)施，就能保證應(yīng)用的正常運(yùn)行梧乘。
三個(gè)less感覺很好：
Codeless 對(duì)應(yīng)的是服務(wù)開發(fā)澎迎，實(shí)現(xiàn)了源代碼托管，你只需要關(guān)注你的代碼實(shí)現(xiàn)选调，而不需要關(guān)心你的代碼在哪夹供，因?yàn)樵谡麄€(gè)開發(fā)過程中你都不會(huì)感受到代碼庫和代碼分支的存在。
Applicationless 對(duì)應(yīng)的是服務(wù)發(fā)布仁堪，在服務(wù)化框架下哮洽，你的服務(wù)發(fā)布不再需要申請(qǐng)應(yīng)用，也不需要關(guān)注你的應(yīng)用在哪弦聂。
Serverless 對(duì)應(yīng)的則是服務(wù)運(yùn)維鸟辅，有了 Serverless 化能力，你不再需要關(guān)注你的機(jī)器資源莺葫，Servlerless 會(huì)幫你搞定機(jī)器資源的彈性擴(kuò)縮容匪凉。
架構(gòu)師在完成上述架構(gòu)設(shè)計(jì)后，最終是需要協(xié)同利益相關(guān)方一起按項(xiàng)目化運(yùn)作落地拿結(jié)果徙融，那么應(yīng)該如何保證利益相關(guān)方在項(xiàng)目落地的滿意度洒缀，如何保證按照架構(gòu)很好的拿到項(xiàng)目成功的結(jié)果呢？架構(gòu)管理能力是架構(gòu)師非常重要的能力欺冀。
架構(gòu)師管理架構(gòu)雙贏模型
架構(gòu)結(jié)果管理
>>>>
參考資料
