查看上篇文章,點擊這裡。
四、利用阿里雲原生服務構建遷移平臺
隨著業務發展,向阿里雲遷移的需求也越來越多,如果按照原來的方式,那麼用戶需要先進行下載、部署,再去遷移,造成了很多時間的浪費,也不夠敏捷。這時候,也對我們的工具提出了更高要求,需要演進成為SaaS版本。阿里雲的原生服務幫助我們進行了快速上雲,並且在不增加人員的情況下,完成了運維和運營的需求。那麼,我們是如何一步步利用阿里雲的原生服務來構建我們的遷移平臺(SaaS)呢?
(一)需求變化
從單機版本到SaaS版本,在部署方式等需求上均發生了變化,具體如下圖所示。
(二)需要改造的內容
從單機版本演進到SaaS版本,在各方面需要改造的內容主要包括如下:
- 增加模塊:對原有用戶模塊進行改造,抽象成多租戶管理和運營管理兩個新模塊;
- 單向通訊:源端在和控制端進行通訊時,採用的是雙向通訊,需要修改為單向通訊;
- UE提升:在雲平臺代理服務部署上需要讓用戶無感知;
- CI流程:去RPM化,能夠支持單機版本,SaaS版本的打包、部署;
- 部署和運維:平臺具備高可靠、擴展性、容易運維;
- 運營需求:在線客服、機器人、工單系統等運營功能。
(三)架構變化
從單機版本到SaaS,架構的變化如下圖所示。整個部署方式全面遷移到了K8s上,既可以保證模塊的可靠,也保證了模塊的可擴展性。
(四)阿里雲部署架構
下圖是遷移平臺在阿里雲的部署架構,主要使用的是阿里雲的容器服務,還使用到了鏡像倉庫、日誌服務等等。除此之外,還用到了阿里雲的雲客服功能來幫助回答一些常見的問題,降低了運維的成本。
(五)如何選擇阿里雲Kubernetes?
在選擇K8s服務的時候,我們對比了規格和價格兩個維度,綜合考慮選擇了託管版本,性價比最高,參考下圖所示例子。對於費用,建議用戶可以先去嘗試按量付費的方式,等業務穩定之後再轉為包年包月的方式。
(六)使用函數計算進行License自動審批
在SaaS版本中,函數計算主要用於License的發放、審批,我們利用了APP Trigger做了一個API接口,服務端直接進行調用即可。然而在單機版本中沒有網絡,很難做到在線的激活,所以我們做了一個二維碼掃描的小程序,用戶填寫信息提交之後後臺會接收到用戶提交的消息,釘釘進行審批之後會進行License的發放,具體流程如下圖所示。
(七)持久化集成
SaaS版本進行了持久化集成,其具體流程如下圖所示。
(八)利用雲原生服務進行運維管理
如下圖所示,我們現在利用阿里雲原生服務進行運維和運營的管理,大大降低了運維和運營的時間成本、人力成本。
(九)使用Zookeeper解決分佈式任務
如下圖所示,在SaaS版本中,我們用Zookeeper解決了分佈式任務的問題。思路一方式對現有架構的改動比較大,另外就是當任務量極其大的時候也會出現瓶頸,而思路二引入Zookeeper幫助我們解決了併發性的問題。
(十)數據安全性
數據安全是用戶非常關心的一點。如下圖所示,我們的SaaS端只會控制用戶控制流的信息,用戶的數據流是直接從源端到用戶租戶下的數據接收代理服務器上,這樣子用戶的數據不會經過我們的SaaS端,保障了用戶的數據安全。
五、未來展望
可以預見的是雲原生的服務對未來的IT行業格局會有非常大的影響。對於我們自身,未來我們的目標是做遷移和容災的SaaS工具集。如下圖所示,我們希望通過對自身模塊的不斷擴充,能夠更好的幫助用戶完成遷移和容災的工作,為業務賦能。
關鍵詞:阿里雲、雲原生服務、遷移服務、SaaS