摘要
新 5G 规范和边缘计算对低提早的要求，给那些试图将一堆不同组件组装成一个不会呈现故障且仍具备低提早的高老本效益应用程序公司带来了严厉的挑战。事实上，这个问题十分重大，以至于须要重新考虑架构。
想要真正从 5G 和高速数据带来的倒退中获利，须要将多个数据层整合到一个集成堆栈中。
介绍
5G 和边缘计算都有扭转世界的后劲。事实上，很多人会辩论说，边缘计算曾经扭转了世界。STL Partners 公布的一份令人震惊的报告深入分析了 IBM 和亚马逊等次要企业目前向边缘计算畛域投入了多少资金，而 5G 也在其中。
钱是一回事，而投资所带来的理论变动是另一回事。
显然，个别的古代企业技术栈还没有为 5G 和边缘计算做好筹备，或是为公司曾经对 5G 和边缘计算进行的投资做好筹备。然而明天的技术栈不是为这两种技术构建的。随着更大、更快、更多样化的数据涌入咱们的零碎，估算限度使它们成为一个十分惨重的累赘。
你无奈将低提早革新到传统零碎中，至多在不花钱的状况下是这样。但残暴的事实是，对高可用性和异地复制的新需要须要一直减少开源或传统技术，最终会导致老本过高。
这给古代企业留下了一个十分明确但也令人担忧的窘境：寻找一种高效且价格合理的形式。
本文将解释为什么 5G 规范须要更好的提早，为什么技术栈变得如此简单，以及适合的数据平台如何能简化技术栈并通过这种简化天然升高 TCO。
为什么 5G 和边缘计算会遇到物理定律
光和所有其余模式的电磁辐射在真空中以每秒约 180 英里的速度流传，在光缆中以每秒约 120,000 英里的速度流传。5G 和边缘计算都围绕极低的提早建设其的价值主张，1-2 毫秒（ms）很快成为规范。
让咱们空想一款非常简单，可能疾速响应的应用程序，其惟一目标是向用户提供其所在城市的名称。如果应用程序托管在爱尔兰都柏林且用户也是，那么用户能够预期 1 - 2 毫秒的响应工夫。但如果该应用程序托管在 288 英里外的伦敦会怎么样？这意味着往返（从都柏林到伦敦再返回都柏林）的最短时间是（288/120）×2 即 4.8 毫秒。这还是在现实状态下，即在真空中。
如果应用程序略微简单一点怎么办？不是一次性给你城市名称，而是一次给你一个字母（即 L -O-N-D-O-N）？这将须要 4.8×5 即 24 毫秒。依照 5G 和边缘计算的规范来看，这速度慢得可笑。
这通知咱们什么？为了牢靠地运行边缘和 5G 应用程序，您须要：
1. 地理位置凑近您的客户
2. 可能在尽可能少的网络传输中解决其业务问 尽管企业正在通过将计算尽可能凑近其边缘来解决第一个问题，但这一边缘须要被定义。第二个限度传输的问题，须要企业重新考虑如何解决数据以及以后的技术栈能够实现什么与新的数据平台能够为他们做什么。
日益减少的复杂性（和 TCO）问题
开源和 XaaS 正在减少企业零碎组件的数量。
在过来二十年中，大量开源、云原生计算基金会（CNCF）和超大规模我的项目的面世使你能够用起码的代码将相当简单的解决方案粘合在一起。但这也意味着用不同的组件组装零碎更容易，所以零碎往往会比所须要的更简单。
比如说，从开发的角度来看，增加 Kafka 可能会节俭一周的工夫。但在操作上，往往会引入多个新组件来反对可能 20 年前用单个文件就能实现的操作。形象导致效率低下的想法并不陈腐，这也是为什么有些事件依然用汇编语言实现。但请记住：面对物理定律，任何额定的复杂性都会耗费咱们的提早估算。
实际上，应用开源技术的 TCO 比人们设想到的要高得多。你开始应用开源代码，找出差距，而后须要雇佣人员来填补差距，而后依据用例进行定制并构建产品。你还须要遵循踊跃的降级过程，免得产生巨额技术债权。
微服务也在减少解决方案中的组件数量
微服务也会使提早问题变得更重大。每个边界（堆栈层之间或微服务之间的程度边界）都会带来提早和复杂性。即便所有组件可能都位于同一个数据中心，但仍存在耗费估算的提早。
微服务都会导致为解决业务问题而运行的次数减少。当在同一建筑物里时这没事，但在高提早网络中会产生问题。在某种程度上你能够异步解决以缓解这种状况，但这又会减少了应用程序的复杂性，并可能导致系统实质上不稳固。假如你须要调用五个微服务来实现业务指标。为了加快速度，你一次运行了其中四个，期待响应，而后再运行第五个，但这可能会呈现很多谬误。
独自体现良好的组件在重叠它们时开始体现不好，起因很简略，因为它们试图做不同的事件，并且是由不同的人以不同的视角和冀望构建的。此外，每次将组件一分为二时，都会创立新的边界、新的提早问题和新的 API。
后果是：“阻力”让所有都变慢了
德国军事理论家冯·克劳塞维茨（Von Clauswitz）写到了“阻力”的概念，他将其定义为：“单位、组织或零碎的现实性指标与其在事实场景中的理论性能之间的差别”。
“阻力”存在于大型简单利用，就像它存在于军队一样。当你上线运行时，你永远无奈取得测试期间的性能，“变量”越多，带来的“阻力”就越多。
因而，开源 /XaaS 和微服务引入了一个真正的“阻力”问题。当你冀望这样一个零碎以最慢组件的速度运行，但理论教训表明，这种影响实际上会让事件至多慢 10 倍。
为什么 NoSQL 数据平台无奈解决提早（或 TCO）问题
基于 NoSQL 的数据平台于 2009/2010 年开始呈现，并迅速成为任何须要疾速扩大解决大量非结构化数据的应用程序（即古代应用程序）公司的“热门”数据库技术。然而，当 5G 和边缘计算呈现时，NoSQL 的局限性就裸露进去了。
在 NoSQL 中，所有解决都由客户端应用程序实现。客户端应用程序的工作是收回多个申请以检索所波及的不同键值，依据须要对其进行更改，而后将其发回。
这有多重含意：
- 随着业务构造变得更加简单，到服务器的网络拜访次数也在减少。
- 在简单的事务中，要害数据常常以“读取、从新读取而后再次读取以确保”的模式发生变化。这会导致重大问题，因为每次传输都会减少更多提早并产生另一个潜在的故障场景。
- 实现事务也会遇到问题。如果你曾经更改了三分之二的数据项，当初须要执行第三个。但发现因为数据库中不足 ACID 听从性，有问题的两个数据项之一已被其他人更改，当初你须要撤销事务并重试。这将显示为“长尾”（即比失常状况更长）提早，并导致在 5G/ 边缘环境中呈现问题。
你还必须思考客户端应用程序的地位以及客户端代码的复杂程度。它不能在边缘设施上生存，因为光是网络传输的次数就注定了它的失败。但这意味着你的应用程序服务器须要位于边缘地位，以便接管来自边缘设施申请并将其发送到位于同一地位的 NoSQL 数据库。然而因为上述处理过程非常复杂，应用服务器自身可能会呈现故障，使零碎处于凌乱和不统一的状态，而更改只实现了一半。
最初，如果相干产品应用 Java 来治理数据，Java 垃圾收集也是一个问题。家喻户晓，垃圾收集很难调整，尤其是产品中的垃圾收集（相较于一次性部署），垃圾收集引起的暂停很容易毁坏 5G/ 边缘 SLA。
简化堆栈的力量
例证：你不能通过减少复杂性来解决问题。
当你将组件的激增与应用须要屡次调用的数据库技术（即 NoSQL）相结合时，你将创立网络传输的几何爆炸式增长。零碎的复杂性使得单个业务事件可能波及零碎内的 20-30 个调用。“阻力”呈现，SLA 隐没。
面对 5G 和边缘计算，传统的性能问题解决方案都无奈见效。因而你无奈雇佣更聪慧的开发人员、应用更快的硬件或应用更多的硬件。而面对光速，你须要从头开始彻底从新思考你的架构。
企业可能须要些工夫能力弄清楚这个问题的全貌。沉没老本谬论应运而生。人们将十分不违心抵赖一个零碎已从根本上被突破，从而引起越来越多勇敢和失望的调整尝试。企业往往在实现解决方案的施行后，才得出一个难堪且低廉的论断，即解决方案行不通。
从堆栈中删除层意味着重新考虑所应用的工具。
当初来质疑微服务的价值可能为时已晚。木已成舟。但迫使开发人员在每次将函数一分为二时思考摩擦减少的结果并不是一件好事。
为了更进一步，让咱们提出一个可能令人不安的问题：你的利用程序代码中有多少用于解决上述问题，而不是为最终用户提供价值？要有多蹩脚你才会开始质疑在 5G/ 边缘体系结构中，是否存在须要为每个逻辑事务执行多个物理事务并重试争用数据的长久层？
当你将业务逻辑限度在客户端应用程序中，检查和 / 或更改数据所需的传输次数会明显增加。如果能够将业务逻辑代码和数据放在同一个物理服务器上以拜访 RAM 而不是网络，那会怎么样？
Volt Active Data 平台如何在将来验证您的技术栈并升高 TCO
Volt 开发初衷是让 OLTP 的运行速度比传统数据库快 10 倍，同时放弃 ACID 听从性并防止争用问题。随着工夫的推移，Volt 增加了额定的性能，直到 Volt Active Data 平台能够替换堆栈中的多个组件，并对其进行高度简化，以便您的应用程序能够轻松满足 5G 和边缘计算的提早要求。
Volt Active Data 平台采纳了传统数据库“继续存储，间断解决”的形式，并转换成了“继续解决，间断存储”。存储是传统数据库的次要性能，而对 Volt Active Data 平台来说是在发现事件时可抉择的解决形式。Volt 的最终目标是尽可能准确地解决尽可能多的事件，同时放弃超低的提早。
在 10 毫秒内，Volt Active Data 平台能够对您的数据执行以下所有操作：
- 消化 —即，意识到一个事件。
- 存储 —即，如需，存储事件或事件的各个方面以供将来决策时参考。
- 汇总 —即，将其汇总以用于统计分析和机器学习（ML）算法。
- 测量 —即便数据以闪电般的速度再零碎中传输，Volt 也能够精准测量。
- 用来做决策 —Volt 十分善于做出精准和可扩大的决策。
- 用来进行操作 —即，生成真实世界的事件响应（如，承受信用卡交易），而无需客户应用程序晓得或参加。
- 用于机器学习 —Volt 可与任何基于 Java 的决定性 ML 引擎配合应用。
Volt 是惟一可能在 10 毫秒内实现上述所有操作的数据平台。
论断
直到最近，企业构建本人的零碎才成为常态。他们可能会将这些零碎与功能齐全、特定畛域的第三方应用程序集成在一起，但大部分代码都是企业的，因而他们“领有”其性能，无论好坏。
然而，在过来十年中，咱们曾经看到了在线云服务的衰亡，例如提供排队和等待性能。这便于你以更快的实现代码编写，但代价是运行时的复杂性和提早。
微服务的宽泛应用让这成为一个更大的挑战。问题是，当你从超大规模提供商处“购买”在线服务时，你能够更快地实现代码，但你可能根本无法以低提早运行。鉴于咱们当初看到的对 5G、边缘计算和个位数毫秒响应的器重，这是一个十分低廉的谬误。
所以，不要犯这样的谬误。
并不是说你须要拆除并替换整个堆栈，只因咱们晓得拆除和替换是一件如许（可能十分低廉）让人头疼的事。你能够缓缓开始，并逐渐集成 Volt，这样你就晓得本人做了正确的抉择。咱们强烈建议你从提早估算开始，而后再进行宽泛的原型设计并确定架构。
如果您心愿集成 VOLT 到您的技术栈中，请与咱们分割！
Volt Active Data 中国网站 | sgao@voltactivedata.com