目標系統架構演變，單體-分布式-微服務-中台
微服務架構核心解決，橫向對比1.0、2.0、3.0
踐行微服務架構，全組件解讀！
也談中台
單體架構Monolithic
單體應用時代：應用程序就是一個項目，在一個進程里面運行。
簡單-省事兒
電商UI->（自營、秒殺、超市、生鮮、金融）->DB
弊端就是東西都堆在一起，不能滿足大數據高並發的訴求，邏輯太多，很難升級。
業務演進推動技術的發展。
垂直拆分
垂直拆分，獨立部署和維護，分而治之！
優勢：
1.獨立開發、獨立維護、獨立演化；
2.更好的利用資源；
劣勢：
1.進程間數據同步，分家時斷不掉聯系的，聯系就麻煩了；
2.分布式的代價，使用數據庫時對數據進行加鎖，數據更新事務的問題；
3.代碼重復問題，如支付、用戶管理等問題；
分布式的第一要務就是不要使用分布式。
分布式服務
分布式：多個進程協作完成一件事兒，多進程抽取公用服務，分布式完成功能。
分布式代價很高。
例如，自營服務調用用戶服務、支付服務、日志服務等，依次順序調用，如果對應服務失敗是否需要回退數據，以及對應數據的處理邏輯是如何處理的。
分布式事務、分布式鎖、服務注冊、服務發現、服務安全、服務治理等等，多個問題都需要解決。
新的問題，也是會被解決的，問題都被解決后，分布式就成了常規手段，輕松的用來高並發，而且都不僅僅於此，包括故意分拆滿足擴展性。
微服務架構
分布式用到走火入魔，就是微服務。
微服務架構（Microsercice Architecture）是什么？
微服務架構就是一個用分布式服務拆分業務邏輯，完成解耦的架構模式（架構風格）。
微服務肯定是分布式的一種，是在分布式技術成熟之后，然后把分布式當成解耦手段來架構系統，是因為拆分服務很細致。
一個項目：三層架構-UI/BLL/DAL
微服務就是把BLL的方法獨立成一個服務去調用。
構建微服務架構，其根基是什么？
把方法都拆成獨立服務了，怎么樣保證項目是可用的呢？
1.保證服務的高可用；
2.服務的可伸縮性；
微服務架構的三個版本的區別也是解決上面兩個特性：v1.0、v2.0、v3.0。
微服務架構核心
基於集群去完成高可用以及伸縮性，集群就是多台服務器都做相同的事情，構建集群。
必須解決以下幾個問題：
1.服務發現，調用方如何發現服務？
2.負載均衡，如何調用服務？
集中式代理-Nginx-v1.0
基於Nginx負載均衡,v1.0
1.服務發現，調用方如何發現服務？
2.負載均衡，如何調用服務？
服務發現：Nginx通過人工配置，指定服務配置數據，完成服務發現，服務伸縮如何處理？需要修改配置文件重啟。
不能實現自動擴張，可以自動減少，如果減少時會自動重啟Nginx，其自身的屬性。
服務調用：由Nginx決定，比較省心。
客戶端嵌入-Consul-v2.0
服務注冊，非人工，怎么找服務的問題，有客戶端決定調用的服務實例。
1.負載均衡；
2.服務注冊與發現；
3.健康檢查；
功能強大，自動發現-自動下線。
客戶端集成復雜，負載均衡在客戶端實現。
網絡的環境是非常復雜的，要以最壞的情況來考慮。
目前用的比較主流。
服務網絡-Service Mesh-v3.0
v3.0用的不多，華為+為品味，主機+代理，lstio
邊車模式，限流、熔斷均在sidecar中實現。
MicroService發展
1.0 Nginx-服務注冊/發現問題
2.0 自動注冊發現，熔斷/限流/降級等服務治理
3.0 Service Mesh
都在無止境的包一層，沒有什么技術問題是包一層不能解決的，如果有，就再包一層。
微服務架構2.0-網關-Gateway
網關的位置就明白了，主要用於服務治理，可以緩存數據，路由映射，限流，熔斷，超時，降級
不響應是為了更好的響應。
客戶端該如何調用服務？
進程間通信-共享存儲
Redis、隊列、第三方存儲
進程通信-服務通信
WebService、WCF、WebAPI
進程通信-RPC
.NET Core、gRPC
鑒權&授權
基於token的安全驗證體系。
在網關中實現，JWT、Identity Server 4.
瞬態故障處理
Polly是一種.NET彈性瞬態故障處理庫，允許我們以非常順暢和線程安全的方式來執行如進行充實、斷流、超時、故障恢復等策略。
分布式追蹤Skywalking-全鏈路追蹤
分布式追蹤和APM的Server端，它將包含Collector、Storage、獨立的Web UI，並使用Open Tracing規范來設計追蹤數據。
ExceptionLess or ELK
ExceptionLess：開源的日志收集和分析框架，能為應用程序提供實時錯誤、特性和日志報告。
統一的配置中心
Apollo：配置管理平台，能夠集中化管理應用不同環境、不用集群的配置，配置修改后能夠實時推送到應用端，並且具備規范的權限、流程治理等特性。
分布式鎖
單進程下，多線程操作同一個對象，可以使用lock鎖保證只有一個線程可以進入。
多線程（分布式）下，如何保證該對象在任意時刻只能一個線程進入呢？
變量A是由狀態的，不同故武器進程內跨進程的互斥機制來控制其共享資源的訪問，這就是分布式鎖。
分布式事務
分布式事務指事務的操作位於不同的節點上，需要保證事務的 AICD 特性。
例如在下單場景下，庫存和訂單如果不在同一個節點上，就涉及分布式事務。
1.兩階提交-2PC
2.補償事務-TCC
3.本地消息表（異步確認）
4.MQ-事務消息
本地消息表
本地消息表與業務數據表處於同一個數據庫中，這樣就能利用本地事務來保證在對這兩個表的操作滿足事務特性，並且使用了消息隊列來保證最終一致性。
-
在分布式事務操作的一方完成寫業務數據的操作之后向本地消息表發送一個消息，本地事務能保證這個消息一定會被寫入本地消息表中。
-
之后將本地消息表中的消息轉發到 Kafka 等消息隊列中，如果轉發成功則將消息從本地消息表中刪除，否則繼續重新轉發。
-
在分布式事務操作的另一方從消息隊列中讀取一個消息，並執行消息中的操作。
容器化
Docker是一個開源的應用容器引擎，可以打包應用以及以來包到一個可移植的鏡像。
Build once run any where.
容器編排K8S
管理應用的全生命周期的工具，從創建應用/部署，應用提供服務，擴容縮容，更新，都非常的方便，與Docker結合使用。
CI/CD