微服務架構強調的第一個重點就是業務系統需要徹底的元件化和服務化，原有的單個業務系統會拆分為多個可以獨立開發，設計，執行和運維的小應用。這些小應用之間通過服務完成互動和整合。每個小應用從前端web ui，到控制層，邏輯層，資料庫訪問，資料庫都完全是獨立的一套。在這裡我們不用元件而用小應用這個詞更加合適，每個小應用除了完成自身本身的業務功能外，重點就是還需要消費外部其它應用暴露的服務，同時自身也將自身的能力朝外部發布為服務。如果一句話來談SOA和微服務的區別，即微服務不再強調傳統SOA架構裡面比較重的ESB企業服務匯流排，同時SOA的思想進入到單個業務系統內部實現真正的元件化。 把這個核心搞清楚後，再來看下網上找到的對微服務架構的一些定義和闡述：  

微服務可以在“自己的程式”中執行，並通過“輕量級裝置與HTTP型API進行溝通”。關鍵在於該服務可以在自己的程式中執行。通過這一點我們就可以將服務公開與微服務架構（在現有系統中分佈一個API）區分開來。在服務公開中，許多服務都可以被內部獨立程序所限制。如果其中任何一個服務需要增加某種功能，那麼就必須縮小程序範圍。在微服務架構中，只需要在特定的某種服務中增加所需功能，而不影響整體程序。 微服務不需要像普通服務那樣成為一種獨立的功能或者獨立的資源。定義中稱，微服務是需要與業務能力相匹配，這種說法完全正確。不幸的是，仍然意味著，如果能力模型粒度的設計是錯誤的，那麼，我們就必須付出很多代價。如果你閱讀了Fowler的整篇文章，你會發現，其中的指導建議是非常實用的。在決定將所有元件組合到一起時，開發人員需要非常確信這些元件都會有所改變，並且規模也會發生變化。服務粒度越粗，就越難以符合規定原則。服務粒度越細，就越能夠靈活地降低變化和負載所帶來的影響。然而，利弊之間的權衡過程是非常複雜的，我們要在配置和資金模型的基礎上考慮到基礎設施的成本問題。

再強調下即：首先對於應用本身暴露出來的服務，是和應用一起部署的，即服務本身並不單獨部署，服務本身就是業務元件已有的介面能力釋出和暴露出來的。瞭解到這點我們就看到一個關鍵，即我們在進行單個應用元件設計的時候，本身在元件內部就會有很大介面的設計和定義，那麼這些介面我們可以根據和外部其它元件協同的需要將其釋出為微服務，而如果不需要對外協同我們完全可以走內部API介面訪問模式提高效率。其次，微服務架構本身來源於網際網路的思路，因此元件對外發布的服務強調了採用HTTP Rest API的方式來進行。這個也可以看到在網際網路開放能力服務平臺基本都採用了Http API的方式進行服務的釋出和管理。從這個角度來說，元件超外部暴露的能力才需要釋出為微服務，其本身也是一種封裝後的粗粒度服務。而不是將元件內部的所有業務規則和邏輯，元件本身的底層資料庫CRUD操作全部朝外部發布。否則將極大的增加服務的梳理而難以進行整體服務管控和治理。微服務的基本思想在於考慮圍繞著業務領域元件來建立應用，這些就應用可獨立地進行開發、管理和加速。在分散的元件中使用微服務雲架構和平臺使部署、管理和服務功能交付變得更加簡單。

對於網際網路談到微服務架構一定會談到Devops即開發測試和部署運維的一體化。當我們的單體應用以及拆分為多個小應用後，雖然整體架構可以鬆耦合和可擴充套件，但是如果拆分的元件越多，這些元件之間本身的整合和部署運維就越複雜。即任何一個元件，當他依賴的外部其它應用元件越多的時候，整個整合，部署和聯調測試的過程就越複雜。這些如果完全靠我們手工去完成一是增加工作量，一是增加出錯概率。 原來談元件化開發談的最多的是單個元件的持續整合，包括配置環境整合，自動打包部署，自動化的冒煙測試等。對於微服務架構下首先仍然是要做好單個元件本身的持續整合，其次在這個基礎上增加了多個元件的打包部署和元件間的整合。裡面的核心思想就是Devops的思路，希望能夠實現開發設計到部署運維的一體化。 由於微服務架構裡面強調了單個元件本身是可以在獨立的程序裡面執行，各個元件之間在部署的時候就能夠做到程序級別的隔離。那麼一臺伺服器我們可能需要初始化幾十個甚至更多的程序來進行應用元件的部署。為了保持程序的隔離性，我們可以用虛擬機器，但是當幾十個程序都完全用獨立的虛擬機器就不現實的，而這個問題的解決剛好就是利用PaaS平臺裡面的輕量Docker容器來做這個事情，每個Docker是獨立的容器剛好又完全做到程序級別的隔離，資源佔用率又最小，這些特點剛好滿足微服務架構的開發測試和自動化部署。 前面這些問題思考清楚後就是考慮所有暴露的微服務是否需要一個統一的服務管控和治理平臺，按照當前微服務架構的整體思路，雖然單個服務的實現和釋出仍然是在元件內部完成的，但是這些元件暴露的服務本身的呼叫情況，服務本身的安全，日誌和流量控制等仍然需要一個統一的SOA服務管理平臺來完成。 由於微服務儘量都是通過HTTP API的方式暴露出去的，因此這種服務管理平臺不需要像傳統企業內部的ESB服務匯流排這麼重。但是最基本的服務註冊，服務代理，服務釋出，服務簡單的路由，安全訪問和授權，服務呼叫訊息和日誌記錄這些功能還是需要具備。類似淘寶的Dubbo架構，即可以做為微服務架構下的服務管控平臺。 對於這種服務管控平臺，核心需要討論的就是服務每次呼叫本身的訊息傳遞，輸入和輸出日誌是否需要記錄，當前就有兩種做法，一種是不記錄，管理平臺只負責服務註冊和目錄釋出，安全授權，實際的服務訪問仍然是兩個元件之間的點對點連線完成，這種方式下整個架構下獲取更高的效能，同時服務管理平臺也不容易成為大併發服務訪問下的單點瓶頸；另外一種方式就是完全記錄，在這種方式下就需要考慮服務管理平臺本身的叢集化不是，高併發下的效能問題。而個人建議最好的方式還是SOA服務管理平臺應該提供兩種管理能力，同時僅僅對核心的需要Log日誌的服務進行日誌記錄，而其它服務只提供服務目錄和訪問控制即可。