【Kubernetes實戰經驗:91APP新零售平臺】新興系統要先容器化,再靠K8s實現IT微服務架構

By |2018-10-05T15:12:07+00:002018-09-25|媒體報導, 新聞媒體|0 條評論

【原文出處/轉載自iThome 2017.11.17 《Kubernetes實戰經驗:91APP新零售平臺》新興系統要先容器化,再靠K8s實現IT微服務架構

儘管多數是.NET系統,91APP也積極擁抱輕量級容器技術,透過鄉村包圍城市的策略,新興系統先擁抱容器,下一步想轉型更高彈性的微服務架構,關鍵就是導入Kubernetes來管理複雜的容器叢集。

臺灣知名的新零售平臺供應商91APP,已有超過1萬家品牌企業,透過91APP平臺經營自家電商生意。為了承載旗下企業用戶整併線上、線下的零售業務擴充需求,成立不久,91APP很快就將自家平臺搬上AWS公有雲,近年更納入跨雲架構,也將部份新服務分散部署到Google雲端平臺GCP上執行,還利用Kubernetes(K8s)為基礎的Google容器引擎GKE,調度、執行新開發的容器應用程式。

91APP踏上容器化的旅程並不久,成立初期,該公司的應用程式都是以.NET框架開發,並且在微軟環境執行。但是,近年在微軟大力擁抱容器技術、走向開放的策略,不只推出了自家的Windows容器技術,重要產品如SQL Server、.NET核心也都可以在Linux環境下執行。

連微軟都開始大力支援,可見容器未來必然成為重要的IT技術。因此,91APP研發處系統架構部技術總監劉峰全也表示:「容器這門技術發展方向變得更加明朗,我們決定開始投資容器技術。」不過91APP是鎖定了以Linux為基礎的Docker容器,並且開始使用Linux、Node.js等平臺著手開發新系統。在2016年Q3後,該公司未來系統藍圖的規畫,已經將容器化、微服務轉型視為重要的轉型策略。

新興系統優先擁抱容器技術

91APP的容器化過程中,採取「鄉村包圍城市」的漸進策略,核心系統不先進行大規模修正,而是先從新興開發的應用程式切入,導入容器技術。林大維認為,這樣逐步加溫的做法,可以免除架構一次大更動的風險,「承受合理的風險,同時擁抱新技術往前進。」

雖然多半正式環境下還是以VM為主力,但是現階段部分系統的開發、測試環境,已經開始導入Docker容器。林大維舉例,現階段研發、產品團隊總共有140人,有許多專案同步進行開發,如果每個環境都得要手動建置,將會浪費許多時間。而Docker其一優點,就是開發者可靠映像檔建置統一環境,除了加強產品開發、測試到上線環境的一致性,除錯工作也因此變得更為順利。

微服務架構要以容器技術為基礎

目前91APP總共有兩個重要服務使用容器為基礎架構,並且利用Kubernetes做為調度引擎,而這兩個服務的共通點在於,不時會產生爆量事件,「因此很適合使用容器技術。」林大維表示,首先是該公司自建的使用者行為追蹤服務,其功能與Google Analytics類似,可用於分析其平臺上使用者的行為。

第二個服務則是通知中心,整合EDM、簡訊以及App通知,作為該公司與消費者的溝通管道,「碰上促銷或是特定節日時,該服務也會產生相當大的使用流量。」

而導入容器技術只是第一步,91APP的更長遠的目標是引入微服務架構。若使用VM打包這些應用程式,將使得部署成本變得非常可觀。劉峰全表示,因此要以先前導入的容器技術為基礎,憑藉其快速開啟、部署的特性,實現微服務架構,「容器與微服務是相輔相成的。」除此之外,容器技術讓跨雲IT架構變得可能。林大維表示,每個公有雲都有各自特色,但相比容器技術,VM與底層架構的相依程度更高,較容易被廠商鎖死。但是,微服務架構會導致應用程式部署變得更為複雜,因此管理這些龐大規模的容器叢集的工作,就得靠容器調度工具完成。劉峰全表示,過去他亦有研究DC/OS、Swarm相關的解決方案,各家也都有優點,像是Swarm在本地開發環境不會占用太多硬體資源,若開發者要在本地環境使用Kubernetes,還得安裝Kubernetes本機版Minikube。

GKE除容器調度外,還能整合GCP其他服務

而劉峰全認為,比較在AWS、GCP使用Kubernetes的經驗,在GCP上的使用體驗更為友善。首先,Google以Kubernetes開發的容器引擎GKE,除了提供方便開發者操作的命令程式介面外,「只需要幾秒鐘就能完成Kubernetes叢集的建置」,不僅如此,劉峰全表示,GKE還可以整合其他GCP上的服務,例如提供應用程式、Log監控的Stackdriver,確保容器應用程式的運作正常。再者,想切入大數據應用,GCP亦有雲端資料倉儲Big Query,或是支援串流、批次資料處理的Dataflow。

相比還未提供正式Kubernetes服務的AWS,劉峰全認為,在此環境Kubernetes叢集的建置工作就較為困難。過去是使用容器平臺Rancher管理主機上的容器。不過他表示,過去使用Rancher經常發生容器叢集故障的問題,直到後來使用Kubernetes安裝工具Kops,才讓建置過程變得較為順利。

而使用Kubernetes其中的一個挑戰,就是其改版速度相當快,每年至少會釋出3到4個大版本。劉峰全表示,目前91APP的Kubernetes已經更新至1.7.2版本,而在GCP環境中,GKE也會自動將Master節點上運作的Kubernetes更新到最新版,而使用者可以依據需求,決定要否更新其餘的Worker節點。

至於AWS環境,目前得仰賴系統管理員手動更新。為了避免更新造成系統不穩定,目前91APP將測試環境叢集獨立,並且整併正式環境、半正式環境。當測試環境更新並未發生異常,才會將新版Kubernetes導入正式環境。

引入新技術也會帶來組織面的變革

而導入容器、Kubernetes的影響,不單只改變了系統架構,同時也對91APP資訊團隊產生了影響。林大維笑著說,91APP始終抱持「自己的程式碼,自己維運」的想法,該精神也與近年的火紅的DevOps不謀而合,意味工程師在開發程式時,就得設法改善程式碼品質,減輕後續維運團隊的壓力。

劉峰全解釋,Kubernetes所帶來的變革,可從開發、維運兩個層面探討。首先,使用者可以透過Kubernetes定義系統元件的相依性,在部署組態設定中,撰寫甲元件、乙元件間的相依關性。因此,雖然導入微服務架構會提高系統複雜度,「但是開發者可利用Kubernetes的組態設定檔案,掌握各元件間的關係。」此外,過去重要服務一個禮拜僅能釋出一次更新,但是現在結合容器技術及Kubernetes,讓CI、CD自動化程度提高,「一天內能進行多次的部署。」

而在維運工作帶來的改變,「Kubernetes也能實現基礎架構程式化(Infrastructure as Code)」,他解釋,因為每一次部署都必須撰寫組態設定檔,因此基礎架構可以如程式碼開發般進行版本控制,當系統故障時,開發者也比較容易追蹤問題的起因。

引入Docker及Kubernetes改革自家IT架構,從單體邁向微服務

同時,IT架構走向容器化時,也逼得91APP開發團隊得要檢視過去的IT架構設計,是否能符合現代應用程式的思維。林大維表示,在傳統單套式架構中,許多企業也不重視系統組態管理,「只要系統能運作,僅更新程式碼,卻不重視系統組態。」但是在使用Docker、Kubernetes時,開發者都必須明確定義應用程式執行所需要的環境組態,也因此,企業必須顛覆過去程式開發的思維,讓應用程式具備水平擴充性,「逐步讓單體架構分解。」林大維笑著說,組態系統管理也是91APP的重要計畫,未來開發者除了交付程式碼外,還得同時交付組態設定檔,必須為自己開發的程式碼與組態負責,「容器化是我們的共識,而這些新技術將會讓91APP持續演進既有的IT架構。」