ppt：
2019 中國.net 開發者峰會目前在國內的.net社群還是很有影響力的，宣傳的內容也都是比較新潮和前言的技術棧。
有乙個不爭的現實是基本上主題都是關於.net core的，以及基於該主題之上的延展。比如ml.net相關的機器學習；基於.net core的微服務實戰；傳統轉型.net core的實戰；.net core在物聯網的應用；.net core結合k8s的應用；.net core架構歷史；.net core相關的雲原生技術等等。可謂欣欣向榮，百花齊放，彷彿讓人看到了.net生態的重新崛起。
峰會的內容給開發者開啟了乙個明亮的視窗，但畢竟只是拋磚迎玉，真正落地開花還有很長的距離。
微服務的基礎設施包括：
也就是說對於服務來說，單個服務變得簡單，整體服務變得複雜。
分布式事務的解決方案。
資料傳輸物件（dto)(data transfer object)，是一種設計模式之間傳輸資料的軟體應用系統
工具是微服務基礎設施的一部分，比如基於gitlab的ci,cd或者jenkins。都是服務自動化發布的利器。另外api介面膨脹後的管理，聯調，測試，規範等等，如果沒有管好api，前後端分離往往會降低我們的開發效率，因為互相等待是常有的事情，就算模擬好資料後，也不能保證不去做聯調。
劉佬說：「微服務的終極價值在於服務的任意拼裝組合。「
好比樂高積木，比起單體粗苯的**調整，顯然是高效率解放生產力的。這種價值其實並不新鮮，從歷史的維度看，從最小的函式封裝，抽象，設計模式，類庫，到程序互動，到最後亞馬遜的微服務發明，無不在學習樂高思想。只是隨著業務複雜度的增加，團隊規模的膨脹，這個樂高的粒度不斷的變大，變遠，最後跨程序，跨域，分布式。
如何保持資料一致性？
劉佬的專案在資料一致性這塊沒有落地，具體原因沒說明，但是我預估當初是業務優先所做的妥協。
分布式事務具備一定的複雜性，是個很大的話題。分布式事務一般採用的是最終一致性，也就是cap裡面的三選二，通過犧牲實時來保證業務的高可用性。電商中如果不涉及到資金安全，比如虛擬錢包和貨幣等核心業務功能，一般不影響使用。
而這裡的最終一致性要落地好，技術上雖然不難，但是要落地完整，需要不少時間。
如何解決資料庫運維？
隨著資料庫和服務一起拆分，資料庫也變多了，給資料庫運維帶來了極大挑戰。
拆分的痛點是表關聯查詢，因為所有的聚合都是服務的聚合，也就是資料庫的join沒有了，替換成的是服務間的關聯了，所以劉佬乾脆棄用mysql，全部採用mongodb，充分發揮mongodb優勢。
但是接下來的代價就是統計和報表的生成，這個難題也不複雜，可以通過資料同步，把mongodb的資料同步到關係型資料庫當中。
對於業務統計或使用者行為事件，會產生很大的資料量，可以在服務入口處做探針，比如在使用者訪問，下訂單服務處埋點，把訪問和統計資料同步到es，發揮es的威力，最後通過dashboard來進行顯示。
參考：微服務的時間和成本去哪兒了
參考：漫談何時從單體架構遷移到微服務？
參考：**vo、dto、do、po的概念、區別和用處
微服務Kong（九） 認證參考
客戶端訪問上游api服務，通常由kong的認證外掛程式及其配置引數來控制。通用認證 一般情況下，上游api服務都需要客戶端有身份認證，且不允許錯誤的認證或無認證的請求通過。認證外掛程式可以實現這一需求。這些外掛程式的通用方案 流程如下 1 向乙個api或全域性新增auth外掛程式 此外掛程式不作用於...
微服務Kong（九） 認證參考
客戶端訪問上游api服務，通常由kong的認證外掛程式及其配置引數來控制。通用認證 一般情況下，上游api服務都需要客戶端有身份認證，且不允許錯誤的認證或無認證的請求通過。認證外掛程式可以實現這一需求。這些外掛程式的通用方案 流程如下 1 向乙個api或全域性新增auth外掛程式 此外掛程式不作用於...
微服務學習2 如何劃分微服務？
1 起點和終點 起點 既有架構的形態 終點 好的架構不是設計出來的，而是進化而來的 一直在演進ing 2 適合上微服務麼 業務形態不適合的 1 系統中包含很多很多強事務場景的 2 業務相對穩定，迭代周期長 3 訪問壓力不大，可用性要求不高 3，康威定律 任何組織在設計一套系統 廣義概念上的系統 時，...