超级账本Indy的混沌工程在区块链中的应用
混沌和工程这两个词似乎并没有联系在一起过。在本文中，我们将探讨它们为什么可以联系在一起，并进一步讨论这个工程规程在区块链中的应用。这一部分的第2部分将着重于超级账本Indy的混沌工程的具体实现。我们使用了一个在业界并不常见的缩写——混沌实验框架（chaos experimental framework， CEF）。在本文中，它作为一个简短形式的使用纯粹是为了方便。
这是一个由大规模分布式系统组成的微服务时代。Netflix， linkein， Medium， Amazon， Microsoft Azure， Uber， AirBnB等等。没有一个人，甚至是整个团队的架构师和程序员能够希望将这种分布式系统的复杂架构牢记于心。甚至这样一个系统的静态配置也由运行在异构硬件或云上的多个服务组成，这些服务通过运行在许多边缘设备上的具有多个sla和用户界面（ui）的网络进行连接。结合这种静态复杂性，这种系统的实时行为引入了来自用户的独立输入和驱动网络系统组件进程的叠加。
组件可能会崩溃、降级或行为失常。恶意或不称职的用户无处不在。混沌工程正是在这个时代发展起来的，最初是作为一种粗略的方法来测量这样一个系统;通过实践提炼成一种哲学和一种通过会议、工具和广泛采用的被广泛接受的方法。
你可能会说，比特币和以太坊等不受许可的公共区块链网络存在于一个混乱的环境中。他们已经不知不觉地陷入混乱。节点连接网络，恶意攻击者不断探查系统，网络连接中断。这种混乱和混沌工程是有区别的。混沌工程是一门利用实验数据揭示系统缺陷的工程学科。
首先，我们介绍了混沌工程的一些基本历史和原理，以及混沌工程在现有分布式系统中的应用。有一个用于混沌工程的开源存储库，称为chaos toolkit。Chaos toolkit是开源的，使用一个用于表示实验的开放API来推广混沌工程交互。该工具包可以使用开放API进行扩展，Kubernetes、AWS、Azure等已经提供了一些驱动程序。它还可以用于在持续集成和构建中自动化混沌工程。
在本系列的第二篇文章中，我们将研究开放源码的“混沌”工具包，并了解它是如何在Hyperledger Indy上用于这些实验的。这将激励人们密切关注他们自己的DLT平台，并创建一个成熟的混乱实验套件来强化他们自己的平台。
纵观历史
自2008年Netflix开始将服务器从数据中心转移到云端以来，他们的工程师一直在生产中进行某种形式的弹性测试。直到后来他们对它的研究才被称为混沌工程。Chaos Monkey开始了这种实践，以关闭生产环境中的服务而闻名。混沌原理使这门学科形式化了。Netflix的Chaos自动化平台24/7在其生产微服务架构上运行Chaos实验。
对于那些对混沌工程作为一门学科感兴趣的人来说，这里是一个精心整理的资源列表。O ‘Reilly发表了一篇关于混沌工程的优秀背景文章，可以免费获得。因为O ’Reilly需要注册才能下载链接，所以不提供链接。
混沌工程的实践
为了在规模上解决分布式系统的弱点，混沌工程可以被看作是发现系统弱点实验的创造和运行。这些表面上的弱点可以作为系统的限制加以解决。可以通过重复实验来验证这种弱点。
第一步是测量系统的稳态。这个系统通过它的输出而为人所知。需要一个稳定的轻触式监控系统来测量系统的稳态。轻触意味着测量的行为不会显著改变系统的行为。稳态的发现需要回答以下问题。
· 测量的是什么？系统变量（如cpu使用率、内存消耗）或业务变量（如响应时间和其他特定于应用程序的指标）。有时候度量标准涵盖了这两个方面。
· 稳态有时间相关的元素吗？一天中不同时间或不同季节的使用和资源利用模式可能不同。
下面给出了设计实验的指导，并建立了一个混沌工程框架（CEF）和一个运行在区块链观点下的过程。
· 一个已知的弱点不应该成为实验的对象。如果一个1/3的攻击破坏了共识（对于BFT），那么关闭一个致命的共识成员百分比就会产生已知的后果，并且无法从这类实验中获得洞见。在一些实验中，数字可能会低于关键阈值。
· 对于区块链，混沌工程实验应该通过随机组合的实验，着眼于共识、网络、存储层以及身份、智能合约、治理、用户交互等交叉元素。当我们在第二篇文章中讨论Indy上现有的混沌实践时，我们可以看到该实践是如何应用的。随机化实验。了解稳态研究中资源利用和系统响应的周期，并密切关注实验中应用的任何特殊情况。
· 当实验揭示底层框架的弱点时，应该提供尽可能多的信息来隔离流程、api或系统行为的组合。这有助于修复系统，使其不会以同样的方式失败。
· 混沌工程不同于单元测试和集成测试。这与进行故障注入和故障测试也不一样。CEF可以使用一些故障注入工具。故障注入和故障测试通常一次只针对一种故障模式。混沌工程旨在通过事件的随机组合来揭示系统的新知识;包括良性或有益的场景，如客户流量激增。除了常规的测试工具和实践之外，还应该实现混沌工程实践。
· 从开发和测试网络的实验开始，在通过修复未发现的问题来确保此类网络的完整性之后，我们将逐步进行生产。只有在生产中才能观察到小工序停产的非线性效应。
· 与整个团队，尤其是devops工程师和开发团队进行沟通和合作。强调混沌工程不是一种对抗性的情况;以及实验是如何使整个系统变硬的。可以通过具体的示例讨论开发活动的上层（包括体系结构、设计和工程实现）的优势。此外，还需要与企业的业务端进行沟通。
· 从时间和实验本身两个方面使实验随机化。注意在稳态研究期间收获的资源利用和系统响应的周期，同时要注意实验期间适用的任何特殊情况。
· 自动化实验的运行，包括快速关闭实验的方法，特别是在生产环境中进行实验时。当然，这意味着自动化监控，以及混沌框架和监控系统之间的某种形式的耦合。
· 避免半途而废。实验的结果不应该对生产造成很大的破坏。上面讨论的各种步骤应该有助于实现这一点。人们可以把这个系统分成两部分;一种不受实验干扰的控制系统，一种处于混沌状态的系统，也可以通过测量来观察实验的效果。这是混沌工程的高级实践。
· 规模：在Netflix上，使用Chaos Monkey，只关闭单个进程或vm，逐步升级到Chaos Kong，关闭整个数据中心或区域。通过这种方式，他们可以看到整个地区的失败的影响。
· 混乱成熟度模型;谈到了混沌工程的各个成熟度级别。各种轴：开发系统到生产;实验的多样性和复杂性;混沌工程自动化水平研究团队对实践的熟悉程度是一个连续的过程;实验的规模。DLT系统在每个轴上都处于不同的水平。成熟度模型有一些粗略和现成的名称，这取决于系统在过程中的位置。基本的，简单的，复杂的，高级的等等。一个确定这一点的分类可以在前面引用的书中找到。
· 区块链框架在公共区块链或许可区块链的多企业环境中最有效。在公共区块链中，环境不受单一类型实体的控制。首要的挑战是在多利益相关者的环境中创建、沟通和执行CEF。使用持续进修基金的好处应该非常清楚。如果CEF是在开发的初始阶段建立的，这应该不会构成很大的挑战，因为开发人员、业务用户和操作人员对平台的稳定性期望很低。然后，应允许持续进修基金与DLT框架的其他部分一起成长，并可成为生态系统的自然组成部分。有关持续进修基金实务的协议，应成为各方在获批准的情况下就管理事宜进行的初步协议及讨论的一部分。
· 对于公共区块链，开发者社区的购买以及与其他参与者的清晰沟通是采用区块链的必要条件;需要从建立良好的测试网络到用于CEF部署的生产系统的路径。这可能并不容易，因为公共区块链的利益相关者和治理方面仍在不断涌现和发展。存在危机，比如以太坊的DAO黑客事件，或者比特币的规模之争，都暴露了系统的脆弱性，并提出了一些特别的解决方案。一个良好的CEF和混沌成熟度模型的进展可能已经暴露了这些漏洞，并寻找更早开始的解决方案。在核心系统和边缘系统中，还有许多其他的漏洞，一个发展良好的持续进修基金本可以针对这些漏洞。
· 在企业区块链中，为了将CEF投入生产，联邦测试网络是必要的。大多数企业区块链都是如此。
· 另一点是关于驱动CEF工程实践的具体实现的知识。例如，在超分类结构中，背书策略指导共识的形成，因此在背书策略出现最少背书人之前删除背书人可以揭示具体实施中的弱点。在Corda中，取出公证网络的一部分，在部分网络流量中引入延迟，干扰Corda防火墙等。
结论
回顾当前大规模分布式系统中的混沌工程实践，揭示了混沌工程的潜力和作用。许多公司的采用，包括在飞机测试和医院系统等在生产系统中进行实践的领域，表明了它的实用性，甚至在敏感的应用程序中也是如此。
在区块链框架中设计实验需要结合框架中的专门知识、暴露于《综合框架》背后的原则，以及组建一个在各个级别上开展工作的小组，以创建一种随平台发展的做法，从而增强对具体实施的信心，从而推动采用。