如何正确地迁移到云原生应用架构
如何正确地迁移到云原生应用架构
原生云的崛起
软件正在吞噬这个世界——马克.安德森（Mark Andreessen）
近年来，一直被拥有根深蒂固的传统思想的大佬们统治的企业正在被快速打乱，他们正在被以软件为核心的企业所破坏。例如Square, Uber, Netflix, Airbnb,和Tesla等公司，这些公司持续快速增长，拥有非公开市场估值，令业内历来领头的企业刮目相看。那么，这些富于创新精神的公司有什么共同点呢？
- 超快创新速度
- 持续可用的服务
- 弹性web
- 以移动为中心的用户体验
迁移到云是软件的自然演化，原生态云应用架构是这些公司获得他们这种破坏性特征的核心。云，我们指的是能以按需、自助的方式弹性提供和释放计算、网络和存储资源的任何计算环境。这个定义包括公有云基础设施（例如AmazonWebServices, Google Cloud, 或者MicrosoftAzure）和私有云基础设施（例如VMwarevSphere或者OpenStack）。本章节我们将会解释原生云应用架构如何能够具有创新特性。然后我们会验证原生云应用架构的一些主要特性。
为什么是原生态云应用架构？
转向云原生应用架构的动机可归为以下几点：
速度
在市场经济中，速度至关重要。能够快速创新，实验，并交付基于软件的解决方案的企业相对那些遵循传统交付模式的企业，具有更强的竞争力。
在传统企业中，提供新应用环境和部署新版本的软件所花费的时间通常以天、周、或月计算。这是种极度缺乏速度的做法，将严重限制发行版本所能承担的风险，因为产生和修补错误的成本也需在同一时段内衡量。
而如果企业可以从故障错误中实时恢复，就可以承担更多风险，从而尝试更多实验。竞争优势就会由此产生。
基于云的基础服务设施的弹性和其自服务的天性与这种对实时性的需求十分契合 – 通过调用云服务API提供新应用环境要比通过基于表单的手动方式快很多。；给持续集成/建立服务器环境添加自服务和钩子（函数）亦可提高速度。
安全
显然，单一追求速度也是不够的。原生云应用架需要在灵活性、稳定性、可用性和耐久性做平衡考虑，这就像高铁和航空系统在建造时兼顾速度和安全性，而不能像在公路上驾车，只是一脚油门到底的去不顾安全的追求速度。
原生云应用架构能够确保使我们能够迅速从错误中恢复。这与错误预防不同，这对于诸多企业投入大量时间成本而来的程序工程十分重要。前期的庞大设计，详尽文档，架构审查工具，和漫长的回归测试周期都与苦寻的速度息息相关。当然，这些做法都是出于好意。但尚无法改提供一致、可衡量的方式改善上述缺陷。
那么怎样才能实现更快、更安全呢？
可视化
架构须提供当错误发生时能看到它的工具，和能够度量一切的能力 – 建立一个“什么是正常的”的配置文件，检测偏差（包括绝对值和变化率），并确定这些偏差的组成部分。功能丰富的指标，监测，报警和数据可视化框架以及工具是在所有的云原生应用架构的核心。
隔离故障
为了限制与故障相关的风险，限制可能会受到故障影响的组件或功能的范围也是必要的 – 如果每次亚马逊的推荐引擎挂掉后就没有人能从Amazon.com上买东西，那将是个灾难。整体应用架构往往具有这种类型的故障模式。原生云应用架构通常采用微服务（“Microservices”）。微服务组合系统，可以把任意一个微服务的错误单单限定在该微服务上，但前提是加上容错。
容错
把一个系统分解成可独立部署的组件是不够的；还要防止其中一个组件的错误通过其可能存在的多个传递依赖关系造成级联故障。MikeNygard在他的《ReleaseIt! – Pragmatic Programmers》一书中描述了一些容错模型，最受欢迎的是断路器。软件断路器的工作原理非常类似于电子断路器:通过断开它保护的组件与故障系统的其余部分之间的回路来防止级联故障。它还可以提供一个优雅的回退行为，比如回路断开的时候一组默认的产品推荐。
自动恢复
利用可视化，错误隔离，容错，涵盖了所有识别错误所需的工具，并可从错误中恢复，在参与识别和恢复的过程中给我们的客户提供一个合理水平的服务。一些错误较易被识别，因为每次发生他们都呈现相同的容易探测的模式。以服务健康检查为例，通常有一个二进制应答：健康或不健康，启动或未启动。大多时候我们每次遇到这样的错误会采取同样的行动。在失败的健康检查的情况下,我们通常会简单地重新启动或重新部署有问题的服务。而原生云应用架构在这些情况下无需手动干预。相反，他们使用自动检测和恢复。换句话说，他们让电脑带上了寻呼机，而不是人。
弹性扩展
随着需求增长，弹性扩展成了必要需求。过去是通过垂直地扩大规模能力来处理更多的需求，也就是够买更强的服务器。这是可行的，但过程很慢并且代价庞大。这会导致只根据峰值使用量预测来规划能力值 – 根据服务器的最高计算能力购买硬件予以满足。这是不得已的做法。例如在黑色星期五。我们负担着成百上千台轻负载CPU的服务器，但使用率很低。
创新型的公司通过两个开创性的举动来解决这个问题：
- 代替继续购买更大型的服务器，使用大量的更便宜机器来水平扩展应用实例。这些机器更容易获得，并且能够快速部署。
- 使用率低的大型服务器以通过虚拟化技术成为几个小型服务器，并部署多个逻辑隔离的工作来提升负载。
由于许多公有云基础设施已是实时，这两个选择已可融合在一起。虚拟化的工作由云服务提供商来承担，客户关注其应用水平扩展部署在很多云服务器实例上。最近，另一个转变也正在兴起，也就是将虚拟化服务器迁移到容器中。
这种向云端的转变为更多的创新敞开了大门，因很多公司不再需要花费大量启动资金来部署他们的应用，后续维护成本也会大幅降低。通过API实现服务供给不仅提高了初始部署速度，还可以对随时变化的需求最大程度地优化服务，提高更快的变更速度。
然而应用架构设计必须是水平化，而非垂直化。云弹性需求变化无穷，不仅需可快速创建新应用实例，还必须能够快速安全地应对。这种需求也带来了管理的问题：如何应对服务的持久性？传统方法例如集群会话和共享文件系统在大多是垂直架构中应用的不是很好。
原生云应用架构的另一特征是将内存中数据网络、缓存和持久的对象存储等状态形象化，让应用实例在本质上处于无状态。无状态的应用可以快速创建或者销毁，也可以快速和从外部状态管理器连接或者分离，以加强对需求变化的应变能力。大多数云基础设施提供者已经认识到这种特征的必要性，并且提供了这种服务的健康状态菜单。
移动应用和客户端的多样化
2014年1月，美国的移动设备在互联网使用设备上占比55%。当下已不是将应用绑在桌面电脑终端让用户使用的时代。相反，我们的用户正将多核心的超级电脑装在口袋里并四处奔波。这点对应用架构意义非凡 – 更多用户将可以随时随地地使用我们的系统。
移动平台的多样性也对应用架构提出了需求。在任何时刻，用户都可能想要从不同厂商生产的设备上与我们的系统做交互，这些设备上运行着各种各样的操作系统，同一操作平台的多个版本，甚至不同设备类型（例如手机和平板）。这不仅对移动应用的开发者们提出很大挑战，并且也对终端服务的开发者们同样提出了各种限制。
移动应用经常要和多种旧系统以及多种原生云应用架构的微服务进行交互。这些服务不可能设计成可以支撑客户使用的各种不同移动平台的特殊需求。这些不同的服务集成在一起会对移动终端产生很大的负担，而这些负担会增加使用的延迟以及网络负载，导致反应时间变慢，电池耗电量高，最终导致客户删掉你的应用。原生云应用架构利用API网关这种设计模式也可以支持移动领先概念，这可以将服务聚合带来的负担转化给服务器端。
定义原生云架构
现在，我们将探讨云原生应用架构的几个关键特性。我们也将看到如何因由这些特性达成我们刚才讨论过的动机。
原生云应用的十二个因素
云原生应用架构被总结为十二因素应用模式，这个模式最早由一名Heroku的工程师开发，描述了一个应用的原型，并诠释了使用原生云应用架构的原因。通过强化详细配置，无状态/零共享水平扩展的过程，以及整体松耦合架构的部署环境，来关注模式的速度，安全以及扩展。
基于十二因素的上下文关联，应用就变成了一个单一部署单元；多个联合部署的单元就是一个应用，而多个联合部署的单元就可以被当成一个分布式系统。
具有这十二个因素的应用的具体描述如下：
代码库每一个部署的应用都在版本控制代码库中被追踪。在多个部署环境中，会有多种部署实例。
相关性通过合适的工具（例如Maven,Bundler, NPM），应用可以很清晰地对部署环境公开和隔绝依赖性，而不是模糊地对部署环境产生依赖性。
配置配置，或者其他可能在部署环境（例如研发，展示，生产）之间区别的任何代码，可以通过操作系统级的环境变量来注入。
后端服务后端服务，例如数据库或者消息代理，作为附加资源，同等地在各种环境中被消耗。
建立，发布，运行建立部署应用，应用与配置结合，结合后一个或几个程序开始运行，这几个阶段是严格分开的。
过程应用以一个或多个无状态不共享的程序(e.g.,master/ workers)运行。任何必要状态都被边缘化到后端服务（缓存，对象存储等）。
端口绑定每个应用的功能都很齐全，通过端口绑定对外提供所有服务（包括HTTP）。
并发性并发性即通常可以依靠水平扩展应用程序来实现（虽然程序也可以通过内部多线程的方式多路径管理工作。）
可任意处置性那些快速启动和缓和关闭的程序可以将系统健壮性达到最大化。这些特性允许系统快速弹性扩展，改变部署以及故障恢复等。
Dev/prod 一致性保持研发，展示，生产环境尽可能的相似，这样可以提供应用的持续交付和部署服务。
日志除了管理日志文件，还可以将日志当作事件流。通过集中服务，在执行环境来收集，聚合，索引和分析这些事件。
管理程序行政类或管理类任务，例如数据库迁移，在与应用长期运行的程序相同环境中，作为一次性程序运行。
当没有对即将部署的环境给予适当的考虑时，这些特征可以使它们很好的快速部署应用。这种对环境缺少假设的情况，需要底层云平台采用一种简单且一致的机制，自动化地快速提供一个新环境将这些应用部署在上面。因此，带有十二个因素应用模式可以最大程度提高应用部署速度。
这些特征也可以使它们适用于生命周期短的事务，或者那些可以以最少成本淘汰的应用。应用环境本身就是100%可处理的，因为任何一个应用状态，在内存中或者持久性存储中，都可以被提取到某个后端服务，这样就可以很容易地自动化弹性扩展或者缩减应用。大多数情况下，底层平台可随意多次简单地复制已有的环境并启动程序，而缩减是通过终止运行程序，并删除环境来实现的。当然你可以选择不花费精力去做备份或者保留这些环境的状态。这样，带有十二个因素的应用模式将扩展性实现最大化。
应用的可处置性使得底层平台自动且快速地从故障中恢复。而且，将日志当作事件流可以大大增加底层应用运行行为的可见性。这种环境之间的同等性和配置机制的一致性以及后端服务管理机制，可以使云平台对应用运行结构的各个方面进行全方面可见性监控服务。这样带有十二个因素的应用模式，将安全性实现最大化。
微服务
微服务代表了将单个业务系统分解成独立可部署的一种的服务，这种服务只专注做一件事情并且做好。而这件事情通常可以是业务能力，或者提供业务价值的最小单元服务。
微服务架构从以下几个方面实现速度、安全和弹性扩展。
业务域可以按功能被分为独立的可部署的能力环境，也可以被分解为与之相关的可变周期。只要这些变化被限制在一个单一的有限制的环境下，这项服务就可以继续完成它已有约定的任务合约，这些变化可以修改，并与其他剩余的业务任务合作部署。结果就是实现更加频繁更加快速地部署。
- 软件开发可以通过扩展开发组织自身实现加速。增加开发人员会导致过度的沟通和协调，难以实现软件开发加速。然而除了将所有的开发者塞进一个沙盘中，我们可以通过设定环境界限创建更多的沙盘来建立一个平行的工作流。
- 如果减少对业务域以及已有代码认知的工作负载，省去建立小团队关系，那么新添加到沙盘工作中的开发者的工作效率和产能就会提升。
- 新技术的加入亦可加速。大型整体应用架构通常与长期技术栈合约息息相关。在大型架构中，技术选型带来的问题的代价高昂，因为这些问题会影响整个企业架构。而如果在单一个体范围内采用新技术，就可以将隔离风险并将它最小化，同样我们可以将运行故障时间隔离，且最小化。
- 微服务能提供独立有效的服务规模化扩展。大型整体架构可以规模化扩展，但是需要将所有元素都进行规模化扩张，而不是简单地只针对重负载元素。微服务规模化扩展，只跟与之相关的负载需求有关。
自服务敏捷基础架构
开发原生态云应用架构的团队只对其自己部署和运行的操作负责。成功的原生云应用的选择者需拥有一支自服务平台的全责团队。
就像为每一个界限环境建立微服务而创建业务能力团队，我们可以创建一支能力团队负责提供平台，在平台上部署运行这些微服务。这些平台的好处在于可以为客户提供基本的抽象层。利用IAAS资源，通过API创建虚拟服务器实例，网络以及存储，然后部署各种配置管理和自动化工具，最终将应用和支持服务运行起来。现如今平台逐渐兴起，这会让我们从应用和后端服务角度来思考问题。
应用代码仅仅只是以预先建立人工产品，或者GIT远程源代码形式的“推进”的产物；而平台可建立、应用人工产品，创建应用环境，部署应用，运行必要的程序。运维团队无需考虑代码在哪运行或者如何运行，因为平台可以透明地处理好这些问题。
后端服务的支持模式亦是如此。数据库、消息队列或者邮箱服务器等需求都可通过该平台满足。目前平台可支持一系列的SQL/NoSQL数据存储、消息队列，搜索引擎、缓存和其他重要的后端服务。通过必要认证将服务实例自动注入到应用环境中供其消耗就可以与应用绑定在一起了。很多凌乱的易出错的自动操作就被消除了。
这些平台也可以提供一系列额外运行能力：
- 自动按需扩展的应用实例
- 应用健康管理
- 通过应用实例实现访问的动态路由和负载均衡
- 日志和度量的聚合
这些工具的结合确保能力团队能够以敏捷原则，开发和运行服务。
基于API的协作
原生态云应用架构之间的唯一服务互动模式是通过发行的各种版本的API。这些API都是典型的带有JSON序列化的HTTP REST形式，但也可以使用其他协议和序列化格式。
在不破坏已有API协议的前提下，开发团队将能够按需随时部署新功能，且不用和其他团队同步。当与业务服务交互时，自服务基础设施平台的交互模型也是一个API。当相同请求被提交给一个API是，就可实现这些请求的自动处理，而不是提交给供给，规模扩展和维护应用的基础设施。
遵循协议可以通过客户驱动协议在服务到服务交互的两端进行验证。服务消费者不允许获得相关性私有实现细节或者直接访问相关数据存储。事实上，只有一个服务曾经允许获得直接访问任何数据存储的权利。这种强迫解耦合方式直接支持原生云速度的目标。
抗脆弱性
抗脆弱性的概念是从NassimTaleb的《Antifragile》一书中引入的。如果脆弱性是系统的一个特征，那么这个系统会变得越来越弱，或者遇到压力就会出现故障，那么这个特性的反面是什么呢？很多人会给出健壮性或者弹性这样的答案，也就是当遇到压力时，系统不会出现故障或者变脆弱。然而，Taleb谈到脆弱性的反面是抗脆弱性，或者一个系统遇到压力时会变更强。什么样的系统能够到达那种程度呢？想一想人类的免疫系统，哪个功能遇到病原体会变得更强，而当隔离病原体后变弱呢？我们能否建立一个那样的架构？
这就是原生态云架构的选择者设法创建的架构。以NetflixSimian Army project为例，通过著名的“ChaosMonkey”子模块，将随机故障插入到生产元素中，实现识别和删除架构中脆弱性。明确地找出应用架构中的脆弱性，插入故障因素，强迫修正，最终这个架构会自然地趋于实现更高级别的安全性。
总结
在本文中，我们从通过软件为业务提供的能力的角度，验证了迁移到原生云应用架构的共同动机。
速度具有比竞争对手更快地创新，实验，交付价值的能力
安全在维持稳定性，可用性和持久性的同时，快速移动的能力。
规模扩展根据需求的改变，弹性地应对能力。
移动性客户可以从任何时间和地点，在任何设备上，完成交付
我们也验证了原生态云应用架构的独有的特征以及提供这些能力的方式：
微服务这种架构模式可以将部署单元和业务能力联合起来，允许每一个能力都能独立自主地移动，并且更快更安全。
自服务敏捷基础设施云平台可以使开发团队以应用和服务抽象层的形式操作，提供基础设施层的速度，安全和规模化扩展
基于API的协作这种架构模式是将服务对服务的交互作为自动可验证的合约模式，通过这种简化集成模式使服务的速度和安全成为可能。
抗脆弱性当我们对系统的速度和规模施压，系统会提升反应能力，增强安全性。