實踐出真知

在上面的電商案例中,我們提到了服務無狀態(tài)化,之所以期望服務無狀態(tài)化,是因為無狀態(tài)應用可以做到快速的擴縮容,可以應對井噴流量,可以最大效率的利用計算資源。我們經常聽到,以無狀態(tài)為榮,以有狀態(tài)為恥,說的就是對于一個服務要盡量無狀態(tài)化它,比如用戶 session 管理,以前我們在業(yè)務邏輯模塊進行管理,導致這些模塊不能按照無狀態(tài)方式任意伸縮。我們可以把這些 session 的管理抽取出來放到一個高可用或分布式的緩存中管理,業(yè)務模塊通過調用API的方式去獲取 session,這樣就實現(xiàn)了這些模塊的無狀態(tài)化。

但這并不意味著所有服務都做到無狀態(tài)才是最好的,開發(fā)者要細細思考自己的業(yè)務模型并進行服務拆分,不要為了無狀態(tài)而無狀態(tài),因為總是會存在有狀態(tài)服務的。

第二階段進階—— 改造遺留應用

如果我們經過認真思考后仍決定對遺留應用進行微服務化,比如需要新增功能、快速迭代現(xiàn)有功能等,那么最好遵循一些最佳實踐經驗。顯然,另起爐灶開發(fā)一套新的系統(tǒng)不太現(xiàn)實,失敗的概率非常高。

第一點注意:新增功能點不能再在原有單體應用基礎上開發(fā),而是需要按照微服務方式開發(fā),但由于這個微服務是隸屬于原來單體應用的一部分功能,所以通常情況需要訪問單體應用的數據,這個時候需要通過API的方式訪問,以防止二者之間發(fā)生緊耦合。對于單體部分來說,無論是采用 Facade,還是 Adapter 或 Translator 模式提供 API,都是為新增的微服務模塊提供松耦合的訪問方式。

第二點注意:對于已有的單體部分也可以逐步微服務化,可選擇經常變化、需要快速迭代滿足用戶需求的部分著手進行改造。經過幾輪改造后要么整體替換掉原單體應用,要么剩下的是穩(wěn)定不變的單體部分,周圍就都是改造過的微服務混合架構了。

第三階段收放自如——Service Mesh

Service mesh 是微服務架構的一部分,它本質上是一個分布式計算中間件,通過攔截流量和安置策略來管理和優(yōu)化服務之間的通信,使得服務變得更加健壯和安全。通常會提供微服務之間認證、鑒權、加密、服務發(fā)現(xiàn)、請求路由、負載均衡、服務自愈等功能。

部署微服務應用,service mesh 是必不可少的部分。這是因為微服務應用是一個分布式的應用,因此相對于單體應用來說在穩(wěn)定性、可管理性等方面都有很大難度,需要有 service mesh來管理幫助服務變得更加健壯和安全。

因此,Service mesh 選型也是比較重要的,經常聽到有人糾結是選擇?Istio 還是 Spring Cloud 等。我們認為?Istio 是 service mesh 的發(fā)展方向,從架構來說,它解耦了控制平面和數據平面,使得開發(fā)者可以專注于應用業(yè)務邏輯的開發(fā),而復雜的分布式應用服務之間的通信交給 service mesh 來控制。Spring Cloud 在架構設計理念上是落后的,試想一下,開發(fā)者在開發(fā)微服務的時候還要思考如何在代碼中實現(xiàn)熔斷、灰度發(fā)布、負載均衡等問題,負擔是非常重的。更重要的是 Spring Cloud 類型的 service mesh 只支持 Java 語言,完全違背微服務可以任選語言開發(fā)的主張,而且有 vendor lock-in 嫌疑。

Istio 身上鮮明的標簽很多:天然適合 Kubernetes 平臺,不侵入代碼,無語言綁定,但不得不承認,Istio 還在發(fā)展過程當中,目前也有一些問題亟待解決:

雖然?Istio 存在上述問題,但我們更應看到其社區(qū)正在飛速增長,就好比一兩年前 k8s、docker swarm 和 Mesos 之爭一樣,那個時候 k8s 強大的生態(tài)活躍度為它最終勝利打下了良好的基礎,我們認為?Istio 就是在 service mesh 領域的 k8s,未來很有可能會贏得這個領域的主導地位。當一個應用的微服務越來越多的時候,service mesh 變得非常重要,而且目光看得更遠一些,隨著 FaaS 步入業(yè)務開發(fā)者的視野,大家越來越享受這種便捷、靈活的開發(fā)方式,這意味著以服務視角的開發(fā)模式會越來越流行,因此 service mesh 框架會變得越來越重要。

綜上所述,通過?Istio 構建微服務治理屏幕,學習曲線起點比較高,運維也非常麻煩,運維人員關注的是功能的輸出,比如熔斷、限流、灰度發(fā)布等,但?Istio 要求他們先要部署組件,編輯 yaml,了解各種抽象的參數,這就好比在看 3D 電影前,讓觀眾自己先要組裝 3D 眼鏡一樣。因此,微服務進階之路道阻且長,企業(yè)需要一個平臺級商業(yè)產品,可以從業(yè)務視角來管理微服務的可視化工具或者平臺,降低用戶的學習和運維成本,提高用戶的業(yè)務價值輸出能力,幫助用戶重塑數字化時代核心競爭力。

分享到

zhupb

相關推薦