0、目錄
整體架構目錄：ASP.NET Core分布式項目實戰-目錄
一、微服務選型
在做微服務架構的技術選型的時候，我們以“無侵入”和“社區活躍”為主要的考量點，將來升級為原子服務架構、量子服務架構的時候、甚至恢復成單體架構的時候，代價最小。因此軟件開發只需要組裝，不再需要從頭開發。
選型也可以參考一下張隊長的文章：微軟MVP張善友告訴你，微服務選型要注意這些地方
二、微服務架構是什么？
按照我的理解介紹一下微服務架構是什么吧。
每一個微服務都是一個零件，並使用這些零件組裝出不同的形狀。微服務架構就是把一個大系統按業務功能分解成多個職責單一的小系統，並利用簡單的方法使多個小系統相互協作，組合成一個大系統。
服務之間互相協調、互相配合，為用戶提供最終價值，每個服務運行在其獨立的進程中，服務於服務間采用輕量級的通信機制互相協作，通常是基於HTTP協議的RESTful API或者RPC。
說白了其核心思想：把大系統拆分為小系統。
三、微服務組件
服務注冊：服務提供方將自己調用地址注冊到服務注冊中心，讓服務調用方能夠方便地找到自己。
服務發現：服務調用方從服務注冊中心找到自己需要調用的服務的地址。
負載均衡:
服務網關：服務網關是服務調用的唯一入口。
配置中心:
API管理：
集成框架：微服務組件都以職責單一的程序包對外提供服務，集成框架以配置的形式將所有微服務組件（特別是管理端組件）集成到統一的界面框架下，讓用戶能夠在統一的界面中使用系統。
分布式事務：保證數據的一致性
調用鏈 ：記錄完成一個業務邏輯時調用到的微服務，並將這種串 行或並行的調用關系展示出來。在系統出錯時，可以方便地找到 出錯點。 （監控）
支撐平台：由於微服務化后，系統變得更加碎片化，系統的部署、運維、監控等都比單體架構更加復雜，就需要用到自動化.
四、微服務架構優勢？為什么要采用微服務架構？
微服務與單體的比較，可看下圖：
看到上面是不是覺得我們可以用微服務啦，但是要用微服務需要滿足一定的條件，如下：（只有復雜、大項目采用）
什么時候選用微服務呢？
從個人來看，有三種場景可以考慮使用微服務
1、規模大 ，團隊超過10人
2、業務復雜度高，系統超過5個子模塊
3、需要長期演進，項目開發和維護周期超過半年
五、快速體驗微服務架構
要想體驗微服務，只要輕輕松松四個步驟，如下：
使用微服務簡單模式進行開發的四個步驟：
1、沿用組織中現有的技術體系開發單一職責的微服務
2、服務提供方將地址信息注冊到注冊中心，調用方將服務地址從注冊中心拉下來。
3、通過門戶后端（服務網關）將服務API暴露給門戶和移動APP。
4、將管理端模塊集成到統一的操作界面上。
是不是get到技能啦！！！
六、運維
這一步是項目的最終實現，當然這里也需要很多技術的配合，想了解devops的請持續關注我的博客吧。
基礎設施：自動構建、自動部署、日志中心、健康 檢查、性能監控等功能
gitlab-CI/CD、Jenkins+gitlab-CI/CD：自動化部署
K8s&Docker+Jenkins&Pipeline+Gitlab--CI/CD：自動化部署
ELK:日志
zipkin/skywalking：微服務監控
七、總結
我們只需要在開發 層面理解了注冊中心、服務發現、負載均衡、服務網關和管理端集成框架， 在運維層面准備好持續集成工具、配置中心和監控告警工具，就可以很容 易地落地微服務架構，享受微服務架構帶來的精彩。祝大家玩得愉快。
八、微服務架構API的開發與治理
1、開放給互聯網用戶調用的API需要在API網關上加上授權、鑒權、限流、限並發、統計、計費等功能
2、內網環境：提供給內網里的其他微服務調用的API。
1、內網環境API開發
1、需要先考慮是用HTTP API還是RPC？
HTTP API：
指的是簡單的基於HTTP協議的API，具體的例子就是MVC的Controller,
http://127.0.0.1/helloworld
RPC:
遠程過程調用(大多數指Socker通信方法的遠程調用)，也可以使用HTTP協議來實現RPC調用，例如gRPC.
HTTP 簡單、RPC基於Socket的RPC性能更好。但我最后還是選擇了HTTP API來使用。
2、HTTP API 的性能足以支撐多數項目
RPC的協議吞吐量是HTTP性能的幾倍，如 protobuf、Thrift、Kyro、Dubbo
等，在考慮自身技術棧、成本、穩定性、易用性、可維護性、業務場景等因素考慮，HTT和RPC的性能差別並不是主要問題。
九、如何保障微服務架構下的數據一致性（粗略的介紹）
以電商平台為例，當用戶下單並支付后，系統需要修改訂單的狀態並
且增加用戶積分。由於系統采用的是微服務架構，分離出了支付服務、訂 單服務和積分服務，每個服務都有獨立數據庫做數據存儲。當用戶支付成 功后，無論是修改訂單狀態失敗還是增加積分失敗，都會 造成數據的不 一致。
然而微服務架構下，每個微服務都有自己的數據庫，導致微服務架構 的系統不能簡單地滿足 ACID，我們就需要尋找微服務架構下的數據一致性解決方案：
CAP是指在一個分布式系統下，包含三個要素：：Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性），並且 三者不 可得兼。
C:所有數據變動都是同步的
A：即在可以接受的時間范圍內正確的相應用戶請求
P：分區容錯性，即某節點或網絡分區故障時，系統仍能提供滿足一致性和可用性的服務。
在分布式系統下，為了保證模塊的分區容錯性，只能在數據強一致性和可用性之間做平衡。具體表現為在一定時間內，可能模塊之間數據是不一致的，但是通過自動或者手動補償后能夠達到最終的一致。
分享我們是如何保證微服務架構的數據一致性的：
1、可靠消息最終一致性（適用於跨平台技術棧不統一的場景）
利用MQ組件實現的二階段提交，涉及三個模塊：
A、上游應用，執行業務並發送MQ消息
B、可靠消息服務和MQ消息組件，協調上下游消息的傳遞，並確保上下游數據的一致性。
C、下游應用，監聽MQ的消息並執行自身業務。
2、TCC方案
涉及三個模塊：主業務、從業務、活動管理器
1、主業務服務分別調用所有從業務服務的try操作，並在活動管理器中記錄所有從業務服務。當所有從業服務try成功或者某個從業服務try失敗時，進入第二階段。
2、活動管理器根據第一階段從業服務的try結果來執行confirm或cancel操作。如果第一階段所有從業務服務都try成功，則協作者調用所有從業服務的confirm操作，否則，調用所有從業務服務的cancel操作。
Confirm 失敗：則回滾所有 confirm 操作並執行 cancel 操作。
Cancel 失敗：從業務服務需要提供自動 cancel 機制，以保證 cancel 成功。
寫到這里，我已經詞窮了，因為針對數據一致性問題，要考慮的非常多。上面的寫的不夠完善
等有機會，我會專門開設關於微服務架構結合DDD實現數據強一致性和最終一致性的問題探討。
樓主努力學習中。
參考地址：
張隊長文章：微軟MVP張善友告訴你，微服務選型要注意這些地方
asp.net Core 交流群：787464275 歡迎加群交流
如果您認為這篇文章還不錯或者有所收獲，您可以點擊右下角的【推薦】按鈕精神支持，因為這種支持是我繼續寫作，分享的最大動力！
微信公眾號：歡迎關注 QQ技術交流群： 歡迎加群
