前言
工作快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
目前接觸的資料量，不用考慮緩存穿透、緩存擊穿、緩存雪崩的情況，緩存同步政策，也看過一些文章，了解過一些
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、沒有重視業務的重要性，沒有沉澱積累業務知識，經常考慮一些技術或者功能實作，忽略了最重要的業務積累