为什么像 MegaFon 这样的公司需要 Tarantool 进行计费？ 从外面看，供应商通常会带来某种大盒子，将插头插入插座 - 这就是计费！ 曾经是这样，但现在已经过时了，这样的恐龙已经灭绝或正在灭绝。 最初，计费是一种开具发票的系统 - 计数机或计算器。 在现代电信中，这是 自动化系统，用于与订户交互的整个生命周期，从签订合同到终止，包括实时计费、付款接受等等。 电信公司的计费就像一个战斗机器人——庞大、强大并且装载着武器。
Tarantool 与它有什么关系？ 他们会谈论它 奥列格·伊夫列夫 и Andrey Knyazev。 奥列格是公司的首席架构师 Andrey 拥有丰富的外企工作经验，担任业务系统总监。 从他们的报告笔录来看 你将了解为什么企业需要研发，Tarantool是什么，垂直扩展和全球化的僵局如何成为该数据库在公司出现的先决条件，关于技术挑战，架构转型，以及MegaFon的technostack与Netflix有何相似之处、谷歌和亚马逊。
“统一计费”项目
该项目称为“统一计费”。 正是在这里，Tarantool 展现了它最好的品质。
高端设备生产率的增长未能跟上用户群的增长和服务数量的增长；由于M2M、物联网和分支机构功能的引领，预计用户和服务数量将进一步增长导致上市时间缩短。 该公司决定创建一个具有独特的世界级模块化架构的统一业务系统，而不是当前8种不同的计费系统。
MegaFon 是八家公司合而为一。 2009 年，重组完成：俄罗斯各地的分支机构合并为一家公司，MegaFon OJSC（现为 PJSC）。 因此，该公司拥有 8 个计费系统，拥有自己的“定制”解决方案、分支机构功能以及不同的组织结构、IT 和营销。
一切都很好，直到我们不得不推出一种共同的联邦产品。 这里出现了很多困难：对于一些人来说，关税是四舍五入的，对于另一些人来说是向下舍入的，而对于另一些人来说则是基于算术平均值的。 这样的时刻有成千上万个。
尽管计费系统只有一个版本、一个供应商，但设置差异很大，需要很长时间才能整合在一起。 我们试图减少他们的数量，但遇到了许多公司都熟悉的第二个问题。
垂直缩放。 即使是当时最酷的硬件也无法满足需求。 我们使用了 Superdome Hi-End 系列的惠普设备，但它甚至不能满足两个分支机构的需求。 我想要横向扩展而不需要大量的运营成本和资本投资。
用户和服务数量增长的预期。 顾问们长期以来一直将物联网和 M2M 的故事带入电信界：总有一天，每部手机和熨斗都将配备一张 SIM 卡，并且冰箱里会放两张。 今天我们只有一批订阅者，但在不久的将来将会有更多。
技术挑战
这四个原因促使我们做出认真的改变。 可以选择升级系统和从头开始设计。 我们思考了很长时间，做出了认真的决定，进行了招标。 因此，我们决定从一开始就进行设计，并接受有趣的挑战——技术挑战。
可扩展性
如果是以前的话 就说吧 8 万订户的 15 次账单，现在应该可以了 100 亿订阅者及更多 - 负载高出一个数量级。
我们的规模已经可以与 Mail.ru 或 Netflix 等大型互联网公司相媲美。
但增加负载和用户基础的进一步行动给我们带来了严峻的挑战。
我们幅员辽阔的国家的地理
加里宁格勒和符拉迪沃斯托克之间 7500公里和10个时区。 光速是有限的，在这样的距离上，延迟已经很明显了。 在最酷的现代光通道上，150 毫秒对于实时计费来说太长了，尤其是现在俄罗斯的电信领域。 此外，您需要在一个工作日内更新，并且对于不同的时区，这是一个问题。
我们不仅仅提供订阅费服务，我们还有复杂的资费、套餐和各种修改器。 我们不仅需要允许或拒绝订阅者通话，还需要给他一定的配额——实时计算呼叫和操作，以免他注意到。
容错
这是中心化的另一面。
如果我们将所有订阅者集中在一个系统中，那么任何紧急事件和灾难都会给企业带来灾难性的后果。 因此，我们设计系统的方式是为了消除事故对整个用户群的影响。
这又是拒绝垂直扩展的结果。 当我们横向扩展时，我们将服务器数量从数百台增加到数千台。 它们需要可管理、可互换、自动备份IT基础设施并恢复分布式系统。
我们面临着如此有趣的挑战。 我们设计了这个系统，当时我们试图寻找全球最佳实践来检查我们的趋势如何，我们在多大程度上遵循先进技术。
世界经验
令人惊讶的是，我们在全球电信中没有找到任何参考资料。
欧洲在用户数量和规模方面已经落后，而美国在资费平坦度方面已经落后。 我们在中国考察了一些，在印度找到了一些，并从沃达丰印度聘请了专家。
为了分析架构，我们组建了一个由IBM领导的梦之队——来自不同领域的架构师。 这些人可以充分评估我们正在做的事情，并为我们的架构带来一定的知识。
规模
一些数字用于说明。
我们设计该系统的目的是 80万订阅用户，XNUMX亿储备。 这就是我们消除未来门槛的方法。 这并不是因为我们要占领中国，而是因为物联网和 M2M 的冲击。
实时处理 300 亿份文档。 尽管我们拥有 80 万订阅者，但如果我们需要收取应收账款，我们会与潜在客户以及已经离开我们的客户合作。 因此，实际体积明显更大。
2亿笔交易 余额每天都会变化 - 这些是付款、收费、通话和其他事件。 200 TB 数据正在积极变化，改变得慢一点 8 PB 数据，这不是存档，而是单个计费中的实时数据。 按数据中心扩展 - 5 个站点上的 14 台服务器.
技术栈
当我们规划架构并开始组装系统时，我们引入了最有趣和最先进的技术。 其结果是任何互联网参与者和制造高负载系统的公司都熟悉的技术堆栈。
该堆栈与其他主要参与者的堆栈类似：Netflix、Twitter、Viber。 它由 6 个组件组成，但我们希望缩短并统一它。
灵活性固然好，但在大公司里，不统一就不行。
我们不会将同一个 Oracle 更改为 Tarantool。 在大公司的现实中，这是一个乌托邦，或者是一场持续5-10年但结果不明朗的十字军东征。 但 Cassandra 和 Couchbase 可以轻松地被 Tarantool 取代，这就是我们正在努力的目标。
为什么选择塔兰图尔？
我们选择这个数据库有 4 个简单的标准。
速度。 我们对 MegaFon 工业系统进行了负载测试。 Tarantool 获胜 - 它展示了最佳性能。
这并不是说其他系统不能满足 MegaFon 的需求。 当前的内存解决方案非常高效，公司的储备绰绰有余。 但我们感兴趣的是与领导者打交道，而不是与落后的人打交道，包括在负载测试中。
Tarantool 甚至可以满足公司的长期需求。
总拥有成本。 对 MegaFon 卷上的 Couchbase 的支持需要花费天文数字，但使用 Tarantool 的情况要愉快得多，而且它们的功能相似。
另一个稍微影响我们选择的好功能是 Tarantool 比其他数据库更适合内存。 他显示 最大效率.
可靠性。 MegaFon 在可靠性方面的投资可能比其他任何公司都多。 因此，当我们考虑 Tarantool 时，我们意识到我们必须使其满足我们的要求。
我们投入了时间和资金，与 Mail.ru 一起创建了企业版本，现在已在其他几家公司中使用。
Tarantool-enterprise 在安全性、可靠性和日志记录方面完全让我们满意。
合伙
对我来说最重要的是 直接与开发商联系。 这正是塔兰图尔的人用来行贿的。
如果你找到一个玩家，尤其是一个与主播客户合作的玩家，并说你需要数据库能够做到这个、这个、这个，他通常会回答：
- 好吧，把需求放在那堆的底部 - 有一天，我们可能会解决它们。
许多人都有未来 2-3 年的路线图，几乎不可能集成到那里，但 Tarantool 开发人员以其开放性着迷，不仅来自 MegaFon，而且还根据客户调整他们的系统。 这很酷，我们真的很喜欢它。
我们在哪里使用 Tarantool
我们在多个元素中使用 Tarantool。 第一个是在试点中，我们在地址目录系统上制作的。 有一次我希望它成为一个类似于 Yandex.Maps 和 Google 地图的系统，但结果有点不同。
例如销售界面中的地址目录。 在 Oracle 上，搜索所需的地址需要 12-13 秒。 - 令人不安的数字。 当我们切换到 Tarantool，在控制台中将 Oracle 替换为另一个数据库，并执行相同的搜索时，我们获得了 200 倍的加速！ 第三个字母后会弹出城市。 现在我们正在调整界面，以便在第一个界面之后发生这种情况。 然而，响应速度完全不同——毫秒而不是秒。
第二个应用是一个流行的主题，称为双速 IT。 这是因为来自各个角落的顾问都说企业应该去那里。
有一个基础设施层，在其之上有一些域，例如电信等计费系统、公司系统、公司报告。 这是不需要触及的核心。 当然，这是可能的，但要偏执地确保质量，因为它会给公司带来金钱。
接下来是微服务层——这是运营商或其他参与者的区别所在。 可以基于某些缓存快速创建微服务，将不同领域的数据带入其中。 这里 实验场 - 如果出现问题，我会关闭一个微服务并打开另一个。 这确实缩短了上市时间，并提高了公司的可靠性和速度。
微服务也许是 Tarantool 在 MegaFon 中的主要角色。
我们计划在哪里使用 Tarantool
如果我们将我们成功的计费项目与德国电信、Svyazcom、沃达丰印度公司的转型计划进行比较，就会发现它具有惊人的活力和创造力。 在实施这个项目的过程中，不仅MegaFon及其结构发生了转变，而且Mail.ru上出现了Tarantool-enterprise，以及我们的供应商Nexign（以前的Peter-Service）-BSS Box（盒装计费解决方案）。
从某种意义上说，这对于俄罗斯市场来说是一个历史性的项目。 这可以与 Frederick Brooks 的《人月神话》一书中的描述进行比较。 然后，在 60 年代，IBM 雇用了 360 名员工来开发用于大型机的新 OS/5 操作系统。 我们的数量少于 000，但我们的数量是背心，考虑到开源和新方法的使用，我们的工作效率更高。
以下是计费领域，或更广泛地说，是业务系统领域。 企业界人士对CRM非常了解。 每个人都应该已经有其他系统：Open API、API Gateway。
开放API
让我们再次查看这些数字以及 Open API 目前的工作原理。 其负载为 每秒 10 笔交易。 由于我们计划积极开发微服务层并构建MegaFon公共API，因此我们预计这部分未来会有更大的增长。 肯定会有100万笔交易.
我不知道我们是否可以与 Mail.ru 的 SSO 进行比较 - 这些家伙似乎每秒有 1 笔交易。 他们的解决方案对我们来说非常有趣，我们计划采用他们的经验 - 例如，使用 Tarantool 进行功能性 SSO 备份。 现在 Mail.ru 的开发人员正在为我们做这件事。
客户关系管理
CRM 的订阅者数量为 80 万，我们希望将其增加到 300 亿，因为已经有 XNUMX 亿份文档包含三年的历史记录。 我们真的很期待新的服务，在这里 增长点是互联服务。 这是一个会不断增长的球，因为会有越来越多的服务。 因此，我们需要一个故事；我们不想偶然发现这个。
通过开具发票、处理客户应收账款自行计费 转换为单独的域。 为了提高性能， 应用领域架构架构模式.
系统划分域，分散负载，保证容错。 此外，我们还使用分布式架构。
其他一切都是企业级解决方案。 在通话存储中 - 每天 2 亿，每月60亿。 有时你必须在一个月内数一下，而且最好快点。 财务监控 - 这与不断增长和增长的300亿完全相同：用户经常在运营商之间流动，增加了这部分。
移动通信中最具电信性的组成部分是 在线计费。 这些系统允许您打电话或不打电话，实时做出决定。 这里的负载是每秒 30 个事务，但考虑到数据传输的增长，我们计划 250 笔交易，因此我们对 Tarantool 非常感兴趣。
上图是我们要使用 Tarantool 的域。 当然，CRM 本身更广泛，我们将在核心本身中使用它。
我们估计的 TTX 订阅用户数为 100 亿，这让作为架构师的我感到困惑 - 如果是 101 亿呢？ 难道所有的事都要重做一遍吗？ 为了防止这种情况发生，我们使用缓存，同时增加可访问性。
一般来说，有两种使用 Tarantool 的方法。 第一的 - 在微服务级别构建所有缓存。 据我了解，VimpelCom 正在遵循这条道路，创建客户端缓存。
我们对供应商的依赖较少，我们正在更改 BSS 核心，因此我们有一个开箱即用的客户端文件。 但我们想扩大它。 因此，我们采取稍微不同的方法 - 在系统内部创建缓存.
这样就减少了同步——一个系统负责缓存和主控源。
当仅更新与更新（即数据更改）相关的部分时，该方法非常适合具有事务框架的 Tarantool 方法。 其他一切都可以存储在其他地方。 没有巨大的数据湖、不受管理的全局缓存。 缓存是为系统设计的，或者是为产品设计的，或者是为客户设计的，或者是为了让维护更容易。 当订户致电并对您的服务质量感到不安时，您希望提供优质的服务。
RTO 和 RPO
IT中有两个术语—— RTO и RPO.
恢复时间目标 是发生故障后恢复服务所需的时间。 RTO = 0 意味着即使出现故障，服务仍会继续工作。
恢复点目标 - 这是数据恢复时间，即在一段时间内我们可能丢失多少数据。 RPO = 0 意味着我们没有丢失数据。
塔兰工具任务
让我们尝试解决 Tarantool 的问题。
给定：一篮子每个人都理解的应用程序，例如在亚马逊或其他地方。 需要 以便购物车每周 24 天 7 小时工作，即 99,99% 的时间。 发送给我们的订单必须保持顺序，因为我们不能随机打开或关闭订户的连接 - 一切都必须严格一致。 上一个订阅会影响下一个订阅，因此数据很重要 - 任何内容都不应丢失。
解。 你可以尝试正面解决并向数据库开发人员询问，但问题无法用数学方法解决。 你可以记住定理、守恒定律、量子物理，但为什么 - 它无法在数据库级别解决。
良好的旧架构方法在这里起作用 - 您需要充分了解主题领域并用它来解决这个难题。
我们的解决方案：在 Tarantool 上创建应用程序的分布式注册表 - 地理分布式集群。 在图中，这是三个不同的数据处理中心 - 两个在乌拉尔山之前，一个在乌拉尔山之后，我们在这些中心之间分发所有请求。
Netflix 现在被认为是 IT 领域的领导者之一，直到 2012 年才拥有一个数据中心。 24 月 XNUMX 日天主教圣诞节前夕，该数据中心出现故障。 加拿大和美国的用户失去了他们最喜欢的电影，感到非常沮丧，并在社交网络上写道。 Netflix 目前在东西海岸拥有 XNUMX 个数据中心，在西欧拥有 XNUMX 个数据中心。
我们最初正在构建一个地理分布式解决方案 - 容错对我们来说很重要。
这样我们就有了一个集群，但是 RPO = 0 且 RTO = 0 又如何呢？ 解决方案很简单，具体取决于主题。
应用中什么最重要？ 两部分：投篮 TO 做出购买决定，以及 AFTER。 电信中的DO部分通常称为 订单捕获 или 订单洽谈。 在电信中，这可能比在网上商店困难得多，因为必须为客户提供服务，提供 5 个选项，这一切都会发生一段时间，但篮子已满。 此时，失败是可能的，但这并不可怕，因为它是在人的监督下交互发生的。
如果莫斯科数据中心突然出现故障，那么通过自动切换到另一个数据中心，我们将继续工作。 理论上，一件产品可能会丢失在购物车中，但您看到它后，会再次添加到购物车并继续工作。 在这种情况下，RTO = 0。
同时，还有第二个选项：当我们点击“提交”时，我们希望数据不丢失。 从这一刻起，自动化开始工作 - 这是 RPO = 0。使用这两种不同的模式，在一种情况下，它可能只是一个具有一个可切换主服务器的地理分布式集群，在另一种情况下是某种仲裁记录。 模式可能会有所不同，但我们解决了问题。
此外，有了分布式应用程序注册表，我们还可以扩展它——拥有许多访问此注册表的调度程序和执行程序。
Cassandra 和 Tarantool 一起
还有一个案例—— “余额展示”。 这是 Cassandra 和 Tarantool 联合使用的一个有趣案例。
我们使用 Cassandra 是因为每天 2 亿次调用还不是极限，而且还会更多。 营销人员喜欢按来源对流量进行着色；例如，越来越多的详细信息出现在社交网络上。 这一切都为故事增添了色彩。
Cassandra 允许您水平缩放至任意大小。
我们对 Cassandra 感觉很舒服，但它有一个问题——它不擅长阅读。 录音一切正常，每秒30次不是问题—— 阅读问题.
因此，出现了一个带有缓存的主题，同时我们解决了以下问题：有一种古老的传统情况，来自在线计费交换机的设备进入我们加载到Cassandra中的文件中。 即使使用 IBM 文件传输管理器的建议，我们也一直在努力解决这些文件的可靠下载问题 - 有一些解决方案可以有效地管理文件传输，例如使用 UDP 协议而不是 TCP。 这很好，但还需要几分钟，而且我们还没有全部加载，呼叫中心的接线员无法回答客户的余额发生了什么事 - 我们必须等待。
为了防止这种情况发生，我们 我们使用并行功能储备。 当我们通过 Kafka 将事件发送到 Tarantool 并实时重新计算聚合时，例如今天，我们得到 现金余额，它可以以任何速度转移余额，例如每秒 100 万笔交易以及同样的 2 秒。
我们的目标是，拨打电话后 2 秒内，您的个人帐户中不仅会显示更改的余额，还会显示有关更改原因的信息。
结论
这些是使用 Tarantool 的示例。 我们真的很喜欢 Mail.ru 的开放性以及他们愿意考虑不同情况的意愿。
对于来自 BCG 或麦肯锡、埃森哲或 IBM 的顾问来说，他们已经很难用新的东西给我们带来惊喜了——他们提供的很多东西，我们要么已经做了、已经做了，要么正计划做。 我认为 Tarantool 将在我们的技术堆栈中占据应有的位置，并将取代许多现有技术。 我们正处于该项目的积极开发阶段。
Oleg 和 Andrey 的报告是去年塔兰图尔会议上最好的报告之一，17 月 XNUMX 日 Oleg Ivlev 将在 有报告 。 Alexander Deulin 也将在 MegaFon 上发表演讲 。 让我们看看发生了什么变化，实施了哪些计划。 加入 - 会议是免费的，您所要做的就是 。 所有 会议议程已形成：新案例、Tarantool使用新体验、架构、企业、教程和微服务。
来源： habr.com