写点什么

历史技术栈体系即将崩溃,我们如何应对?

用户头像
VoltDB
关注
发布于: 2021 年 03 月 11 日

01 前言


当大家都在谈论 5G 和边缘计算,这意味着新的技术变革即将到来,我们的技术演进迭代也将发生重大变化。简单来说:


  • 我们对延迟的需求正在逼近物理极限,并且很快就会受到光在光纤电缆传播速度的物理限制。

  • “最终用户”曾经是指数千万的人口,但在不久的将来,数百亿的物联网设备将取代人类用户,这些物联网设备的连接和数据处理是迫在眉睫的现实需求。

  • 在不造成中断的情况下,完成系统部署升级也是非常现实的问题。


当延迟的需求达到需要以光速或接近光速的速度运行时,此前可行的简单处理方式都将失效,将倒逼我们采用更先进的架构和方案。

对 5G 和边缘计算的巨大增长需求,使我们走到了技术发展的分水岭:一方面是旧有的面临淘汰的技术栈。另一方面是安全和广阔的新世界。

但是,您需要采用正确的技术方案才能达到目标。


02 为什么旧有的技术栈即将崩溃?


随着数据和设备的爆炸式增长,同时现实又要求这些设备之间的交互提供更低的延迟,并对各种数据做出实时决策响应。当同时涉及到大数据、低延迟、实时状态更新需求时,三个因素将迅速让现有的技术栈崩溃。


2.1 物理极限


5G 和边缘计算有望实现连接全球数百亿的智能设备,并实现远程控制和智能编排。5G 移动网络提供 1-2 毫秒的延迟,这比普通的 4G 网络快 23 毫秒,但这也向现有的技术栈提出了一个非常棘手的问题:它可以打破物理极限吗?

借助 5G 和边缘计算,我们到达了一个新场景,当添加更多或者更快的设备并不能解决问题,并且不再可能迁移到“更快的网络”。下图说明了这一点,光在 WAN 网络中的传播速度每毫秒约 120 英里(约 200 公里),将 4G 的最低延迟时间所需的最大距离与 5G 的最大无延迟时间距离进行比较,比真空中的速度慢 30%。



理论最大传输距离对比:5G VS. 4G

网络技术受到光速的限制,光速在真空中一毫秒内可以传播 181 英里,而在光纤中只能在一毫秒内传播约 54 英里。这意味着 1 毫秒的延迟,5G 网络理论上最多只能在 54 英里以内的设备间通信。

当下的网络技术、客户端-服务器计算所处的位置、客户端和服务器之间的距离导致了各种延迟的增加。

光在 10 毫秒内移动了 1,810 英里,这意味着任何需要在 10 毫秒或更短时间内发生的客户端-服务器通信,其设备的物理距离都不得超过 1,810 英里。实际的光纤电缆发送数据的速度,比光速还要慢 30%,也就是 WAN 中,数据传输 10 毫秒大约才走 500 英里。

当然,可以通过新技术、例如在专用光纤电缆上追加投资等方式,可以加快网络速度,但是不可能超越光纤电缆的能力,更不用说接近光速了。

5G 有望最终产生 1 毫秒的往返延迟,满足这么低延迟的唯一方法是双方(发送方-接收方或者客户端-服务器)彼此之间相距几英里,并进行简短的信息交换。

没有物理学上的突破,就没有技术上的突破。


2.2

数字孪生的激增


数字孪生是虚拟的数字映射,通常由以下元素组成:


  1. 物理设备上的各种信号接入后,可以实现远程控制

  2. 各种在线设备系统的数字映射关系

  3. 设备间的可靠数据传输可以代表设备的当前状态


一旦这三个要素到位,不仅云计算应用将变得可行,还可以控制便宜且简单的设备,通过使用云来让大量的数字孪生设备一起协同工作,完成同一目标。

到目前为止,许多设备与互联网的交互是可选的,或者不必要,而且通常无法控制其核心功能。但是 5G 和边缘技术已经可以促使成百上千亿的数字孪生,每天都在满足我们赖以生存的生活需求,而这一切都取决于他们自己在网络中某个地方进行可靠的超低延迟决策。大量的设备不停的被用到,然而过往的设备操作过程是“先关闭然后再打开”,这种方式已经不能满足我们管理无数设备的期许了。

延迟还意味着设备依赖快速连接来完成预期工作,因此未能满足 SLA 的情况与设备中断区别不大,如果设备是根据过期的信息来决策或者执行操作,可能会带来更为糟糕的后果。

2.3 计划内停机

计划内的停机时间将为 5G 和边缘应用带来严重后果。通常来说,5G 的设备需要实时联网才能工作,停机意味着重大事故。

这有几个含义:

1.采用开源组件的复杂技术栈可能无法胜任工作。如果堆栈中的每一层都有其自己的独立补丁,当补丁达到一定复杂程度或者数量时,停机更新可能是不可避免的。但如果不打补丁,也可能会带来潜在的法律或者安全问题。当停机更新的时间每分钟需要花费数千美元时,减少技术栈组件数量或许非常必要。

2.为软件打补丁和维护相对比较容易,但为固件打补丁则非常麻烦,所以尽可能不要固件或者硬件代码来完成软件栈的功能,而是从终端设备完成固件的更新与维护。

3.敏捷开发可能并不适用于与数十亿数字孪生设备一起工作,伴随每个小版本更新可能随之带来各种错误,从而导致设备中断,甚至更严重的后果。


03 新常态的不便之处


我们面临的根本问题是,由于 5G 场景对于延迟的需求,很大程度上是由于技术组件栈太深,而导致了额外的延迟,从而浪费了真正的有效数据处理时间。

请记住:5G 和边缘计算不会在真空中发生,也不会慢慢发生。5G 和边缘计算的实施意味着设备和用户会话的数量将迅速飙升。当前 5G 规范,联网设备的密度约为每平方公里 100 万台。

其中许多设备将是运行在 SLA 保障较高的数字孪生场景,需要不断与远程计算能力保持联机通信,并实时做出决策。

联网设备的爆炸式增长与对延迟和连接性的期望将同时发生。



延迟预期 VS. 连接设备数

随着时间的流逝,我们使用的设备数量激增,现在已经超过了人类总量。但是设备不像人类,它期望以毫秒为单位的实时决策响应。

在以前,“我们希望更快”就可以了。而现在,“我们在 4 毫秒内得到响应”很可能是 SLA 的需求。

如果我们认可 5G 和边缘计算对于低延迟需求的价值,那么我们也必须接受对当前的技术和架构的挑战。


04 如何避免技术堆叠的责任


当接近延迟要求的拐点,到达物理极限时,我们需要对管理数据和运行技术栈的方式进行革新,每项革新都会带来不同的挑战和开放式的方案。

他们是:

1.边缘处理

尽管我们仍将在数据中心计算上进行大量投资,但由于新应用程序对低延迟的要求很高,因此,在边缘端执行大量对延迟敏感的功能是很有必要的。从技术和业务角度来看,边缘处理意味着更加复杂的部署架构。

2.更简单的技术组件栈

在 5G 和边缘计算之前,业务问题通常通过创建包含多个组件的分层架构来解决架构间的解耦问题。但是,每一层都会增加延迟,在 5G 世界中,需要节省与边缘设备间的通信延迟,而不是在软件组件逻辑层之间的额外通信上浪费时间。现实是,只有推动架构向前发展,使用更少的技术组件栈,将数据流、流处理和事务状态管理合并在一起,才能从根本上解决这个问题。

3.“ 哑巴”设备

早期的 IoT 项目涉及向设备添加传感器,以便它们可以发送数据到服务器端,在远端完成数据分析。这些早期架构中,设备会使用有限的本地计算能力来执行部分核心功能。

而 5G 和边缘应用的连接无处不在,没有理由在每台终端设备上保留强大的处理能力。这样做会增加设备成本,而且也会造成无休止的设备端补丁更新噩梦。

边缘计算,逻辑上就有可能发生从设备中删除尽可能多的智能处理单元。


05 下一步:您需要评估的五个需求问题


5G 不仅仅是营销术语,还是用稍好的硬件代替一般硬件的借口。但真正需要改变的是我们做事的方式。

从以下五个问题来评估您的应用场景是否适合 5G:


  1. 它适用于 OLTP 吗?如果是,它是否可以在单位延迟时内从大规模数据中做出准确的决策?

  2. 它可以在架构上最小化数据在网络中传输的次数吗?

  3. 它是否足够简单且垂直集成,从而以高可用的方式用最少的时间来处理数据?

  4. 它是否用于 IoT 或流消息?如果是,它是否具与 Kafka,Kinesis 等消息中间件的入站和出站连接,方便集成多个数据流?

  5. 如果您的下一代 5G 应用依赖开源技术,您是否真正考虑过停机和故障的后果?


如果您对以上任何一个问题的回答都是“否”,那么您很可能将面临技术堆叠导致应用崩溃的境地,应该寻求有专业支持的集成解决方案来主动避免这场灾难。


06 VOLTDB 如何满足 5G 的需求?


随着我们步入 5G 和边缘计算场景,您必须接受这样一个事实,现有的软件堆栈或开发技术可能很快就会过时。在技术领域,情况一直如此:昨天可以稳定工作的平台软件今天会失效,明天更可能会面临系统崩溃。

低延迟需求将大多数技术堆栈的功能扩展到其极限,许多公司都会试图找到最便宜或开发效率最快的方法。但他们不会从整体上或者根本上进行架构思考,而是从拼图和创可贴的角度开展工作,从而导致更大的后果。

没错:5G 和边缘计算就在这里,并正在取代数据世界的运行方式。

如果您正在寻找可以在毫秒延迟内实现高可用性、可扩展性和实时决策的平台,请立即通过 https://www.voltdb-china.cn/contact 与我们联系,来聊聊我们如何提供帮助。


参考:

1.https://www.quora.com/What-is-precisely-the-speed-of-light-in-fiber-optics

2.https://en.wikipedia.org/wiki/Digital_twin

3. https://arstechnica.com/information-technology/2017/02/5g-imt-2020-specs/


如果您希望集成 VoltDB 到您的技术栈中,或者想和更多小伙伴一起交流

请私信与我们联系。


关于 VoltDB

VoltDB 支持强 ACID 和实时智能决策的应用程序,以实现互联世界。没有其它数据库产品可以像 VoltDB 这样,可以同时需要低延时、大规模、高并发数和准确性相结合的应用程序加油。

VoltDB 由 2014 年图灵奖获得者 Mike Stonebraker 博士创建,他对关系数据库进行了重新设计,以应对当今不断增长的实时操作和机器学习挑战。Stonebraker 博士对数据库技术研究已有 40 多年,在快速数据,流数据和内存数据库方面带来了众多创新理念。

在 VoltDB 的研发过程中,他意识到了利用内存事务数据库技术挖掘流数据的全部潜力,不但可以满足处理数据的延迟和并发需求,还能提供实时分析和决策。VoltDB 是业界可信赖的名称,在诺基亚、金融时报、三菱电机、HPE、巴克莱、华为等领先组织合作有实际场景落地案例。


用户头像

VoltDB

关注

VoltDB以及数据库应用场景知识库 2020.11.02 加入

VOLTDB诞生作为支持云端部署的内存数据库,并在持续增强流计算能力,原生分布式架构提供了可伸缩性,同时完全满足ACID要求,数据安全可靠,是由2014图灵奖得主Mike Stonebraker博士领导全新设计的架构。

评论

发布
暂无评论
历史技术栈体系即将崩溃,我们如何应对?