1. 程式人生 > >微服務架構風格可以降低系統的複雜度嗎?

微服務架構風格可以降低系統的複雜度嗎?

有人說:使用多個獨立的微服務組合成一個複雜的業務系統。如此的話,業務系統整體的複雜度並沒有降低。如果極限情況下,每個public函式都是一個獨立執行的服務,如此一來反倒是增加系統的複雜度。如此看來,微服務只不過是解決了部分功能的擴充套件性的問題。和SOA架構或者monolic相比,並沒有根本性的改變。


事實並非如此。


分散式意味著複雜性的挑戰,以靜止的觀點來看,也就是系統長期沒什麼大變化這種情況,採用微服務架構通常會增加系統整體的複雜度,得不償失。


然而有個詞叫做“架構腐化”,系統不可能靜止不動,隨著業務的成長,市場的變化,系統總要不斷增加新的能力,時間長了,最初簡單高效的架構,往往就會變得極其複雜,臃腫不堪,即便最初的規範、分層都合理了,可擴充套件性、可用性、效能帶來的複雜性也是難以避免的,祖傳程式碼牽一髮而動全身,改一行修半年該有多可怕。這也是熵增原理的一種體現。


而採用微服務架構,邊界和職責明確了,模組高內聚低耦合,系統熵增就可以變慢,而且系統分拆之後,對於負責單個微服務的小團隊來說,工作也變得很簡單多了。這都是強調服務匯流排(ESB)的 SOA 和單體架構所不能的。


誠然微服務架構的正常運轉需要做很多事情,比如:

  • 服務註冊/發現:服務例項的網路地址是動態分配的,服務例項的配置也經常變化,沒有這個就不好玩了。

  • 持續部署:功能越多,構建和部署時間越多,再小的修改都需要部署,要是手動部署的話,這人生就看到頭了。

  • 異常定位與修復:服務眾多鏈路複雜的時候,這和在茫茫人海中找到那個他/她有一拼了。

  • 高可用:服務之間確實相對獨立,資源也隔離,減少區域性故障對整體的影響,但是有呼叫和依賴,不做好每一個服務的高可用,就要等著雪崩了。


但這些是基礎設施層面的工作,只要有一個好的微服務基礎設施,業務侵入性很小,儘可能支援自動化,就不是問題了。網易雲輕舟微服務的設計,就是希望解決微服務應用生命週期的一切問題。


所以,微服務架構也不僅僅解決部分功能擴充套件性的問題,對於系統可用性的保證,溝通成本的減少,支援技術選擇的多樣性,到研發效率的提升,微服務可以發揮的作用還是非常巨大的。


優化業務系統的複雜度,應該在於保證業務響應能力、業務創新能力,同時提升 IT 效率,很多網際網路公司以及傳統企業都在搞微服務,當然是因為搞微服務是有這種好處的。


相關文章:
【推薦】 終於有人把雲端計算、大資料和人工智慧講明白了!(1)


【推薦】 Kafka實踐、升級和新版本(0.10)特性預研
【推薦】 BigData – Join中竟然也有謂詞下推!?