微服務(wù)體系的發(fā)展并不是一蹴而就的，經(jīng)過了2014年前后的低潮期，微服務(wù)概念頂層的泡沫逐漸褪去，那些真正能夠在企業(yè)落地的實(shí)踐在一輪又一輪的大浪淘沙后被甄別、沉淀。這篇文章希望討論一些在團(tuán)隊(duì)中實(shí)行微服務(wù)架構(gòu)時(shí)值得考慮的『增值項(xiàng)目』，它們中的一些看起來(lái)已經(jīng)是理所應(yīng)當(dāng)?shù)模硪恍┧坪鹾臀⒎?wù)并沒有必然的關(guān)聯(lián)，但許多經(jīng)驗(yàn)?zāi)軌蜃C明這些項(xiàng)目都是保障微服務(wù)系統(tǒng)長(zhǎng)期運(yùn)作并最大化發(fā)揮其Scale Out能力值得投入的高附加值實(shí)踐。

持續(xù)交付

    對(duì)于微服務(wù)的成功實(shí)施，團(tuán)隊(duì)持續(xù)交付能力是至關(guān)重要的衡量指標(biāo)。在由上百個(gè)服務(wù)組成的復(fù)雜系統(tǒng)中，如果所有服務(wù)都按照人為指定發(fā)布周期進(jìn)行整體交付，很容易出現(xiàn)由于細(xì)小的失誤導(dǎo)致大面積線上故障。

    持續(xù)交付實(shí)踐要求每個(gè)獨(dú)立服務(wù)都具有完備的交付流水線，在流水線的末端隨時(shí)能提供當(dāng)時(shí)最新的可工作、可交付的產(chǎn)品。持續(xù)交付通常會(huì)配合自動(dòng)化的測(cè)試和部署手段，從而減少功能代碼提交到上線的端到端時(shí)間。這就使得每個(gè)獨(dú)立服務(wù)能按照各自不同的節(jié)奏進(jìn)行發(fā)布，并且將自己的發(fā)布狀態(tài)可視化出來(lái)。

    采用盡可能精簡(jiǎn)且穩(wěn)定的分支策略也是使得持續(xù)交付流程能夠順利實(shí)施的關(guān)鍵，我們提倡使用單主干的分支策略（Trunk Based Development）。在單主干的開發(fā)方式中，除了一個(gè)用于持續(xù)開發(fā)和集成的『主干分支』（通常即Master分支）和一系列依據(jù)發(fā)布周期創(chuàng)建的發(fā)布分支以外，應(yīng)該避免創(chuàng)建其他的Long-lived分支。如果有多個(gè)功能需要開發(fā)，則推薦采用特性開關(guān)（Feature Toggle）的方法來(lái)控制它們的發(fā)布時(shí)機(jī)。當(dāng)然，單主干策略是允許存在短生命周期特性分支的（短于一周），有時(shí)這些小分支甚至無(wú)需提交到遠(yuǎn)程倉(cāng)庫(kù)中。下面這是一幅經(jīng)典的單主干分支策略示意圖。

    值得指出的是，在劃分得當(dāng)?shù)奈⒎?wù)系統(tǒng)中，同一個(gè)服務(wù)需要同時(shí)進(jìn)行開發(fā)的特性通常不會(huì)多于兩到三個(gè)（否則應(yīng)該考慮這個(gè)服務(wù)是否承擔(dān)了過多的職責(zé)）。因此即使在不需要特性開關(guān)和其他額外開發(fā)工作量的情況下，已經(jīng)可以比較好的實(shí)現(xiàn)每個(gè)功能點(diǎn)的獨(dú)立發(fā)布和測(cè)試，這反向說明了微服務(wù)架構(gòu)對(duì)于持續(xù)交付的實(shí)施也是十分友好的。

    除了嚴(yán)格的單主干，一種常見的變式是多主干策略，典型的是一個(gè)開發(fā)分支加幾個(gè)固定的發(fā)布分支，通常用于無(wú)需維護(hù)多個(gè)發(fā)布版本的SaaS服務(wù)交付。這種模式的優(yōu)點(diǎn)是能夠?qū)l(fā)布流水線目標(biāo)環(huán)境和分支顯示的關(guān)聯(lián)起來(lái)，例如『Develop分支』對(duì)應(yīng)集成環(huán)境，『Release分支』對(duì)應(yīng)驗(yàn)收環(huán)境和正式環(huán)境。下圖展示了一組與此模式下的持續(xù)交付流水線。

    保持每個(gè)服務(wù)高頻率的集成和交付，會(huì)使得有故障的功能在很短的反饋周期內(nèi)被發(fā)現(xiàn)，在快速迭代發(fā)布的前提下做到整個(gè)系統(tǒng)發(fā)布井然有序。這樣的氛圍不僅有利于改善代碼的質(zhì)量，而且能夠提高開發(fā)士氣，頻繁的發(fā)布上線也有利于增強(qiáng)團(tuán)隊(duì)對(duì)產(chǎn)品的榮譽(yù)感和自信心。

全功能團(tuán)隊(duì)

    全功能團(tuán)隊(duì)是DevOps運(yùn)動(dòng)所倡導(dǎo)的一種產(chǎn)品團(tuán)隊(duì)組織結(jié)構(gòu)，通過將不同角色的業(yè)務(wù)和技術(shù)成員納入到團(tuán)隊(duì)，組成具備端到端交付和運(yùn)營(yíng)能力的完整單元。

    康威定律闡述了開發(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)品中帶來(lái)的收益，要遠(yuǎn)遠(yuǎn)超過它在傳統(tǒng)模塊化開發(fā)的產(chǎn)品中所帶來(lái)的收益。這是因?yàn)槲⒎?wù)的架構(gòu)中的所有服務(wù)真正具備獨(dú)立運(yùn)行和獨(dú)立運(yùn)營(yíng)的能力，從本質(zhì)上來(lái)說就是一個(gè)端到端的子業(yè)務(wù)產(chǎn)品。

    這種架構(gòu)和團(tuán)隊(duì)的影響是雙向的。一方面，微服務(wù)的運(yùn)營(yíng)結(jié)構(gòu)要求團(tuán)隊(duì)具有高內(nèi)聚的自主管理能力。另一方面，全功能團(tuán)隊(duì)也為特定服務(wù)進(jìn)行獨(dú)立技術(shù)選型提供了更靈活的發(fā)揮空間。服務(wù)與團(tuán)隊(duì)通常是多對(duì)一的關(guān)系，每個(gè)團(tuán)隊(duì)管理的是一組相互關(guān)聯(lián)緊密的服務(wù)群，并且可以在必要的情況下對(duì)服務(wù)進(jìn)行進(jìn)一步拆分。在實(shí)際的實(shí)踐中推薦采用例如接口網(wǎng)關(guān)（API Gateway）等方式對(duì)一組具有業(yè)務(wù)意義的服務(wù)接口進(jìn)行聚合，從而保證局部服務(wù)結(jié)構(gòu)變化不會(huì)直接影響服務(wù)的消費(fèi)方的調(diào)用。

    值得一說的是，在一些傳統(tǒng)企業(yè)內(nèi)的IT部門劃分，往往已經(jīng)按照職能分為開發(fā)團(tuán)隊(duì)、運(yùn)維團(tuán)隊(duì)、運(yùn)營(yíng)團(tuán)隊(duì)，甚至單獨(dú)的測(cè)試團(tuán)隊(duì)。在這樣的企業(yè)中很難快速完成全功能團(tuán)隊(duì)的轉(zhuǎn)變，因此在實(shí)施微服務(wù)架構(gòu)過程中比較容易走偏。對(duì)于這種情況可以采用逐步演進(jìn)的轉(zhuǎn)換方式，具體途徑主要有兩種。

    第一種方式是進(jìn)行項(xiàng)目試點(diǎn)。對(duì)于習(xí)慣了按功能分層、分塊的『實(shí)現(xiàn)接口開發(fā)』式的組織，即使勉強(qiáng)湊齊每個(gè)角色的人組在一起也難以成為真正具備端到端交付能力的團(tuán)隊(duì)。因此與其做得徒有其表，不如找出項(xiàng)目中一些全局意識(shí)比較到位的成員，對(duì)特定的項(xiàng)目進(jìn)行試點(diǎn)，然后逐步擴(kuò)大，將這種端到端的責(zé)任和意識(shí)帶入到更多的項(xiàng)目中去。試點(diǎn)的項(xiàng)目應(yīng)該是以實(shí)施現(xiàn)有系統(tǒng)的一個(gè)獨(dú)立業(yè)務(wù)功能點(diǎn)為目標(biāo)，而不是開發(fā)與企業(yè)主線系統(tǒng)無(wú)關(guān)的短期產(chǎn)品，否則容易出現(xiàn)試點(diǎn)項(xiàng)目很成功，但項(xiàng)目結(jié)束便不了了之的結(jié)果。

自動(dòng)化運(yùn)維