一、什麼是微服務
1、微服務的由來
2、爲什麼需要微服務
3、微服務與單體架構區別
（1）單體架構所有的模塊全都耦合在一塊，代碼量大，維護困難。
微服務每個模塊就相當於一個單獨的項目，代碼量明顯減少，遇到問題也相對來說比較好解決。
（2）單體架構所有的模塊都共用一個數據庫，存儲方式比較單一。
微服務每個模塊都可以使用不同的存儲方式（比如有的用redis，有的用mysql等），數據庫也是單個模塊對應自己的數據庫。
（3）單體架構所有的模塊開發所使用的技術一樣。
微服務每個模塊都可以使用不同的開發技術，開發模式更靈活。
4、微服務本質
（1）微服務，關鍵其實不僅僅是微服務本身，而是系統要提供一套基礎的架構，這種架構使得微服務可以獨立的部署、運行、升級，不僅如此，這個系統架構還讓微服務與微服務之間在結構上“松耦合”，而在功能上則表現爲一個統一的整體。這種所謂的“統一的整體”表現出來的是統一風格的界面，統一的權限管理，統一的安全策略，統一的上線過程，統一的日誌和審計方法，統一的調度方式，統一的訪問入口等等。
（2）微服務的目的是有效的拆分應用，實現敏捷開發和部署 。
（3）微服務提倡的理念團隊間應該是 inter-operate, not integrate 。inter-operate是定義好系統的邊界和接口，在一個團隊內全棧，讓團隊自治，原因就是因爲如果團隊按照這樣的方式組建，將溝通的成本維持在系統內部，每個子系統就會更加內聚，彼此的依賴耦合能變弱，跨系統的溝通成本也就能降低。
5、什麼樣的項目適合微服務
微服務可以按照業務功能本身的獨立性來劃分，如果系統提供的業務是非常底層的，如：操作系統內核、存儲系統、網絡系統、數據庫系統等等，這類系統都偏底層，功能和功能之間有着緊密的配合關係，如果強制拆分爲較小的服務單元，會讓集成工作量急劇上升，並且這種人爲的切割無法帶來業務上的真正的隔離，所以無法做到獨立部署和運行，也就不適合做成微服務了。
6、微服務開發框架
目前微服務的開發框架，最常用的有以下四個：
Spring Cloud：http://projects.spring.io/spring-cloud（現在非常流行的微服務架構）
Dubbo：http：//dubbo.io
Dropwizard：http://www.dropwizard.io （關注單個微服務的開發）
Consul、etcd&etc.（微服務的模塊）
7、什麼是Spring Cloud
8、Spring Cloud和Spring Boot是什麼關係
9、Spring Cloud相關基礎服務組件
10、Spring Cloud的版本
Spring Cloud並沒有熟悉的數字版本號，而是對應一個開發代號。
| Cloud代號 | Boot版本(train) | Boot版本(tested) | lifecycle |
|---|---|---|---|
| Angle | 1.2.x | incompatible with 1.3 | EOL in July 2017 |
| Brixton | 1.3.x | 1.4.x | 2017-07卒 |
| Camden | 1.4.x | 1.5.x | - |
| Dalston | 1.5.x | not expected 2.x | - |
| Edgware | 1.5.x | not expected 2.x | - |
| Finchley | 2.0.x | not expected 1.5.x | - |
| Greenwich | 2.1.x | ||
| Hoxton | 2.2.x |
開發代號看似沒有什麼規律，但實際上首字母是有順序的，比如：Dalston版本，我們可以簡稱 D 版本，對應的 Edgware 版本我們可以簡稱 E 版本。
小版本
Spring Cloud 小版本分爲:
SNAPSHOT： 快照版本，隨時可能修改
M： MileStone，M1表示第1個里程碑版本，一般同時標註PRE，表示預覽版版。
SR： Service Release，SR1表示第1個正式版本，一般同時標註GA：(GenerallyAvailable),表示穩定版本。