來源：https://www.cnblogs.com/telwanggs/p/7101758.html
微服務架構強調的第一個重點就是業務系統需要徹底的組件化和服務化，原有的單個業務系統會拆分為多個可以獨立開發，設計，運行和運維的小應用。這些小應用之間通過服務完成交互和集成。每個小應用從前端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日誌的服務進行日誌記錄，而其它服務只提供服務目錄和訪問控制即可。
擴展閱讀
閱讀更多 Java面經 的文章
