微服務(wù)的兩種模式：應(yīng)用中心和任務(wù)中心

微服務(wù)不僅僅是一個學(xué)術(shù)話題。它來自于運(yùn)行大規(guī)模分布式應(yīng)用程序的挑戰(zhàn)，通過云本地技術(shù)的最新進(jìn)展來啟用。快速、有效、持續(xù)交付軟件的能力，因?yàn)槲幕w移，已經(jīng)成為開發(fā)者、運(yùn)維者、架構(gòu)師之間的熱門話題，并在企業(yè)里被廣泛接受。技術(shù)格局的日新月異使得它不僅值得期待，也變得更具有競爭力。

單單只有文化遷移是不足以帶來實(shí)際影響的。所以開始了這條路的組織都必須審視它對于內(nèi)部工作過程和系統(tǒng)到底意味著什么？處理不可變基礎(chǔ)設(shè)施和大規(guī)模可編排的服務(wù)意味著需要在運(yùn)維方面的投入。容器及其周邊工具通過獨(dú)立的、可移植的、持續(xù)的工作流和運(yùn)行時(shí)提供了構(gòu)建塊，與此同時(shí)，它的含義也不只是簡單的“Build，Ship，Run”。

社區(qū)對于微服務(wù)的特性已相當(dāng)一致——一種松耦合、可以被獨(dú)立開發(fā)和部署同時(shí)保留了獨(dú)立擴(kuò)展、可升級和可替換的去狀態(tài)化服務(wù)。它是對Unix設(shè)計(jì)哲學(xué)的最佳實(shí)踐——做一件事，并把它做好，并且當(dāng)然，容器化所有的事情。通往微服務(wù)的道路始于將一個應(yīng)用依照微服務(wù)的特性“打碎”為多個可以被解耦的組件。

然而，常常被對話遺漏的是在實(shí)際生產(chǎn)環(huán)境里的表現(xiàn)。每個獨(dú)立的微服務(wù)從它被遷移開始具有了”生命”，帶來了全新的運(yùn)維復(fù)雜度。除了任何試圖將微服務(wù)一般化為獨(dú)立的表現(xiàn)模式，也沒有“一體適用”的方法來處理這么多遷移的部分。基于此，我這里想要完成的是一種用于區(qū)分不同特色微服務(wù)的基本框架：實(shí)時(shí)請求["應(yīng)用中心"]和背景過程["任務(wù)中心"]

這里主要的區(qū)別是——同步和異步。除了是一種簡單的通信方式，這一個字母的不同帶來的分別是工作負(fù)載在遷移后的表現(xiàn)。用來審視你自己的工作負(fù)載的基本問題很簡單：“我是否需要即時(shí)響應(yīng)？”如果是，那就是“應(yīng)用中心”，如果不是，則是“任務(wù)中心”。一旦建立了這樣的基準(zhǔn)，有大量貫穿了微服務(wù)整個生命周期的對照方法來管理每個微服務(wù)。

我們構(gòu)建微服務(wù)是為了它們的生產(chǎn)運(yùn)行時(shí)，通常通過一個CI/CD管道來保證一致性。一個容器鏡像是一個用于部署的可移植單元，但是通過Dockerfile創(chuàng)建環(huán)境的時(shí)候，設(shè)置時(shí)有“準(zhǔn)備請求”和“準(zhǔn)備執(zhí)行”這樣一個關(guān)鍵區(qū)別。

“應(yīng)用中心”微服務(wù)被推到一個階段性運(yùn)行時(shí)，在這里它們已經(jīng)準(zhǔn)備好接收來自客戶端的請求了。設(shè)置環(huán)境意味著“拉”鏡像層、導(dǎo)入任何外部依賴、運(yùn)行京城和暴露一個端口來接收到來的請求。這與通過buildpack來部署應(yīng)用非常相似，但通過Docker我們可以擁有更細(xì)粒度的彈性和控制。

“任務(wù)中心”微服務(wù)被上傳到鏡像倉庫，這里它們等待一個事件觸發(fā)執(zhí)行。這意味著容器按需求被啟動，所以它的最佳實(shí)踐是通過最小基礎(chǔ)鏡像層來維持最小啟動時(shí)間，并且在可應(yīng)用處合并操作。依賴于所用的語言，推薦采用現(xiàn)有的供應(yīng)商的依賴，這樣在調(diào)用的時(shí)候就沒有額外的啟動時(shí)間了。

小貼士：考慮使用Alpine Linux作為Docker鏡像的基礎(chǔ)層。它是仍然提供對于外部依賴的包管理的極其輕量的發(fā)行版。

因?yàn)槟K化和分布式組成，一個良好定義的API對于微服務(wù)架構(gòu)是至關(guān)重要的。這些都高于好的文檔、邏輯資源命名和語義版本。理解終端的觸發(fā)、工作負(fù)載的初始化方式也是至關(guān)重要的。

“應(yīng)用中心”微服務(wù)由同步的請求/響應(yīng)模型實(shí)現(xiàn)。API終端會通常經(jīng)過純HTTP協(xié)議而被客戶端直接調(diào)用。因?yàn)槠谕玫綄?shí)時(shí)響應(yīng)，因此最好使用端對端通信方式。作為分布式系統(tǒng)，延遲因素和潛在的不可達(dá)終端是非常重要的。

“任務(wù)中心”微服務(wù)模型由事件驅(qū)動模型實(shí)現(xiàn)，比如當(dāng)一個動作會自動觸發(fā)了異步工作流。事件可能以各種形式到來，擁有廣闊的來源，例如調(diào)度、網(wǎng)絡(luò)鉤子、回調(diào)、消息機(jī)制、傳感器或者直接API調(diào)用。因?yàn)樗漠惒奖举|(zhì)，在消息隊(duì)列里的任務(wù)將保持請求直到它可以被執(zhí)行。

小貼士：考慮使用API網(wǎng)關(guān)作為所有添加特性請求的單入口點(diǎn)，例如監(jiān)控、鑒權(quán)、安全以及限流等。

保證容器化微服務(wù)可以正確地分布在大量動態(tài)主機(jī)上使用了大量的策略。底層系統(tǒng)必須足夠智能以在可用容器組里按需調(diào)度工作負(fù)載而無需聲明或過度使用資源。

“應(yīng)用中心”微服務(wù)以運(yùn)行的容器實(shí)現(xiàn)分布式。這意味著當(dāng)一個請求到來時(shí)，系統(tǒng)需要知道容器進(jìn)程處于哪里（IP地址和端口），所有它可以直接路由。這樣的整個生態(tài)系統(tǒng)被服務(wù)注冊和容器編排所圍繞，所以為任務(wù)挑選正確的工具經(jīng)常轉(zhuǎn)變?yōu)槟阆胍橄蟮某潭群涂刂频亩嗌佟?/span>

“任務(wù)中心”微服務(wù)按隊(duì)列優(yōu)先進(jìn)行執(zhí)行，意味著編排問題并不是“服務(wù)在哪里”而是“我在哪里可以運(yùn)行服務(wù)”。運(yùn)行任務(wù)的工作節(jié)點(diǎn)注冊在系統(tǒng)，并可從隊(duì)列獲取。這意味著系統(tǒng)需要了解整個池的可用容量，所有它會啟動一個邊界內(nèi)的新容器來執(zhí)行這個進(jìn)程。

小貼士：描繪出每個微服務(wù)的最優(yōu)計(jì)算環(huán)境將有助于有效地分配資源。例如內(nèi)存和/或CPU敏感的工作負(fù)載需要運(yùn)行在更強(qiáng)力的硬件上。

微服務(wù)的一個關(guān)鍵好處是能夠最大化利用你的基礎(chǔ)設(shè)施資源，但曾經(jīng)維護(hù)一些形式的分布式系統(tǒng)的任何人都了解“運(yùn)行”和“大規(guī)模運(yùn)行”的區(qū)別不僅僅表現(xiàn)在容量上。

“應(yīng)用中心”微服務(wù)是持續(xù)運(yùn)行在一個共享資源池的容器進(jìn)。擴(kuò)展由流量驅(qū)動，并據(jù)此啟動或關(guān)閉容器。為了操作容量，需要在前端部署負(fù)載均衡器，將請求分發(fā)至每個可用的節(jié)點(diǎn)。

“任務(wù)中心”微服務(wù)執(zhí)行和結(jié)束，僅需要一個進(jìn)程計(jì)算環(huán)境。擴(kuò)展是并發(fā)驅(qū)動的，啟動n個容器取決于給定時(shí)間內(nèi)需要運(yùn)行多少進(jìn)程。相比可用容器，在有更多的任務(wù)需要運(yùn)行的場景里，隊(duì)列的表現(xiàn)類似緩沖。

小貼士：可采用基于已知或未知量的預(yù)測式和響應(yīng)式伸縮技術(shù)。為“應(yīng)用中心”微服務(wù)使用流量度量（流量、速率），為“任務(wù)中心”微服務(wù)使用隊(duì)列度量（大小、速率）。

可視性是使某件事情變?yōu)槠髽I(yè)級的顯著特點(diǎn)之一。對于微服務(wù)，它有更多需要追蹤的內(nèi)容，例如位置、主機(jī)、環(huán)境、來源和終端等。一個適應(yīng)性好的系統(tǒng)可以對不同的錯誤做出不同的響應(yīng)。

“應(yīng)用中心”微服務(wù)是被實(shí)時(shí)請求調(diào)用的“活”進(jìn)程。當(dāng)一個終端不可達(dá)，系統(tǒng)需要能夠故障轉(zhuǎn)移到另一個運(yùn)行的實(shí)例，這樣請求就不會丟失。容器進(jìn)程可以被實(shí)時(shí)監(jiān)控，并采用合適的報(bào)警技術(shù)。

“任務(wù)中心”微服務(wù)會發(fā)生同樣的錯誤，然而，跟上面的區(qū)別是任務(wù)狀態(tài)將保留在隊(duì)列里直至完成。這表示當(dāng)錯誤發(fā)生時(shí)任務(wù)可以被自動或手動取回。由于工作負(fù)載的異步本質(zhì)，監(jiān)控更多面向日志，所以開發(fā)者可以回看發(fā)生了什么。

小貼士：為了隔離錯誤，需要確認(rèn)監(jiān)控、日志、報(bào)警和報(bào)告在都獨(dú)立的微服務(wù)層完成，并且進(jìn)行采集以擁有對整個系統(tǒng)的實(shí)時(shí)可視性。

理解這些表現(xiàn)模式使你可以做出關(guān)于如何在高可擴(kuò)展生產(chǎn)環(huán)境中管理多種工作負(fù)載類型的更專業(yè)的決定。通過微服務(wù)，DevOps的角色變得越來越重要，“基礎(chǔ)設(shè)施及代碼”亦如此。

與聽到的相反，DevOps的“圣杯”不是NoOps。而是使運(yùn)維變成一種無需特定技術(shù)集來在任何環(huán)境里大規(guī)模運(yùn)行代碼、一種開發(fā)過程的擴(kuò)展行為。云基礎(chǔ)設(shè)施服務(wù)的持續(xù)革新和開發(fā)平臺正在使這種“無服務(wù)器”狀態(tài)成為可能，熟知每種工作負(fù)載在真實(shí)世界里如何表現(xiàn)使開發(fā)者可以自信地構(gòu)建和部署分布式應(yīng)用。