1.什麼是微服務？
這裡引用一下知乎老劉的圖檔和相關了解 https://www.zhihu.com/question/65502802/answer/802678798
網上超市：
引入了微信和APP端，進一步擴大
再次更新，把備援的子產品拿出來獨立成為一個系統
細心的朋友可以發現，這時系統的瓶頸是資料庫，是以再次更新改造，把資料庫拆分并加入消息隊列機制，商品服務和促銷服務通路頻率大是以加入了緩存機制
mq的作用
服務監控 ：
微服務架構雖然邏輯上看似完美，但也存在問題：
- 定點故障點非常困難
- 一個伺服器故障可能導緻其他伺服器一起挂掉
- 部署和管理的工作量大
- 測試不便
是以為了解決問題：1.減少故障發生的機率 2.降低故障造成的影響，是以監控體系應運而生，系統實作思路是讓各個元件報告自己目前狀态，然後用一個名額采集器元件定時擷取和儲存各元件狀态，同時可指定查詢某元件目前的狀态，最後這些資料用UI顯示。這裡拿商品服務的舉例
鍊路跟蹤：
一個使用者的請求往往涉及多個内部服務調用。為了友善定位問題，需要能夠記錄每個使用者請求時，微服務内部産生了多少服務調用，及其調用關系。這個叫做鍊路跟蹤。我們用一個Istio文檔裡的鍊路跟蹤例子來看看效果：
從圖中可以看到，這是一個使用者通路productpage頁面的請求。在請求過程中，productpage服務順序調用了details和reviews服務的接口。而reviews服務在響應過程中又調用了ratings的接口。整個鍊路跟蹤的記錄是一棵樹及一個實作方案
日志監控：
當通路數變大、或伺服器規模增多時，日志檔案的大小會膨脹到難以用文本編輯器進行通路，更糟的是它們分散在多台伺服器上面。排查一個問題，需要登入到各台伺服器去擷取日志檔案，一個一個地查找（而且打開、查找都很慢）想要的日志資訊。是以，在應用規模變大時，我們需要一個日志的“搜尋引擎”。以便于能準确的找到想要的日志。常用日志分析元件：ELK（Elasticsearch、Logstash、Kibana）
- Elasticsearch：搜尋引擎，日志存儲
- Logstash：日志采集器，它接收日志輸入，對日志進行一些預處理，然後輸出到Elasticsearch
- Kibana：UI元件，通過Elasticsearch的API查找資料并展示給使用者
EFK（Elasticsearch、Filbeat/Fluent、Kibana）：采用Fibeat或Fluent其中一種即可，倆中功能類似
- Filbeat：日志采集工具，是Logstash的優化版
- Fluent：日志采集工具
網關路由：
大量的服務，大量的接口，使得整個調用關系亂糟糟的。經常在開發過程中，寫着寫着，忽然想不起某個資料應該調用哪個服務。或者寫歪了，調用了不該調用的服務，本來一個隻讀的功能結果修改了資料……為了應對這些情況，微服務的調用需要一個把關的東西，也就是網關，每次調用時進行權限校驗。
熔斷：
當一個服務因為各種原因停止響應時，調用方通常會等待一段時間，然後逾時或者收到錯誤傳回。如果調用鍊路比較長，可能會導緻請求堆積，整條鍊路占用大量資源一直在等待下遊響應。是以當多次通路一個服務失敗時，應熔斷，标記該服務已停止工作，直接傳回錯誤。直至該服務恢複正常後再重建立立連接配接。
服務降級：
當下遊服務停止工作後，如果該服務并非核心業務，則上遊服務應該降級，以保證核心業務不中斷。比如網上超市下單界面有一個推薦商品湊單的功能，當推薦子產品挂了後，下單功能不能一起挂掉，隻需要暫時關閉推薦功能即可。
限流：
一個服務挂掉後，上遊服務或者使用者一般會習慣性地重試通路。這導緻一旦服務恢複正常，很可能因為瞬間網絡流量過大又立刻挂掉，在棺材裡重複着仰卧起坐。是以服務需要能夠自我保護——限流。限流政策有很多，最簡單的比如當機關時間内請求數過多時，丢棄多餘的請求。另外，也可以考慮分區限流。僅拒絕來自産生大量請求的服務的請求。例如商品服務和訂單服務都需要通路促銷服務，商品服務由于代碼問題發起了大量請求，促銷服務則隻限制來自商品服務的請求，來自訂單服務的請求則正常響應。
新内容補充 ，引自：https://www.jianshu.com/p/7293b148028f
什麼樣的服務才算微服務呢？
- 單一職責的。一個微服務應該都是單一職責的，這才是“微”的展現，一個微服務解決一個業務問題（注意是一個業務問題而不是一個接口）。
- 面向服務的。将自己的業務能力封裝并對外提供服務，這是繼承SOA的核心思想，一個微服務本身也可能使用到其它微服務的能力
目前國内企業使用的微服務架構主要是Spring Cloud和Dubbo（或者DubboX），但是Dubbo那兩年的停更嚴重打擊了開發人員對它的信心，Spring Cloud已經逐漸成為主流
服務注冊與發現：
應用微服務化之後，首先遇到的第一個問題就是服務發現問題，一個微服務如何發現其他微服務呢？最簡單的方式就是每個微服務裡面配置其他微服務的位址，但是當微服務數量衆多的時候，這樣做明顯不現實。是以需要使用到微服務架構中的一個最重要的元件：服務注冊中心，所有服務都注冊到服務注冊中心，同時也可以從服務注冊中心擷取目前可用的服務清單：
服務注冊與發現可選擇元件：Zookeeper、Eureka、Consul等
配置服務：
當服務數量超過一定程度之後，如果需要在每個服務裡面分别維護每一個服務的配置檔案，運維人員估計要哭了，那麼就需要用有一個配置中心來管理服務的配置問題
3.SpringCloud