数人云|两个故事,看12要素如何助力亚马逊和Netflix开启云原生大门

云原生体系图

应用开发的模式，不管是团队仍是我的都在不断的发展，开源为软件行业提供了不少工具、框架、平台和操做系统，它们都愈来愈关注与灵活性和自动化，当今最流行的开源工具主要都集中在一些特性上，这些特性使得团队可以在开发和运维的各类级别上，不断地交付应用，较之以往，效率大为提高。

亚马逊的故事

从20世纪90年代初开始，一家总部位于西雅图的在线书店开始成为世界上最大的在线零售商，2015年，亚马逊超越沃尔玛成为美国最具价值的零售商，关于它无与伦比的增加故事中，最有趣的部分能够总结为一个简单的问题：做为一个简单的在线书店，一个网站如何转变成为世界上最大的零售商之一？

不难看出，在全球各地愈来愈多的企业介入互联网，使电子商务的世界发生了改变和重塑，随着我的电脑设备变得愈来愈小，智能手机、平板电脑，甚至智能手表无处不在，在分销渠道的可访问性方面经历了指数级增加，直接改变了世界商业的方式。

亚马逊首席技术官Werner Vogels见证了亚马逊从一家很是成功的在线书店到世界上最具价值的科技公司和产品零售商的这种技术衍变。2006年6月Vogels接受了计算机杂志ACM的采访：这是一项技术选择的快速发展，这一技术为亚马逊的增加提供了动力，在采访中，Vogles谈到了背后的核心驱动力，在亚马逊的技术发展中，有很大一部分是为了实现这一持续的增加，在保持可用性和性能的同时，实现了超可扩展性。

对于亚马逊来讲，要实现这一能力，须要转向不一样的应用架构模式，其提到亚马逊是一个单一的应用，随着时间的推移，愈来愈多的团队在同一个应用上运行，代码库全部权的界限开始变得模糊，Vogels说：没有孤立的状况，所以也就没有明确的全部权。

Vogels指出，像数据库这样的共享资源，使其很难扩展整个业务，共享资源的数量越多，不管是应用服务器仍是数据库，当将特性交付到生产环境时，控制团队就越少。

他触及了一个共同的主题：云应用共享，团队拥有他所构建东西的想法，他说：传统的模式是，将应用开发出来，而后又将开发运维分离，开发将应用抛给运维就撒手无论了。

在一些全球最重要的软件会议上，一些著名的演讲嘉宾都引用了一句最经常使用的名言——You build it，you run it。这句话后来成为了咱们今天所熟知的DevOps口号。

Vogels在2006年谈到的许多实践都是当今流行概念的影子，如DevOps和微服务这样的实践。尽管相似于亚马逊这种大型互联网公司正在开发相似的应用，但，围绕这些想法的工具须要数年的时间才能开发并成熟为一种服务。

2006年，亚马逊推出了一款名为Amazon Web Service（AWS）的新产品，其理念是提供一个与亚马逊内部使用的平台相同的平台，并将其做为服务发布给公众，亚马逊迫切但愿看到这个平台背后的理念和工具的商业化，Vogels推出的许多想法都已经在亚马逊的平台上创建了，经过该平台发布为公众服务，亚马逊将进入一个名为“公有云”的新市场。

公有云背后的逻辑是合理的，虚拟资源能够按需供应，而无需担忧底层基础设施，开发者能够简单地租用虚拟机来存放他们的应用，无需购买或管理基础设施，这是一种低风险的自助服务，它将有助于提供公有云的吸引力，而AWS一直在采用方面保持着领先。

AWS将须要数年时间才能造成一套用于构建和运行应用的服务以及模式，这些应用都是在公有云上运行的，虽然许多开发人员都涌向这些服务去构建新的应用，但对于不少公司来讲，迁移是一大难题，由于现有的应用不是为了可移植性而设计的，此外许多应用仍然依赖于与公有云不兼容的遗留工做负载。

为了让大多数公司可以利用公有云，他们须要改变开发应用的方式。

平台

平台，是时下常被说起的一个词。

当讨论计算的平台时，一般讨论的是一组帮助构建或运行应用的能力，平台最能归纳的是，它们对开发者如何构建应用施加了约束。

平台可以自动完成对应用的业务需求不十分重要的那些任务，这使得开发团队更加灵活，由于他们只支持那些有助于区分业务价值的特性。

任何编写过Shell脚本或已标记的容器和虚拟机来实现自动化部署的团队都已经构建了一个平台，问题是：这个平台能保证什么？为持续交付新应用所需的大多数（甚至所有）的需求须要作多少工做？

当构建平台时，其实正在构建一个工具，能够自动化一组可重复的实践。实践是由一组将有价值的想法转化为计划的约束所制定的。

想法：平台的核心理念是什么？为何它们具备价值？
约束：将平台的想法转化为实践的比较条件是？
实践：将约束自动化到一组可重复的实践中？
每一个平台的核心都是简单的想法，当实现时，经过使用自动化工具来增长不一样的业务价值。

以亚马逊平台为例，Vogels说，经过增长应用组件之间的隔离，团队能够对他们的交付特性进行更多的控制。

想法：

• 经过增长应用组件之间的隔离，可以快速且独立地交付系统的一部分。

经过将这个想法做为平台的基础，咱们能够将其变成一组约束，约束以一种观点的形式出现，关于核心理念是如何在自动化的实践中创造价值的，下面的语句是关于如何提升组件隔离性的一些限制。

约束：

• 应用组件将做为独立的可部署服务构建。
• 服务中全部业务逻辑都封装在它所操做的数据中。
• 从服务外部没法直接访问数据库。
• 服务将发布一个Web接口，该接口容许从其余服务访问其业务逻辑。

有了这些限制，对于如何在实践中增长应用组件的隔离性有了必定的认知，当自动化到实践时，这些约束的Promise将为团队提供更多的控制，以控制特性是如何交付的生产的？下一步是描述如何将这些约束捕获到一组可重复的实践中。

从这些约束中派生出来的实践应该做为Promise的集合来声明，经过将实践表述为Promise，咱们对平台的用户保持了对他们如何构建和操做应用的预期。

实践：

• 向团队提供了一个自助服务接口，容许提供操做应用所需的基础设施。
• 数据库以服务的形式提供给应用程序，并使用自助服务接口进行供应。
• 应用是做为环境变量提供给数据库的凭证，但前提是在声明与数据库的明确关系做为服务绑定以后。
• 每一个应用都提供了一个服务注册表，该服务注册表被用做在何处定位外部服务依赖项的清单。

上面列出的每一个实践都以向用户Promise的形式呈现，这样，平台核心思想的意图就会被用于应用的约束来实现。

云原生应用是创建在一组约束的基础上的，这些约束能够减小在进行无差别的繁重工做时所花费的时间。

AWS首次向公众发布时，亚马逊不强迫用户遵循相同的约束，他们在内部用于Amazon.com.Staying Amazon Web服务名称，AWS自己不是一个云平台，而是独立的基础设施服务的集合，能够组合成自动化工具相似于一个平台的Promise，在AWS的第一次发布后的几年里，亚马逊开始提供一系列管理平台服务，从物联网到机器学习。

若是每一个公司都须要从头开始构建本身的平台，那么在应用程序中交付价值的时间就会被延迟，直到平台彻底组装好，早期采用AWS的公司须要将一些相似平台的自动化设备组装在一块儿，每家公司都必须在一系列的Promise中进行，这些Promise抓住了如何开发和交付应用的核心理念。

最近，每一个云平台都应该有一套基本且共同的Promise，经过使用开源平台做为服务（PaaS）云计算，这些Promise将在本文中获得探索，云计算背后的核心动机是提供一个平台，它封装了一套用于快速构建和操做的通用Promise，云计算公司作出了这些Promise，同时还提供了许多个不一样的云基础设施提供商之间的可移植性。

这本书的主题是如何构建云原生Java应用，咱们将主要关注工具和框架，经过利用云平台的有点和Promise，帮助减小未分化的繁重工做。

模式

如何运用新模式去开发应用，会令人更深刻地思考应用在生产中的行为，开发和运维都更增强调他们的应用如何在生产中运行，在失败的状况下更少的保证复杂性将如何破解。

与Amazon.com的状况同样，应用开始远离大型的且单一的模式，如今架构的重点是在不牺牲性能和可用性的状况下实现超可伸缩性，经过分解一个庞然大物的组成部分，工程组织正在努力分散变动管理，为团队提供更多的控制，使它们可以更好地控制产品的生产方式，经过增长组件之间的隔离，开发团队开始进入分布式系统开发的世界，重点是构建更小、更专一的服务，并具备独立的发布周期。

云原生利用了这一组模式，让团队在向生产交付特性时更加敏捷，随着应用的分布愈来愈分散（为了向拥有应用的团队提供更多的控制所必须的隔离的结果。）在应用组件通讯方式中失败的集成会成为了一个重要的关注点，随着应用程序转变为复杂的分布式系统，操做失败是不可避免的。

云原生架构提供了超可伸缩性的好处，同时仍然保证了应用的整体可用性和性能，尽管如亚马逊这样的公司在云计算中得到了超可伸缩性的好处，但普遍使用的用于构建云原生应用的工具还没有浮出水面，这个工具和平台最终将做为一个由公有云早期开拓者维护的开源项目的集合而被开发出来：Netflix。

可靠性

团队之间（开发、运维、测试等）自荐创建的指望是契约，这意味着提供或使用某种级别的服务，经过观察团队在开发应用过程当中如何为彼此提供服务，咱们能够更好地理解通讯中的失败是如何致使风险从而失败的。

建立团队之间的服务协议是为了减小为业务带来价值的总体功能意外行为的风险，团队之间的服务协议是要明确的，以保证行为与预期的运营成本一致，经过这种方式，服务可使业务单元最大化其总输出，应用业务的目标是经过成本——咱们称之为可靠性的成本去预测价值的创造。

业务的服务模型与构建应用时使用的模型相同，这就是如何保证系统的可靠性，不管是在生产应用中自动化功能，仍是在培训的人员执行手工操做的状况下。

敏捷性

由于再也不是只有一种开发和运维应用的方法，在采用敏捷方法和将应用做为服务（SaaS）业务模型的推进下，惬意应用堆栈正变得愈来愈分布式，开发分布式系统是一项复杂的任务，向公司提供更分布式的应用架构的作法，是因为须要更快地交付应用，而且减小了失败的风险。

注意项

最近有一些人在盛传敏捷已死这种理念，但正如咱们所说，敏捷其实指的是一种以组织为单位的热情来传递新的价值以及快速响应的想法，条条大路通罗马，本文不关心你所信奉的管理实践，关键是要明白敏捷是一种价值，而不是目标。

现代应用定义业务寻求重组其开发过程，以使应用项目更快地交付，并将应用持续地部署到生产中，不只是公司想要提升应用的开发速度，并且还要增长他们建立和运维应用的数量，以服务于一个组织的各类业务单位。

应用正日益成为企业的竞争优点，更快和更好的工具能让业务专家打开新的收入来源，或者以促进快速创新的方法优化业务功能。这场运动的核心是云计算，当谈论云计算时，咱们讨论的是一组很是具体的技术，这些技术使开发和运维可以利用现有的Web服务来提供和管理虚拟计算基础设施。目前的企业正开始走出数据中心，进入公有云阶段，Netflx，正式一家流行的基于订阅的流媒体公司。

Netflix的故事

目前，Netflix是世界上最大的按需流媒体服务公司之一，在云服务中运营期在线服务，Netflix于1997年在加州由Reed Hastings 和 Marc Randolph创立，最开始Netflix提供了一种在线DVD租赁服务，容许用户每个月付费订阅无限制的电影，而不收取其余任何费用。

2008年，Netflix经历了一场严重的数据库故障，使得该公司没法将任何DVD邮寄给客户，当时，Netflix刚刚开始向客户提供流媒体视频服务，其流媒体团队意识到，相似的服务中断将对其将来业务形成毁灭性的打击，所以，Netflix作出了一个相当重要的决定：采起一种不同凡响的方式开发和运行应用，确保客户永远都是使用服务。

所以它们决定放弃垂直规模的基础设施和单一的失败点，实现是数据库损坏的结果，这是使用锤石伸缩的关系数据库结果，Netflix将其客户数据迁移到一个分布式的NoSQL数据库，是一个名为Apache Cassandra的开源数据库项目。这也被视为“云原生”公司的开始，将全部的应用做为高度分布式和弹性的服务在云中运行，Netflix公司经过向其应用和数据库中添加冗余来增长其在线服务的健壮性，并在一个扩展的基础设施模型中增长了冗余。

做为迁移到云端的一部分，Netflix决定将其庞大的应用部署迁移到高度可靠的分布式系统上，但这面临着一个重大的挑战：Netflix的团队将不得不从新架构应用，同时从一个内部数据中心转移到公有云，2009年，Netflix开始向Amazon Web Service（AWS）迁移，并专一于三个主要的目标：可伸缩性、性能、和可用性。

很明显，2009年初的需求将大幅度增长，事实上，Netflix的云计算和平台工程副总裁ury Izrailevsky在2013年的AWS大会上表示，自2009年依赖，该公司已经增长了100倍。

此外，他还指出，当考虑到期快速的全球扩张时，可伸缩性在云计算中的优点变得更加明显“为了给咱们的欧洲客户提供更好的低延迟体验，咱们在爱尔兰推出了第二个云计算区，在不一样的地区创建一个新的数据中心须要花费数月的时间和数百万美圆的资金，这是一个巨大的投资。”

随着Netflix开始在Amazon Web Service上托管应用，员工们在Netflix公司的博客上记录了他们的学习经验，Netflix的许多员工都在提倡一种新的架构，这种架构专一于软件栈的各个层面的水平可扩展性。

John Ciancutii当时是Netflix的个性化技术副总裁，他在2010年的公司博客上写道：云环境是水平扩展机构的理想选择，咱们没必要猜想将来几个月咱们的硬件、存储和网络需求将会是什么样子的，能够经过编程方式从Amazon Web Service中的共享池中访问更多资源。

Ciancutti所说的“以编程方式访问”资源的意思是，开发和运维能够经过编程的方式访问由Amazon Web Service公开的某些管理API，以给客户提供一个用于提供他们的虚拟计算基础设施的控制器，RESTful API为开发人员提供了一种构建管理和为其应用提供虚拟基础设施的应用的方法：

Ps：为控制虚拟计算基础设施提供管理服务是云计算的主要概念之一，称为基础设施即服务，一般称为IaaS。

云计算堆栈

Ciancutti在同一片博客文章中坦白，Netflix并不商场预测客户的增加或设备的参与，这是云原生企业背后的一个核心主题，云原生是一种心态，它认可没法可靠地预测什么时候何地须要容量。

在Yury Izrailevsky 2013年的演讲中，他说：在云计算中，随着流量的增长，咱们能够在几天内提升产能，当咱们成为一家全球性公司的时候，咱们能够依靠在世界各地的多个亚马逊网络服务区，不管他们在哪里，都能给咱们的客户提供一个很好的互动体验。”

受益于AWS国际扩张的规模经济也让Netflix受益，随着AWS向美国之外地区扩展了可用性区域，Netflix只使用AWS提供的管理API扩大了气服务范围。

Izrailevsky引用了企业云计算的广泛观点：“固然，云计算很是好，但对于咱们来讲太贵了。”他对这一观点的回应是：“Netflix迁移到云，运维成本降低了87%，所支付的费用，是以前数据中心支付的八分之一。”

Izrailevsky进一步解释了为何云计算为Netflix提供了如此巨大的成本节省：在不担忧容量缓冲的状况下，可以实现增加是颇有帮助的。随着成长，又能够扩大需求。

微服务

云原生应用和微服务是齐头并进的，构建微服务的主要思想之一是让功能团队围绕特定的业务功能组织本身和应用，这种方法不管如何都不是特别新颖，从小型的分布式组件中建立一个系统，这些组件能够很好地工做，并以这样的方式拆分，以尽量减小将单个特性交付到生产环境中的阻力，这几十年来一直是可能的，那么，为何这种构建模式如今才流行起来？这和云有什么关系吗？

构建应用之一都很困难，理智与行为之间的区别每每是别人剥夺了你本身糟糕的选择结果，昨天作出的技术决策将会妨碍你明天作出正确决策的能力。

理解一件小事很容易，但要理解它的缺失所带来的影响则要困可贵多，若是咱们仔细研究一个设计良好的单片应用，咱们将看到相似的驱动，若是咱们在今天的微服务架构中看到的模块化、简单性和松耦合，固然，其中一个主要的区别是历史，不难理解，选择层如何将精心设计的东西变成了一个糟糕的东西。若是一我的在架构的一个可替换单元中作出了糟糕的选择，那么这个选择就会随着时间的推移而变得更容易分解，可是，若是同一我的在设计一个精心准备的庞然大物的多个独立模式上工做，那么额外的历史可能会影响到其余人之后作出理想选择的能力，所以，最终不得不妥协，被迫在一些从未有机会作出的选择上作出稍微更好的决定，而这些选择是咱们从未有过的。

想要改变的应用就变成了一种生活的东西——老是被历史所改变，永远不会对生存之风的变化免疫，正因如此，必须以改变为基础，必须拥抱变革，同时抵制将来构建的诱惑，毕竟，将来的设计知识一种华丽的设计，把它装扮成敏捷的开发，不管咱们多么聪明，在预先设计完美的系统时，都没法准确地预测它的功能在将来会发生怎样的变化，由于一般状况下，它不会由咱们来决定，市场倾向于决定产品的命运，正因如此，只能在头脑中进行设计。

微服务只是一个想法，模式和实践在一个流体状态下仍然波动，而耐心地等待一个稳定的定义，他们在更普遍的垂直领域的拥抱——更好仍是更糟——还有待最终裁决。

有两种主要的力量影响着架构变化的速度：微服务和云计算，云计算极大地下降了管理基础设施所需的成本和工做量，目前，咱们可以使用自助服务工具为应用程序提供基础设施，由此，新的、创新的开始迅速地成为现实，使咱们从新思考和重塑之前的管理，以前关于构建应用的真实状况多是不真实的，在大多数状况下，真相被是被掩盖的，如今咱们发现本身须要在反复无常的假设基础上作出艰难的决定：服务器是物理的，而虚拟机是永久的，容器是无状态的。

Splitting the Monolith

Netflix列举了从一个单一的庞然大物中迁移到分布式架构的两个主要好处：敏捷性和好处。

在使用云以前，Netflix的架构包括一个单一的Java虚拟机（JVM）应用，虽然拥有一个大型的应用程序部署有不少优势，但主要的缺点在于开发团队因为须要协调变动而减缓效率。

当构建和运维应用时，集中化下降了需求协调的成本增长的风险，协调须要时间，应用体系构建越集中，就月须要花费更多的时间去协调对其中任何一项的更改。

一体化也不太可靠，当组件在相同的虚拟机上共享资源时，一个组件中的故障可能会蔓延到其余组件，从而致使用户宕机，当团队须要协调他们的变动时，在一个单一的块中作出一个变动的风险会增长，在单个发布周期中发生的变化越多，就越有可能形成宕机，经过将一个单一的块分割成更小、更专一的服务，能够在团队的独立发布周期中使用较小的批处理大小来进行部署。

Netflix不只须要改变其构建和运营应用的方式，还须要改变其组织文化，Netflix转向了一种名为DevOps新的操做模式，在这个操做重视中，每一个团队都变成了一个产品组，远离了传统的项目组结构，在一个产品中，团队是垂直的，在每一个团队中嵌入运维和产品管理，产品团队会拥有他们所需的一切构建和运维应用。

Netflix OSS

随着Netflix转型为一家云计算公司，它也开始积极参与开源项目，2010年底，时任系统与电子商务工程副总裁的Kevin McEntee在一篇文章里所：该公司将来将在开源领域发挥做用。他说，一个号的开源项目可以解决一个共同的挑战，那就是它发展了本身的动力，而且在持续改进的良性循环中持续很长一段时间。

在这一宣布以后的几年间，Netflix开放了超过50个内部项目，每一个项目都成为了Netflix战略品牌的一部分。

2012年7月，Netflix的云平台工程主管Ruslan Meshenberg在公司的技术博客上发表了一篇文章，这篇博客的文章：《Netflix的开源》解释了为何Netflix才去了如此大胆的举措，开源了如此多的内部工具。

Meshenberg在博客中写道：“Netflix是一个早期的云采用者，将咱们全部的流媒体服务都在AWS的基础设施上运行”。

Netflix为开源社区和技术生态系统作出的文化动机被认为与微观经济概念背后的原则紧密相关，即规模经济，在被称为“云时代”到来之际，Netflix发现它的先去不是如IBM或微软这样的科技公司，而是诞生在互联网背后的公司，Netflix和亚马逊都是始于90年代末的网络公司，都是经过提供旨在与实体公司竞争的在线服务而起家。

目前，Netflix和亚马逊都已经大大超过了同类型实体店的估值，随着亚马逊进入云计算市场，它将本身的集体经验和内部工具转变为一套服务，Netflix随后也在亚马逊的服务上作了一样的工做，在此过程当中，Netflix开放了本身的经验以及工具，转型为一家基于亚马逊AWS提供的虚拟基础设施服务的云原生公司，这就是规模经济推进了云计算行业革命。

2015年初，据报道Netflix的第一季度财报显示，该公司的估值达到了329亿美圆。

云原生Java

Netflix向软件行业提供了丰富的只是，这是它成为云原生公司的结果，本文借鉴Netflix的经验和开源项目，并将其做为一套模式，其中有两个主题：

使用Spring和Netflix操做系统构建具备弹性的分布式系统
使用云计算，持续交付来操做本地云原生应用

以及云原生的12要素，12要素的方法是由Heroku云平台的建立者编写的一套流行的应用开发原则。

云原生12要素的核心思想：

为安装自动化使用声明式格式，以最小化新开发人员加入项目的时间和成本
与底层操做系统有一个明确的契约，在执行环境之间提供最大的可移植性
适用于现代云平台上的部署，从而避免了服务器和系统管理的需求
最小化开发和生产之间的差别，从而实现最大敏捷性的持续部署
而且能够在没有对工具、架构或开发实践进行重大更改的状况下进行扩展

云原生的12要素能够帮助构建利用这些想法的应用，它是一套基本的约束，能够用来构建云原生应用，因为这些因素涵盖了全部现代云平台的常见实践，所以构建12要素应用是云本地应用开发的一个常见起点。

图片摘自网络

上图是12条因素即12条军规，这里挑几个重要进行讲解：

Codebase：和整个测试环境有关，你们拉基线是为了整个版本的稳定性。

依赖：要解决依赖的问题，若用Java的话，意义不大，原始上会有依赖管理，但电商公司有各类语言都很是原始，直接依赖于源代码，若其版本发生变化，有些API就编译不过去。

Configuration：Java和其余语言很是冲突就在于此，作Java的同窗都知道配置通常都会打在根应用的生产日报里，会有大量的配置文件，上到云应用，让底层人员运行做业炸包，首先就要配置文件，一切配置要么走配置中心，连访问配置中心的地址可能也是外部注入进来，不用再去配置上声明整个中心是什么；要么是全部的配置都由平台帮助注入，不能本身携带相关的Jap去作，原来整个构建，底下会有一些构建的模式，以前构建最先版本很是有意思，好比大了一个测试环境的炸包，若没问题，便可交给运维，由于配置VI里面彻底不同，会在应用和部署的公共机器时，有自动替换配置文件的动做，要替换的配置文件其实也是预先上传到平台上的，整个发布平台会帮助作一个配置文件的替换，方式很原始，不是运行它去改配置，由于包本质上是变化的，配置文件属于包的一部分，所以它也是变更的，等于整个包的密封性被打破了，此时去上一个云原生的平台，首先要作的是灭配置文件，要经过环境变量或启动平参数的模式去启动应用，这时平台能自动地把整个环境——生产、预发布、测试、以及延长等环境，将不一样的配置设置好，因此这一点对开发来讲改动比较大，正常上这种云应用，最难的是将配置问题解决，由于大量的Java配置都是在文件中进行，包括内部有框架的，特定的文件，将这些都清除掉。

Backing Services：即不要把依赖服务彻底写死，依赖服务也是经过环境注入进来，如数据库链接，能够经过外部配置进来。

构建、发布和运行：要流程化。

进程：进程是微服务的根基，应用应以进程的级别运行，跟原来的方式不一样，不少功能都是达到一个进程，经过不一样的线程运行，但有几个很差的地方，相似于微服务，发布可能会影响不该影响的一些部分，追踪也不是很好作，好比当当最近在作内部的Tracing，目前只能作到进程间的Tracing，若是内部的线程Tracing须要改造，仍是有一些麻烦的。
端口：相似于一种端口的绑定解决方案，是由编排工具动态注入，要动态监听一些要发布的端口信息。

日志：不该生成文件，而是经过服务的方式将其进行传递，整个管理平台应有自动收集日志的功能，这也达到了云原生的态度，要将所要定位的信息不和应用绑在一块儿，由于应用很快会启动或注销，那么整个轨迹要持久化的保留。

（节选自高洪涛老师的《12条军规说Dev，3大重点讲Ops——当当网的云原生之路》）