1、基本概念和原理

    微服務架構是一種架構模式，它提倡將單一應用程式劃分成一組小的服務，服務之間互相協調和配合，為使用者提供最終價值。一個大型複雜軟體應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個服務之間是鬆耦合的。每個服務執行在獨立的程序中，服務與服務間採用輕量級的通訊機制互相溝通。微服務的目的是有效的拆分應用，實現敏捷開發和部署。
    微服務架構的優勢：複雜度可控、獨立部署、技術選型靈活、容錯、擴充套件。

    業界常用的微服務開發框架有：Dubbo、Spring boot、SpringCloud等。常用的通訊機制協議有RPC、REST。     

    微服務落地存在的主要困難有如下幾方面：

    1）單體應用拆分成分散式系統後，程序間的通訊機制和故障處理措施變得更加複雜。

    2）系統微服務化後，一個看似簡單的功能，內部可能需要呼叫多個服務並操作多個數據庫實現，服務呼叫的分散式事務問題變的非常突出。

    3）微服務數量眾多，其測試、部署、監控等都變得更加困難。

    隨著RPC框架的成熟，第一個問題已經逐漸得到解決。例如dubbo支援多種通訊協議，SpringCloud可以非常好的支援restful呼叫。對於第三個問題，隨著docker、devops技術的發展以及公有云paas平臺自動化運維工具的推出，微服務的測試、部署與運維變得越來越容易。而對於第二個問題，是最具挑戰性的一個技術難題。目前阿里採用GTS。

    因此，要想使用微服務帶來的優勢，就需要使用容器引擎（比如Docker）來實現容器化。並且還要解決分散式事務的難題。

    常用容器Docker，是一個開源的應用容器引擎。Docker介於VM與應用之間，更類似於VM，但比VM更加靈活的分配資源。Docker容器通過Docker映象來建立。容器可以將應用依賴的中介軟體和軟體都打包進去，為基礎環境的部署和運維提供了便利，能很好的支援DevOps。

2、微服務架構演進的思考

    目前我們的企業級架構是SOA架構，要演進到微服務架構，首先需要從業務和應用層面對目前的元件進一步拆分成微服務。拆分的大原則是當業務不依賴或極少依賴其它服務，有獨立的業務語義，為超過2個的其他服務或客戶端提供資料，那麼它就應該被拆分成一個獨立的服務。其次，微服務提倡的理念團隊間應該是inter-operate，not integrate。inter-operate是定義好系統的邊界和介面，在一個團隊內全棧，讓團隊自治。這樣，每個服務從開發、測試、運維等都是獨立的，自己就有一套完整的流程，完全可以把它當成一個專案來對待，不必依賴其他服務。還有，我們需要解決分散式事務這個難題。解決方案有：基於XA協議的兩階段提交方案、TCC方案（Try、Cononfirm、Cancel）、基於訊息的最終一致性方案、基於衝正的一致性方案、GTS（阿里分散式事務解決方案）。最後是選擇合適的微服務開發框架、輕量級通訊協議、容器引擎以及DevOps。
    上述這些要點都需要應用架構制定統一的原則和技術選型。
    對於現有傳統架構的系統遷移到微服務架構，可以考慮將服務分為四類。基礎服務（檔案服務、訊息服務、簡訊服務、機構員工服務、客戶資訊服務等）、介面服務（前置類系統、ESB）、組合服務（結售匯、資管、同業等）、其他服務（客戶端服務、監控服務等）。
    基礎服務由於最符合微服務的特點，應最先進行遷移。而組合服務，就是涉及到了具體的業務，一般放到最後再進行微服務化改造，因為這類服務最為複雜，除非涉及到大的業務邏輯變更，否則是不會輕易進行遷移的。還有考慮傳統服務和微服務的配合方式，所有微服務可以通過微服務閘道器來對外提供統一的訪問入口，所有需要和微服務架構內部服務進行通訊的請求都走統一閘道器。

3、同業公有云輸出的相關思考

    如果同業雲輸出專案要進行微服務化，需要考慮以下方面：

    1）制定統一的微服務架構相關原則和技術選型。

    2）從業務和應用層面梳理現有系統有哪些服務需要微服務化，尤其是基礎服務。

    3）必須有容器化、DevOps、公有云paas平臺自動化運維工具的底層支撐。

    4）考慮專案實施週期、技術難度以及投入產出價效比，建議採用分階段實施策略。組合服務如果沒有大的業務邏輯變更，則不進行微服務化。基礎服務優先進行微服務化，可作為試點。有大業務邏輯變更的組合服務可考慮進行微服務化。