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

臺灣知名的新零售平臺供應商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架構。」