微服務的兩種模式：應用中心和任務中心

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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