建站
咨詢
售后
建站咨詢
新聞中心
我們?nèi)粘Ｉ钪惺褂煤芏鄳?yīng)用程序，有微信、抖音、王者這種涉及多人聯(lián)網(wǎ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。
在林州等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強(qiáng)發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供成都網(wǎng)站設(shè)計、成都網(wǎng)站制作、外貿(mào)網(wǎng)站建設(shè) 網(wǎng)站設(shè)計制作按需求定制設(shè)計,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),成都品牌網(wǎng)站建設(shè),成都全網(wǎng)營銷推廣,成都外貿(mào)網(wǎng)站建設(shè),林州網(wǎng)站建設(shè)費(fèi)用合理。
從普通用戶視角跳出來，切換到程序員視角，應(yīng)用程序可以理解為是M個Client和N個Server的組合。在軟件開發(fā)過程中，Client/Server的邊界如何劃分，Server之間如何通信，多個Server如何組織能夠保證整個系統(tǒng)按照預(yù)期的方式運(yùn)行，都是服務(wù)架構(gòu)要考慮的問題。
下面我們簡單串一下主流的幾個服務(wù)架構(gòu)，包括分層架構(gòu)、client-queue-worker架構(gòu)、微服務(wù)架構(gòu)、事件驅(qū)動架構(gòu)、大數(shù)據(jù)、大計算架構(gòu)，并從四個方面對每個架構(gòu)進(jìn)行總結(jié)：
- 架構(gòu)的描述和架構(gòu)圖
- 推薦的使用場景
- 優(yōu)點(diǎn)、潛在問題和最佳實踐
- 一些現(xiàn)實場景中的示例
分層架構(gòu)
WAF全稱Web Application Firewall，就是防火墻
在開發(fā)傳統(tǒng)企業(yè)應(yīng)用中，分層架構(gòu)得到了廣泛使用。一個應(yīng)用被劃分為多個邏輯功能的層，比如展示層、業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層。這些分層同時也定義了依賴關(guān)系，每個層都只能調(diào)用它下面的層。每個層可以是一個獨(dú)立的模塊，整個系統(tǒng)的各個模塊可以獨(dú)立甚至并行開發(fā)和測試，交付質(zhì)量可以得到比較好地保證，所以這是目前最為廣泛使用的架構(gòu)之一。但它也有一些難以解決的問題，尤其體現(xiàn)在產(chǎn)品上線后的變更上。體現(xiàn)在：
- 在大型系統(tǒng)中，層的劃分邏輯并不那么明顯，可能出現(xiàn)過度分層的問題
- 分層往往是從技術(shù)角度做的，沒有按照業(yè)務(wù)領(lǐng)域進(jìn)行，導(dǎo)致系統(tǒng)對業(yè)務(wù)擴(kuò)展不友好
- 分層以后，跨層通信比較困難，對性能敏感的業(yè)務(wù)無法接受由此帶來的網(wǎng)絡(luò)通信開銷和編解碼開銷
- 迭代困難，因為需要所有層的變更，協(xié)調(diào)多個團(tuán)隊的成本非常高
分層架構(gòu)在私有云系統(tǒng)中非常常見，比如一個私有云的解決方案可以設(shè)計為：
- 物理機(jī)層：物理機(jī)、網(wǎng)絡(luò)設(shè)備等
- 虛擬化層：將物理資源進(jìn)行虛擬化，可以用kvm
- 資源管理層：對資源進(jìn)行調(diào)度編排，也提供故障恢復(fù)、彈性擴(kuò)容等功能，比如k8s
- 服務(wù)編排層：定義和管理服務(wù)的部署、配置和自動化，通常是k8s上做二次開發(fā)出的一層殼
- 用戶展示層：通常是web界面、命令行，也可以是API
任務(wù)調(diào)度架構(gòu) Web-Queue-Worker
這個架構(gòu)下，用戶通過前端Web頁面將任務(wù)異步發(fā)送到后端，協(xié)議可以是HTTP或RPC。通常情況下，后端的worker接收任務(wù)后，執(zhí)行一段事件CPU密集型計算，生成結(jié)果。
作為對比，分層架構(gòu)中來自client的請求大都同步到達(dá)，請求可以很快得到滿足，server端處理完成后同步返回；相反，任務(wù)調(diào)度架構(gòu)下，每個請求要得到滿足，可能耗費(fèi)server大量的計算/網(wǎng)絡(luò)或存儲資源，所以異步返回。
在通信方式上，任務(wù)調(diào)度架構(gòu)更多地采用類似于隊列的方式（不一定真的有一個消息隊列，從數(shù)據(jù)庫拉取任務(wù)也算）
微服務(wù)架構(gòu)
如果應(yīng)用非常復(fù)雜，可以采用微服務(wù)模式。微服務(wù)應(yīng)用是由很多小且獨(dú)立的服務(wù)組合而成，每個服務(wù)都獨(dú)立實現(xiàn)一套完整的業(yè)務(wù)能力。服務(wù)的關(guān)系非常松散，僅通過API進(jìn)行通信。
每個服務(wù)都可以由一個獨(dú)立的研發(fā)團(tuán)隊進(jìn)行開發(fā)，理論上也可以單獨(dú)部署，不用和其他團(tuán)隊進(jìn)行太多的協(xié)同。因此，微服務(wù)架構(gòu)非常鼓勵頻繁的更新。一個微服務(wù)架構(gòu)可以非常復(fù)雜，它可以由多個分層架構(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請求，以支撐超高的QPS。
事件驅(qū)動架構(gòu)
事件驅(qū)動架構(gòu)采用了訂閱-發(fā)布模型，也叫生產(chǎn)者-消費(fèi)者模型。生產(chǎn)者負(fù)責(zé)發(fā)布事件到消息隊列，消費(fèi)者訂閱消息隊列。生產(chǎn)者和消費(fèi)者互相獨(dú)立，多個消費(fèi)者之間也互相獨(dú)立。
依賴的中間件有 Kafka、RocketMQ、Redis Pub/Sub 等。
事件驅(qū)動架構(gòu)下，應(yīng)用程序可以以非常低的延遲處理大量的數(shù)據(jù)，在數(shù)據(jù)采集分析場景下使用非常廣泛。比如IoT場景、大型互聯(lián)網(wǎng)應(yīng)用的數(shù)據(jù)收集子系統(tǒng)（日志/埋點(diǎn)數(shù)據(jù)回收）。
大數(shù)據(jù)、大計算
大數(shù)據(jù)是目前互聯(lián)網(wǎng)的標(biāo)配場景，它的第一步一般是流式地搜集應(yīng)用日志，清洗后存到分布式存儲中，應(yīng)用到離線場景，或分發(fā)到消息隊列，用于流式處理。這一點(diǎn)與事件驅(qū)動架構(gòu)有部分重疊。
當(dāng)我們聊大數(shù)據(jù)是，通常是說對一個超大數(shù)據(jù)集進(jìn)行分片/區(qū)，執(zhí)行并行計算，最終產(chǎn)出分析和報表。數(shù)據(jù)集大小可能是PB級。
大計算，也叫高性能計算(HPC)，可以在上千核的CPU上并行計算。除了我們熟悉的大數(shù)據(jù)場景，也應(yīng)用在圖形渲染、流體動力學(xué)、金融風(fēng)險建模、石油勘探、藥物設(shè)計等領(lǐng)域。
不同架構(gòu)模式的局限
任何架構(gòu)在設(shè)計上都有受到一些限制，比如架構(gòu)基本元素的形態(tài)，以及元素之間允許存在的關(guān)系。這些限制本質(zhì)上是在某種架構(gòu)下，我們可選的最大集合，它影響甚至間接塑造了架構(gòu)的最終形態(tài)。當(dāng)應(yīng)用的構(gòu)建遵循某種架構(gòu)模式時，一些好的符合預(yù)期的特性也會出現(xiàn)。
上面這段話有點(diǎn)抽象，我們以微服務(wù)架構(gòu)的限制為例：
- 每個服務(wù)承擔(dān)獨(dú)立單一的職責(zé)
- 服務(wù)之間相互獨(dú)立
- 數(shù)據(jù)只歸屬于擁有它的服務(wù)，服務(wù)之間不共享數(shù)據(jù)的所有權(quán)
遵循這些限制之后，系統(tǒng)中的服務(wù)就可以獨(dú)立進(jìn)行部署。收益時事故隔離、支持頻繁更新、可便捷地引入新技術(shù)。
在選擇某種架構(gòu)模式之前，我們需要理解架構(gòu)的底層原則和限制。否則，架構(gòu)設(shè)計只在最表層符合某種架構(gòu)模式，但無法發(fā)揮這種架構(gòu)模式的潛力。在使用架構(gòu)過程中，務(wù)實很重要，有時候我們可能要放寬一些限制，而不是堅持架構(gòu)的純粹。
下面這張表總結(jié)了不同的架構(gòu)模式如何管理依賴，以及適用的業(yè)務(wù)領(lǐng)域
|
架構(gòu)模式 |
依賴管理 |
適用業(yè)務(wù)場景 |
|
分層架構(gòu) |
按照子網(wǎng)進(jìn)行水平分層 |
傳統(tǒng)業(yè)務(wù)領(lǐng)域，更新頻率不高 |
|
Web-queue-worker |
前后端任務(wù)分離，通過異步消息進(jìn)行解耦 |
相對簡單的業(yè)務(wù)場景，需要執(zhí)行一些資源密集型任務(wù) |
|
微服務(wù)架構(gòu) |
功能/垂直節(jié)藕的服務(wù)，通過API調(diào)用進(jìn)行通信 |
比較復(fù)雜的業(yè)務(wù)場景，支持高頻率的更新 |
|
事件驅(qū)動架構(gòu) |
生產(chǎn)者/消費(fèi)者，每個子系統(tǒng)有獨(dú)立的數(shù)據(jù)視圖 |
IoT和實時系統(tǒng) |
|
大數(shù)據(jù)架構(gòu) |
將一個超大數(shù)據(jù)集拆分成小的數(shù)據(jù)塊，在之上進(jìn)行并行計算 |
批處理和流式處理的數(shù)據(jù)分析，機(jī)器學(xué)習(xí)模型支持的預(yù)測分析 |
|
大計算架構(gòu)（高性能計算） |
數(shù)據(jù)被分配到上千核CPU上進(jìn)行計算 |
計算密集型的場景，比如模擬系統(tǒng) |
不同架構(gòu)模式面臨的挑戰(zhàn)vs收益
架構(gòu)的限制使其在某些場景下面臨一些挑戰(zhàn)，所以在采用這些架構(gòu)模式時，需要理解其中的利弊權(quán)衡。我們需要保證，在我們所在的子領(lǐng)域（場景），疊加場景的限制條件下，架構(gòu)帶來的收益超過要面臨的挑戰(zhàn)。
下面列出了在選擇架構(gòu)模式時面臨的四類挑戰(zhàn)：
- 復(fù)雜性。架構(gòu)的復(fù)雜性是否匹配我們所在的業(yè)務(wù)領(lǐng)域？換句話說，架構(gòu)模式在處理這個業(yè)務(wù)領(lǐng)域時是否太簡單，以至于無法處理將來的情況？如果是，那么未來系統(tǒng)會演變成一堆屎山，因為架構(gòu)無法幫你梳理清楚依賴關(guān)系。
- 異步消息和最終一致性。異步消息可以幫助我們解耦服務(wù)，增加系統(tǒng)穩(wěn)定性和擴(kuò)展性。但是在最終一致性上可能會有問題，比如重復(fù)消息、亂序消息。
- 服務(wù)間通信。把應(yīng)用拆分成多個獨(dú)立的服務(wù)之后，服務(wù)間的通信延遲可能成為一個風(fēng)險，在數(shù)據(jù)量快速增長的情況下尤為明顯。比如在微服務(wù)架構(gòu)下面臨的問題可能有，接口延遲過高，或者網(wǎng)絡(luò)擁塞。
- 可管理性。管理應(yīng)用的難度如何，包括監(jiān)控、部署、更新等等？
本文標(biāo)題：服務(wù)架構(gòu)簡介：你是否了解這些常用架構(gòu)？
鏈接分享：http://www.5511xx.com/article/cdcsisg.html
