最近幾年，個人寫了不少的微服務架構相關的文章，這篇文章剛好結合微服務架構相關的文章和實踐，來進一步整理如何從一個新的知識點，在不斷學習和實踐中，將相關的內容知識體系化。
對于新領域的學習，我前面也專門寫過如何快速切入新領域的文章，在此不再贅述。
在我接觸微服務架構的時候，首先看下自己已有了SOA，云計算，私有云PaaS平臺，敏捷開發，持續集成和CMMI過程改進等多方面知識點的積累。因此當接觸到微服務架構的時候，自己首先思考的還是微服務架構和SOA有什么區別和關系，微服務網關和ESB有什么區別，微服務架構和原來的組件化架構有什么區別？
在學習微服務架構的文章過程中，不斷地去思考這些關聯和區別，其核心的目的仍然是真正找到微服務架構的核心，或者說你自己能夠理解的概念模型。即微服務架構本身是將傳統單體應用打破為多個獨立自治（可以在自己獨立進程中運行）的微服務模塊，同時這些模塊間通過輕量的Http API接口進行交互。這就是微服務架構的核心概念模型。
和SOA的區別，即SOA的概念內化到單體應用內部，單體應用拆分為微服務模塊了。同時可以看到微服務架構并沒去強調SOA里面的第二個層次，即服務能力的組合，組裝和編排。和ESB的區別，微服務架構網關才是和ESB對應的東西，只是網關更加輕量，沒有大量的遺留適配，協議轉換等，同時接口基本推進主流的Http Rest模式。而同傳統組件化架構的區別，則更加強調了組件完全獨立自治，從數據庫到應用層全部要拆分。
學習任何一個新概念或切入一個新領域，重點就是要抓住核心概念模型。你把核心抓住了，就達到了從道理上懂了的第一步，當然從道理上懂了，到你自己能夠親自去做，能夠按這個思想去實踐還差得遠。
但是你抓住了這個概念模型，你后面所有的深入都將圍繞這個核心展開。大家可以參考下我最新發布過微服務相關的文章，相當來說比較零散。
如果簡單總結的話會涉及到如下關鍵詞內容，傳統企業IT架構轉型，中臺構建，微服務網關，SpingCLoud，DevOps和持續交付，容器化部署，服務注冊發現，流量控制和熔斷，微服務模塊的拆分，微服務API接口的識別和定義，服務治理，微服務開發框架，微服務實施，HttpRest接口，微服務模塊集成，開發過程，技術中臺。
而所有上面的內容基本都圍繞微服務架構相關點展開，那么這些零散的點到后面就需要進行整理和歸納，讓零散的知識體系結構化。
如何結構化？
簡單來說仍然還是這些知識朝上面聚合，而聚合后可能形成動態結構，也可能形成靜態結構。靜態結構重點圍繞微服務架構展開，而動態結構圍繞微服務開發全生命周期展開。
再來看微服務架構核心概念模型本質是做兩件事情。
一是拆分微服務模塊，一是模塊開發和集成，形成完整應用。那么再展開來看，從動態分析思路，微服務架構完整的生命周期就可以理解為：
規劃咨詢-》架構設計-》微服務模塊開發-》上線運行-》微服務架構應用治理
對于規劃咨詢+架構設計，重點就是要識別和劃分清楚微服務模塊，同時定義清楚模塊間的Http API接口，確保各個微服務間高內聚松耦合。對于后續各個階段重點是開發微服務模塊，并完成集成上線。而應用治理則重點是后續的管控和運維。
在這個大脈絡梳理清楚后，你會看到微服務架構開發框架在微服務模塊開發這個階段，而這個開發框架即使從開業的SpringCLoud來說，這個框架就會包括（服務注冊發現，流控，負載均衡，微服務網關，安全）等關鍵的技術組件，而這本身就是一個靜態架構展開了。
把這個梳理清楚后，你會發現我們還談到的微服務架構規范體系，DevOps和持續集成在哪個位置？而這些內容剛好就是橫向底層重要的支撐過程。首先是規范體系，其次是DevOps持續交付過程和方法論。
對于架構設計，一個重要工作就是識別和定義微服務模塊組件，同時定義組件間的http api接口。在談整體架構框架的時候，參考SOA思想，一個重點就是分層，而這個分層重點就是形成技術中臺+業務中臺+上層應用的多層分層架構。上層的應用應該是基于技術中臺加業務中臺的能力進行組裝，組合而構建出來的。
一個流程引擎的微服務模塊，屬于技術中臺，而一個是產品中心的微服務模塊則屬于業務中臺（業務中臺包括了數據中心和業務規則處理中心）。
再回來看，還剩余的類似Docker容器技術和自動化部署，完全是屬于我們整個DevOps支持過程里面的一個子過程和最佳實踐了。即沒有采用容器化部署并不影響整個架構體系是微服務架構。但是采用了容器化+DevOps是業界推薦的最佳實踐而已，這種最佳實踐可以進一步提升效率和自動化程度。
一個微服務架構更加不是否定了傳統的軟件生命周期，軟件工程和軟件項目管理，而是結合微服務架構的特點，更加強調了敏捷方法論和持續交付，持續集成的內容而已。這個時候就需要考慮我們的敏捷方法論，持續集成等最佳實踐如何和微服務架構下的開發集成進一步結合。
當然，除了微服務從架構設計和開發外，另外一個重點就是微服務模塊上線后的運維和管控治理，由于微服務拆分的比傳統單體應用粒度更細，各個微服務間的接口集成關系也更加復雜，如果沒有一個很好的治理規范和管控流程，往往導致后期微服務運營和運維失控。
因此微服務治理是微服務知識體系里面另外一個重要內容。
微服務治理不僅僅是簡單的微服務設計開發規范制定，后期微服務運行監控，而是應該覆蓋整個微服務從需求到設計，從開發到測試上線，從運維監控到變更交付的全生命周期。
經過上面思考，你會看到微服務架構知識體系，由前面說的最核心的微服務架構生命周期，進一步擴展到規范體系和支撐工具集，軟件項目管理和敏捷方法論三者的融合。而這和傳統的CMMI談的項目管理+軟件工程+支撐過程域也是完全對應的。
有了上面的思考，基本就可以看到微服務架構整體知識體系就梳理清楚了。
但是可以看到上面仍然還是從道理上面的進一步闡述，你只是道理上理解的更加細化了，接著要做的還是圍繞這些知識點展開實踐，你可以從采用最近的SpringCloud框架，開發Rest接口服務做起，然后再過渡到多個微服務模塊間的持續集成，后期的微服務架構管控治理。只有這樣，你才能對微服務架構有完整的理解，而不是僅僅局限在會使用SpringCloud框架。
