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

往事隨灬鋒發表於2020-12-14
微服務框架原始碼

框架中使用的技術知識

工作快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經典分層架構，與認識

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

  1. 根據業務，將問題域逐步分解，把一個大的問題，逐步分解為小的問題，針對細分出的問題，給出相應的解決方案，降低業務的複雜性和系統實現的複雜性

  2. 領域驅動設計是有門檻的，需要全方位提升，包括，業務知識，溝通能力，瞭解需求的能力，分析業務的能力，軟體建模能力（希望有朝一日能爬過去）

  3. 個人感覺領域驅動設計最重要的就是，讓團隊每個人都理解業務，達成共識，過程中留下來的文件，圖例，模型，對公司對個人都是一筆財富，提升了團隊能力，沉澱了業務知識

  4. 學習領域驅動設計是一個長期的過程，書本的理論知識中沒有明確指出實踐的方式，基本上不會有完整的案例，因為實踐領域驅動設計的系統都是公司的核心繫統，裡面包 含了公司大量的業務，以及商業價值，一般不會開源出來分享，需要結合專案，業務，人員，團隊，來綜合考慮，權衡，團隊需要達成共識去實踐，在實踐中總結，進步

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

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

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

WebApiClient，Grpc來實現

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

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

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

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

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

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

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

EventBus來實現

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

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

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

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

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

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

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

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

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

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 來管理

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

  2. Swagger訪問的統一路徑是：IP+埠/swagger，部署閘道器後，都是8000埠，由於Kong 的Route不能重複，我該怎麼來配置？

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

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

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

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

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

    4. 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

相關文章