工作快4年了，有時很迷茫，有時很有幹勁，學習了一些技術，也忘記了一些技術，即使對一些技術，了解的深度不夠，至少自己學習過使用過，那麼在面對問題時，不會顯得那麼無力，解決問題後，也能有更大的收穫。
net core基礎知識，ef core code first，db first
領域驅動設計理論，三層架構，ddd經典分層架構
webapi，swagger，webapiclient，grpc，exceptionless，serilog
redis，consul，identityserver4，rabbitmq，kafka，cap
ocelot，kong，docker，docker-compose，jenkins
ddd經典分層架構，與認識
根據業務，將問題域逐步分解，把乙個大的問題，逐步分解為小的問題，針對細分出的問題，給出相應的解決方案，降低業務的複雜性和系統實現的複雜性
領域驅動設計是有門檻的，需要全方位提公升，包括，業務知識，溝通能力，了解需求的能力，分析業務的能力，軟體建模能力（希望有朝一日能爬過去）
個人感覺領域驅動設計最重要的就是，讓團隊每個人都理解業務，達成共識，過程中留下來的文件，圖例，模型，對公司對個人都是一筆財富，提公升了團隊能力，沉澱了業務知識
學習領域驅動設計是乙個長期的過程，書本的理論知識中沒有明確指出實踐的方式，基本上不會有完整的案例，因為實踐領域驅動設計的系統都是公司的核心系統，裡麵包 含了公司大量的業務，以及商業價值，一般不會開源出來分享，需要結合專案，業務，人員，團隊，來綜合考慮，權衡，團隊需要達成共識去實踐，在實踐中總結，進步
服務間的通訊：webapiclient，grpc，eventbus，以及問題
多個服務中需要通訊的時候，我們需要根據場景，來選擇不同的通訊手段，每種通訊手段都有好處和壞處，以及異常的情況，需要綜合來考慮選擇
在下單扣庫存的場景中，我們在訂單服務中下單完成後，需要扣除商品服務中的sku庫存，由於在不同的服務，我們不能保證他們的事務，只能保證最終一致性
如何保證不超賣？扣減庫存的併發量比較大怎麼辦？
商品服務提供restful api，grpc 服務端，扣減庫存介面時：利用資料庫行鎖，和新增扣除的數量不能大於資料庫的庫存數量的條件（update t_sku set stock=stock - where id = 『』 and stock > ）
如何保證生成訂單與商品庫存的最終一致性？
重試 + 補償 ，訂單服務儲存訂單後，使用webapiclient，呼叫restful api扣減庫存介面，使用grpc 請求服務端扣減庫存，根據呼叫的返回結果，結果失敗重試，重試一定次數後，記錄日誌，回歸訂單，提示失敗，成功則提示下單成功！
訂單服務可能會多次請求商品服務扣減庫存的介面，會不會造成多次扣減庫存？
商品服務扣減庫存的介面需要根據訂單服務提供的唯一標識做冪等，grpc 服務端扣減庫存做冪等,冪等可以採用redis 的hash，和設定hash的過期時間來做冪等，也可以使用冪等表，新增一張表，用訂單服務的標識做唯一索引，我這裡使用的是冪等表
eventbus來實現
怎麼選擇訊息佇列，rabbitmq 還是 kafka？
rabbitmq 的社群比較活躍，官方文件比較詳細，有.net的客戶端，效能沒有kafka高,kafka 的原理架構比rabbitmq 容易理解，kafka的集群更好搭建，目前來說沒有效能要求，工作中用的是rabbitmq
下單扣除庫存是比較重要的場景，聽說訊息佇列會丟訊息？
rabbitmq 提供了發布者確認機制，消費者提供了ack機制,可以保證不丟訊息，訊息發布到rabbitmq 伺服器，開啟了發布者確認，訊息持久化到磁碟成功後，會返回持久化的狀態，持久化磁碟成功了，代表發布訊息成功了，訊息者開啟ack,訊息消費失敗後，會返回訊息佇列中，多次失敗後，可以把訊息放到指定的延遲佇列中，rabbitmq 掛了，重啟時會，不斷的重試，直到成功，也可以失敗一定次數後，人工干預解決問題
kafka有生產者訊息確認機制，消費者ack機制，kafka 發布訊息是可以設定ack=all，訊息需要，leader持久化磁碟成功，所有的isr中的follower都持久化磁碟成功後，才表示真正的成功，消費者可以手動提交當前偏移量，保證不丟訊息
有沒有寫好的，使用非常簡單方便的框架，這樣我就能直接搬磚了？
楊曉東老師的cap:乙個基於本地訊息表+訊息佇列 的分布式事務的解決方案，同樣具有 eventbus 的功能，基於本地訊息表意味者，多了幾次io，會影響一點效能，但是可靠，使用簡直是easy，最好能了解一些原理，這樣遇到一些問題，也能解決
用訊息佇列我還需要考慮冪等嗎？
用訊息佇列一定要考慮冪等，很多訊息佇列都保證至少一次投遞訊息，可能出現多次投遞的情況。冪等方式與上面的一致
identityserver4 是為asp.net core系列量身打造的一款基於 openid connect 和 oauth 2.0 認證框架。 對外提供restful api介面，需要token來進行驗證，jwt token中包含一些使用者資訊，我們可以結合rbac許可權進行授權
在已有登入的專案中，我們可以使用密碼授權模式，獲取token
使用混合流模式，結合前端使用oidc-client-js，獲取token
使用混合流模式，identityserver提供了一套基於 mvc 的樣例 ui,可以直接從github上拉取，引用到專案中，獲取token
consul
使用consul來實現服務發現與健康檢查
ocelot是乙個用.net core實現並且開源的api閘道器，它功能強大，包括了：路由、請求聚合、服務發現、認證、鑑權、限流熔斷、並內建了負載均衡器
ocelot 可以結合consul 實現服務發現，實現負載均衡
ocelot 所有的請求路由都走ocelot，可以結合identityserver4，可以在ocelot上統一認證授權
ocelot swagger,kong swagger,遇到過的問題
swagger 是乙個很好用的介面文件，可以幫助我們前後端聯調，以及多個專案介面的管理
使用ocelot閘道器，多個服務，怎麼統一的使用swagger 來管理
swagger載入時請求乙個ip+埠+服務名稱+swagger.json的介面，我們可以在ocelot中，配置單個服務的swagger路由，在ocelot上配置swagger，通過選擇的服務名稱，來路由到指定服務的swagger
swagger訪問的統一路徑是：ip+埠/swagger，部署閘道器後，都是8000埠，由於kong 的route不能重複，我該怎麼來配置？
我們可以使用konga視覺化介面，給指定的服務配置特定的路由
swagger訪問的統一路徑是：ip+埠/swagger，我們可以為每個服務設定ip+埠/+swagger，比如訂單服務：47.104.83.210:8000/orderswagger
我們公司現在有幾十個服務，每個都需要在konga上配置，很麻煩，怎麼辦？
kong有官方的文件，提供了restful api介面，可以呼叫kong的8001埠來，配置，目前kong admin api 沒有官方的.net客戶端，有位大佬開源了kong.net,可以幫助我們更快的去實現
docker ，docker-compose ，jenkins
使用jenkins pipeline 來實現，從git 伺服器上拉取**，發布**，把**打包，通過ssh，傳輸到linux 伺服器，在linux 伺服器執行，docker images ，docker run ，docker-compsoe，部署專案。 使用docker，docker-compose，部署專案，以及安裝各種需要的環境，工具。
二十四點演算法
給出四個數，不可以重複使用，可以用 和括號，怎麼得出24？return 1 表示當前方法不行 private int workbystep int op,int num1,int num2 else if op 1 else if op 2 else if op 3 只要沒有有小數生成，即使有負數也...
演算法二十四 矩形
給定兩個矩陣，判斷第二個矩陣在第乙個矩陣的哪些位置出現過。輸入的第一行包含四個正整數a,b,c,d，表示第乙個矩陣大小為a b，第二個矩陣的大小為c d。接下來是乙個a b的矩陣。再接下來是乙個c d的矩陣。保證矩陣中每個數字都為正整數且不超過100。若第二個矩陣在第乙個矩陣的 i,j 位置出現 即...
二十四點演算法
package com.onezero 計算24遊戲 給出四張1到13之間的整數，通過 組合成合法表示式並使結果等於24 如給出1 3 4 6，可以組合乘6 1 3 4 演算法仍然是窮舉法，不過刪除了一些重複的式子。為了精確表示除法結果，這裡實現有理數類。基本思想 先在四張牌中選出兩張，有6種，再計...