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

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

單單只有文化遷移是不足以帶來實際影響的。所以開始了這條路的組織都必須審視它對于內部工作過程和系統到底意味著什么？處理不可變基礎設施和大規?？删幣诺姆找馕吨枰谶\維方面的投入。容器及其周邊工具通過獨立的、可移植的、持續的工作流和運行時提供了構建塊，與此同時，它的含義也不只是簡單的“Build，Ship，Run”。

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

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

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

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

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

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

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

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

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

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

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

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

“應用中心”微服務以運行的容器實現分布式。這意味著當一個請求到來時，系統需要知道容器進程處于哪里（IP地址和端口），所有它可以直接路由。這樣的整個生態系統被服務注冊和容器編排所圍繞，所以為任務挑選正確的工具經常轉變為你想要抽象的程度和控制的多少。

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

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

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

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

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

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

可視性是使某件事情變為企業級的顯著特點之一。對于微服務，它有更多需要追蹤的內容，例如位置、主機、環境、來源和終端等。一個適應性好的系統可以對不同的錯誤做出不同的響應。

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

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

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

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

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