云原生集成開發環境——TitanIDE
通過網頁在任何地方更安全、更高效地編碼2022-04-29
1996
作者:樂魚創新 Synuwxy
背景
隨著業務需求的日漸復雜以及產品迭代節奏的不斷加快,業務開發部門面臨著前所未有的壓力。為了搶占先機,用最快的速度準確把握用戶需求的變化,優化開發出來的業務產品,微服務(MicroServices)架構技術在各大企業不斷生根發芽。
微服務架構可以極大的降低業務的復雜性。開發和部署相對大單體架構而言更加簡單,單個微服務的功能可以更快地更改,啟動和調試單個微服務的時間成本相比于單體應用也大大減少。微服務治理也成為了困擾各大企業的難題。
普遍而言,微服務架構具備以下優點:
· 更好的容錯性,業務服務各司其職,單點故障不易影響全局
然而微服務架構并非沒有代價,就如軟件工程中沒有真正的銀彈。
原來在單體架構時,所有的邏輯都在一個服務內處理,方法和方法之間是進程內部的調度方式,然而采用微服務架構之后,服務與服務之間需要通過網絡相互溝通,一個業務的實現往往是多個服務的共同作用下完成,由此,微服務治理帶來了一系列的問題。
企業微服務治理面臨的挑戰
1. 復雜的網絡通信提升了故障出現的概率
在微服務架構體系中,服務與服務之間需要通過網絡相互溝通,意味著研發人員在原本的業務邏輯之外,還需要額外考慮網絡通信相關的問題。比如服務在向其上游服務發起請求時需要對上游服務的各種意外響應做出處理,常見的有401錯誤,404錯誤,500錯誤,503錯誤等。此外還涉及到對網絡延遲,網絡故障等環境問題做出處理。
一旦研發人員不能妥善處理這些網絡通信帶來的意外情況,隨著微服務數量的不斷變多,故障的風險概率將會隨之增大,進而影響系統的整體穩定性。
2. 海量的微服務加大了故障排查的難度
隨著業務的發展,微服務之間的溝通關系開始變得復雜,一個業務的實現往往是途徑了很多個微服務,然而冗長的調用鏈帶來的是數倍增長的排錯難度。
故障定位一直以來都是一件麻煩事,在微服務架構下排錯更是需要支付高昂的成本。
3. 當故障出現時難以確定影響范圍
雖然在微服務架構下,單點故障難以對系統造成整體上的破壞,但業務從來都不是獨立完成的,各服務之間存在各式各樣的依賴關系,這就導致故障出現時往往會級聯影響到下游業務,甚至引發其他業務的連鎖故障,此時業務最終呈現的現象往往會干擾研發人員對其故障范圍的判斷。
4. 微服務架構在部署環境中的故障難以復現
微服務架構下的服務調度錯綜復雜,一個業務故障的產生往往與其上下游的服務有很大的關系。有時我們在本地測試一切正常,但放到環境當中運行時卻會引發故障,其原因或許是部署的環境有問題,亦或許是下游服務給予了一些意外的參數,亦或許是上游服務響應的結果不符合預期,此類種種都是我們在離開了部署環境時很難預料到的變故,并且在微服務架構的掩蓋下,復現故障十分困難。
總結
微服務架構是解決業務復雜度的一個很好的方法,也是目前企業實踐中最常用的辦法。但是由于微服務架構的復雜性,企業想要管理好基于微服務架構的應用,也需要具備更高的能力。如果微服務治理得不恰當,反而有可能適得其反,不僅不能享受到微服務架構帶來的好處,反而會因為微服務帶來的系統復雜性,造成開發、運維部署的復雜度增加,進?影響開發迭代的速度,甚至影響系統的整體穩定性。
綜上所述,企業對微服務治理的需求是十分明確的,就是想知道當下環境當中,特別是在數量龐大的微服務相互溝通的過程中,到底發生了什么,當故障發生時,故障的影響范圍,故障的根本原因,最后是需要解決或緩解故障對業務影響的手段。
目前主流的微服務治理解決思路
1. 以SDK為主要表現形式的研發側解決思路
通過編碼的方式,讓我們的業務代碼直接具備解決問題的手段,這是目前最主流的也是發展時間最長的一種解決問題的思路。
在這條思路上最出名的開源庫是SpringCloud。作為微服務治理框架的集合,SpringCloud的核心庫封裝了包括服務發現、流量訪問、網關路由、熔斷器、鏈路追蹤等能力。
使用SDK解決服務治理的思路優勢是:研發可以完全的掌握服務治理的所有能力,能夠根據實際需求進行定制化,使其更加適配企業的實際情況。并且經過經年累月的打磨,部分語言的治理框架已經比較完善,為研發后續的開發打下了堅實的基礎。
缺點是:研發掌握了一切,一旦SDK內部邏輯出現故障,或者是需要升級,就必須讓研發介入重新編譯打包,并且由于大部分服務都接入了服務治理SDK,所以一次升級可能需要涉及到很大范圍的重新部署,這樣做風險很大。SDK具備語言相關的屬性,雖然部分語言的治理框架相對完善,但仍有很多流行的編程語言缺少完善的治理庫,如果企業內部語言較多,為了平衡各類治理框架的差異,做統一管理,就需要投入額外的開發成本。
2. 以Sidecar為主要表現形式的運維側解決思路
隨著技術的快速發展,DevOps理念開始流行,一種以Sidecar為主要表現形式的運維側解決思路開始出現。研發只需要關注自身的業務部分,服務治理能力通過其他工具插入到正在運行的業務服務當中。
Sidecar模式,指單獨將能力封裝在另一個程序當中與業務共同運行,以此來增強業務服務的能力。服務網格(Service Mesh)技術就大量的使用了Sidecar模式,其中最為著名的開源庫是Istio。
使用Sidecar模式解決服務治理的思路優勢是:Sidecar作為基礎設施可以由運維人員完全掌控,它與編程語言無關,并且完美的規避了SDK升級帶來的重新編譯部署的煩惱,并且由于Sidecar完全獨立于業務服務,這就賦予業務在任何時間接入和任何時間退出的權利,即插即用。
與之相對的是Sidecar模式的缺陷:Sidecar必須劫持流量才可以做到對業務服務的能力增強,這就意味著在業務調度的過程中產生了一個新的不確定因素,一旦Sidecar本身出現故障,它將影響業務的正常運轉。其次,在路由中每個服務都多了一跳,這就導致Sidecar必然帶來性能的損耗。
3. 以SDK與Sidecar同時存在為主要表現形式的解決思路
在云原生理念的推動下,業界又誕生了一種新的解決思路,它融合了SDK和Sidecar這2種解決問題的想法,并且期望實現完全的云原生,這就是Dapr。
Dapr 是微軟主導的云原生開源項目,2019年10月首次發布,到今年2月正式發布 V1.0 版本。在不到一年半的時間內,Github star 數達到了1.2 萬,發展勢頭迅猛,Dapr 這個詞是是「Distributed Application runtime」的首字母縮寫:dapr是一個為應用提供分布式能力的運行時。
準確來說Dapr并不單單解決服務治理問題,而是完全基于云原生理念誕生的產物,Dapr希望將一切都抽象成云資源,代碼通過對云資源的依賴來實現相應的業務。為了讓各種語言都有統一的實現規范,Dapr給很多流行的語言提供了SDK,又結合了Sidecar思想,將真正實現邏輯的部分都封裝在Sidecar當中,此時的Sidecar就是Dapr的運行時,有多個Sidecar,那就會出現多個運行時。業務代碼會先通過SDK溝通Sidecar,再歷經各個Sidecar的相互作用來實現具體需求,其中就包含了服務治理能力。
這種解決問題的辦法有一個重要的優勢:Dapr不僅可以動態的添加包含服務治理能力在內的各項公共能力,還可以基于抽象的云資源實現對底層實現的替換,比如將MongoDB替換成Redis等。
然而這種方式的缺陷也十分明顯:Dapr幾乎包含了SDK模式和Sidecar模式的大多缺點,SDK如果無法匹配Sidecar的版本時同樣面臨著SDK升級困難問題。由于多運行時共同作用,在路由上流量每經過一個服務,可能多了不止一跳,同樣面臨著性能問題。由于邏輯都封裝在Sidecar上,也避免不了Sidecar本身故障時無法正常訪問,并且由于多運行時,當故障出現很難準確定位故障。
如何抉擇
SDK的方式和企業業務最貼合,完全的自主可控,可是需要付出巨大的研發和維護代價,去實現服務治理相應的功能。
Dapr的理念十分前衛,它能提供更多的想象空間,但是如果使用Dapr結構,研發需要放棄經營已久的開發框架去適配Dapr,相當于把底層框架幾乎換掉,這個代價不是大多數企業能夠承受的。
從企業成本付出來看,服務網格或許是現階段最適合的解決方案。
使用服務網格解決微服務治理問題是當下代價最小的解決方案
服務網格(Service Mesh)是Sidecar模式的代表型技術之一,是處理服務間通信的基礎設施層,在實踐中,服務網格通常以輕量級網絡代理陣列的形式實現,這些代理與應用程序代碼部署在一起。作為云原生的網絡基礎設施,它把微服務調度中有關網絡的公共能力下沉到代理,實現了在無任何代碼侵入的情況下提供可觀察性、流量管理和安全性等能力。
· 升級便利,作為獨立第三方服務,服務網格的升級迭代并不會影響業務的正常運行。
服務網格即插即用的特質對于企業十分友好,特別是針對組織架構相對復雜的企業,越少的部門關聯意味著越少的溝通成本,而部門之間的溝通幾乎是企業成本最大的地方。
綜上所述,使用服務網格解決企業微服務治理是現階段代價最小的選擇,也是最推薦的解決方案。
------------------------------------------------------
下一篇:未來,云原生應用研發四大趨勢