微服務
定義：
它是一種架構模式，提倡將大的單體系統，按業務拆分成一個個較小且獨立的服務，服務與服務之前進行相互協作和配合。
歷史：
針對網際網路行業的蓬勃發展，需要支撐的業務越來越多，越來越大，單體程式越來越難以支撐，因此才出現了微服務的這種架構。
優點：
它的優點主要是與單體程式相比
1.開發獨立：因開發獨立就可以使用不同的語言進行開發，這樣就更能發揮出各語言擅長的方面。
2.低耦合 ：服務與服務間採用輕量級的通訊機制相溝通（Http，tcp/id），當某一服務出現問題，可以通過“降級熔斷”等手段來保證系統不雪崩。
3.獨立部署：這個就厲害了，獨立部署帶給我們的就是快速的迭代，完全與現在的敏捷開發相符。
4.橫向擴充套件：這就是對於某一個服務的壓力大的時候，我們就可以針對這一個服務進行叢集擴充套件，而不像原單體系統那樣，需要整個系統作擴充套件。
缺點：
1.因架構使各服務（系統）的顆粒度更小了，整體來說對開發和維護的難度就增加。（當然現在以雲的方式部署，因此能遮蔽一些問題）
2.因服務與服務之前的通訊機制是網路的方式，因此對於單體的程式內通訊就顯得執行效率降下來了。
原則：
1.單一職責：每個微服務只需要實現自己的業務邏輯就可以了，比如訂單管理模組，它只需要處理訂單的業務邏輯就可以了，其它的不必考慮
2.服務自治：每個微服務從開發、測試、運維等都是獨立的，包括儲存的資料庫也都是獨立的，自己就有一套完整的流程，我們完全可以把它當成一個專案來對待。不必依賴於其它模組。
3.輕量級通訊：首先是通訊的語言非常的輕量，第二，該通訊方式需要是跨語言、跨平臺的，之所以要跨平臺、跨語言就是為了讓每個微服務都有足夠的獨立性，可以不受技術的鉗制。
4.介面明確：由於微服務之間可能存在著呼叫關係，為了儘量避免以後由於某個微服務的介面變化而導致其它微服務都做調整，在設計之初就要考慮到所有情況，讓介面儘量做的更通用，更靈活，從而儘量避免其它模組也做調整。
使用：
服務拆分：
1.微服務拆分原則:領域模型、限定上下文、組織架構、康威定律
2.每個服務有自己的資料庫
3.微服務之間確定服務邊界,通過共享模型建立聯絡
資料一至性
1.使用最終一致性來代替強一致性
2.可靠性事件模式
3.補嘗模式
服務通訊
1.通訊技術方案: RPC vs REST vs 非同步訊息
2.服務註冊和發現
3.負載均衡
服務閘道器
1.API Gateway
2.劃分前端服務的後端服務，移動端服務
3.身份認證、路由服務、限流防刷、日誌統計
高可觀察
1.健康檢測、集中監控
2.日誌聚合及檢索
3.分散式追蹤
可靠性
1.流量控制，超時控制
2.艙壁隔離，熔斷機制
3.服務降級, 冪等重試
微服務是近期興起的一種架構模式，因此再使用時，我們就會遇到不同的坑，比如需要依賴的中介軟體更新速度比較快，因此會造成每個版本在使用上的不同。因此在使用時請注意儘量選擇一些大公司已經使用的技術。
在.Net Core中使用的技術
服務治理發現：Consul
熔斷降級：Polly
閘道器： Ocelot
身份認證：Identity Server
RPC通訊：Thirft
分散式配置中心：Apollo（阿波羅）
監控外掛：App Metrics
分散式日誌收集框架: Exceptionless
時間序列資料庫:InfluxDB
開源儀表盤工具:Grafana