官方彩票投注

Jackyfei

微服務的時間和成本去哪兒了

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

posted @ 2019-12-20 10:05  張飛洪  閱讀(...)  評論(...收藏