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