我們?nèi)粘Ｉ钪惺褂煤芏鄳?yīng)用程序，有微信、抖音、王者這種涉及多人聯(lián)網(wǎng)互動(dòng)的大型應(yīng)用，它們以操作系統(tǒng)作為宿主；也有網(wǎng)站、小程序、PWA等借殼的應(yīng)用。面向用戶表現(xiàn)為Android/iOS/Windows/MacOS/瀏覽器/H5/Terminal 等端上的應(yīng)用程序，名為 Client。更多情況下，業(yè)務(wù)的核心邏輯體現(xiàn)在背后看不見的服務(wù)，名為 Server。

(資料圖片)

從普通用戶視角跳出來，切換到程序員視角，應(yīng)用程序可以理解為是M個(gè)Client和N個(gè)Server的組合。在軟件開發(fā)過程中，Client/Server的邊界如何劃分，Server之間如何通信，多個(gè)Server如何組織能夠保證整個(gè)系統(tǒng)按照預(yù)期的方式運(yùn)行，都是服務(wù)架構(gòu)要考慮的問題。

下面我們簡單串一下主流的幾個(gè)服務(wù)架構(gòu)，包括分層架構(gòu)、client-queue-worker架構(gòu)、微服務(wù)架構(gòu)、事件驅(qū)動(dòng)架構(gòu)、大數(shù)據(jù)、大計(jì)算架構(gòu)，并從四個(gè)方面對(duì)每個(gè)架構(gòu)進(jìn)行總結(jié)：

架構(gòu)的描述和架構(gòu)圖推薦的使用場(chǎng)景優(yōu)點(diǎn)、潛在問題和最佳實(shí)踐一些現(xiàn)實(shí)場(chǎng)景中的示例分層架構(gòu)

WAF全稱Web Application Firewall，就是防火墻

在開發(fā)傳統(tǒng)企業(yè)應(yīng)用中，分層架構(gòu)得到了廣泛使用。一個(gè)應(yīng)用被劃分為多個(gè)邏輯功能的層，比如展示層、業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層。這些分層同時(shí)也定義了依賴關(guān)系，每個(gè)層都只能調(diào)用它下面的層。每個(gè)層可以是一個(gè)獨(dú)立的模塊，整個(gè)系統(tǒng)的各個(gè)模塊可以獨(dú)立甚至并行開發(fā)和測(cè)試，交付質(zhì)量可以得到比較好地保證，所以這是目前最為廣泛使用的架構(gòu)之一。但它也有一些難以解決的問題，尤其體現(xiàn)在產(chǎn)品上線后的變更上。體現(xiàn)在：

在大型系統(tǒng)中，層的劃分邏輯并不那么明顯，可能出現(xiàn)過度分層的問題分層往往是從技術(shù)角度做的，沒有按照業(yè)務(wù)領(lǐng)域進(jìn)行，導(dǎo)致系統(tǒng)對(duì)業(yè)務(wù)擴(kuò)展不友好分層以后，跨層通信比較困難，對(duì)性能敏感的業(yè)務(wù)無法接受由此帶來的網(wǎng)絡(luò)通信開銷和編解碼開銷迭代困難，因?yàn)樾枰袑拥淖兏瑓f(xié)調(diào)多個(gè)團(tuán)隊(duì)的成本非常高

分層架構(gòu)在私有云系統(tǒng)中非常常見，比如一個(gè)私有云的解決方案可以設(shè)計(jì)為：

物理機(jī)層：物理機(jī)、網(wǎng)絡(luò)設(shè)備等虛擬化層：將物理資源進(jìn)行虛擬化，可以用kvm資源管理層：對(duì)資源進(jìn)行調(diào)度編排，也提供故障恢復(fù)、彈性擴(kuò)容等功能，比如k8s服務(wù)編排層：定義和管理服務(wù)的部署、配置和自動(dòng)化，通常是k8s上做二次開發(fā)出的一層殼用戶展示層：通常是web界面、命令行，也可以是API任務(wù)調(diào)度架構(gòu) Web-Queue-Worker

這個(gè)架構(gòu)下，用戶通過前端Web頁面將任務(wù)異步發(fā)送到后端，協(xié)議可以是HTTP或RPC。通常情況下，后端的worker接收任務(wù)后，執(zhí)行一段事件CPU密集型計(jì)算，生成結(jié)果。

作為對(duì)比，分層架構(gòu)中來自client的請(qǐng)求大都同步到達(dá)，請(qǐng)求可以很快得到滿足，server端處理完成后同步返回；相反，任務(wù)調(diào)度架構(gòu)下，每個(gè)請(qǐng)求要得到滿足，可能耗費(fèi)server大量的計(jì)算/網(wǎng)絡(luò)或存儲(chǔ)資源，所以異步返回。

在通信方式上，任務(wù)調(diào)度架構(gòu)更多地采用類似于隊(duì)列的方式（不一定真的有一個(gè)消息隊(duì)列，從數(shù)據(jù)庫拉取任務(wù)也算）

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

如果應(yīng)用非常復(fù)雜，可以采用微服務(wù)模式。微服務(wù)應(yīng)用是由很多小且獨(dú)立的服務(wù)組合而成，每個(gè)服務(wù)都獨(dú)立實(shí)現(xiàn)一套完整的業(yè)務(wù)能力。服務(wù)的關(guān)系非常松散，僅通過API進(jìn)行通信。

每個(gè)服務(wù)都可以由一個(gè)獨(dú)立的研發(fā)團(tuán)隊(duì)進(jìn)行開發(fā)，理論上也可以單獨(dú)部署，不用和其他團(tuán)隊(duì)進(jìn)行太多的協(xié)同。因此，微服務(wù)架構(gòu)非常鼓勵(lì)頻繁的更新。一個(gè)微服務(wù)架構(gòu)可以非常復(fù)雜，它可以由多個(gè)分層架構(gòu)應(yīng)用和任務(wù)調(diào)度架構(gòu)應(yīng)用組合而成。

由于服務(wù)非常多，DevOps的重要性就凸顯出來了。如果操作正確的話，這種架構(gòu)可支持高度靈活的發(fā)布節(jié)奏、更快的創(chuàng)新和高度的彈性及擴(kuò)展性。

目前大型互聯(lián)網(wǎng)公司普遍采用微服務(wù)架構(gòu)，處理用戶側(cè)發(fā)起的short-lived請(qǐng)求，以支撐超高的QPS。

事件驅(qū)動(dòng)架構(gòu)

事件驅(qū)動(dòng)架構(gòu)采用了訂閱-發(fā)布模型，也叫生產(chǎn)者-消費(fèi)者模型。生產(chǎn)者負(fù)責(zé)發(fā)布事件到消息隊(duì)列，消費(fèi)者訂閱消息隊(duì)列。生產(chǎn)者和消費(fèi)者互相獨(dú)立，多個(gè)消費(fèi)者之間也互相獨(dú)立。

依賴的中間件有 Kafka、RocketMQ、Redis Pub/Sub 等。

事件驅(qū)動(dòng)架構(gòu)下，應(yīng)用程序可以以非常低的延遲處理大量的數(shù)據(jù)，在數(shù)據(jù)采集分析場(chǎng)景下使用非常廣泛。比如IoT場(chǎng)景、大型互聯(lián)網(wǎng)應(yīng)用的數(shù)據(jù)收集子系統(tǒng)（日志/埋點(diǎn)數(shù)據(jù)回收）。

大數(shù)據(jù)、大計(jì)算

大數(shù)據(jù)是目前互聯(lián)網(wǎng)的標(biāo)配場(chǎng)景，它的第一步一般是流式地搜集應(yīng)用日志，清洗后存到分布式存儲(chǔ)中，應(yīng)用到離線場(chǎng)景，或分發(fā)到消息隊(duì)列，用于流式處理。這一點(diǎn)與事件驅(qū)動(dòng)架構(gòu)有部分重疊。

當(dāng)我們聊大數(shù)據(jù)是，通常是說對(duì)一個(gè)超大數(shù)據(jù)集進(jìn)行分片/區(qū)，執(zhí)行并行計(jì)算，最終產(chǎn)出分析和報(bào)表。數(shù)據(jù)集大小可能是PB級(jí)。

大計(jì)算，也叫高性能計(jì)算(HPC)，可以在上千核的CPU上并行計(jì)算。除了我們熟悉的大數(shù)據(jù)場(chǎng)景，也應(yīng)用在圖形渲染、流體動(dòng)力學(xué)、金融風(fēng)險(xiǎn)建模、石油勘探、藥物設(shè)計(jì)等領(lǐng)域。

不同架構(gòu)模式的局限

任何架構(gòu)在設(shè)計(jì)上都有受到一些限制，比如架構(gòu)基本元素的形態(tài)，以及元素之間允許存在的關(guān)系。這些限制本質(zhì)上是在某種架構(gòu)下，我們可選的最大集合，它影響甚至間接塑造了架構(gòu)的最終形態(tài)。當(dāng)應(yīng)用的構(gòu)建遵循某種架構(gòu)模式時(shí)，一些好的符合預(yù)期的特性也會(huì)出現(xiàn)。

上面這段話有點(diǎn)抽象，我們以微服務(wù)架構(gòu)的限制為例：

每個(gè)服務(wù)承擔(dān)獨(dú)立單一的職責(zé)服務(wù)之間相互獨(dú)立數(shù)據(jù)只歸屬于擁有它的服務(wù)，服務(wù)之間不共享數(shù)據(jù)的所有權(quán)

遵循這些限制之后，系統(tǒng)中的服務(wù)就可以獨(dú)立進(jìn)行部署。收益時(shí)事故隔離、支持頻繁更新、可便捷地引入新技術(shù)。

在選擇某種架構(gòu)模式之前，我們需要理解架構(gòu)的底層原則和限制。否則，架構(gòu)設(shè)計(jì)只在最表層符合某種架構(gòu)模式，但無法發(fā)揮這種架構(gòu)模式的潛力。在使用架構(gòu)過程中，務(wù)實(shí)很重要，有時(shí)候我們可能要放寬一些限制，而不是堅(jiān)持架構(gòu)的純粹。

下面這張表總結(jié)了不同的架構(gòu)模式如何管理依賴，以及適用的業(yè)務(wù)領(lǐng)域

架構(gòu)模式	依賴管理	適用業(yè)務(wù)場(chǎng)景
分層架構(gòu)	按照子網(wǎng)進(jìn)行水平分層	傳統(tǒng)業(yè)務(wù)領(lǐng)域，更新頻率不高
Web-queue-worker	前后端任務(wù)分離，通過異步消息進(jìn)行解耦	相對(duì)簡單的業(yè)務(wù)場(chǎng)景，需要執(zhí)行一些資源密集型任務(wù)
微服務(wù)架構(gòu)	功能/垂直節(jié)藕的服務(wù)，通過API調(diào)用進(jìn)行通信	比較復(fù)雜的業(yè)務(wù)場(chǎng)景，支持高頻率的更新
事件驅(qū)動(dòng)架構(gòu)	生產(chǎn)者/消費(fèi)者，每個(gè)子系統(tǒng)有獨(dú)立的數(shù)據(jù)視圖	IoT和實(shí)時(shí)系統(tǒng)
大數(shù)據(jù)架構(gòu)	將一個(gè)超大數(shù)據(jù)集拆分成小的數(shù)據(jù)塊，在之上進(jìn)行并行計(jì)算	批處理和流式處理的數(shù)據(jù)分析，機(jī)器學(xué)習(xí)模型支持的預(yù)測(cè)分析
大計(jì)算架構(gòu)（高性能計(jì)算）	數(shù)據(jù)被分配到上千核CPU上進(jìn)行計(jì)算	計(jì)算密集型的場(chǎng)景，比如模擬系統(tǒng)

不同架構(gòu)模式面臨的挑戰(zhàn)vs收益

架構(gòu)的限制使其在某些場(chǎng)景下面臨一些挑戰(zhàn)，所以在采用這些架構(gòu)模式時(shí)，需要理解其中的利弊權(quán)衡。我們需要保證，在我們所在的子領(lǐng)域（場(chǎng)景），疊加場(chǎng)景的限制條件下，架構(gòu)帶來的收益超過要面臨的挑戰(zhàn)。

下面列出了在選擇架構(gòu)模式時(shí)面臨的四類挑戰(zhàn)：

復(fù)雜性。架構(gòu)的復(fù)雜性是否匹配我們所在的業(yè)務(wù)領(lǐng)域？換句話說，架構(gòu)模式在處理這個(gè)業(yè)務(wù)領(lǐng)域時(shí)是否太簡單，以至于無法處理將來的情況？如果是，那么未來系統(tǒng)會(huì)演變成一堆屎山，因?yàn)榧軜?gòu)無法幫你梳理清楚依賴關(guān)系。異步消息和最終一致性。異步消息可以幫助我們解耦服務(wù)，增加系統(tǒng)穩(wěn)定性和擴(kuò)展性。但是在最終一致性上可能會(huì)有問題，比如重復(fù)消息、亂序消息。服務(wù)間通信。把應(yīng)用拆分成多個(gè)獨(dú)立的服務(wù)之后，服務(wù)間的通信延遲可能成為一個(gè)風(fēng)險(xiǎn)，在數(shù)據(jù)量快速增長的情況下尤為明顯。比如在微服務(wù)架構(gòu)下面臨的問題可能有，接口延遲過高，或者網(wǎng)絡(luò)擁塞。可管理性。管理應(yīng)用的難度如何，包括監(jiān)控、部署、更新等等？

關(guān)鍵詞：