微服務實施需要明確每一步怎麼做，可能存在的問題和解決思路、方法。如果能有相應的經驗和理論指導，將會大大有助於我們設計和構建微服務體系。但由於目前大部分人員都是關注微服務開發框架或工具，甚少討論微服務架構方法論。因此，進行微服務規劃，在一個相對較高的層次來探討、研究微服務的設計和實現顯得尤為重要。理論方法論就象燈塔、導航，為我們指明瞭方向，雖然也會有這樣那樣的問題，但只要方向對了，就不會南轅北轍，總會到目的地的。

也基於這樣的認知，我們在實施微服務的時候，基於相應的理論學習和經驗實踐，把微服務的生命週期過程關注的重點事項定義為：微服務規劃、微服務構建、微服務協同、微服務測試、微服務部署釋出、微服務運營、微服務治理、微服務下線。每項任務側重點不同，實現的能力不同，共同完成微服務生命週期過程。

一、 微服務生命週期
採用微服務不僅僅是寫幾個微服務就萬事大吉了，微服務的部署、運營，微服務之間的呼叫、協作，微服務版本管理、上線下線，以及微服務體系的規劃、每個微服務的設計構建、測試，都是微服務體系中重要的內容。也是基於此考慮，我們將微服務整個生命週期過程任務事項梳理定義為規劃、構建、協同、測試、部署、釋出、運營、下線和治理等：

微服務規劃是在決定採用微服務之後對現有業務流程進行梳理，根據自身技術能力和特點選擇合適的設計和構建方法論，規劃和構建微服務所需資源和基礎設施平臺等。

微服務構建是基於微服務設計和構建方法論，逐步提取微服務元件服務，分步驟的實現整個微服務體系建設。

微服務協同設計，是指微服務間基於彼此的聯絡和依賴實現服務間呼叫和協作，共同完成業務應用邏輯功能。

微服務測試是微服務在測試環境構建測試域，利用測試擋板工具或服務完成微服務的各項測試，以滿足業務部門提出的功能、效能、部署、安全等各項需求。

微服務部署是微服務達到生產就緒的條件下部署到生產環境，為微服務正式釋出做好準備。

微服務釋出是完成生產驗證後正式對外發布服務，使服務可用。

微服務運營是向業務應用客戶提供正常的服務的過程，記錄並監控執行情況、計量計費、維護資源、修復缺陷、安全保證等。

微服務下線涉及微服務的版本管理、下線計劃、下線提醒、替代方案、介面停用、服務關閉等事項。

微服務治理則是為保證微服務整個生命週期過程中微服務的正常運營協調所需人員、流程、資源及所採取的措施等，比如提供微服務介面服務、微服務安全、微服務監控以及微服務生命週期管理等，進行流程、人員、工具之間協作的一種方式。

微服務生命週期中的微服務規劃、微服務構建、微服務協同、微服務測試、微服務部署釋出、微服務運營、微服務下線、微服務治理等事項側重點不同，實現的能力不同，共同完成微服務生命週期過程。同時微服務生命週期過程也是DevOps貫穿的過程，微服務的彈性、灰度、監控、治理、管理等需要依賴容器等基礎設施平臺的支撐。這樣可以充分利用各種技術的優勢來提升IT對業務變化的響應能力。

（一） 微服務規劃
基於前期的學習、交流和研究，以及對自身技術實力、對業務流程的理解和認知，選擇合適的方法梳理業務流程，梳理資料互動，嘗試業務分解，規劃業務微服務。微服務規劃直接會影響到後期微服務的設計和構建，對微服務設計思想的認知和對業務流程理解的深度以及微服務設計方法直接決定了微服務設計的質量。所以我們認為如果沒有這方面的專家指導微服務規劃和設計，沒有相應的基礎設施支撐，不能自主管控微服務的生命週期，不建議輕易採用微服務架構。

我們認為IT系統建設已經過了走一步看一步的階段，當前需要對IT技術的選型和基礎平臺建設做出一個相對中長期的規劃，這類似於戰略層級，方向性的錯誤損失可能無法彌補。這也是我們關注規劃的原因之一。

微服務規劃的關鍵是對業務和技術的理解。梳理業務流程的目的也是為了加深對業務的理解，業務流程伴隨著資料流程。但往往一個現實的問題是技術人員對業務都是一知半解，但業務系統建設通常由技術人員主導，所以結果往往不令人滿意。所以我們強調從業務和資料的雙向融合，業務從上而下，資料從下而上，根據業務考慮資料的產生節點、資料量、資料變化頻率、SLA（負載、響應時間、最大併發請求）、儲存需求、網路流量、侷限性等，從而可以方便的在下個階段構建資料物理模型。當然這並不容易，既要求對業務有深入的理解，也要求對技術有深厚背景和廣闊知識面，能自主把控的專家參與並指導。

微服務規劃也是基於資源整合的考慮，人力、技術、設施、工具、資料等等若能整合在一起，可以集中力量發揮整體優勢。當前軟體發展已經從單體-整合階段過渡到了融合-平臺階段，服務化特別是微服務的思想使單體軟體系統逐步消亡，代之以統一化平臺，比如基礎設施資源虛擬化平臺、開發託管運維PaaS平臺、業務資料中臺和服務中臺等，這些平臺也不是彼此獨立，而是協同成為一個支撐企業業務的大統一平臺。平臺以元件服務如同積木可插拔的方式構建，其擴充套件性、彈性、可維護性、開放性、標準化、可替換性等都是當前單體或整合軟體無法滿足的。

在融合-平臺階段，前臺不同業務組、業務團隊的運營需要通過雲端計算的多租戶機制來保證，許可權隔離、資源隔離、可擴充套件性、自治等由基礎設施平臺來支撐。可便捷的實現資源的重組和調配，敏捷響應業務快速變化需求。

（二） 微服務構建
規劃做好了，構建就容易多了。首先提取公共的元件，比如許可權、配置、日誌、監控告警、報表等。然後使用選擇的微服務設計構建方法從上到下，從業務到技術；從下到上，從資料到技術，設計構建出滿足業務需求的微服務。比如DDD和主資料設計方法。微服務設計、構建或拆分的關鍵在於正確的理解業務，識別新建業務應用或重構單體應用內部的業務領域及其邊界，識別資料生成、流動、變化、儲存、來源的節點。構建主資料模型，基於模型構建業務元件微服務，再基於業務流程構建其他的微服務元件。

不同問題需要不同視角來觀察理解，需要全面的認知，我們不認為一種方式可以萬能，所以可以嘗試不同的方法來構建，從不同的視角、不同的層次來驗證微服務構建的結果。

微服務實現可能更多需要考慮業務資料：資料量、資料儲存、資料變化、頻率以及侷限條件等，然後確定資料庫層實現或儲存設計：單表、分割槽、分表、分庫、分資料中心、分地域等，微服務邏輯的實現方式會影響到微服務的配置、部署、擴充套件、彈性等。

（三） 微服務協同
我們一再強調微服務構建工具並不重要，微服務生態環境才是需要認真考慮的事情。微服務協同就要微服務在整個生態環境中高效合作完成業務需求。

（四） 微服務測試
測試是微服務生產就緒前的重要工作之一。測試是很繁瑣但又是很重要的工作，特別採用微服務之後，如果無法實現測試的自動化或DevOps，不只是影響交付效率和質量，其繁重的測試工作也會讓測試人員不堪重負。特別眾多微服務不同版本之間的協同測試，靠人力可能會捉襟見肘。我們可能不得不借助工具，在測試環境根據測試的場景自動構建測試域，利用測試擋板工具模擬呼叫的服務，自動生成測試用例，由容器雲平臺提供資源支援，實現彈性伸縮、灰度釋出、負載均衡等能力，完成微服務的功能測試、整合測試、效能測試等要求。同時檢驗部署、擴充套件、安全、日誌、監控告警能力等。

（五） 微服務部署
為支援不同的開發語言和開發框架，我們要求開發交付的標準是可用的滿足功能、效能、彈性、輕量的映象，映象倉庫是各個環境之間的媒介，是微服務在不同環境釋出和部署的起點。通常DevOps流程實現映象安全檢查、匯入匯出、映象同步、映象部署、微服務配置、微服務註冊、微服務API管理、微服務釋出等，由容器雲平臺提供微服務部署管理和治理能力。

可生產部署的微服務我們要求是生產就緒的。微服務生產就緒要滿足功能、效能、彈性、高可用、容錯、日誌、監控、文件可用等能力，根據業務場景的要求支援不同的部署方式。

（六） 微服務釋出
微服務部署之後，完成生產驗證，通常可以通過API閘道器對外發布API介面服務。在服務目錄或者API Portal上進行瀏覽檢視或測試。

微服務釋出可能會有灰度的場景需求，也就是對於釋出的新的版本功能引導部分流量過來，以便用實際的業務流量資料檢驗新的版本功能的正確性，確保整體業務應用的穩定，在初始灰度驗證的時候若有問題，可以及時調整，以減少影響，若沒有問題則逐步擴大流量，直到最後接管全部流量。

（七） 微服務運營
API閘道器是微服務架構下重要的基礎元件，利用API閘道器可以完成微服務的認證授權、訪問控制、安全機制、路由、過濾、對映、轉換、流控、熔斷等非業務邏輯功能，也可進行服務請求統計分析、計量計費、生成報表、實現API經濟，可以和容器雲平臺結合更好的實現微服務的治理。

微服務運營要採取措施保證微服務提供的介面服務的正常執行，比如容錯機制、負載均衡、備份、自動擴充套件，或者根據業務場景實施流量控制，或某些特殊情景下采取熔斷機制等。

運營過程中出現的缺陷需要及時修復，通過的DevOps缺陷修復流程實現快速的迭代更新，保證業務應用不受明顯影響。

（八） 微服務下線
隨著時間的推移，微服務的版本可能會越來越多，不可能同時運營維護所有的版本，一些老舊的版本在運營一段時間之後就可能需要考慮遷移到新的支援版本，以減少維護工作量，提高收益率。

微服務運營可以採用產品運營的方法，在新的版本釋出之後，經過一段時間穩定執行之後就不再更新維護舊的版本，建議使用者逐步遷移到新版本。這需要定義相應的微服務下線規則、流程和方式。

（九） 微服務治理
微服務治理理論上貫穿微服務生命週期各個階段，涉及人、組織、流程等。通常我們討論的是微服務釋出部署和運營運維階段的治理能力，關注的更多是技術層面。我們討論過用API閘道器實現微服務治理，還涉及微服務規範、介面標準、微服務註冊、日誌、監控、API管理等等，都是微服務生命週期過程中治理的內容。我們也探討過容器雲之微服務治理 ，這裡就不再深入討論。

二、 DevOps協作
歷史總是驚人的相似！很多技術思想也是相通的。DevOps是為了增強不同團隊之間的協作，以高效地工作，微服務協同是協調微服務之間的協同合作。微服務是構建業務應用的基本單元，業務應用生命週期過程也就是DevOps貫穿的過程，協調相關的人、組織、流程、資源、工具，採取有力的措施來保障業務應用的研發、測試、部署、釋出、運營等高效執行，滿足快速變化的業務需求的要求，對市場需要快速響應，或者引領創造新的市場需求。

三、 容器雲基礎設施平臺支撐
站的高看的遠。基礎設施平臺的高度決定了其上託管運營的業務應用的敏捷度。微服務雖然不是必須要求容器雲等基礎設施平臺，但有這樣的平臺將有助於提升業務應用的敏捷度，提高對業務變化的響應能力。

歡迎工作一到五年的Java工程師朋友們加入Java程式設計師開發： 854393687
群內提供免費的Java架構學習資料（裡面有高可用、高併發、高效能及分散式、Jvm效能調優、Spring原始碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！