Sorry, this entry is only available in 繁體中文. For the sake of viewer convenience, the content is shown below in the alternative language. You may click the link to switch the active language.
【原文出處／轉載自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架構。」