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

持續(xù)交付

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

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

    采用盡可能精簡且穩(wěn)定的分支策略也是使得持續(xù)交付流程能夠順利實施的關(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ā)布時機。當(dāng)然，單主干策略是允許存在短生命周期特性分支的（短于一周），有時這些小分支甚至無需提交到遠程倉庫中。下面這是一幅經(jīng)典的單主干分支策略示意圖。

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

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

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

全功能團隊

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

    康威定律闡述了開發(fā)團隊的組織結(jié)構(gòu)和其設(shè)計的產(chǎn)品結(jié)構(gòu)之間具有的相似關(guān)系。許多的實踐結(jié)果也表明，將全功能團隊實踐應(yīng)用在微服務(wù)產(chǎn)品中帶來的收益，要遠遠超過它在傳統(tǒng)模塊化開發(fā)的產(chǎn)品中所帶來的收益。這是因為微服務(wù)的架構(gòu)中的所有服務(wù)真正具備獨立運行和獨立運營的能力，從本質(zhì)上來說就是一個端到端的子業(yè)務(wù)產(chǎn)品。

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

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

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

自動化運維