原标题：【Kubernetes实战经验：91APP电商平台】新兴系统要先容器化，再靠K8s实现IT微服务架构
91APP研发处副总经理林大维表示，使用Docker、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架构。”
相关：
【深度剖析容器应用平台】甲骨文锁定原生容器应用开发需求，靠CI工具串公云进军跨云市场
甲骨文推出了容器原生应用程序开发平台，在应用程序的开发周期中，主要靠Kubernetes来负责持续部署（CD）的任务，再搭配一套持续整合工具Wercker，来串接起开发环境到容器储存库间的持续整合（CI）工作，而利用Werc
【靠分散架构实现每秒20万笔交易】中国支付龙头142亿次海量红包派送关键大剖析
腾讯支付基础平台与金融应用线的平台研发部技术营运总监程伟指出，为了应付高频次的交易量，腾讯近年导入分散式架构，以及SET化的思维。（摄影／沈庭安） 从创立后，每逢正月初八，过完年假的第一个开工日，腾讯高
【深度剖析企业级K8s平台】IBM Cloud Private以K8s为调度核心，主攻私有容器云平台市场
IBM△Cloud△Private可作为企业的私有容器云管理平台，而以容器为基础发展，也为企业使用者带来更多自由度，例如，可以自由加入开源工具如Elasticsearch、Kibana或是Grafana等。（图片来源／IBM） IBM△Cloud△Pri
IBM发表可容器化应用程序且就地部署的IBM Cloud Private
图片来源: IBM IBM近日发表了IBM△Cloud△Private，这是个专门用来开发与管理就地部署且容器化应用程序的平台，有鉴于通过该平台能够打造原生的云端应用，将可替未来与公有云的介接铺路。IBM△Cloud△Private内建知名
OPNFV专案推新NFV平台也拥抱容器技术，要让虚拟网络功能也能跑在容器上
OPNFV专案在最新释出的开源NFV平台Euphrates中，开始初步支援了容器技术，要让虚拟化网络功能（VNF）也可以在容器中来执行，让企业在NFV环境中管理与调度VNF功能变更容易，这也是OPNFV迈向云端原生应用跨出的重要一