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架构。