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