如何有效提升團(tuán)隊(duì)的微服務(wù)落地能力？
微服務(wù)體系的發(fā)展并不是一蹴而就的，經(jīng)過了2014年前后的低潮期，微服務(wù)概念頂層的泡沫逐漸褪去，那些真正能夠在企業(yè)落地的實(shí)踐在一輪又一輪的大浪淘沙后被甄別、沉淀。這篇文章希望討論一些在團(tuán)隊(duì)中實(shí)行微服務(wù)架構(gòu)時值得考慮的『增值項(xiàng)目』，它們中的一些看起來已經(jīng)是理所應(yīng)當(dāng)?shù)模硪恍┧坪鹾臀⒎?wù)并沒有必然的關(guān)聯(lián)，但許多經(jīng)驗(yàn)?zāi)軌蜃C明這些項(xiàng)目都是保障微服務(wù)系統(tǒng)長期運(yùn)作并最大化發(fā)揮其Scale Out能力值得投入的高附加值實(shí)踐。
持續(xù)交付
對于微服務(wù)的成功實(shí)施，團(tuán)隊(duì)持續(xù)交付能力是至關(guān)重要的衡量指標(biāo)。在由上百個服務(wù)組成的復(fù)雜系統(tǒng)中，如果所有服務(wù)都按照人為指定發(fā)布周期進(jìn)行整體交付，很容易出現(xiàn)由于細(xì)小的失誤導(dǎo)致大面積線上故障。
持續(xù)交付實(shí)踐要求每個獨(dú)立服務(wù)都具有完備的交付流水線，在流水線的末端隨時能提供當(dāng)時最新的可工作、可交付的產(chǎn)品。持續(xù)交付通常會配合自動化的測試和部署手段，從而減少功能代碼提交到上線的端到端時間。這就使得每個獨(dú)立服務(wù)能按照各自不同的節(jié)奏進(jìn)行發(fā)布，并且將自己的發(fā)布狀態(tài)可視化出來。
采用盡可能精簡且穩(wěn)定的分支策略也是使得持續(xù)交付流程能夠順利實(shí)施的關(guān)鍵，我們提倡使用單主干的分支策略（Trunk Based Development）。在單主干的開發(fā)方式中，除了一個用于持續(xù)開發(fā)和集成的『主干分支』（通常即Master分支）和一系列依據(jù)發(fā)布周期創(chuàng)建的發(fā)布分支以外，應(yīng)該避免創(chuàng)建其他的Long-lived分支。如果有多個功能需要開發(fā)，則推薦采用特性開關(guān)（Feature Toggle）的方法來控制它們的發(fā)布時機(jī)。當(dāng)然，單主干策略是允許存在短生命周期特性分支的（短于一周），有時這些小分支甚至無需提交到遠(yuǎn)程倉庫中。下面這是一幅經(jīng)典的單主干分支策略示意圖。
值得指出的是，在劃分得當(dāng)?shù)奈⒎?wù)系統(tǒng)中，同一個服務(wù)需要同時進(jìn)行開發(fā)的特性通常不會多于兩到三個（否則應(yīng)該考慮這個服務(wù)是否承擔(dān)了過多的職責(zé)）。因此即使在不需要特性開關(guān)和其他額外開發(fā)工作量的情況下，已經(jīng)可以比較好的實(shí)現(xiàn)每個功能點(diǎn)的獨(dú)立發(fā)布和測試，這反向說明了微服務(wù)架構(gòu)對于持續(xù)交付的實(shí)施也是十分友好的。
除了嚴(yán)格的單主干，一種常見的變式是多主干策略，典型的是一個開發(fā)分支加幾個固定的發(fā)布分支，通常用于無需維護(hù)多個發(fā)布版本的SaaS服務(wù)交付。這種模式的優(yōu)點(diǎn)是能夠?qū)l(fā)布流水線目標(biāo)環(huán)境和分支顯示的關(guān)聯(lián)起來，例如『Develop分支』對應(yīng)集成環(huán)境，『Release分支』對應(yīng)驗(yàn)收環(huán)境和正式環(huán)境。下圖展示了一組與此模式下的持續(xù)交付流水線。
保持每個服務(wù)高頻率的集成和交付，會使得有故障的功能在很短的反饋周期內(nèi)被發(fā)現(xiàn)，在快速迭代發(fā)布的前提下做到整個系統(tǒng)發(fā)布井然有序。這樣的氛圍不僅有利于改善代碼的質(zhì)量，而且能夠提高開發(fā)士氣，頻繁的發(fā)布上線也有利于增強(qiáng)團(tuán)隊(duì)對產(chǎn)品的榮譽(yù)感和自信心。
全功能團(tuán)隊(duì)
全功能團(tuán)隊(duì)是DevOps運(yùn)動所倡導(dǎo)的一種產(chǎn)品團(tuán)隊(duì)組織結(jié)構(gòu)，通過將不同角色的業(yè)務(wù)和技術(shù)成員納入到團(tuán)隊(duì)，組成具備端到端交付和運(yùn)營能力的完整單元。
康威定律闡述了開發(fā)團(tuán)隊(duì)的組織結(jié)構(gòu)和其設(shè)計(jì)的產(chǎn)品結(jié)構(gòu)之間具有的相似關(guān)系。許多的實(shí)踐結(jié)果也表明，將全功能團(tuán)隊(duì)實(shí)踐應(yīng)用在微服務(wù)產(chǎn)品中帶來的收益，要遠(yuǎn)遠(yuǎn)超過它在傳統(tǒng)模塊化開發(fā)的產(chǎn)品中所帶來的收益。這是因?yàn)槲⒎?wù)的架構(gòu)中的所有服務(wù)真正具備獨(dú)立運(yùn)行和獨(dú)立運(yùn)營的能力，從本質(zhì)上來說就是一個端到端的子業(yè)務(wù)產(chǎn)品。
這種架構(gòu)和團(tuán)隊(duì)的影響是雙向的。一方面，微服務(wù)的運(yùn)營結(jié)構(gòu)要求團(tuán)隊(duì)具有高內(nèi)聚的自主管理能力。另一方面，全功能團(tuán)隊(duì)也為特定服務(wù)進(jìn)行獨(dú)立技術(shù)選型提供了更靈活的發(fā)揮空間。服務(wù)與團(tuán)隊(duì)通常是多對一的關(guān)系，每個團(tuán)隊(duì)管理的是一組相互關(guān)聯(lián)緊密的服務(wù)群，并且可以在必要的情況下對服務(wù)進(jìn)行進(jìn)一步拆分。在實(shí)際的實(shí)踐中推薦采用例如接口網(wǎng)關(guān)（API Gateway）等方式對一組具有業(yè)務(wù)意義的服務(wù)接口進(jìn)行聚合，從而保證局部服務(wù)結(jié)構(gòu)變化不會直接影響服務(wù)的消費(fèi)方的調(diào)用。
值得一說的是，在一些傳統(tǒng)企業(yè)內(nèi)的IT部門劃分，往往已經(jīng)按照職能分為開發(fā)團(tuán)隊(duì)、運(yùn)維團(tuán)隊(duì)、運(yùn)營團(tuán)隊(duì)，甚至單獨(dú)的測試團(tuán)隊(duì)。在這樣的企業(yè)中很難快速完成全功能團(tuán)隊(duì)的轉(zhuǎn)變，因此在實(shí)施微服務(wù)架構(gòu)過程中比較容易走偏。對于這種情況可以采用逐步演進(jìn)的轉(zhuǎn)換方式，具體途徑主要有兩種。
第一種方式是進(jìn)行項(xiàng)目試點(diǎn)。對于習(xí)慣了按功能分層、分塊的『實(shí)現(xiàn)接口開發(fā)』式的組織，即使勉強(qiáng)湊齊每個角色的人組在一起也難以成為真正具備端到端交付能力的團(tuán)隊(duì)。因此與其做得徒有其表，不如找出項(xiàng)目中一些全局意識比較到位的成員，對特定的項(xiàng)目進(jìn)行試點(diǎn)，然后逐步擴(kuò)大，將這種端到端的責(zé)任和意識帶入到更多的項(xiàng)目中去。試點(diǎn)的項(xiàng)目應(yīng)該是以實(shí)施現(xiàn)有系統(tǒng)的一個獨(dú)立業(yè)務(wù)功能點(diǎn)為目標(biāo)，而不是開發(fā)與企業(yè)主線系統(tǒng)無關(guān)的短期產(chǎn)品，否則容易出現(xiàn)試點(diǎn)項(xiàng)目很成功，但項(xiàng)目結(jié)束便不了了之的結(jié)果。
自動化運(yùn)維
實(shí)施自動化運(yùn)維涉及的工具有很多，例如Ansible、SaltStack、Terraform，甚至Docker都可以看做是自動化運(yùn)維的一部分。這當(dāng)中大多數(shù)工具都提供有定義操作行為的領(lǐng)域DSL，它們通常是一些配置式語言或腳本語言，因此自動化運(yùn)維也涉及到代碼的編寫。與開發(fā)項(xiàng)目代碼不同的地方在于，自動化運(yùn)維的代碼大多不是長期運(yùn)行的，很多代碼也許只在特定場景使用一次，然后就會非常長時間無人問津，直到某些緊急情況才會再次需要用到。此外，運(yùn)維的代碼本身并不直接具有業(yè)務(wù)價值，這些因素導(dǎo)致它們往往沒有被很好的管理起來。
下面以采用Ansible或SaltStack這類通用自動化工具為例，介紹一些在實(shí)踐中需要注意的地方。
首先是運(yùn)維腳本應(yīng)該通過Git或SVN這樣的版本管理工具進(jìn)行歸類和管理。通常來說，推薦將特定服務(wù)部署的Ansible或SaltStack YAML腳本文件與服務(wù)本身的代碼放在同一個代碼倉庫中，方便開發(fā)人員在必要時候快速的修改它。然后將基礎(chǔ)設(shè)施管理的YAML腳本文件放在單獨(dú)的代碼倉庫，方便復(fù)用和查找。但這樣可能帶來的問題是，在實(shí)際使用時可能會需要同時獲取兩個代碼倉庫的腳本以獲得完整的部署功能，因此如果使用的其他配套工具對多倉庫支持不佳，也可以將所有運(yùn)維腳本在同一個倉庫管理。
其次，應(yīng)該在持續(xù)交付流水線上使用服務(wù)部署的自動化工具，從而實(shí)現(xiàn)快速的交付上線。在條件允許的情況下，還應(yīng)該在流水線上直接配備自動化的災(zāi)備恢復(fù)任務(wù)入口，以及定期的對這些恢復(fù)腳本進(jìn)行測試和演練。
服務(wù)高可用
L7負(fù)載均衡即在OSI網(wǎng)絡(luò)模型應(yīng)用層進(jìn)行的軟件負(fù)載均衡，例如Nginx和HAProxy都屬于這類。這些L7負(fù)載均衡通常帶有后端服務(wù)檢查的能力，會自動屏蔽掉不可用的后端服務(wù)，從而在一部分服務(wù)出現(xiàn)故障時候，請求仍然能被正常運(yùn)行的后端服務(wù)接收。
DNS負(fù)載均衡是利用了DNS服務(wù)可以為同一個域名配置多個解析地址，且配置多個地址后，每次解析域名時輪詢著將配置的地址返回給請求方，這個特性稱為DNS輪詢。實(shí)際上DNS輪詢僅僅是一種特殊的負(fù)載均衡技術(shù)，本身并不具有檢測服務(wù)狀態(tài)、提供后端服務(wù)高可用的功能。但一些新出現(xiàn)的開源DNS產(chǎn)品，例如SkyDNS和Consul將DNS服務(wù)與服務(wù)發(fā)現(xiàn)技術(shù)進(jìn)行了結(jié)合，具有自動移除不可訪問的解析地址的功能，這使得DNS負(fù)載均衡也可以被用于實(shí)現(xiàn)服務(wù)的高可用了。
服務(wù)發(fā)現(xiàn)是一種基于注冊和查詢服務(wù)信息的鍵值數(shù)據(jù)庫服務(wù)。提供服務(wù)的一方將自己的名稱和IP地址注冊到服務(wù)發(fā)現(xiàn)的服務(wù)端，使用服務(wù)的一方則通過服務(wù)發(fā)現(xiàn)的服務(wù)端進(jìn)行查詢，然后將實(shí)際請求發(fā)送給查詢到的目標(biāo)IP地址。服務(wù)發(fā)現(xiàn)的服務(wù)端會負(fù)責(zé)檢測每個注冊服務(wù)的運(yùn)行狀態(tài)，及時移除出現(xiàn)故障的服務(wù)，并在每次收到查詢時從符合名稱的服務(wù)中任意返回一個作為結(jié)果。
不離線部署
遞進(jìn)式升級（Rolling Update）是指將集群中的服務(wù)劃成多個分組，每次只升級其中的一個分組，然后依次進(jìn)行，直到所有服務(wù)都升級完成的過程。采用遞進(jìn)式升級會使得集群中的服務(wù)有一段時間同時存在新舊兩個版本。
長任務(wù)指是接收到請求后需要花費(fèi)幾秒、甚至幾小時才能執(zhí)行完的任務(wù)，例如一些涉及大量計(jì)算或需要遠(yuǎn)程同步調(diào)用的事務(wù)。具有長任務(wù)的服務(wù)都有『運(yùn)行中』和『空閑』這樣的運(yùn)行狀態(tài)。當(dāng)服務(wù)處于『運(yùn)行中』的時候，中斷它可能導(dǎo)致意外的結(jié)果。一般來說在Linux中停止服務(wù)的流程是先向服務(wù)發(fā)送一個TERM信號，使其正常結(jié)束，若是信號發(fā)送幾秒后，服務(wù)仍然在運(yùn)行，才會發(fā)送KILL信號將它強(qiáng)行終止。處理短任務(wù)的服務(wù)通?？梢栽诮邮盏絋ERM信號后及時停止，因此不存在這種風(fēng)險。這里應(yīng)該將『無長任務(wù)的服務(wù)』與『無狀態(tài)的服務(wù)』加以區(qū)分，后者指的是服務(wù)對每次請求的處理，不依賴于其他請求。即服務(wù)處理一次請求所需的全部信息，要么都包含在這個請求里，要么可以從外部獲取到（比如說數(shù)據(jù)庫），服務(wù)器本身不存儲任何信息。通常來說，微服務(wù)架構(gòu)中的服務(wù)一定是無狀態(tài)的，但不一定是無長任務(wù)的。
如果服務(wù)不能采用遞進(jìn)式的升級，不論其是否具有長任務(wù)，藍(lán)綠部署都是一種十分推薦的部署方式。藍(lán)綠部署的做法是同時準(zhǔn)備一組線上運(yùn)行的服務(wù)器，以及一組用于下次部署的服務(wù)器，兩組服務(wù)器具有相同的數(shù)量和配置。執(zhí)行部署時，先將新的服務(wù)部署到?jīng)]有放到線上運(yùn)行的那組服務(wù)器上，等到部署全部完成，直接將負(fù)載均衡的流量導(dǎo)向到剛剛這組服務(wù)器上，從而使得兩組服務(wù)器的角色互換。下一次進(jìn)行部署的時候，則換用另外一組服務(wù)器執(zhí)行部署，然后將負(fù)載均衡切換回來。這個過程如下圖所示：
藍(lán)綠部署的優(yōu)點(diǎn)在于新舊服務(wù)的切換是瞬間完成的，并且當(dāng)流量切換到另一組服務(wù)器上之后，原先的那組服務(wù)器可以繼續(xù)運(yùn)行，這樣即使上面有未完成的任務(wù)也不會被強(qiáng)行中斷，如果升級后的版本發(fā)現(xiàn)了比較嚴(yán)重的問題，也可以快速的切換回原先的版本。而它的缺點(diǎn)也十分明顯，那就是會占用比實(shí)際需要多一倍的服務(wù)器作為下次部署的備用機(jī)器。
一些前端服務(wù)可能會屬于這類情況，我們也許不希望在升級的過程中，一部分用戶看到是新的頁面，另一部分看到還是舊的頁面。另外對于Nginx這類負(fù)載均衡工具，后端服務(wù)的健康檢查并非是實(shí)時生效的，有可能出現(xiàn)服務(wù)已經(jīng)離線，但請求仍然被分發(fā)到這個主機(jī)的情況，因此采用負(fù)載均衡作為高可用方案的服務(wù)，藍(lán)綠部署也是比較可取的方式。
如果服務(wù)的數(shù)量比較多，并且允許同時存在兩個運(yùn)行的版本，那么采用遞進(jìn)式升級方式則會更加節(jié)省資源。以每次升級一個節(jié)點(diǎn)的遞進(jìn)方式為例，當(dāng)升級開始后，我們首先停止所有服務(wù)節(jié)點(diǎn)中的任意一個，將它進(jìn)行升級，然后讓它重新加入集群，接著從剩下的服務(wù)節(jié)點(diǎn)從再任意選擇一個，直到最后一個服務(wù)也被升級完成。這個過程不需要增加額外的服務(wù)器資源，只要待升級的服務(wù)具有兩個以上的節(jié)點(diǎn)，就不會對服務(wù)的整體功能造成中斷。遞進(jìn)式升級的過程如下圖所示：
顯然如果服務(wù)本身是不能被隨時停止的，那么這種簡單的遞進(jìn)升級就不能很好的滿足了。此時我們需要對服務(wù)的調(diào)度進(jìn)行干涉，以采用服務(wù)發(fā)現(xiàn)的高可用方式為例，下圖展示了一種『帶狀態(tài)檢查的遞進(jìn)式升級』策略進(jìn)行服務(wù)部署。
這種升級方法具有普通遞進(jìn)式升級的相似優(yōu)勢，但在集群中有個別服務(wù)執(zhí)行任務(wù)時間很長，始終處于『運(yùn)行中』狀態(tài)的情況下，將使得升級過程阻塞，大大的延長服務(wù)部署的時間。事實(shí)上，長任務(wù)的服務(wù)通常都可以被改造成為批處理式的服務(wù)（Batch-Task Service），批處理式服務(wù)的升級只需要直接將服務(wù)執(zhí)行文件替換，從根本上簡化了升級難度。
監(jiān)控告警
內(nèi)存不足、磁盤耗盡、網(wǎng)絡(luò)中斷、服務(wù)失效，這些天災(zāi)人禍隨時可能殃及產(chǎn)品的服務(wù)集群。很難想象，在一個龐大的微服務(wù)系統(tǒng)中，如果沒有合適的監(jiān)控和告警設(shè)施，服務(wù)的運(yùn)營會變得多么混亂不堪。
對微服務(wù)系統(tǒng)進(jìn)行監(jiān)控主要需要考慮兩個方面：基礎(chǔ)設(shè)施的監(jiān)控和應(yīng)用服務(wù)的監(jiān)控。
基礎(chǔ)設(shè)施的監(jiān)控通常由部署在每個節(jié)點(diǎn)上的數(shù)據(jù)采集端、集中式的數(shù)據(jù)匯聚端、以及數(shù)據(jù)展示、數(shù)據(jù)分析和告警通知等部分組成。而監(jiān)控告警系統(tǒng)的實(shí)施中，還需要結(jié)合團(tuán)隊(duì)的運(yùn)維自動化能力，選擇合適的技術(shù)棧進(jìn)行。開源的Promethus和InfluxDB都是值得考慮的工具。
容器化
其次是精細(xì)的資源分配。通過虛擬機(jī)分配服務(wù)資源時，為了簡化管理，通常不論服務(wù)實(shí)際使用多少CPU和內(nèi)存資源，都只能從固定的主機(jī)類型中挑選一種，按主機(jī)的個數(shù)計(jì)費(fèi)。容器能夠很好的實(shí)現(xiàn)面向資源池的服務(wù)管理，各個服務(wù)可以根據(jù)并發(fā)進(jìn)程數(shù)、CPU和內(nèi)存用量等資源計(jì)費(fèi)，實(shí)現(xiàn)更加精細(xì)的資源管理。
此外，容器還有利于資源的動態(tài)調(diào)整。過去企業(yè)里的服務(wù)器資源一般是按計(jì)劃分配的，有的部門為了避開繁瑣的資源申請流程，一次性申請大量資源囤積備用，造成浪費(fèi)。容器的面向資源池特性，使得企業(yè)能夠?qū)⑺杏?jì)算資源進(jìn)行運(yùn)行時動態(tài)調(diào)整，實(shí)現(xiàn)按計(jì)劃分配到按需分配的轉(zhuǎn)變。業(yè)務(wù)只需適應(yīng)流量負(fù)載的變化。在負(fù)載高峰期快速增加資源，保證業(yè)務(wù)服務(wù)質(zhì)量，在負(fù)載低峰期釋放資源給其它服務(wù)，提高集群資源利用率。
小結(jié)
每一個精心設(shè)計(jì)的企業(yè)級架構(gòu)背后，都蘊(yùn)含了相當(dāng)?shù)膹?fù)雜性，微服務(wù)亦是如此。優(yōu)秀的架構(gòu)并不能讓軟件的復(fù)雜度憑空消失，而是通過更加合理的拆分和約束，使得軟件結(jié)構(gòu)更加容易匹配業(yè)務(wù)、適應(yīng)變化，從而在規(guī)模化的同時保持高度的響應(yīng)力。架構(gòu)不是銀彈，離開了必要的實(shí)踐前提，空談微服務(wù)，猶如東施效顰，期望拆了服務(wù)就能為企業(yè)帶來受益，無疑于空中樓閣的笑話而已。
責(zé)任編輯：售電衡衡
- 相關(guān)閱讀
- 碳交易
- 節(jié)能環(huán)保
- 電力法律
- 電力金融
- 綠色電力證書
-
碳中和戰(zhàn)略｜趙英民副部長致辭全文
2020-10-19碳中和,碳排放,趙英民 -
兩部門：推廣不停電作業(yè)技術(shù) 減少停電時間和停電次數(shù)
2020-09-28獲得電力,供電可靠性,供電企業(yè) -
國家發(fā)改委、國家能源局：推廣不停電作業(yè)技術(shù) 減少停電時間和停電次數(shù)
2020-09-28獲得電力,供電可靠性,供電企業(yè)
-
碳中和戰(zhàn)略｜趙英民副部長致辭全文
2020-10-19碳中和,碳排放,趙英民 -
深度報(bào)告 | 基于分類監(jiān)管與當(dāng)量協(xié)同的碳市場框架設(shè)計(jì)方案
2020-07-21碳市場,碳排放,碳交易 -
碳市場讓重慶能源轉(zhuǎn)型與經(jīng)濟(jì)發(fā)展并進(jìn)
2020-07-21碳市場,碳排放,重慶
-
兩部門：推廣不停電作業(yè)技術(shù) 減少停電時間和停電次數(shù)
2020-09-28獲得電力,供電可靠性,供電企業(yè) -
國家發(fā)改委、國家能源局：推廣不停電作業(yè)技術(shù) 減少停電時間和停電次數(shù)
2020-09-28獲得電力,供電可靠性,供電企業(yè) -
2020年二季度福建省統(tǒng)調(diào)燃煤電廠節(jié)能減排信息披露
2020-07-21火電環(huán)保,燃煤電廠,超低排放
-
四川“專線供電”身陷違法困境
2019-12-16專線供電 -
我國能源替代規(guī)范法律問題研究（上）
2019-10-31能源替代規(guī)范法律 -
區(qū)域鏈結(jié)構(gòu)對于數(shù)據(jù)中心有什么影響？這個影響是好是壞呢！
