2019 中國.NET 開發者峰會目前在國内的.NET社群還是很有影響力的，宣傳的内容也都是比較新潮和前言的技術棧。
有一個不争的現實是基本上主題都是關于.NET Core的，以及基于該主題之上的延展。比如ML.NET相關的機器學習；基于.NET Core的微服務實戰；傳統轉型.NET Core的實戰；.NET Core在物聯網的應用；.NET Core結合K8S的應用；.NET Core架構曆史；.NET Core相關的雲原生技術等等。可謂欣欣向榮，百花齊放，仿佛讓人看到了.NET生态的重新崛起。
峰會的内容給開發者開啟了一個明亮的視窗，但畢竟隻是抛磚迎玉，真正落地開花還有很長的距離。
本人在.NET Core上面落地過，對微服務也興趣盎然，是以我重點傾聽了劉騰飛老師的演講，并做部分解讀，從共鳴中寫下個人感想，希望對您有所啟發。
為什麼選擇微服務？
雖然劉老師的說辭有點舉重若輕，說的是因為執着和技術人的專研精神選擇了微服務，甚至也對比和調研過，但是在隻有四個人的團隊裡，連一張披薩都沒有湊齊的前提下就“冒然”選型，顯然不能讓我信服。可能是劉大佬有比較充分的調研和把握，或者說有一定的技術自信。否則換成我，我是無論如何不敢帶着四個缺少微服務實戰經驗的小夥伴貿然前進，除非我想把這個項目當成試驗品。
因為如果分層架構足夠規範簡單，團隊規範足夠精細，設計面向微服務的架構就足夠解決問題，等團隊和業務發展壯大後，再切換到微服務不遲。
劉佬團隊中間加過多少班，踩過多少坑，也許隻有劉老師知道。
演講中插曲說：有一次加班到淩晨3點多，然後一起出來吃火鍋。我聽完除了敬佩還是敬佩。有句話叫哪裡有歲月靜好，因為有人替你負載前行。
微服務難在哪裡？
因為微服務确實需要比較高的門檻，具體可以參考我的另外一篇文章《漫談何時從單體架構遷移到微服務？》
微服務的基礎設施包括：
- CI、CD，限流，熔斷，管理協作，分布式技術，
- 網關，服務監控，日志收集，重複代碼
- 配置中心，負載均衡，釋出成本
- 領域劃分和明确
- 容器相關技術棧等等
也就是說對于服務來說，單個服務變得簡單，整體服務變得複雜。
這些菜都端上來，如果沒有很好的技術儲備和高效管理和協作，估計是要不消化的。重點是劉大佬在演講最後，仍然沒有給提問者一個很好的關于分布式事務的解決方案。
如何降低微服務的成本？
這裡的目的是探讨如何降低成本，是以我們必須要面對這些困難，一個一個的去解決。當這些困難的成本和單體一緻或持續的接近單體的時候，我覺得上微服務就胸有成竹了。
為此我們必須要梳理并識别以上的技術難點，這裡挑選最核心的或者說最影響時間成本的點來展開。
引入K8S
面對JAVA的SPRING全家桶，劉佬采用K8S來解決，也就是說K8S自帶微服務等大部分基礎設施，比如配置中心不一定要用Appolo，使用K8S的ConfigMap就可以了；服務發現和注冊也是K8S自帶的。K8S解決了基礎設施一半以上的問題，這個成本是非常低的。
也就是說對微服務的學習成本，變成了對K8S的學習成本。這對開發人員來說是個福音，因為可以有現成的輪子，但是也不能高興太早，因為K8S并不是一個容易掌握的技術。可以說K8S内容龐雜，官方文檔也是大而全，想要一下子掌握它非一日之寒。
剩下的另外一半成本在哪兒？我覺得服務劃分，服務調用，相關提效工具的使用等等。
服務劃分
前期服務的劃分，包括基礎服務，核心服務，網關選型，全鍊路監控等技術棧。包括但不限于如下表所示：
服務調用：
- 服務在互相調用的時候，難免會産生重複模型，比如DTO。
- 使用HTTP請求的性能不足問題
- 采用gRPC
- 采用gRPC後服務開發解決單體開發，減少備援的代碼，做到分布式部署和本地部署。
- 分布式跨服務通路，讀寫操作做分離，盡量隻做查詢，POST操作走異步消息事件。
劉佬提到的服務調用連續疊代了三個版本，這個坑給我很大啟發，雖然我目前的服務沒有采用gRPC，但是模型的代碼重複已經開始備援了。代碼備援不可避免，有沒有更好的解決方案呢？有些人會覺得引入Abp架構來解決，最新的Abp Next。這是很好的輪子，但是問題又來了，Abp Next和K8S一樣，如果團隊沒有好的研發型人員或者對Abp的使用有過幾個項目墊底的人，那麼Abp的引入可能會增加技術的複雜度，因為Abp在性能方面也是有坑的，何況Abp Next目前也在跟着疊代，文檔都不是很健全。
工具使用
工具是微服務基礎設施的一部分，比如基于gitLab的CI,CD或者jenkins。都是服務自動化釋出的利器。另外API接口膨脹後的管理，聯調，測試，規範等等，如果沒有管好API，前後端分離往往會降低我們的開發效率，因為互相等待是常有的事情，就算模拟好資料後，也不能保證不去做聯調。
終極價值
劉佬說：“微服務的終極價值在于服務的任意拼裝組合。“
好比樂高積木，比起單體粗苯的代碼調整，顯然是高效率解放生産力的。這種價值其實并不新鮮，從曆史的次元看，從最小的函數封裝，抽象，設計模式，類庫，到程序互動，到最後亞馬遜的微服務發明，無不在學習樂高思想。隻是随着業務複雜度的增加，團隊規模的膨脹，這個樂高的粒度不斷的變大，變遠，最後跨程序，跨域，分布式。
提問和啟發：
在演講結束的提問環節，問了三個問題我覺得很有品質，也是難點。
如何保持資料一緻性？
劉佬的項目在資料一緻性這塊沒有落地，具體原因沒說明，但是我預估當初是業務優先所做的妥協。
分布式事務具備一定的複雜性，是個很大的話題。分布式事務一般采用的是最終一緻性，也就是CAP裡面的三選二，通過犧牲實時來保證業務的高可用性。電商中如果不涉及到資金安全，比如虛拟錢包和貨币等核心業務功能，一般不影響使用。
而這裡的最終一緻性要落地好，技術上雖然不難，但是要落地完整，需要不少時間。
如何解決K8S服務幹擾？
某個服務因為各種原因，比如代碼不夠健壯導緻，或者因為ES的大記憶體需求，導緻叢集其他服務異常，甚至整個叢集垮掉該如何解決？
- 容器資源限制
- 核心服務抽離
主要采用資源限制，但是資源限制會導緻某個容器挂掉。可以通過資源告警和日志分析的方式快速定位容器并進行資源重新伸縮配置設定，特别是在生産環境。
如何解決資料庫運維？
随着資料庫和服務一起拆分，資料庫也變多了，給資料庫運維帶來了極大挑戰。
拆分的痛點是表關聯查詢，因為所有的聚合都是服務的聚合，也就是資料庫的Join沒有了，替換成的是服務間的關聯了，是以劉佬幹脆棄用MySQL，全部采用MongoDB，充分發揮MongoDB優勢。
但是接下來的代價就是統計和報表的生成，這個難題也不複雜，可以通過資料同步，把MongoDB的資料同步到關系型資料庫當中。
對于業務統計或使用者行為事件，會産生很大的資料量，可以在服務入口處做探針，比如在使用者通路，下訂單服務處埋點，把通路和統計資料同步到ES，發揮ES的威力，最後通過Dashboard來進行顯示。
ppt
希望以上分享對你有所幫助，感謝您的捧場。
作者： 張飛洪[廈門]
QQ群：
共享交流群
打賞支援