微服务介绍及Asp.net Core实战项目系列之微服务介绍
0、目錄
?整體架構目錄：ASP.NET Core分布式項目實戰-目錄
?
一、微服務選型
在做微服務架構的技術選型的時候，以“無侵入”和“社區活躍”為主要的考量點，將來升級為原子服務架構、量子服務架構的時候、甚至恢復成單體架構的時候，代價最小。
軟件開發只需要組裝，不再需要從頭開發。
選型可以參考一下張隊長的文章：?微軟MVP張善友告訴你，微服務選型要注意這些地方
二、微服務架構是什么？
?
每一個微服務都是一個零件，并使用這些零件組裝出不同的形狀。微服務架構就是把一個大系統按業務功能分解成多個職責單一的小系統，并利用簡單的方法使多個小系統相互協作，組合成一個大系統。
服務之間互相協調、互相配合，為用戶提供最終價值，每個服務運行在其獨立的進程中，服務于服務間采用輕量級的通信機制互相協作，通常是基于HTTP協議的RESTful API或者RPC。
核心思想：把大系統拆分為小系統。
三、微服務組件
服務注冊：服務提供方將自己調用地址注冊到服務注冊中心，讓服務調用方能夠方便地找到自己。
服務發現：服務調用方從服務注冊中心找到自己需要調用的服務的地址。
負載均衡:
服務網關：服務網關是服務調用的唯一入口。
配置中心:
API管理：
集成框架：微服務組件都以職責單一的程序包對外提供服務，集成框架以配置的形式將所有微服務組件（特別是管理端組件）集成到統一的界面框架下，讓用戶能夠在統一的界面中使用系統。?
分布式事務：保證數據的一致性
調用鏈 ：記錄完成一個業務邏輯時調用到的微服務，并將這種串 行或并行的調用關系展示出來。在系統出錯時，可以方便地找到 出錯點。 （監控）
支撐平臺：由于微服務化后，系統變得更加碎片化，系統的部署、運維、監控等都比單體架構更加復雜，就需要用到自動化.
四、微服務架構優勢？為什么要采用微服務架構？
?
微服務與單體的比較，可看下圖：
什么時候選用微服務呢？
從個人來看，有三種場景可以考慮使用微服務
1、規模大 ，團隊超過10人
2、業務復雜度高，系統超過5個子模塊
3、需要長期演進，項目開發和維護周期超過半年
?
五、快速體驗微服務架構
?
使用微服務簡單模式進行開發的四個步驟：
1、沿用組織中現有的技術體系開發單一職責的微服務
2、服務提供方將地址信息注冊到注冊中心，調用方將服務地址從注冊中心拉下來。
3、通過門戶后端（服務網關）將服務API暴露給門戶和移動APP。
4、將管理端模塊集成到統一的操作界面上。
?
六、運維
?
基礎設施：自動構建、自動部署、日志中心、健康 檢查、性能監控等功能
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 成功。
?參考地址：
張隊長文章：?微軟MVP張善友告訴你，微服務選型要注意這些地方
原文地址:?https://www.cnblogs.com/guolianyu/p/9568400.html
.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com
總結
以上是生活随笔為你收集整理的微服务介绍及Asp.net Core实战项目系列之微服务介绍的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： AspNetCore中使用Ocelot之
- 下一篇： 你需要知道的这几种 asp.net co