我们听说了很多关于容器编排执行得好,就能够流水化 IT 和业务流程的信息。3 月,在谷歌云平台会议上,我们在电子支付提供商 WePay 的实践中看到了成功。WePay 打破了单个程序到一套通过谷歌开源平台 Kubernetes 容器编排引擎来合作的模式。
“它真的改变了我们的业务,”,Richard Steenburg(WePay 的首席工程师)在后续的采访中说道。“Kubernetes 不会让你觉得做什么都束手束脚,相反,它为你要做的事情提供了基础。”
这周,谷歌发布了 Kubernetes 的最新版本,1.3 版本是一个“企业友好型”平台,比如说它支持有状态应用程序。
WePay 创建了 PCI 认证系统,用来处理信用卡支付,作为业务和用户之间的中间商。一开始是这样的,公司创建服务来作为单个应用程序,并且用 PHP 来处理主要部分。之后公司遭遇了令人苦恼的性能问题,妨碍了整体的系统的运行。比如,API 日志服务只用来进行内部找 bug,频繁地查询数据库,以至于拖慢了性能。
公司正处于把这个服务分解成更小的服务阶段。把单应用分解成粒度更小的服务同时,冻结了新功能的开发。
从目前看,Kubernetes 恰好会为 WePay 提供公司所需的灵活性来扩展到新的方向。“我们在路标上就可以看到能够帮助我们的功能,”Steenburg 说道。
WePay 转型到基于服务的解决方案,几个步骤就到它展开的架构。首先,开发团队剥去一些功能,将他们添加到 Docker 容器。开发过程仍然涉及到创建单个容器,所以 WePay 会继续使用 Ansible,每个虚拟机安装一个容器。
使用 SCM(软件配置管理)产品,比如 Ansible 就有它自己面临的挑战。换句话说,WePay 无法将服务进行自动伸缩。
“对于每次部署,如果你想要添加更多,你需要回滚,并且修改配置脚本,所以伸缩非常手工化,而且每次回滚的时候,都会有故障停机的风险,因为你实际上修改了部署它的东西,以此来处理更多节点。” Steenburg 说道。
Steenburgh 认为,Ansible 确实有滚动更新的能力,这点可以节约时间。这是 Kubernetes 提供的一个打开即用的方便功能。所以,对于公司来说,首先要迁移到 Kubernetes。
首先,Kubernetes 在重新思考架构的时候,确实提出了一个问题。特定的 jobs 将不再跟特定的一套机器绑定。公司不得不用把 job 的操作当成纯状态机,由一整套完全独立于硬件的关联进程组成,并且没有任何特殊的硬件需求。“我觉得这很不错,因为你的模型很纯粹,你不会想脱离它。” Steenburg 说道。
另一个使用 Kubernetes 的初始的挑战就是,开源编排引擎并没有加密信息流的方法,这也就意味着公司为了维护支付卡行业数据安全标准(PCI)需要自己去加密。当 Kubernetes 将 pods 实例化的时候,给了他们本地主机名,这样的话 pods 就无法在外网通过第三方证书授权来进行验证。
所以说,公司在 Nginx 和 Kube DNS 的基础上创建了一个 Kubernetes 方面的 pod 来提供内部证书授权(CA)服务,可以用来签署加密消息。
“实现支付很困难。跟银行一起合作处理很困难,跟协调者一起处理也很困难,其实最大的困难在于欺诈和识别欺诈,这是我们很长时间里都会遇到的情况,要做好跟它打长期战的准备,因为这是我们进行我们的业务的时候必然会遇见的。” Steenburg 说道。
现目前的情况看起来,不久之后,WePay 就会有一个足够灵活的架构来攻克这些面临的难题。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。