【译】云原生应用的崛起（上）

技术译文专栏归来！三墩IT人近期完成了对云原生应用相关原著的翻译，将分为两期与大家分享。今天带来上半部分：向云原生应用架构迁移的驱动力。...

【译者】


朱智武    浙江移动云平台架构师、资深SRE

钱晓优    上海天玑运营工程师

以下为译文

被传统巨头统治多年的稳定行业正被以软件为核心的新贵们迅速颠覆，像Square, Uber, Netflix, Airbnb及Tesla这样私有市场估值持续迅速增长的公司，已经引起这些传统巨头管理者的注目。那么，这些创新型企业有何共通之处？

• 快速创新
• 不间断的服务
• 网络规模
• 以移动为中心的用户体验

    云化迁移是聚焦于软件的自然演进，而云原生应用程序架构也是上述公司获取其颠覆地位的核心。云是计算、网络、存储资源以自助形式按需弹性提供和回收的任何计算环境。此定义包含公有云的基础设施（例如亚马逊网络服务，谷歌云或微软Azure）及私有云的基础设施（例如VMware vSphere或OpenStack）

本文将阐述云原生应用程序架构如何驱动这些创新，随后我们一起来审视云原生应用程序架构的一些关键问题。

Why Cloud-Native Application Architectures?

为什么采用云原生应用程序架构？

首先，我们来探讨向云原生应用程序架构迁移的幕后驱动力。

Speed 速度

显而易见，速度赢得市场。那些勇于创新，尝试及迅速交付的基于软件解决方案业务将迅速淘汰那些采用传统交付模式的业务。

在企业里，提供新的应用程序环境及部署软件新版本通常所需时间以日、周甚至以月计算。这种速度严重限制了软件发布所能承受的风险，因为犯错及改错也需要花费同样的时间成本。

互联网公司经常因一日部署数百次被作为标杆。频繁部署为何如此重要？倘若你在一天的时间里可以部署数百次，那么你几乎可以立即从错误中翻身。立即从错误中翻身，意味着你就可以承受更多的风险。而承受更多风险的能力，可以让那些创新的大胆尝试成为你的下一个竞争优势。

云基础设施的可伸缩性及自助性让其自然而然向这种工作方式转变。相比基于表单的人工流程，调用云服务API提供新的应用程序环境则快好几个数量级。通过调用其他API给新环境部署代码则又提升了速度。给团队的持续集成/编译服务器环境增加自助及钩子能力则再次提升了速度。最终，我们可以试着回答Mary Poppen-Dick大师的问题，“你的组织需要多长时间部署一行简单代码的变更？” 几分乃至几秒之内！

试想，若你可以做到如此快速，那么你的团队你的公司将可以做些什么！

Safety 安全性

当然仅靠快速远远不够。若你上车就油门踏板踩到底加速，最后很可能发生严重（致命）的交通事故。飞机高铁等交通工具是兼顾了速度及安全，云原生应用程序架构平衡稳定性、可用性及持久性需求的同时，还满足了对快速运行的需要。这两者是可以且必须兼得的。

正如之前所提到的，云原生应用程序架构可使我们迅速从错误中恢复过来。这里并不是说企业需要花大量的宝贵时间关注工程进展来错误避免。大量预先设计，详尽的文档，架构审核委员会及漫长的回归测试周期都与我们所寻找的“高速度”相悖。当然，所有这些设计的初衷都是好的。但不幸的是，在使之付诸生产的缺陷梳理检测中，都没能可以提供持续的改进。

那么，我们如何做到既快速又安全？

1、可见性

架构必须提供故障检测的必要工具，我们需要检测任何事件的能力，包括建立一个“正常状态”的档案，探测异常事件（包括绝对值及更改率），确认造成这些偏差的组件。功能丰富的指标、监控、告警以及数据可视化框架和工具是所有云原生应用程序架构的核心。

2、故障隔离

为控制故障带来的风险，我们需限制能被故障影响的组件或者特征的范围。若每次亚马逊的推荐引擎发生故障，客户都不能通过网站购买产品，那将是个灾难。单体式应用程序架构通常会发生这种类型的故障。云原生应用程序架构通常使用微服务架构，通过微服务编排系统，我们可以把任一微服务的故障缩小到仅限于该服务内，但前提是必须与容错相结合。

3、容错性

仅仅将系统分解为独立部署的组件还是不够的，我们还必须要防止那些会因依赖性而引起连锁故障的组件出现问题。 Mike Nygard在他的书Release it（程序员修炼之道）内描述了一些容错模式，最有名的是关于熔断器的描述。软件熔断器的工作原理与电路熔断器非常相似：通过熔断其保护的组件与故障系统剩余部分之间的电路来阻止连锁故障，还可以在断开后提供一个优雅的回退动作，比如一套默认的推荐版本进行回退。

4、自动恢复

通过可视化、故障隔离、容错机制，便拥有所需的工具来识别与恢复故障，并在识别及复原故障的过程中给我们的客户提供合理的服务。有些故障很容易识别：他们在每次发生时均有类似容易察觉的症状。以服务器健康检查为例，通常只有两种结果：健康或不健康，运行或关闭。每次在面对这样的故障时，大多都采取同样的措施。如若健康检查失败，我们通常重新启动或部署该问题服务。云原生应用程序架构在此种情况下并不会等人工来干预。相反，它们会使用自动检测及恢复。换言之，通过让计算机携带传呼机来代替人工干预。

Scale 可扩展性

随着需求的增加，我们必须扩展我们的能力来满足需求。过去，我们通过垂直扩容处理不断增加的需求：购买更大的服务器。虽然我们实现了扩展，但扩展速度缓慢，且为此支付了高昂的费用。因此必须开始进行基于高峰期使用量的容量规划。我们思考“该服务所需最大计算能力是多少？”，然后购买足够的硬件满足这个数量。这种办法很多时候都会出错，例如实际可用容量仍然不够对付“黑色星期五”这样的节日。更多时候，大部分服务器的cpu处于空闲状态，导致利用率指标底下。

创新型公司用两个开创性措施来处理这个问题：

• 放弃继续购买更大服务器的做法，他们通过购买大量便宜的通用X86机器水平扩展应用实例。这些机器可轻易获取（或集成），快速部署。
• 通过对通用服务器的虚拟化，并部署多份独立的负载，从而提升现网大量服务器的利用率。

    随着像亚马逊AWS这样的公有云基础设施的出现，这两个措施则合二为一。虚拟化由云提供商负责，而用户专注于其应用程序基于大量云服务器实例的水平扩展。近期的另一个转变是，从虚拟服务器技术转向作为应用部署单元的容器技术。

云的这种转变打开了更多创新的大门，因为企业不再需要大量启动资金来部署软件。日常维护也仅需更低的资金投入，API的提供不仅提高了初始开发速度，还使我们响应需求变化的速度达到最快。

然而所有这些好处均需付出代价。应用程序必须进行水平架构，而非垂直架构。云的伸缩要求迅速，因此，我们不仅要迅速创造新的应用实例，还要快速安全地销毁他们。此需求是状态管理的难题：一次性与持久性如何交互？大多用于垂直架构的集群会话及共享文件系统等传统方法的扩展性并不是很好。

云原生应用程序架构的另一个特征是，将状态向外存储到内存数据网格、缓存、持久化对象存储，从而保持应用实例本身无状态。无状态应用可被快速创造和销毁，亦可附加或脱离外部状态管理器，提高我们应对需求变化的能力。当然，外部状态管理器本身必须可扩展。大部分云基础设施提供商已意识到其必要性，正在持续提供此类服务。

Mobile Applications and Client Diversity 移动应用及用户多样性

截至2014年1月，全美的55%的互联网访问来自移动设备，基于桌面终端实现应用程序的日子一去不复返。相反，我们要设想到用户正拿着多核超级计算机在到处晃荡。这对应用程序架构有着十分重要的影响，因为不断增加的用户可以在任何时间任何地点与我们的系统进行交互。

以查看活期账户余额为例：通常这个过程是通过致电给银行呼叫中心，或者亲自前往ATM机，或者咨询银行任一支行的服务专员完成的。这些用户互动模式极大地限制了银行底层软件系统在任一时间均可承载的需求。

虽然转向在线银行服务引发了需求的上涨，但仍不能从根本上改变互动模式。人们仍需坐在电脑前与系统互动，而这仍较大程度限制了需求。正如我的同事Andrew Clay Shafer所说，只有我们所有人带上口袋里的超级计算机到处移动，我们才开始让这些旧有系统感受到痛苦。如今，成千上万的客户可以在任一时间任一地点使用银行的系统。一位银行高管说，发薪日当天，用户会在几分钟内多次查询余额。传统银行系统的架构并不能满足这类需求，但云原生应用程序架构却可以。

移动平台间的巨大多样性对应用程序的架构也提出很多要求。在任一时刻，客户可能通过多个不同供应商生产的设备与我们的系统进行交互，这些设备运行多个不同的操作系统，或运行同一操作系统的多个版本，或运行在不同规格的设备上（例如手机和平板电脑）。这不仅给移动应用程序的开发者增加了各种约束，也给后端服务的开发者增加了约束。

移动应用程序通常需要与多个传统银行系统及云原生应用程序架构内的多个微服务交互。这些服务不在设计时并不支持用户使用的各种移动终端的独特需求。强行让移动开发者负担这些不同服务的集成，会增加延迟和网络开销，导致缓慢的响应及高耗电量，最终致使用户删除该应用程序。云原生应用程序架构也通过比如API网关等设计模式支持移动先行开发的理念，API网关将服务聚合的负担转移回服务端。

Summary 总结

本章，根据我们“希望通过软件提供用于业务的能力”这一目的，探究了向云原生应用架构迁移的共同驱动力。

Speed 速度

比竞争对手更快地实施创新、试验及实现价值的能力。

Safety 安全性

快速行动的同时保持稳定性、可用性及持久性的能力。

Scale 扩展

灵活应对需求改变的能力。

Mobility 灵活性

客户可在任何时间任何地点任何设备上与我们无缝互动的能力。

我们还调查了云原生应用架构的独特特点及他们如何帮助我们提供这些能力。

to be continued ...

译文下篇：
将为大家分享云原生应用架构十二要素，敬请期待。

    关注 三墩IT人