聊下系統改造

最近公司技術架構需要改造升級,實現分佈式服務中心、分佈式日誌系統以及統一的後臺任務管理系統,當時接到這些任務,心裏是猶豫的,主要有以下幾點考慮(這裏考慮的任務是分佈式服務中心,其他兩個任務還是比較好改造的)。
 
1. 人力不夠,後端本來人手就幾個,一個蘿蔔一個坑,不可能全部調動來做這個事,畢竟公司需要拓展新的業務賺錢。
2. 工作量太大,目前公司至少有50+的服務在線上跑(這還不包括藍綠、集羣環境),每個服務都跟網關發生了關係,而且原來就有一套服務發現機制,更麻煩的是還有同事在網關裏面直接聚合業務邏輯,沒有完全抽象出來網關層,這就意味着,這個活不好做,週期太長,費力不討好,很簡單因爲老架構在跑,有對比。
3.成本太高,這麼多工作需要遷移,不可能短時間內就能一步到位,期間肯定會出現新老架構的協作問題,原本就比較複雜的架構勢必會變的更復雜,到那時候我就吃不了兜着走了。像這種情況在沒有絲滑平移的解決方案之前千萬不要盲目改造,尤其是小公司,困難再大,工作還是要做,下面簡單聊下我這邊的改造方案,不涉及技術。
 
第一個任務,目前公司有很多後臺任務,沒有統一的方案,開發人員各寫各的,各自發布,技術方案也是滿天飛,有hangfire、有quartz,有while循環等等。最嚴重的問題就是出了問題連服務都找不到在哪裏。統一後臺任務管理,需要把這些服務全部統一管理起來,我這邊的方案就是參考jenkins,基於net6mvc,alc機制實現一個最基本的web插件系統,支持熱插拔並且提供dashboard對插件進行管理,插件與框架之間基於約定的方式實現,最終的效果就是,服務還是各自開發,但是需要遵循框架的約定,提供插件信息描述文件,配置路由和view試圖以及日誌log,開發人員開發完插件通過dashboard上傳到框架,進行簡單任務配置,最後啓用任務。
 
第二個任務,目前碰到的幾個問題,1. 外部請求被轉發到gateway網關,網關需要寫一份對應的轉發代碼,包括請求參數和返回參數還有對應的方法(這個工作很費時間,參數需要對齊,效率很低),2. 網關代碼量越來越龐大,性能也會越來越差,後期維護越來越難,3. 網關裏面直接編碼聚合了業務,4. 還有服務發現的問題等等。基於以上問題,我這邊最開始的想法就是拿掉這個僞gateway,直接上ocelot或者envory,後面果斷放棄了,原因前面寫了,工作量太大,兩套架構並行,無疑是加大工作量和複雜度,而且週期太長。幹不掉它那就妥協,我這邊最終的方案就是還用原來的gateway,兼容原來的工作,再在此gateway之上擴展出新的功能,路由、鑑權等功能結合服務註冊中心,適配新的方案,這樣就能寫很少的代碼,花很低的成本過度了這幾個問題。新功能的開發後端不要去對接網關,網關代碼量的增長也就停止了,後面新接口的請求,網關直接通過服務註冊中心zookeeper或者consul獲取地址轉發,原來的那些老接口不需要做任何改動,走原來那一套服務發現和轉發策略,互不影響。這還是沒有從根本上解決問題,老服務的那些代碼還在網關裏面,還在用原來那套服務發現機制,這個問題確實不是一兩天能解決的,但是至少整個架構在往新的方案遷移,而且成本最低,對現有開發團隊的工作沒有絲毫影響,非常絲滑。原來gateway裏面的那些對接老代碼,後期哪個同事需要對老服務開發新的功能,再把這個服務之前跟網關對接的代碼刪掉就好,只要刪掉原來對接的代碼,再把這個老服務註冊到服務中心就行(這裏說明一下,我們所有服務都是基於DDD領域設計劃分業務邊界的,所以每個服務的粒度很細業務代碼也不多)。還有最後一個問題,gateway裏面還有很多聚合業務的代碼,針對這個問題的處理方案就是在gateway後面設計出了一個聚合服務,後續開發人員碰到了,再把它平移到聚合服務,到最後這些工作遷移的差不多了,再把網關平移到ocelot或者envory等專業的網關產品上面。
 
第三個任務相對來說比較簡單,就這樣吧。
 
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章