为什么像MegaFon，Tarantool这样的公司在开票？ 从外部看来，供应商通常来了，带来了一个大盒子，将插头插入插座-来了！ 它曾经是，但是现在是一个古老的，这种恐龙已经灭绝或灭绝。 最初，计费是一种计费系统-阅读器或计算器。 在现代电信中，这是一个
用于自动完成与订户互动的整个生命周期的系统，从合同签订到终止 ，包括实时计费，付款接受等等。 电信公司的帐单类似于战斗机器人-大型，功能强大且悬挂武器。
这是Tarantool？
Oleg Ivlev和
Andrey Knyazev将讨论这个问题。 奥列格（Oleg）是
MegaFon的首席架构师，在外国公司工作有丰富经验，安德烈（Andrey）是业务系统总监。 从他们在
2018年Tarantool大会上的报告的
笔录中，您将了解到为什么企业需要进行研发，Tarantool是什么，垂直扩展和全球化的僵局如何成为该数据库在公司中崛起的先决条件，技术挑战，架构转型以及MegaFon的technostek与Netflix类似，谷歌和亚马逊。
单一计费项目
将要讨论的项目称为“单帐单”。 正是在他身上，Tarantool表现出了最好的品质。
高端设备性能的增长跟不上用户基础的增长和服务数量的增长，由于M2M，物联网，预计用户和服务数量的进一步增长，以及分支机构的功能导致上市时间的缩短。 该公司决定创建一个具有独特世界级模块化体系结构的统一业务系统，而不是使用8种当前不同的计费系统。
MegaFon是八家公司合而为一的 。 2009年，重组完成：俄罗斯各地的分支机构合并为一家公司MegaFon OJSC（现为PJSC）。 因此，该公司拥有8个计费系统，具有自己的“自定义”解决方案，分支机构功能以及不同的组织结构，IT和营销。
一切正常，直到我不得不推出一种通用的联邦产品。 这里出现了很多困难：根据算术平均值，对于一些人来说，加价进行取价，对于其他人来说，程度较小，对其他人来说，也是这样。 有数千个这样的时刻。
尽管计费系统的版本相同，但一个供应商的设置却有所不同，因此胶水使用了很长时间。 我们试图减少它们的数量，并遇到了许多公司都熟悉的第二个问题。
垂直缩放 。 当时即使是最冷的铁也无法满足需求。 我们使用了Hewlett-Packard设备Superdome Hi-End系列，但它甚至不需要两个分支。 我想要水平缩放，而无需大量交易成本和资本投资。
对订户和服务数量增长的期望 。 顾问们早已将有关物联网和M2M的故事带入了电信世界：将会有一段时间，每部电话和熨斗都有一张SIM卡，而冰箱中有两张。 今天，我们有一个订户，不久的将来还会有一个数量级。
技术挑战
这四个原因促使我们进行重大变革。 在升级系统和从头开始设计之间可以选择。 他们考虑了很长时间，做出了认真的决定，做出了投标。 结果，他们决定从一开始就进行设计，并接受了有趣的挑战-技术挑战。
可扩展性
比方说，如果以前有
8个计费帐户，则有1500万订户 ，而现在应该有
1亿订户，甚至更多 —负担要高一个数量级。
我们的规模已经可以与主要的互联网公司（如Mail.ru或Netflix）相媲美。
但是，增加负载和用户群的进一步行动给我们带来了严峻的挑战。
我们广大国家的地理
加里宁格勒和符拉迪沃斯托克之间
7500公里和10个时区 。 光速是有限的，并且在这样的延迟距离下已经很重要了。 最凉爽的现代光学频道上的150 ms对于实时计费来说有点麻烦，尤其是在俄罗斯电信中。 此外，您需要在一个工作日内和不同的时区进行更新-这是一个问题。
我们不仅提供按月收费的服务，还提供复杂的资费，套餐和各种修饰符。 我们不仅需要允许或禁止用户讲话，还需要给他一定的配额-实时计算通话和操作，以使他不会注意到。
容错能力
这是集中化的另一面。
如果我们将所有订户收集到一个系统中，那么任何紧急事件和灾难都会给企业带来灾难性的后果。 因此，我们以某种方式设计系统，以排除事故对整个用户群的影响。
这再次是拒绝垂直缩放的结果。 当我们进行水平扩展时，我们将服务器的数量从数百个增加到了数千个。 它们需要进行管理和互换，并自动备份IT基础架构和恢复的分布式系统。
如此有趣的挑战摆在我们面前。 我们设计了系统，那时我们试图找到世界上最好的做法，以检查我们有多少趋势，我们遵循先进技术的程度。
世界经验
令人惊讶的是，在世界电信行业中，我们找不到任何参考。
欧洲下降了订户数量和规模，美国下降了关税。 我们在中国看到了一些东西，但在印度发现了一些东西，并聘请了沃达丰印度公司的专家。
为了分析体系结构，由IBM带领了来自各个领域的建筑师组成的Dream Team。 这些人可以充分评估我们在做什么，并将某些知识带入我们的体系结构。
规模
一些数字来说明。
我们为
8000万用户设计了
一个拥有10亿储备的系统 。 因此，我们删除了未来的门槛。 这不是因为我们要接管中国，而是因为物联网和M2M的压力。
实时处理3亿个文档 。 尽管我们有8000万订户，但我们需要与潜在客户以及如果我们需要收款的人离开我们的客户合作。 因此，实际交易量要大得多。
每天有
20亿笔交易会改变余额-这些是付款，费用，通话和其他事件。
200 TB的数据主动更改 ，
8 PB的数据更改慢一点，这不是存档，而是单次计费中的实时数据。 数据
中心规模为
14个站点的5000台服务器 。
技术栈
当我们计划架构并着手组装系统时，我们引入了最有趣和最先进的技术。 结果是形成了高负载系统的任何Internet播放器和公司都熟悉的技术堆栈。
堆栈与其他主要参与者的堆栈相似：Netflix，Twitter，Viber。 它由6个组成部分组成，但是我们要减少和统一它。
灵活性很好，但是在大型公司中，没有统一是不可能的。
我们不会将相同的Oracle更改为Tarantool。 在大公司的现实中，这是乌托邦，或者是长达5到10年的十字军东征，其结果令人无法理解。 但是Cassandra和Couchbase可以用Tarantool代替，我们致力于这一点。
为什么选择Tarantool？
我们选择此数据库有四个简单的标准。
速度 。 我们对MegaFon工业系统进行了压力测试。 Tarantool获胜-它表现出最好的表现。
这并不是说其他系统不能满足MegaFon的需求。 当前的内存解决方案是如此高效，以至于该公司的存货绰绰有余。 但是，我们有兴趣与领导者打交道，而不是与那些编织尾巴的人打交道，包括进行负载测试。
Tarantool甚至可以长期满足公司的需求。
总拥有成本（TCO）成本 。 在MegaFon卷上支持Couchbase会花费大量空间，而使用Tarantool则情况要好得多，并且就功能而言，它们非常接近。
另一个对我们的选择有轻微影响的好功能-Tarantool比具有内存的其他数据库更好。 它显示出
最大的效率 。
可靠度 MegaFon投资于可靠性，可能与众不同。 因此，当我们查看Tarantool时，我们意识到需要做什么才能使其满足我们的要求。
我们投入了时间和财力，并与Mail.ru一起创建了一个企业版，现已被其他多家公司使用。
Tarantool企业版在安全性，可靠性和日志记录方面使我们完全满意。
合作伙伴
对我来说，最重要的是
直接与开发人员联系 。 这正是Tarantool家伙行贿的原因。
如果您来找一位玩家，尤其是与锚客户端合作的玩家，并说您需要数据库才能做到这一点，那么，这个通常就可以回答：
-好吧，把需求放在那堆的底部-也许有一天，我们会解决这些需求的。许多人都制定了未来2-3年的路线图，几乎不可能在那里进行整合，而且Tarantool开发人员不仅要与MegaFon合作，还要开放地贿赂他们，并使其系统适应客户。 这很酷，我们非常喜欢。
我们在哪里应用Tarantool
在我们这里，Tarantool用于多种元素。
首先是我们在地址目录系统上
进行的试验 。 一次，我希望它成为类似于Yandex.Maps和Google Maps的系统，但结果却有所不同。
例如，销售界面中的地址目录。 在Oracle上，找到所需的地址需要12到13 s。 -不舒服的数字。 当我们切换到Tarantool时，在控制台中将Oracle替换为另一个数据库，并执行相同的搜索，我们得到200倍的加速！ 该城市在第三个字母后弹出。 现在，我们正在调整接口，以便在第一个之后进行。 但是，响应速度完全不同-已经是毫秒而不是秒。
第二个应用程序是一个流行的主题，称为“两速IT” 。 这是因为各家公司的顾问都说公司应该去那里。
有一层基础架构，位于其上方的域，例如计费系统，例如电信，公司系统，公司报告。 这是不需要触动的核心。 当然，这是可能的，但是在提供质量方面存在偏执，因为它为公司带来了收益。
接下来是微服务层-区分运营商或其他参与者。 可以基于某些缓存快速创建微服务，从而从那里的不同域提取数据。 这是一个
实验领域 -如果无法解决问题，请关闭一个微服务，然后打开另一个微服务。 这样可以真正缩短产品上市时间，并提高公司的可靠性和速度。
微服务可能是Tarantool在MegaFon中的主要角色。
我们计划在哪里应用Tarantool
如果我们将成功的计费项目与印度沃达丰Svyazkome的Deutsche Telekom的转换计划进行比较，则它令人惊讶地充满活力和创造力。 在实施该项目的过程中，不仅MegaMon及其结构发生了变化，而且Tarantool-enterprise也出现在Mail.ru上，而我们的供应商Nexign（以前称为Peter-Service）拥有一个BSS Box（盒装计费解决方案）。
从某种意义上说，这是俄罗斯市场的历史性项目。 可以将其与弗雷德里克·布鲁克斯（Frederick Brooks）的“神话人月”一书中所描述的相比较。 然后，在60年代，IBM吸引了5,000人开发大型机的新OS / 360操作系统。 我们的数量较少，只有1,800个，但是我们的资产却要归于所有，考虑到使用开源和新方法，我们的工作效率更高。
计费域或更广泛的业务系统如下所示。 企业中的人们非常了解CRM。 每个人都应该已经拥有其他系统：Open API，Gateway API。
开放API
让我们再次查看数字以及Open API现在如何工作。 它的负载是
每秒10,000个事务 。 由于我们计划积极开发微服务层并构建MegaFon公共API，因此我们希望在这一特定部分将来会有更多的增长。
十万笔交易肯定会 。
我不知道SSO是否可以与Mail.ru相提并论-这些家伙每秒有1,000,000笔交易。 我们对他们的解决方案非常感兴趣，并且我们计划从他们的经验中学习-例如，使用Tarantool进行功能性的SSO储备。 现在，来自Mail.ru的开发人员正在与我们合作。
客户关系管理
CRM-这些是我们希望增加到十亿的八千万用户，因为已经有包含三年历史的三亿文档。 我们真的很期待新的服务，而
增长点就是连接服务 。 这将是一个不断发展的球，因为将会有越来越多的服务。 因此，将需要一个故事，我们不想迷失在此。
就开票而言，与客户的应收款一起开票是
一种独立的领域 。 为了使性能最大化，将应用
域体系结构体系结构模板 。
将系统划分为多个域，分配负载并提供容错能力。 此外，我们使用分布式架构。
其他一切都是企业级解决方案。 在呼叫存储中-
每天 20亿，每月600亿。 有时，您必须重新计算一个月，然后很快重新计算。
财务监控恰恰是不断增长的3亿：订户经常在运营商之间运行，这增加了这一部分。
移动通信中最电信的组成部分是
在线计费 。 这些系统可以让您打电话或不打电话，实时做出决定。 在这里，负载为每秒30,000个事务，但是考虑到数据传输的增长，我们计划
250,000个事务 ，因此我们对Tarantool非常感兴趣。
上图是我们要使用Tarantool的领域。 当然，CRM本身更广泛，我们将在核心本身中应用它。
我们估计有1亿订户的TTX令我作为建筑师感到困惑-如果1.01亿怎么办？ 要重做一切吗？ 为了防止这种情况，我们使用缓存，同时提高了可访问性。
通常，有两种使用Tarantool的方法。 首先是
在微服务级别构建所有缓存 。 据我了解，VimpelCom遵循此路径，创建了客户端缓存。
我们减少了对供应商的依赖，我们正在改变BSS的核心，因此我们开箱即用了单个客户卡索引。 但是我们要绣花。 因此，我们使用略有不同的方法-
我们在系统内部进行缓存 。
因此，几乎没有一个rassynchron-一个系统既负责缓存，又负责主主资源。
当仅与更新相关的部分（即数据更改）被更新时，该方法非常适合Tarantool事务框架方法。 其他所有内容都可以存储在其他位置。 没有巨大的数据湖，没有托管的全局缓存。 高速缓存是为系统而设计的，无论是针对产品还是针对客户，或者是为了简化服务寿命。 当订户对质量感到不满时，我想为他提供定性服务。
RTO和RPO
IT-
RTO和
RPO中有两个术语。
恢复时间目标是故障后恢复服务的时间。 RTO = 0表示即使出现故障，该服务仍可继续工作。
恢复点目标是恢复数据的时间，即一段时间内我们可能丢失多少数据。 RPO = 0表示我们不会丢失数据。
Tarantool挑战
让我们尝试解决Tarantool的问题。
鉴于 ：每个人都了解一揽子应用程序，例如在亚马逊或其他地方。
该购物篮
需要每周7天，每天24小时或99.99％的时间工作。 接到我们的订单必须保持订单，因为我们不能随机启用或禁用订户的通信-所有内容必须严格一致。 前一个订阅会影响下一个订阅，因此数据很重要-不应丢失任何内容。
解决方法 。 您可以尝试直接解决该问题，并询问数据库开发人员，但是该问题并未在数学上得到解决。 人们可能会想起定理，守恒定律，量子物理学，但是为什么-它不能在数据库级解决。
好的旧架构方法在这里有效-您需要充分了解主题领域，并为此付出代价以解决此难题。
我们的解决方案：为Tarantool（地理分布的集群）创建分布式应用程序注册 。 在图中，这是三个不同的数据中心-两个到乌拉尔，另一个在乌拉尔，我们将所有应用程序分发到这些中心。
如今被认为是IT领导者之一的Netflix在2012年之前只有一个数据中心。 在12月24日天主教圣诞节前夕，该数据中心发生故障。 加拿大和美国的用户都没有喜欢的电影，这让他们非常沮丧，并在社交网络上写下了这些。 Netflix现在在西海岸拥有三个数据中心，在西欧拥有一个数据中心。
我们最初建立了一个地理分布的解决方案-容错对我们很重要。
因此，我们有一个群集，但是RPO = 0和RTO = 0呢？ 解决方案很简单，这取决于主题。
在应用中什么重要？ 分两部分：
在做出购买决定
之前扔篮子，以及
之后 。 电信中DO的一部分通常称为
订单捕获或
订单协商 。 在电信中，这可能比在线商店要复杂得多，因为在那里您需要为客户提供服务，提供5种选择，而且这一切都需要一段时间，但是篮子已经满了。 此时，故障是可能的，但并不可怕，因为它是在人的监督下以交互方式发生的。
如果莫斯科数据中心突然发生故障，然后自动切换到另一个数据中心，我们将继续工作。 从理论上讲，篮子中的一种产品可能会丢失，但是您看到了这一点，请再次补充篮子并继续工作。 在这种情况下，RTO = 0。
同时，还有第二个选项：单击“提交”时，我们希望数据不会丢失。 从这一刻起，自动化开始起作用-这已经是RPO =0。在一种情况下，这两种不同模式的应用可以只是具有一个可切换主服务器的地理分布群集，而在另一种情况下，则是某种仲裁输入。 模式可能会有所不同，但我们可以解决问题。
此外，有了分布式的应用程序注册器，我们还可以扩展所有内容-拥有许多访问此注册表的调度员和承包商。
Cassandra和Tarantool在一起
还有另一种情况-
“余额的展示” 。 这只是Cassandra和Tarantool联合使用的一个有趣案例。
我们使用Cassandra，因为每天20亿次通话没有限制，而且还会有更多。 营销人员喜欢按来源对流量进行着色，例如，社交网络上的详细信息越来越多。 这一切都增加了故事。
Cassandra允许您水平缩放到任意音量。
我们对Cassandra感到满意，但她有一个问题-她不擅长阅读。 , 30 000 —
.
, : , - , Cassandra. , IBM manager file transfer — , , UDP, , TCP. , , , - , — .
,
. Kafka Tarantool, , , ,
, , , 100 2 .
, 2 , , .
结论
Tarantool. Mail.ru, .
BCG McKinsey, Accenture IBM - — , , , , . , Tarantool . .
— Tarantool Conference , 17 T+ Conference 2019 « Tarantool Enterprise» . « Tarantool Oracle» . , , . — , . : , Tarantool, , , .