2020年總結-用學習過的技術搭建一個簡單的微服務框架 + 原始碼

框架中使用的技術知識

作業快4年了，有時很迷茫，有時很有干勁，學習了一些技術，也忘記了一些技術，即使對一些技術，了解的深度不夠，至少自己學習過使用過，那么在面對問題時，不會顯得那么無力，解決問題后，也能有更大的識訓，

1. NET Core基礎知識，EF CORE Code First，DB First
2. 領域驅動設計理論，三層架構，DDD經典分層架構
3. WebApi，Swagger，WebApiClient，Grpc，Exceptionless，Serilog
4. Redis，Consul，IdentityServer4，Rabbitmq，Kafka，CAP
5. Ocelot，Kong，Docker，Docker-Compose，Jenkins

DDD經典分層架構，與認識

1. 根據業務，將問題域逐步分解，把一個大的問題，逐步分解為小的問題，針對細分出的問題，給出相應的解決方案，降低業務的復雜性和系統實作的復雜性
2. 領域驅動設計是有門檻的，需要全方位提升，包括，業務知識，溝通能力，了解需求的能力，分析業務的能力，軟體建模能力（希望有朝一日能爬過去）
3. 個人感覺領域驅動設計最重要的就是，讓團隊每個人都理解業務，達成共識，程序中留下來的檔案，圖例，模型，對公司對個人都是一筆財富，提升了團隊能力，沉淀了業務知識
4. 學習領域驅動設計是一個長期的程序，書本的理論知識中沒有明確指出實踐的方式，基本上不會有完整的案例，因為實踐領域驅動設計的系統都是公司的核心系統，里面包 含了公司大量的業務，以及商業價值，一般不會開源出來分享，需要結合專案，業務，人員，團隊，來綜合考慮，權衡，團隊需要達成共識去實踐，在實踐中總結，進步

服務間的通訊：WebApiClient，Grpc，EventBus，以及問題

多個服務中需要通訊的時候，我們需要根據場景，來選擇不同的通訊手段，每種通訊手段都有好處和壞處，以及例外的情況，需要綜合來考慮選擇

在下單扣庫存的場景中，我們在訂單服務中下單完成后，需要扣除商品服務中的sku庫存，由于在不同的服務，我們不能保證他們的事務，只能保證最終一致性

WebApiClient，Grpc來實作

WebApiClient的github地址：https://github.com/dotnetcore/WebApiClient

1. 如何保證不超賣？扣減庫存的并發量比較大怎么辦？

商品服務提供RESTful API，GRPC 服務端，扣減庫存介面時：利用資料庫行鎖，和添加扣除的數量不能大于資料庫的庫存數量的條件（UPDATE t_sku SET Stock=Stock - {sku.SkuQuantity} where Id = '{sku.SkuId}' AND Stock > {sku.SkuQuantity}）

2. 如何保證生成訂單與商品庫存的最終一致性？

重試 + 補償 ，訂單服務保存訂單后，使用WebApiClient，呼叫RESTful API扣減庫存介面，使用Grpc 請求服務端扣減庫存，根據呼叫的回傳結果，結果失敗重試，重試一定次數后，記錄日志，回歸訂單，提示失敗，成功則提示下單成功！

3. 訂單服務可能會多次請求商品服務扣減庫存的介面，會不會造成多次扣減庫存？

商品服務扣減庫存的介面需要根據訂單服務提供的唯一標識做冪等，Grpc 服務端扣減庫存做冪等,冪等可以采用redis 的Hash，和設定Hash的過期時間來做冪等，也可以使用冪等表，新增一張表，用訂單服務的標識做唯一索引，我這里使用的是冪等表

EventBus來實作

1. 怎么選擇訊息佇列，Rabbitmq 還是 Kafka？

Rabbitmq 的社區比較活躍，官方檔案比較詳細，有.NET的客戶端，性能沒有Kafka高,Kafka 的原理架構比rabbitmq 容易理解，kafka的集群更好搭建，目前來說沒有性能要求，作業中用的是Rabbitmq

2. 下單扣除庫存是比較重要的場景，聽說訊息佇列會丟訊息？

Rabbitmq 提供了發布者確認機制，消費者提供了ACK機制,可以保證不丟訊息，訊息發布到rabbitmq 服務器，開啟了發布者確認，訊息持久化到磁盤成功后，會回傳持久化的狀態，持久化磁盤成功了，代表發布訊息成功了，訊息者開啟ACK,訊息消費失敗后，會回傳訊息佇列中，多次失敗后，可以把訊息放到指定的延遲佇列中，Rabbitmq 掛了，重啟時會，不斷的重試，直到成功，也可以失敗一定次數后，人工干預解決問題

kafka有生產者訊息確認機制，消費者ack機制，kafka 發布訊息是可以設定ACK=all，訊息需要，Leader持久化磁盤成功，所有的ISR中的Follower都持久化磁盤成功后，才表示真正的成功，消費者可以手動提交當前偏移量，保證不丟訊息

3. 有沒有寫好的，使用非常簡單方便的框架，這樣我就能直接搬磚了？

楊曉東老師的CAP:https://github.com/dotnetcore/CAP,一個基于本地訊息表+訊息佇列 的分布式事務的解決方案，同樣具有 EventBus 的功能，基于本地訊息表意味者，多了幾次IO，會影響一點性能，但是可靠，使用簡直是easy，最好能了解一些原理，這樣遇到一些問題，也能解決

4. 用訊息佇列我還需要考慮冪等嗎？

用訊息佇列一定要考慮冪等，很多訊息佇列都保證至少一次投遞訊息，可能出現多次投遞的情況，冪等方式與上面的一致

Redis

CsRedis的github地址：https://github.com/2881099/csredis

目前接觸的資料量，不用考慮快取穿透、快取擊穿、快取雪崩的情況，快取同步策略，也看過一些文章，了解過一些

1. CsRedis 冪等
2. CsRedis 分布式鎖
3. CsRedis做快取，加快查詢的速度，快取一些熱點資料，比如權限

IdentityServer4

IdentityServer4的檔案地址：http://www.identityserver.com.cn/

IdentityServer4 是為ASP.NET Core系列量身打造的一款基于 OpenID Connect 和 OAuth 2.0 認證框架， 對外提供RESTful API介面，需要Token來進行驗證，JWT Token中包含一些用戶資訊，我們可以結合RBAC權限進行授權

1. 在已有登錄的專案中，我們可以使用密碼授權模式，獲取Token
2. 使用混合流模式，結合前端使用oidc-client-js，獲取Token
3. 使用混合流模式，IdentityServer提供了一套基于 MVC 的樣例 UI,可以直接從Github上拉取，參考到專案中，獲取Token

Consul

使用Consul來實作服務發現與健康檢查

1. Consul提供了可視化的界面，我們可以隨時查看服務的狀態
2. Consul有.net的客戶端，我們可以在服務啟動的時候向consul注冊，服務關閉時注銷，也可以通過Json檔案的方式向consul中注冊服務
3. Consul的健康檢查，會根據你設定的時間來對你的服務發起呼叫，檢查服務是否正常，所以我們需要提供一個介面，表示服務的運行狀態
4. Consul可以在一個服務中注冊多個Ip+埠號，客戶端可以根據服務名稱獲取所有的Ip+埠號，根據演算法，實作負載均衡

Ocelot

Ocelot檔案地址：https://ocelot.readthedocs.io/en/latest/index.html

Ocelot是一個用.NET Core實作并且開源的API網關，它功能強大，包括了：路由、請求聚合、服務發現、認證、鑒權、限流熔斷、并內置了負載均衡器

1. Ocelot 可以結合Consul 實作服務發現，實作負載均衡
2. Ocelot 所有的請求路由都走Ocelot，可以結合Identityserver4，可以在Ocelot上統一認證授權

Ocelot Swagger,Kong Swagger,遇到過的問題

Swagger 是一個很好用的介面檔案，可以幫助我們前后端聯調，以及多個專案介面的管理

1. 使用Ocelot網關，多個服務，怎么統一的使用swagger 來管理

Swagger加載時請求一個IP+埠+服務名稱+Swagger.json的介面，我們可以在ocelot中，配置單個服務的swagger路由，在Ocelot上配置Swagger，通過選擇的服務名稱，來路由到指定服務的swagger

2. Swagger訪問的統一路徑是：IP+埠/swagger，部署網關后，都是8000埠，由于Kong 的Route不能重復，我該怎么來配置？

我們可以使用KongA可視化界面，給指定的服務配置特定的路由



Swagger訪問的統一路徑是：IP+埠/swagger，我們可以為每個服務設定IP+埠/{唯一的名稱}+swagger，比如訂單服務：47.104.83.210:8000/orderSwagger



3. 我們公司現在有幾十個服務，每個都需要在KongA上配置，很麻煩，怎么辦？

kong有官方的檔案，提供了RESTful API介面，可以呼叫kong的8001埠來，配置，目前Kong Admin Api 沒有官方的.NET客戶端，有位大佬開源了Kong.Net,可以幫助我們更快的去實作

Kong.Net的github地址：https://github.com/lianggx/Kong.Net

Docker ，Docker-Compose ，Jenkins

使用Jenkins pipeline 來實作，從git 服務器上拉取代碼，發布代碼，把代碼打包，通過SSH，傳輸到Linux 服務器，在Linux 服務器執行，docker images ，docker run ，docker-compsoe，部署專案， 使用Docker，Docker-Compose，部署專案，以及安裝各種需要的環境，工具，

總結

喜歡溝通交流，歡迎大家給出意見，謝謝！

1. 基礎知識不足，技術的深度不夠，沒有養成記錄知識的習慣，習慣性的忘記了許多東西
2. 沒有重視業務的重要性，沒有沉淀積累業務知識，經常考慮一些技識訓者功能實作，忽略了最重要的業務積累
3. 做的事件很雜，很散，沒有方向，也識訓了一些，比如，討論出的方案，我會思考這樣做，是否會有問題，有問題的地方在哪里，提出來，大家討論
4. 學習領域驅動設計，讓我明白了業務的重要性，我一直想要提高自己的溝通能力和需求分析能力,卻沒有方向，十分的迷茫，一無所有，卻缺乏從頭再來的勇氣

原始碼地址

碼云Gitee地址：https://gitee.com/lifeng618/Sample.git

轉載請註明出處，本文鏈接：https://www.uj5u.com/net/234539.html

標籤：.NET技术

上一篇：WinUI 3 Preview 3 發布了，再一次試試它的性能

下一篇：C# / VB.NET 獲取PDF檔案的數字簽名資訊