微服務介紹及Asp.net Core實戰項目系列之微服務介紹

標籤：活動管理   不同   partition   strong   商務邏輯   統計   理解   htm   blank   

0、目錄

 整體架構目錄：ASP.NET Core分布式項目實戰-目錄

 

一、微服務選型

在做微服務架構的技術選型的時候，以“無侵入”和“社區活躍”為主要的考量點，將來升級為原子服務架構、量子服務架構的時候、甚至恢複成單體架構的時候，代價最小。

軟體開發只需要組裝，不再需要從頭開發。

選型可以參考一下張隊長的文章：https://mp.weixin.qq.com/s/UIFjm7W6bDfdmjpeMVJtqA

二、微服務架構是什嗎？

 

每一個微服務都是一個零件，並使用這些零件組裝出不同的形狀。微服務架構就是把一個大系統按業務功能分解成多個職責單一的小系統，並利用簡單的方法使多個小系統相互協作，組合成一個大系統。
服務之間互相協調、互相配合，為使用者提供最終價值，每個服務運行在其獨立的進程中，服務於服務間採用輕量級的通訊機制互相協作，通常是基於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 Gateway上加上授權、鑒權、限流、限並發、統計、計費等功能

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、可靠Message Service和MQ訊息組件，協調上下遊訊息的傳遞，並確保上下遊資料的一致性。
C、下遊應用，監聽MQ的訊息並執行自身業務。

2、TCC方案

涉及三個模組：主業務、從業務、Active Manager
1、主商務服務分別調用所有從商務服務的try操作，並在Active Manager中記錄所有從商務服務。當所有從業服務try成功或者某個從業服務try失敗時，進入第二階段。
2、Active Manager根據第一階段從業服務的try結果來執行confirm或cancel操作。如果第一階段所有從商務服務都try成功，則共同作業者調用所有從業服務的confirm操作，否則，調用所有從商務服務的cancel操作。
Confirm 失敗：則復原所有 confirm 操作並執行 cancel 操作。
Cancel 失敗：從商務服務需要提供自動 cancel 機制，以保證 cancel 成功。

 

參考地址：

張隊長文章：https://mp.weixin.qq.com/s/UIFjm7W6bDfdmjpeMVJtqA

文檔參考地址：《從 0 開始的微服務架構》

文檔：《從 0 開始的微服務架構》

 

asp.net Core 交流群：787464275 歡迎加群交流
如果您認為這篇文章還不錯或者有所收穫，您可以點擊右下角的【推薦】按鈕精神支援，因為這種支援是我繼續寫作，分享的最大動力！

LouieGuo
聲明：原創部落格請在轉載時保留原文連結或者在文章開頭加上本人部落格地址，如發現錯誤，歡迎批評指正。凡是轉載於本人的文章，不能設定打賞功能，如有特殊需求請與本人聯絡！

微服務介紹及Asp.net Core實戰項目系列之微服務介紹