巨人也能身手敏捷？看美国KeyBank的实战经验

Raffaele Spazzoli是红帽PaaS和DevOps咨询部架构师。本博文描述了他在加入红帽之前为KeyBank提供服务的经验。

将发布周期从三个月缩短到一星期的历程。

这是超大型地区银行KeyBank将每季度向生产环境部署缩短到每周部署的历程。在这个过程中，我们全部采用开源软件从WebSphere迁移到Tomcat，并使用OpenShift作为私有Linux容器云平台。并且是在数字渠道现代化项目中做到这一点的，这是银行在当时最重要的项目。

数字渠道现代化项目的范围是迁移基于控制器、在本土MVC框架上开发，并在Java 1.6和WebSphere 7.x上已运行15年的Java web应用到更现代化的web环境，并创建一个新的移动Web应用。

该Web应用在维护和满足我们SLA方面的花费越来越高。这是一种典型的大型应用。我们的架构目标是创建一个API层，用于将展示逻辑（Web或移动）与业务逻辑分离——这首先需要完全更新持续集成和部署流程。最初，我们的发布周期是每个季度。发布流程的费用高昂，任务艰巨。这是极高标准的发布流程（包含需要大约70个手工步骤完成的Excel电子表格），通常在周末进行，目的是系统在周一早上可以恢复上线，进行正常的业务处理。我们曾对此有信心，但结果并不好。

于是，我对大型企业（Google、Amazon、Facebook等）如何管理发布流程进行了一些研究，而且幸运的是，我在参加一次会议听到了Netflix介绍自己采用的方法。通过研究发现，这些企业的发布流程指标（频率、成本、代码完成到代码部署到生产环境的时间）比我们大两三个量级。我决定让我们的交付组织从每季度发布改为每周发布。坦率地说，我对这个挑战并没有太认真地考虑，但这个目标已经在我心中形成。我认为，每周发布对于银行的数字渠道非常合理。我在项目中的角色是解决方案架构师。我提出了一种新的架构，其中包含完全无状态的REST服务层和两个前端：基于AngularsJs的Web应用和基于Ionic框架的移动应用（基本上采用与Web应用相同的代码）。目前，我们的计划仍然是在WebSphere上运行这个新应用，因此，我开始要求运营团队开展一系列变更。我要求对JDK进行更新（从版本6更新到版本7）。我需要更新的JDK，这样才能利用JAX-RS编写REST服务。起初，运营团队不愿意做出改变，然后，在认识到目前使用的JDK很快就会淘汰后，他们开始部署新的JDK。这个过程耗时6个月。我要求能够使用Liberty作为应用服务器。WebSphere在开发人员的笔记本电脑上启动速度极慢，需要5-10分钟，因此，由于即将开始实施的大项目，我们需要更敏捷、更快的解决方案。我得到的答复是：我们可以在笔记本上使用Liberty，但生产环境唯一支持的应用服务器是WebSphere。因此，我们在做这件事的时候感觉非常不舒服，原因是从直觉上来讲，我们知道生产环境“走得更快”很重要，否则，在更高层的环境（IT、QA、生产）中更改堆栈的主要要素时，环境中会出现过多错误。我需要一种分布式缓存工具。之所以需要这种工具，是因为我希望我们的服务层完全无状态（而且无会话），而且处于效率方面的考虑需要有缓存功能。我了解到的情况是，目前并没有官方支持的分布式缓存平台，未来可能会有。这些情况（以及其他未提到的情况）让我思考：我们显然做错了。开发团队无法正确地表达自己的需求，运营团队可能过于担心业务中断从而保持现状，而我作为解决方案架构师夹在这两个部门之间，可能无法展开很好的协作。我觉得需要彻底改变这种模式，并且摒弃交付团队以前采用的复杂服务请求流程，改为由运营团队交付基础架构。另一个需要设立全新基础架构的团队曾经做过一项调查，结果发现，他们必须提出大约四百项申请。我认为交付团队应该能够自行配置其自己的基础架构。最后得出结论，我需要私有云基础架构。于是，我决定自己进行研究，看哪种工具最适合我们。同时，一个小型运营团队刚刚解决了一些非常棘手而且长期存在的网络问题，并接手了下一个难题，即在KeyBank构建私有云。我们携手合作，并且根据研究结果，确定Kubernetes是目前最好的基于容器的私有云平台。我们采用基于虚拟机的云平台没有意义，因为我们明白容器从技术上来讲优于虚拟机。我们寻找为Kubernetes提供专业支持的机构，最终发现红帽及其OpenShift平台是极为可靠的选择。随后的事情进展很快。在与红帽签约后，我们进行了为期4个月的生产环境预览，并且7个月内在首批客户的生产环境中部署。我们将应用从WebSphere迁移到Tomcat，并且将REST引擎从Wink转移到更受欢迎的（在WebSphere中无法运行）Jersey，同时新增了Hystrix，并实施了断路器模式作为可用性战略的组成部分。我们采用Redis实施分布式缓存。

（点击图片查看高清大图）

技术方面永远是最容易做到的。我们的目标仍然是每周发布，而且我们遵循的原则是：自行配置基础架构和无法更改的基础架构。为了实现目标，我们需要定义OpenShift中部署的应用的所有权和支持模式。事实上，如果开发团队可以自行维护其基础架构，那么问题是：谁为其提供支持？通过考察Google、Netflix、Spotify的方式，我们采用的模式是由交付团队负责其所需要的基础架构（即在容器中添加的内容），而开发团队的任务是保持OpenShift的可用性（很明显，OpenShift对可用性的要求比其上运行的应用更高，这意味着银行要达到接近100%的可用性）。为了保证所有权的明晰，我们决定将指定项目的OpenShift配置文件与其他项目源代码放在一起。我们还需要通过持续交付渠道实现所有业务的自动化。

（点击图片查看高清大图）

我们采用以下逻辑在Jenkins中建立了一个流程：

• 每十分钟对源代码库轮询一次，如果有变化，我们将触发新的构建动作。

• 构建流程会运行单元测试和其他操作，以创建我们项目的Docker镜像。该Docker镜像此后不会变化。这是我们的不可变基础架构的一个要点。

• 下一步是在解决方案的每一层以隔离方式运行一系列集成测试。隔离是指模拟对外依赖性。这样，我们就能够独立于可用性而运行一系列测试，包括下游依赖关系和测试数据的质量。这些测试在临时环境中运行（在OpenShift中相对较容易进行）。

• 接下来的步骤是在IT环境中运行一系列集成测试。

• 我们每天在QA环境中部署最后一个成功的构建版本。这个环境用于手动探索性测试和手动（目前如此）加载测试。

• 最后一步是在生产预览环境中每周部署一次。这一步需要手动批准。

在生产环境中部署需要KeyBank的多次批准。这些批准以会议形式完成，即人们展示将部署的内容，而高级领导者签署发布命令。这个过程不适合我们，因为我们没有足够的时间每周举行三次会议（的确，这需要三个不同部门确信发布版本的合理性）。我们可以改变这样的流程，并且同意：如果一个版本仅影响OpenShift内部的组件，我们就自动批准该版本的发布。我们需要的最后一块是我们的自动化回归测试套件的完全覆盖。经历几次磨人的操作，我们很快认识到，如果不能做到完整的回顾测试覆盖，我们就无法将发布速度提升到每周一次。实际上，手动测试团队无法足够快地每周对所有内容进行重新测试。我们采用一些行为驱动开发 (BDD) 原则构建了测试框架，并选择Cucumber作为BDD工具。Cucumber的优点在于，它允许以自然语言（英语或其他语言）编写测试案例。我们决定充分利用这个优点，并让业务分析师团队编写测试例子。这样，我们能够同时开发业务代码和测试代码，而在以前，这两项任务要依次进行，因此，测试（手动或自动）过程始终要测试旧版本的代码。我们使用Selenium测试浏览器和浏览器应用操作系统的多种组合，并使用 Appium测试移动设备和移动应用操作系统的多种组合。结论现在，KeyBank对我们发布流程的信心有了很大提高，而且我们能够在每个星期四早上发布。通过采用滚动部署——OpenShift的现成特性之一，我们可以进行零停机发布，这是我们长期以来的要求，而以前的解决方案都做不到这一点。我们还实现了自动扩展。我们在加载测试期间深入测试了这项特性，而且我们现在知道，我们的系统（或者至少是在OpenShift中部署的层）将通过横向扩展，为管理当前负载部署正确数量的实例，从而应对负载峰值。这在银行内部被认为是一个优秀的成功故事，而接下来的任务是将这些流程复制到其他项目中，将更多负载迁移到OpenShift。