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來進行顯示。