了解什么是微服務
參考：https://www.cnblogs.com/skabyy/p/11396571.html
一）、原有單體服務的弊端
場景演示：
需求：小明和小皮一起創業做網上超市 的故事
功能：
網站
- 用戶注冊、登錄功能
- 商品展示
- 下單
管理后台
- 用戶管理
- 商品管理
- 訂單管理
二）、業務拓展：
- 網站系統增加促銷活動功能
- 增加移動設備：微信小程序，移動App(移動設備的功能和網站的功能相同)，
- 在后台系統添加促銷管理和數據分析
- 四個系統共用一個數據庫
業務擴展后架構出現的弊端;
1.網站和移動端應用有很多相同業務邏輯的重復代碼
2.數據有時候通過數據庫共享，有時候通過接口調用傳輸。接口調用關系雜亂
3.數據庫表結構被多個應用依賴，無法重構和優化
4.所有應用都在一個數據庫上操作,數據庫性能急劇下降
5.開發、測試、部署、維護愈發困難, 即使只改動一個小功能，也需要整個應用一起發布 ,
三）、微服務的特點：
抽象：抽象出公用的業務能力，做成幾個公共服務
解決了各應用間數據庫的共用問題：一個服務對應一個數據庫
數據庫拆分產生的問題和挑戰 ：跨庫級聯的需求
四）、日志排查
原有單體系統的日志排查：查看日志，研究錯誤信息和調用堆棧
在微服務架構中，一個服務故障可能會產生雪崩效用，導致整個系統故障
五）、微服務的弊端
1.微服務架構整個應用分散成多個服務，定位故障點非常困難
2.穩定性下降，一個服務出現故障 ，可能導致整個系統掛掉
3.服務數量非常多，部署、管理的工作量很大
4.如何保證各個服務在持續開發的情況下仍然保持協同合作
5.原本單個程序的測試變為服務間調用的測試。測試變得更加復雜
六）、如何進行故障處理：
減少錯誤：事前監控，事后分析
降低影響：容錯，服務降級
建立完善的監控體系
微服務架構中組件繁多 ,各個組件所需要監控的指標不同 ,做一個大而全的監控系統來監控各個組件是不大現實的
例如：Redis緩存監控的指標有占用內存值 ，網絡流量 ，數據庫監控連接數 ，磁盤空間 ，業務服務監控並發數，響應延遲、錯誤率等
如何實現監控：
1.各個組件提供報告自己當前狀態的接口（metrics接口）
2.接口輸出的數據格式一致
3.部署一個指標采集器組件，定時從這些接口獲取並保持組件狀態，提供查詢服務
4.需要一個UI ，從指標采集器查詢各項指標 ，繪制監控界面 或 根據閾值發出告警。
例如：Redis緩存和MySQL數據庫的指標接口：RedisExporter和MySQLExporter （網上有開源組件）
使用采用Prometheus作為指標采集器
六）、鏈路跟蹤
什么叫鏈路跟蹤？
一個用戶的請求往往涉及多個內部服務調用
鏈路跟蹤 ：記錄每個用戶請求 ，記錄微服務內部產生了多少服務調用，及其調用關系
實現鏈路跟蹤：
1）、服務調用要在HTTP的HEADERS中記錄至少四項數據
1.traceId ：標識一個用戶請求的調用鏈路，具有相同traceId的調用屬於同一條鏈路
2.spanId ：標識一次服務調用的id
3.parentId : 父節點的spanId
4.requestTime & responseTime : 請求時間和響應時間
2）、調用日志收集與存儲的組件，以及展示鏈路調用的UI組件
鏈路跟蹤的實現過程：
使用HTTP請求的攔截器，在每次HTTP請求時生成這些數據注入到HEADERS，同時異步發送調用日志到Zipkin的日志收集器中
鏈路跟蹤只能定位到哪個服務出現問題 ，查找具體的錯誤信息的能力則需要由日志分析組件來提供
日志分析
ELK（Elasticsearch、Logstash和Kibana ）日志分析組件：
Elasticsearch：搜索引擎，同時也是日志的存儲
Logstash：日志采集器，它接收日志輸入，對日志進行一些預處理，然后輸出到Elasticsearch
Kibana：UI組件，通過Elasticsearch的API查找數據並展示給用戶
日志分析過程：
日志輸出到文件------》每個服務里再部署個Agent，掃描日志文件 -------》輸出給logstash