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

0、目錄


 總體架構目錄:ASP.NET Core分佈式項目實戰-目錄html

 

1、微服務選型


在作微服務架構的技術選型的時候,咱們以「無侵入」和「社區活躍」爲主要的考量點,未來升級爲原子服務架構、量子服務架構的時候、甚至恢復成單體架構的時候,代價最小。所以軟件開發只須要組裝,再也不須要從頭開發。git

選型也能夠參考一下張隊長的文章:微軟MVP張善友告訴你,微服務選型要注意這些地方數據庫

2、微服務架構是什麼?


 按照個人理解介紹一下微服務架構是什麼吧。後端

每個微服務都是一個零件,並使用這些零件組裝出不一樣的形狀。微服務架構就是把一個大系統按業務功能分解成多個職責單一的小系統,並利用簡單的方法使多個小系統相互協做,組合成一個大系統。
服務之間互相協調、互相配合,爲用戶提供最終價值,每一個服務運行在其獨立的進程中,服務於服務間採用輕量級的通訊機制互相協做,一般是基於HTTP協議的RESTful API或者RPC。
說白了其核心思想:把大系統拆分爲小系統。微信

3、微服務組件


服務註冊:服務提供方將本身調用地址註冊到服務註冊中心,讓服務調用方可以方便地找到本身。網絡

服務發現:服務調用方從服務註冊中心找到本身須要調用的服務的地址。
負載均衡:
服務網關:服務網關是服務調用的惟一入口。
配置中心:
API管理:
集成框架:微服務組件都以職責單一的程序包對外提供服務,集成框架以配置的形式將全部微服務組件(特別是管理端組件)集成到統一的界面框架下,讓用戶可以在統一的界面中使用系統。
分佈式事務:保證數據的一致性
調用鏈 :記錄完成一個業務邏輯時調用到的微服務,並將這種串 行或並行的調用關係展現出來。在系統出錯時,能夠方便地找到 出錯點。 (監控)
支撐平臺:因爲微服務化後,系統變得更加碎片化,系統的部署、運維、監控等都比單體架構更加複雜,就須要用到自動化.架構

4、微服務架構優點?爲何要採用微服務架構?


 

微服務與單體的比較,可看下圖:併發

看到上面是否是以爲咱們能夠用微服務啦,可是要用微服務須要知足必定的條件,以下:(只有複雜、大項目採用)負載均衡

何時選用微服務呢?框架

從我的來看,有三種場景能夠考慮使用微服務
一、規模大 ,團隊超過10人
二、業務複雜度高,系統超過5個子模塊
三、須要長期演進,項目開發和維護週期超過半年

 

5、快速體驗微服務架構


 要想體驗微服務,只要輕輕鬆鬆四個步驟,以下:

使用微服務簡單模式進行開發的四個步驟:
一、沿用組織中現有的技術體系開發單一職責的微服務
二、服務提供方將地址信息註冊到註冊中心,調用方將服務地址從註冊中心拉下來。
三、經過門戶後端(服務網關)將服務API暴露給門戶和移動APP。
四、將管理端模塊集成到統一的操做界面上。

 

是否是get到技能啦!!!

6、運維


 這一步是項目的最終實現,固然這裏也須要不少技術的配合,想了解devops的請持續關注個人博客吧。

基礎設施:自動構建、自動部署、日誌中心、健康 檢查、性能監控等功能
gitlab-CI/CD、Jenkins+gitlab-CI/CD:自動化部署
K8s&Docker+Jenkins&Pipeline+Gitlab--CI/CD:自動化部署
ELK:日誌
zipkin/skywalking:微服務監控

7、總結


 

咱們只須要在開發 層面理解了註冊中心、服務發現、負載均衡、服務網關和管理端集成框架, 在運維層面準備好持續集成工具、配置中心和監控告警工具,就能夠很容 易地落地微服務架構,享受微服務架構帶來的精彩。祝你們玩得愉快。

  

8、微服務架構API的開發與治理


 

一、開放給互聯網用戶調用的API須要在API網關上加上受權、鑑權、限流、限併發、統計、計費等功能

二、內網環境:提供給內網裏的其餘微服務調用的API。

一、內網環境API開發


 

一、須要先考慮是用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來使用。

二、HTTP API 的性能足以支撐多數項目

RPC的協議吞吐量是HTTP性能的幾倍,如 protobuf、Thrift、Kyro、Dubbo
等,在考慮自身技術棧、成本、穩定性、易用性、可維護性、業務場景等因素考慮,HTT和RPC的性能差異並非主要問題。

 

 

9、如何保障微服務架構下的數據一致性(粗略的介紹)


 

 

以電商平臺爲例,當用戶下單並支付後,系統須要修改訂單的狀態並
且增長用戶積分。因爲系統採用的是微服務架構,分離出了支付服務、訂 單服務和積分服務,每一個服務都有獨立數據庫作數據存儲。當用戶支付成 功後,不管是修改訂單狀態失敗仍是增長積分失敗,都會 形成數據的不 一致。

 

然而微服務架構下,每一個微服務都有本身的數據庫,致使微服務架構 的系統不能簡單地知足 ACID,咱們就須要尋找微服務架構下的數據一致性解決方案:

CAP是指在一個分佈式系統下,包含三個要素::Consistency(一致性)、 Availability(可用性)、Partition tolerance(分區容錯性),而且 三者不 可得兼。
C:全部數據變更都是同步的
A:即在能夠接受的時間範圍內正確的相應用戶請求
P:分區容錯性,即某節點或網絡分區故障時,系統仍能提供知足一致性和可用性的服務。
在分佈式系統下,爲了保證模塊的分區容錯性,只能在數據強一致性和可用性之間作平衡。具體表現爲在必定時間內,可能模塊之間數據是不一致的,可是經過自動或者手動補償後可以達到最終的一致。

分享咱們是如何保證微服務架構的數據一致性的:

一、可靠消息最終一致性(適用於跨平臺技術棧不統一的場景)

利用MQ組件實現的二階段提交,涉及三個模塊:
A、上游應用,執行業務併發送MQ消息
B、可靠消息服務和MQ消息組件,協調上下游消息的傳遞,並確保上下游數據的一致性。
C、下游應用,監聽MQ的消息並執行自身業務。

二、TCC方案

涉及三個模塊:主業務、從業務、活動管理器
一、主業務服務分別調用全部從業務服務的try操做,並在活動管理器中記錄全部從業務服務。當全部從業服務try成功或者某個從業服務try失敗時,進入第二階段。
二、活動管理器根據第一階段從業服務的try結果來執行confirm或cancel操做。若是第一階段全部從業務服務都try成功,則協做者調用全部從業服務的confirm操做,不然,調用全部從業務服務的cancel操做。
Confirm 失敗:則回滾全部 confirm 操做並執行 cancel 操做。
Cancel 失敗:從業務服務須要提供自動 cancel 機制,以保證 cancel 成功。

 寫到這裏,我已經詞窮了,由於針對數據一致性問題,要考慮的很是多。上面的寫的不夠完善

等有機會,我會專門開設關於微服務架構結合DDD實現數據強一致性和最終一致性的問題探討。

樓主努力學習中。

 

 

參考地址:

張隊長文章:微軟MVP張善友告訴你,微服務選型要注意這些地方

 

asp.net Core 交流羣:787464275 歡迎加羣交流
若是您認爲這篇文章還不錯或者有所收穫,您能夠點擊右下角的【推薦】按鈕精神支持,由於這種支持是我繼續寫做,分享的最大動力!

做者:LouieGuo
聲明:原創博客請在轉載時保留原文連接或者在文章開頭加上本人博客地址,如發現錯誤,歡迎批評指正。凡是轉載於本人的文章,不能設置打賞功能,若有特殊需求請與本人聯繫!

微信公衆號:歡迎關注                                                 QQ技術交流羣: 歡迎加羣

                

相關文章
相關標籤/搜索