哈Ha！ 我们在RBKmoney编写了一个新的付款处理程序。 从头开始。 好吧，这不是梦吗？
但是，和往常一样，在通往梦想的道路上，大多数方式都必须在有缺陷的情况下沿着河流游泳，部分原因是要骑上自己组装的自行车。 这样，我们获得了很多有趣和有用的知识，我们希望与您分享。
我们将告诉您我们称为RBKmoney Payments整个处理过程的编写方式。 他们如何使其抵抗负载和设备故障，以及如何提出几乎线性的水平缩放的可能性。
最后，当我们所有人起飞时，不要忘了内部人员的舒适性，我们创建的付款系统的想法主要是让开发人员和创建该系统的人感兴趣。
在这篇文章中，我们将打开一系列文章，其中我们将共享特定的技术知识，方法和实现，以及原则上开发大型分布式系统的经验。 第一篇文章是一篇评论文章，其中指定了我们将详细（有时是非常详细）披露的里程碑。
免责声明自上次发布博客以来，已经过去了5年。 在这段时间里，我们的开发团队得到了显着更新，现在有新人接管公司。
创建支付系统时，您需要考虑很多不同的事物并开发许多解决方案。 从可以处理数千个同时发生的借记借记请求的处理到用户友好的界面。 如果您不考虑细微差别，请放心。
严酷的现实是，付款处理背后有一些付款组织，根本没有开放的双臂来接受这种流量，有时甚至要求“每秒向我们发送不超过3个请求”。 那些可能是第一次在Internet上决定付钱购买东西的人，则着眼于界面。 以及任何外加的用户体验，难以理解和延迟-这是一个恐慌的时刻。
即使在龙卷风期间也可以放入购物篮
我们创建付款处理的方法是提供始终开始付款的功能。 不管我们内部发生了什么-服务器烧坏了，管理员对网络感到困惑，建筑物/地区/城市的电力都被切断了，我们有柴油车……我们迷路了。 没关系 该服务仍将允许您开始付款。
这种方法听起来很熟悉，对吧？
是的，我们受到Amazon Dynamo Paper中描述的概念的启发。 来自亚马逊的家伙们还建立了所有东西，以便用户可以将书放在篮子里，无论显示器另一侧发生了什么恐怖。
当然，我们没有违反物理定律，也没有想出如何反驳CAP定理 。 这不是事实，即会立即付款-毕竟，银行方面可能有问题，但是服务会创建一个请求，用户会看到一切正常。 是的，理想情况下，我们还有十几个积压的清单，其中包含技术债务，这是一种罪过，我们偶尔可以回答504。
让我们看看地堡，一旦龙卷风落在窗外
必须使我们的支付网关始终可用。 无论峰值负载是否增加，直流中是否有东西掉落或需要维护-最终用户都完全不会注意到这一点。
这是通过最小化存储系统状态的位置来决定的-很明显，无状态应用程序易于扩展。
应用程序本身在Docker容器中旋转，我们从中可靠地将日志合并到中央Elasticsearch存储库中； 他们通过服务发现彼此找到对方，并且数据在Macro服务内部通过IPv6传输。
收集并一起使用的所有微服务以及相关服务都是宏服务，最终为您提供了一个支付网关，从外部您可以看到它是我们的公共API。
SaltStack会密切注意顺序，该顺序描述了Macroservice的整个状态。
我们将返回整个农场的详细描述。
随着应用程序的简化。
但是，如果将状态存储在某处，则请确保将其存储在数据库中，该数据库中部分节点的故障成本最低。 另外，这样它就不会具有带有数据的主节点。 这样具有可预测的等待时间来响应请求。 这是你的梦想吗？ 然后，即使要为其提供服务，也并不是特别必要，而且语言开发人员也喜欢它。
是的，我们不是说用Erlang编写的整个在线处理过程都编写了吗？
正如许多人可能已经猜到的那样，我们别无选择。
我们系统在线部分的整个状态都存储在Basho Riak中 。 我们还将告诉您如何烹饪Riak而不伤手指（因为您会伤脑筋），但现在让我们继续。
钱在哪里，莱博夫斯基？
如果您花了无数的钱，您也许可以构建无限可靠的处理程序。 但这是不准确的。 而且他们没有给我们很多钱。 在服务器级别上，“质量，但中国”。
幸运的是，这带来了积极的影响。 当您了解作为一名开发人员时，要获得40个可寻址512GB RAM的物理核心将有些困难，您必须走出去并编写小型应用程序。 但是可以根据需要部署任意数量的服务器-服务器仍然便宜。
即使在我们这个世界上，任何服务器在重新启动后也往往无法恢复工作，甚至在最不适当的时刻捕获电源故障。
着眼于所有这些恐怖，我们学习了如何构建一个系统，期望它的任何部分都必定会突然崩溃。 很难记得这种方法是否给在线处理部分的开发带来了任何不便。 也许这与Erlangists的哲学及其著名的概念LetItCrash有关 ？
但是使用服务器会更容易。
我们找出了放置应用程序的位置，其中有很多应用程序都是可伸缩的。 该基地也是分布式的，没有主节点，被烧毁的节点也不是一件可惜的事情，我们可以迅速将服务器装载到推车上，来到DC并用叉子放在机架中。
但这不是磁盘阵列的情况！ 甚至一个很小的磁盘存储设备的故障都是部分支付服务故障，这是我们无法承受的。 重复存储？ 太不切实际了。
而且，我们不想负担昂贵的品牌磁盘阵列。 即使从简单的美感出发，它们也不会放在名词排成偶数的架子旁边。 而且价格昂贵。
最后，我们决定完全不使用磁盘阵列。 我们拥有的所有块设备均在同一台便宜的服务器上运行CEPH-我们可以将它们大量放入所需的机架中。
对于网络硬件，方法没有太大不同。 我们带中农，我们得到了很好的，合适的设备来完成任务是相当便宜的。 如果发生交换机故障，第二个服务器并行工作，并且在服务器上配置了OSPF，可确保收敛。
这样，我们得到了一个方便，容错和通用的系统-一个装有简单廉价服务器，几个交换机的机架。 下一个立场。 依此类推。
简单，方便，整体-非常可靠。
听船上的行为准则
我们从未想过要去办公室，做工作并获得现金。 财务部分非常重要，但是它不能代替做得好的工作带来的乐趣。 我们已经编写了付款系统，包括以前的工作地点。 并粗略地想象我们不想做什么。 而且我不想要标准但经过验证的解决方案，也不想要无聊的企业。
因此，我们决定为工作增加最大的新鲜度。 他们说，在支付系统的开发中，新解决方案通常受到限制，为什么您根本需要一个码头工人，让我们不要它。 和一般。 不安全。 拒绝
我们决定不禁止任何事情，而是鼓励一切新事物。 因此，在我们的生产中，我们通过docker容器中的大量应用程序构建了宏服务，这些应用程序通过SaltStack ，Riak群集， Consul即服务发现，分布式系统中查询跟踪的原始实现以及许多其他出色技术进行管理。
所有这些都是非常安全的，您可以在hackerone.com上发布Bugbounty程序而不会感到羞耻。
当然，沿这条路的最初步骤散落着一些绝对不雅的耙子。 当我们遍历它们时，我们将告诉您，例如，还告诉我们为什么没有测试环境，并且所有处理过程都可以通过简单的配置就可以部署在开发人员的便携式计算机make up 。
像一堆有趣的东西。
感谢您选择我们的航空公司！
PS：原始内容！ 帖子中的所有照片都是我们办公室生活中的场景。