我们听说了很多关于容器编排执行得好，就能够流水化 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 就会有一个足够灵活的架构来攻克这些面临的难题。

本文转载自才云Caicloud公众号。

原文链接：https://mp.weixin.qq.com/s/13lej58uqJKKSSOe2fxV8Q

创作场景

WePay: Kubernetes 改变了我们的业务