微服務(wù)不僅僅是一個學術(shù)話題。它來自于運行大規(guī)模分布式應(yīng)用程序的挑戰(zhàn)，通過云本地技術(shù)的最新進展來啟用。快速、有效、持續(xù)交付軟件的能力，因為文化遷移，已經(jīng)成為開發(fā)者、運維者、架構(gòu)師之間的熱門話題，并在企業(yè)里被廣泛接受。技術(shù)格局的日新月異使得它不僅值得期待，也變得更具有競爭力。
單單只有文化遷移是不足以帶來實際影響的。所以開始了這條路的組織都必須審視它對于內(nèi)部工作過程和系統(tǒng)到底意味著什么？處理不可變基礎(chǔ)設(shè)施和大規(guī)模可編排的服務(wù)意味著需要在運維方面的投入。容器及其周邊工具通過獨立的、可移植的、持續(xù)的工作流和運行時提供了構(gòu)建塊，與此同時，它的含義也不只是簡單的“Build，Ship，Run”。
社區(qū)對于微服務(wù)的特性已相當一致——一種松耦合、可以被獨立開發(fā)和部署同時保留了獨立擴展、可升級和可替換的去狀態(tài)化服務(wù)。它是對Unix設(shè)計哲學的最佳實踐——做一件事，并把它做好，并且當然，容器化所有的事情。通往微服務(wù)的道路始于將一個應(yīng)用依照微服務(wù)的特性“打碎”為多個可以被解耦的組件。
然而，常常被對話遺漏的是在實際生產(chǎn)環(huán)境里的表現(xiàn)。每個獨立的微服務(wù)從它被遷移開始具有了”生命”，帶來了全新的運維復雜度。除了任何試圖將微服務(wù)一般化為獨立的表現(xiàn)模式，也沒有“一體適用”的方法來處理這么多遷移的部分。基于此，我這里想要完成的是一種用于區(qū)分不同特色微服務(wù)的基本框架：實時請求["應(yīng)用中心"]和背景過程["任務(wù)中心"]
這里主要的區(qū)別是——同步和異步。除了是一種簡單的通信方式，這一個字母的不同帶來的分別是工作負載在遷移后的表現(xiàn)。用來審視你自己的工作負載的基本問題很簡單：“我是否需要即時響應(yīng)？”如果是，那就是“應(yīng)用中心”，如果不是，則是“任務(wù)中心”。一旦建立了這樣的基準，有大量貫穿了微服務(wù)整個生命周期的對照方法來管理每個微服務(wù)。
我們構(gòu)建微服務(wù)是為了它們的生產(chǎn)運行時，通常通過一個CI/CD管道來保證一致性。一個容器鏡像是一個用于部署的可移植單元，但是通過Dockerfile創(chuàng)建環(huán)境的時候，設(shè)置時有“準備請求”和“準備執(zhí)行”這樣一個關(guān)鍵區(qū)別。
“應(yīng)用中心”微服務(wù)被推到一個階段性運行時，在這里它們已經(jīng)準備好接收來自客戶端的請求了。設(shè)置環(huán)境意味著“拉”鏡像層、導入任何外部依賴、運行京城和暴露一個端口來接收到來的請求。這與通過buildpack來部署應(yīng)用非常相似，但通過Docker我們可以擁有更細粒度的彈性和控制。
“任務(wù)中心”微服務(wù)被上傳到鏡像倉庫，這里它們等待一個事件觸發(fā)執(zhí)行。這意味著容器按需求被啟動，所以它的最佳實踐是通過最小基礎(chǔ)鏡像層來維持最小啟動時間，并且在可應(yīng)用處合并操作。依賴于所用的語言，推薦采用現(xiàn)有的供應(yīng)商的依賴，這樣在調(diào)用的時候就沒有額外的啟動時間了。
小貼士：考慮使用Alpine Linux作為Docker鏡像的基礎(chǔ)層。它是仍然提供對于外部依賴的包管理的極其輕量的發(fā)行版。
因為模塊化和分布式組成，一個良好定義的API對于微服務(wù)架構(gòu)是至關(guān)重要的。這些都高于好的文檔、邏輯資源命名和語義版本。理解終端的觸發(fā)、工作負載的初始化方式也是至關(guān)重要的。
“應(yīng)用中心”微服務(wù)由同步的請求/響應(yīng)模型實現(xiàn)。API終端會通常經(jīng)過純HTTP協(xié)議而被客戶端直接調(diào)用。因為期望得到實時響應(yīng)，因此最好使用端對端通信方式。作為分布式系統(tǒng)，延遲因素和潛在的不可達終端是非常重要的。
“任務(wù)中心”微服務(wù)模型由事件驅(qū)動模型實現(xiàn)，比如當一個動作會自動觸發(fā)了異步工作流。事件可能以各種形式到來，擁有廣闊的來源，例如調(diào)度、網(wǎng)絡(luò)鉤子、回調(diào)、消息機制、傳感器或者直接API調(diào)用。因為它的異步本質(zhì)，在消息隊列里的任務(wù)將保持請求直到它可以被執(zhí)行。
小貼士：考慮使用API網(wǎng)關(guān)作為所有添加特性請求的單入口點，例如監(jiān)控、鑒權(quán)、安全以及限流等。
保證容器化微服務(wù)可以正確地分布在大量動態(tài)主機上使用了大量的策略。底層系統(tǒng)必須足夠智能以在可用容器組里按需調(diào)度工作負載而無需聲明或過度使用資源。
“應(yīng)用中心”微服務(wù)以運行的容器實現(xiàn)分布式。這意味著當一個請求到來時，系統(tǒng)需要知道容器進程處于哪里（IP地址和端口），所有它可以直接路由。這樣的整個生態(tài)系統(tǒng)被服務(wù)注冊和容器編排所圍繞，所以為任務(wù)挑選正確的工具經(jīng)常轉(zhuǎn)變?yōu)槟阆胍橄蟮某潭群涂刂频亩嗌佟?/span>
“任務(wù)中心”微服務(wù)按隊列優(yōu)先進行執(zhí)行，意味著編排問題并不是“服務(wù)在哪里”而是“我在哪里可以運行服務(wù)”。運行任務(wù)的工作節(jié)點注冊在系統(tǒng)，并可從隊列獲取。這意味著系統(tǒng)需要了解整個池的可用容量，所有它會啟動一個邊界內(nèi)的新容器來執(zhí)行這個進程。
小貼士：描繪出每個微服務(wù)的最優(yōu)計算環(huán)境將有助于有效地分配資源。例如內(nèi)存和/或CPU敏感的工作負載需要運行在更強力的硬件上。
微服務(wù)的一個關(guān)鍵好處是能夠最大化利用你的基礎(chǔ)設(shè)施資源，但曾經(jīng)維護一些形式的分布式系統(tǒng)的任何人都了解“運行”和“大規(guī)模運行”的區(qū)別不僅僅表現(xiàn)在容量上。
“應(yīng)用中心”微服務(wù)是持續(xù)運行在一個共享資源池的容器進。擴展由流量驅(qū)動，并據(jù)此啟動或關(guān)閉容器。為了操作容量，需要在前端部署負載均衡器，將請求分發(fā)至每個可用的節(jié)點。
“任務(wù)中心”微服務(wù)執(zhí)行和結(jié)束，僅需要一個進程計算環(huán)境。擴展是并發(fā)驅(qū)動的，啟動n個容器取決于給定時間內(nèi)需要運行多少進程。相比可用容器，在有更多的任務(wù)需要運行的場景里，隊列的表現(xiàn)類似緩沖。
小貼士：可采用基于已知或未知量的預測式和響應(yīng)式伸縮技術(shù)。為“應(yīng)用中心”微服務(wù)使用流量度量（流量、速率），為“任務(wù)中心”微服務(wù)使用隊列度量（大小、速率）。
可視性是使某件事情變?yōu)槠髽I(yè)級的顯著特點之一。對于微服務(wù)，它有更多需要追蹤的內(nèi)容，例如位置、主機、環(huán)境、來源和終端等。一個適應(yīng)性好的系統(tǒng)可以對不同的錯誤做出不同的響應(yīng)。
“應(yīng)用中心”微服務(wù)是被實時請求調(diào)用的“活”進程。當一個終端不可達，系統(tǒng)需要能夠故障轉(zhuǎn)移到另一個運行的實例，這樣請求就不會丟失。容器進程可以被實時監(jiān)控，并采用合適的報警技術(shù)。
“任務(wù)中心”微服務(wù)會發(fā)生同樣的錯誤，然而，跟上面的區(qū)別是任務(wù)狀態(tài)將保留在隊列里直至完成。這表示當錯誤發(fā)生時任務(wù)可以被自動或手動取回。由于工作負載的異步本質(zhì)，監(jiān)控更多面向日志，所以開發(fā)者可以回看發(fā)生了什么。
小貼士：為了隔離錯誤，需要確認監(jiān)控、日志、報警和報告在都獨立的微服務(wù)層完成，并且進行采集以擁有對整個系統(tǒng)的實時可視性。
理解這些表現(xiàn)模式使你可以做出關(guān)于如何在高可擴展生產(chǎn)環(huán)境中管理多種工作負載類型的更專業(yè)的決定。通過微服務(wù)，DevOps的角色變得越來越重要，“基礎(chǔ)設(shè)施及代碼”亦如此。
與聽到的相反，DevOps的“圣杯”不是NoOps。而是使運維變成一種無需特定技術(shù)集來在任何環(huán)境里大規(guī)模運行代碼、一種開發(fā)過程的擴展行為。云基礎(chǔ)設(shè)施服務(wù)的持續(xù)革新和開發(fā)平臺正在使這種“無服務(wù)器”狀態(tài)成為可能，熟知每種工作負載在真實世界里如何表現(xiàn)使開發(fā)者可以自信地構(gòu)建和部署分布式應(yīng)用。
文章轉(zhuǎn)載請保留網(wǎng)址：http://waterplane.cn/news/industry/1682.html
