91APP新零售平台实践分享:靠Kubernetes实现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架构。