世界不会停滞不前。 进步带来了新的技术挑战。 根据不断变化的需求，信息系统的体系结构也应不断发展。 今天，我们将讨论面向事件的架构，竞争力，并发性，异步性，以及如何在Erlang中与所有这些和平地生活。
引言
根据所设计系统的大小及其要求，我们（开发人员）选择在系统中交换信息的方法。 在大多数情况下，为了组织服务的交互，工作选项可以是例如基于RabbitMQ或kafka的具有代理的方案。 但是有时候，事件流，SLA和对系统的控制级别使现成的消息传递不适合我们。 当然，您可以通过负责传输层和群集的形成来使系统复杂化，例如使用ZeroMQ或nanomsg。 但是，如果系统具有足够的带宽和标准Erlang群集的功能，那么引入额外实体的问题就需要进行详细研究和经济证明。
反应式分布式应用程序的主题非常广泛。 为了保持本文的格式不变，今天的讨论主题只是基于Erlang / Elixir构建的同类环境。 Erlang / OTP生态系统允许使用低成本的反应式架构。 但是无论如何，我们都需要一个消息传递层。
理论基础
设计始于目标和限制的定义。 主要目标不是以发展促发展。 我们需要获得一个安全且可扩展的工具，在此基础上我们可以创建工具，最重要的是，它可以在各个级别上开发现代应用程序：从为一小部分用户服务的单服务器应用程序，后来可以发展为最多50-60个节点的集群，以集群联合会结束。 因此，主要目标是通过减少最终系统的开发成本和所有权来最大化利润。
最终系统有4个主要要求：
- 每天都有方向。
系统总是准备好通过事件流并执行必要的操作。 - 可扩展性。
单个块可以垂直和水平缩放。 整个系统应该能够无限地横向增长； - 关于容错。
所有级别和所有服务都应该能够自动从故障中恢复； - 保证响应时间。
时间是宝贵的，用户不应等待太久。
还记得有关“可能的小引擎”，又名“可能的引擎”的古老童话吗？ 为了使设计的系统成功地从原型阶段出现并逐步发展，其基础必须满足SMOG的最低要求。
作为基础结构工具和所有服务的基础，消息传递中增加了另一件事：程序员的可用性。
活动方向
为了使应用程序从单个服务器增长到群集，其架构必须提供弱连接。 异步模型满足此要求。 在其中，发件人和收件人负责消息的信息负载，而不必担心系统内的传输和路由。
可扩展性
可伸缩性和系统性能并存。 应用程序组件必须能够利用所有可用资源。 我们利用能力的效率越高，我们的加工方法越优化，我们在设备上的花费就越少。
Erlang在一台机器上创造了一个高度竞争的环境。 并发和并发之间的平衡可以通过选择可用于Erlang VM的操作系统线程数和使用这些线程的调度程序数来设置。
Erlang进程没有共同的状态，并且在非阻塞模式下工作。 与基于阻塞同步的传统应用程序相比，这提供了相对较低的延迟和更高的带宽。 Erlang调度程序负责CPU和IO的公平分配，并且没有锁可以使应用程序即使在峰值负载或故障时也能做出响应。
在集群级别，还存在回收问题。 重要的是，群集中的所有计算机均应均匀加载，并且网络不会过载。 想象一下一种情况：用户流量落在传入的平衡器（haproxy，nginx等）上，它们在可用后端组之间尽可能平均地分配处理请求。 在应用程序基础结构的框架中，实现所需接口的服务仅是最后一英里，它将需要请求许多其他服务才能回答初始请求。 内部查询还需要路由和平衡。
为了有效地管理数据流，消息传递必须为开发人员提供控制路由和负载平衡的接口。 因此，开发人员将能够使用微服务模式（聚合器，代理，链，分支等）来解决标准任务，而且很少出现。
从业务角度来看，可伸缩性是风险管理工具之一。 最主要的是通过最佳使用设备来满足客户的需求：
- 随着设备能力的提高而进步。 由于软件缺陷，它不会处于空闲状态。 Erlang在垂直方向上可以完美缩放，并且可以始终回收所有CPU内核和可用内存。
- 在多云的环境中，我们可以根据当前或预期的负载来控制设备数量，并保证SLA。
容错能力
考虑两个公理：“失败是不可接受的”和“失败将永远是”。 对于企业而言，软件故障是金钱损失，更糟的是声誉。 在潜在的损失和开发容错软件的成本之间取得平衡，您通常可以找到一个折衷方案。
在短期内，具有容错能力的体系结构可节省购买交钥匙群集解决方案的成本。 它们很昂贵，而且也有错误。
从长远来看，容错架构会在开发的所有阶段中重复支付其应用程序的成本。
在设计阶段通过代码库内部的消息传递，您可以详细计算系统内组件的交互。 由于所有关键组件都处理故障，因此简化了响应和管理故障的任务，并且生成的系统知道如何通过设计使故障自动恢复正常。
反应性
无论失败如何，应用程序都必须响应请求并满足SLA。 现实情况是人们不想等待，因此业务必须进行调整。 期望更多的应用程序具有高响应能力。
响应式应用程序接近实时模式。 Erlang VM在软实时模式下运行。 对于某些领域，例如交易所交易，医药，工业设备管理，硬实时模式很重要。
响应式系统增强了用户体验并为企业提供帮助。
初步结果
在计划本文时，我想分享创建消息代理和在其基础上构建复杂系统的经验。 但是，理论和动机部分却相当广泛。
在本文的第二部分中，我将讨论交换点，消息传递模板及其应用程序实现的细微差别。
在第三部分中，我们考虑了服务组织，路由和平衡的一般问题。 让我们谈谈系统的可伸缩性和容错性的实际方面。
第一部分结束。
图片@lucabravo 。