查看上篇文章，點擊這裡。
四、利用阿里雲原生服務構建遷移平臺
隨著業務發展，向阿里雲遷移的需求也越來越多，如果按照原來的方式，那麼用戶需要先進行下載、部署，再去遷移，造成了很多時間的浪費，也不夠敏捷。這時候，也對我們的工具提出了更高要求，需要演進成為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
