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