微服務
定義：
它是一種架構模式，提倡將大的單體系統，按業務拆分成一個個較小且獨立的服務，服務與服務之前進行相互協作和配合。
歷史：
針對互聯網行業的蓬勃發展，需要支撐的業務越來越多，越來越大，單體程序越來越難以支撐，因此才出現了微服務的這種架構。
優點：
它的優點主要是與單體程序相比
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