從航空母艦上起飛,是怎樣一種體驗----EDAS帶你快速搞定分布式應用
【EDAS最近更新】
- 2.13.1 版本:提供對本地方法執行追蹤; 支持租戶內服務鑒權與授權。
- 2.13.0 版本:Http流量管理功能上線,提供了對應用運行時線程堆棧和內存分布的查看。
- 2.12.3 版本:鏈路分析功能上線全新視覺界麵;調用鏈支持多維查詢。
- 2.12.2 版本:服務監控上線全新視覺界麵;PaaS 平台機器接入層架構升級,支持無限水平擴容。
背景:
- 攻城獅:誰又動了我模塊接口?誰又改了我模塊邏輯???
- 運維:有bug!模塊之間的調用跟個蜘蛛網一樣,我怎麼排查!
- 測試:這麼複雜的調用邏輯,我的自動化測試用例咋寫?!
- 架構師:業務上升了,係統要部署到多台服務器才行,這我怎麼拆?!
- 新人入職後:代碼太難理解,想shi的心都有了…….
- 老板:為啥大半年過去了需求還沒搞定!!!
作為一個開發者,你是否經曆過這樣的咆哮?
這樣的場景出現,不是誰的脾氣有bug,而是打開方式或許不對。今天我們就通過一個真實案例,來看看分布式開發對消滅吐槽,促進團隊和諧的作用。
單體應用很豐滿,現實很骨感
X公司是一個秉承傳統的開發方式的典型,如下圖的架構圖是一個實際場景中的架構圖,按照傳統的開發方式,業務模塊層按照“高內聚低耦合”的原則劃分成不同的模塊,所有模塊的開發人員都是在一個大工程下進行編碼測試,模塊之間的業務劃分的很清晰。
但理想是豐滿的,現實很骨感,按照很“完美”的模塊劃分後,在一個大的應用工程下進行開發進行開發,但隨著係統功能越來越強大,,軟件複雜度急劇增加,開發人員的新舊交替,慢慢的單體應用給開發團隊、產品發展等造成的直接弊端,係統維護變得異常艱難。
一切不完美,都可以坦然麵對
在這種情況下,估計很多的開發團隊估計都會想到用分布式應用來解決。但是,分布式應用就一定是完美的嗎?答案當然是否定的。分布式應用也難免存在很多問題,例如:
- 如何保證服務之間調用鏈路的穩定性
- 如何保證服務調用安全性
- 遇到應用需要擴容時候該怎麼辦
- 應用拆分了,都需要單獨部署,我能怎麼更方便管理應用部署問題
- 服務調用的性能能保證嗎
- 畢竟是由本地調用改為了rpc方式,我需要怎樣更方便的監控調用鏈路呢?
- 分布式事務的問題要如何解決呢?
這些問題其實如果要全部解決,也是個浩大的工程。還好,不完美的世界不需要一個人麵對,總有些人在尋找解決方案。比如阿裏雲中間件產品EDAS,就是為分布式開發的不完美提供了不少解決方案。
EDAS能夠帶來什麼?
1、搭建分布式應用係統
快速基於EDAS開發好分布式應用,減少大量開發工作,應用可以是服務提供者,也可以是服務消費者,也可以兩者都是。
2、應用生命周期管理
3、鏈路調用監控
實際的大型係統中,都有很複雜的業務鏈路調用,如果將單體應用重構為分布式應用後,沒有一套良好的監控體係,在係統出現問題時定位問題將會異常困難。如圖是一個實際場景下的鏈路調用:
EDAS 鷹眼監控係統能夠分析分布式係統的每一次係統調用、消息發送和數據庫訪問,從而精準發現係統的瓶頸和隱患。
4. 單機進程內方法追蹤
當當當當~~
最新重量級功能隆重登場:方法追蹤。
讓你以火箭般的速度,打通應用診斷的“最後一公裏”。
EDAS 方法追蹤能夠幫助用戶在應用運行時出現問題時,進行快速的問題排查,典型的場景包括:
- 應用運行時突然發現執行某一個業務邏輯耗時很長,此時希望能夠有一種方式定位運行時代碼各個部分的耗時,以確定耗時點在什麼地方。
- 應用運行時一切正常,絕大部分情況下,業務運行都非常順暢,但某一例用戶反饋,當傳入XXX參數時,業務響應非常緩慢。此時希望能夠有一種方式針對特定的方法入參來觀察代碼執行情況。
- 一個比較複雜的程序方法,其中業務邏輯較為複雜,在真正運行時,無法確定具體調用了那些邏輯,以及調用時序。此時希望能夠有一種方式詳細的展現出方法執行的具體邏輯、時序等。
此外,以上的任何一種場景,都希望代碼無入侵,可以在應用運行時不停機的情況下,定位問題。
EDAS 方法追蹤采用 JVM 字節碼增強的技術,對選中方法的所有方法調用增加必要的耗時與調用序列記錄的增強,從而達到觀看執行過程中的具體執行序列的目的。
EDAS 單擊進程內方法追蹤和RPC框架無關,屬於 EDAS 基礎版功能,提升用戶應用診斷能力。方法追蹤是對當前分布式調用鏈路追蹤的補充,解決在使用調用鏈路追蹤功能定位到單機某一個服務的問題後,進一步診斷該服務方法本地執行的時序細節、各執行環節的耗時、入參/返回值和異常情況。
X公司開發案例實戰
像開頭說到的,當係統到達一定規模後,軟件複雜度急劇增加,維護也將變得異常艱難。如何用挽救X公司於水深火熱之中?下圖是將業務拆分後一部分業務架構:
其中,將資產中心和鑒權中心采用docker部署的方式,docker部署的方式可以支持一台服務器上部署多個應用,這樣也有利於節省硬件成本,提高資源利用率。
業務開發
代碼工程劃分
整體思路是提供一個公共的接口應用,作為公共引入的jar包(這隻是其中一種開發模式),其他每個應用一個工程,采用maven工程的模式來開發。本地開發時,如果幾個應用工程都在同一個環境下,可以將幾個groupId都指向同一個,方便調試。下圖是工程劃分:
接口應用開發
在接口應用中將需要被不同應用引用的實體以及需要對外暴露的接口都定義好。如圖所示
創建好後eclipse工程如截圖:
部分代碼片段:
引入接口工程
將tradeshop-api工程打成jar包發布到maven倉庫,在其他三個工程pom文件引入:
資產中心開發
資產中心要實現的業務是能夠被交易中心調用、獲取資產信息,所以資產中心需要做的是實現獲取資產信息的接口業務,並且用hsf標簽對外注冊提供服務。例如簡單的業務實現代碼為:
代碼實現後,就需要將服務對外暴露,供服務消費端來調用:
需要注意的是,發布的服務中version和group固定了,那麼消費端在調用的時候,這兩者的值必須保持統一。
鑒權中心開發
鑒權中心實現的業務是提供對外的接口用來查詢鑒權信息,那麼也是需要對外暴露一個服務,開發方式跟資產中心類似,可以參考資產中心的開發。
交易中心開發
交易中心需要有兩方麵的作用,一是對外暴露服務用於查詢交易信息,一個是充當消費端,主動去調用其他服務。充當服務端的代碼開發模式和前兩個應用類似,充當消費端去調用資產中心和鑒權中心的,就可以采用spring bean加載的方式獲取到接口service,然後當做本地方法來調用,如核心代碼:
將依賴的服務和需要發布的服務配置,注意版本號和分組值,以及接口名不能寫錯。
用戶中心開發
用戶中心在本案例中充當業務入口,去調用交易服務,所以用戶中心隻需要注冊消費一個服務即可:
消費代碼:
業務驗證
參考EDAS官網文檔,創建好應用,並成功將應用部署到線上後,可以在EDAS控製台上很方便的進行業務驗證,鏈路跟蹤,也就能很方便的定位到平時業務之間鏈路的瓶頸所在。查看創建及發布應用的文檔
應用服務驗證
當應用部署成功後,可以在控製上看到提供的服務和調用的服務,也可以在應用控製台上看到業務運行的日誌,如截圖所示
同樣也可以查看到應用中的http服務、hsf服務信息:
服務鏈路驗證
通過鏈路監控,可以很直觀的監控到整個業務調用的狀態,及時的定位到問題出現的地方
好了,一套簡單的分布式應用係統就開發完成了,so easy!X公司的故事,也不出意外的迎來了happy ending。
相關鏈接
產品專家建議:各版本特色看這裏
0-5個節點推薦:基礎版
5-50個節點推薦:高級版
50以上推薦:專業版
最後更新:2017-05-16 17:01:56