区块链生态系统将崩溃，Rust 超越 Go，Serverless 占主导地位

出品 | CSDN（ID：CSDNnews）

执行摘要：

编程语言

近年来，编程语言的发展似乎出现了类型化语言的趋势，其中最引人注目的是 TypeScript 和 Rust。根据 GitHub Octoverse 最近的一份报告，TypeScript 被当今大多数 JavaScript 框架采用，TypeScript 是十大编程语言之一。

Rust 的成长有目共睹。越来越多的低级软件是用 Rust 编写的，为了安全和速度，许多软件都移植到了 Rust。此外，Rust 也非常适合 WebAssembly (WASM) 生态系统，因为 Rust 可以编译成非常小的 WASM 二进制文件，主要是因为 Rust 没有运行时或垃圾收集。由于 Rust 不寻常的内存模型以及所有权和借用的概念，现代语言不包括垃圾收集是相当奇怪的。从 RedMonk 指数来看，鉴于驱动 Rust 的因素，Rust 很可能在未来几年内超过 Go。

从长远来看，我认为一些基于 Rust 概念的新语言（主要是内存模型和借位检查）会获得普及。同样将类型系统提升到一个新的水平，我相信具有依赖类型的语言（如 Idris）将从学术界跃升为工业中使用的流行语言。

在开发微服务时，尤其是 Kubernetes，使用一种可以生成小型、自包含二进制文件的语言是非常有利的。编译为 WASM 的语言也将变得更加重要，因为它们提供了对各种 PaaS 以及边缘平台的访问。这两个因素可能会限制依赖 Erlang VM 的 Elixir 和 Gleam 等语言的增长。

Kubernetes 和部署平台

未来 5 年，Kubernetes 将继续增长。但是，如果 Kubernetes 不采取措施解决日益增长的复杂性，一个强大的竞争对手可能很快就会出现。现阶段Kubernetes的运行和维护难度很大，所以很多用户采用了GKE等托管服务，或者聘请了Giant Swarm、Container Solutions等专业公司来管理Kubernetes。即使是使用托管服务的公司也会寻求专业公司的支持。这不一定是坏事，因为这些服务允许组织专注于他们的核心业务最新区块链项目交流群，但这也意味着不想为这些服务付费的用户很容易被其他替代品所吸引。

请注意，Kubernetes 的复杂性不仅隐藏在幕后，它甚至会溢出到界面中并影响用户。如今，通过 `kubectl run` 设置和运行演示相对简单。但是运行一个生产应用程序，并弄清楚如何安全地公开它，需要了解大量的特性，这不可避免地会导致臃肿的 YAML 文件甚至超过大多数微服务的源代码。

为什么会有这样的复杂性？很多都是发展的必然结果。一开始一切都很简单（最初的 Kubernetes 比较简单），然后添加了对某个用例的支持。然后，我们意识到我们应该实现一个特性，并且还要重写一些特性，但同时又要保持向后兼容。结果，软件变得越来越复杂。这意味着新的竞争对手将出现并取而代之，因为这些竞争对手没有历史包袱，可以从过去的成功和错误中吸取教训。

换句话说，支持的用例数量增加会导致“80/20”问题：80% 的用户只使用 20% 的功能，但每个用户使用的 20% 不同。并且移除一些特征是非常困难的。新的竞争对手没有这个问题，他们可以围绕一组核心功能构建新产品并修复/避免其他问题。

与往常一样，首先我们会看到一些小的变化。小公司和个人会避开 Kubernetes，转而使用更简单的解决方案，可能是某种开源 PaaS，或者可能是 WASM。Nomad 的采用将在未来几年显着增加。虽然一开始人们会说“是的，但你不能大规模使用一个软件”，但这些问题会逐渐得到解决，很快行业的另一次大变革就会到来。

另一种可能性是，Kubernetes 将成为构建其他一切的底层基础设施。因此，一个小项目可能会使用看似简单、精益的 PaaS（或类似 Knative 的 FaaS），但 PaaS 的底层是 Kubernetes。考虑到 Kubernetes 所需的资源量和 Kubernetes 的复杂性，我有点怀疑这种方法是否会被大规模采用。一个更简单有效的方法是提炼Kubernetes的精髓，构建一个新的系统。我们已经看到了很多这方面的探索性工作，比如k3s、KCP和badidea。附带说明一下，Backstage 和 Crossplane 等内部平台和工具将在大型组织中变得更加普遍，即使 Kubernetes 的问题得到解决，它们也​​不会消失。

无论未来发生什么，Kubernetes 都会在短期内以某种形式存在。它仍在快速增长，我们可以看到 Kubernetes 在未来几年内产生巨大影响。自定义操作符和 GitOps 将变得更加普遍。一些创新的 Kublet 实现，例如 Krustlet（它支持将 WebAssembly 模块作为 Pod 运行）可能会引起人们的兴趣。

WASM

WebAssembly 已经存在很多年了，并且变得越来越普遍。说起 WASM 的流行，我们不禁想起了 Java 的口号：“一次编写，到处运行”。当我们了解到 Java 可以在任何地方运行并且完全可移植时，这是一个巨大的成功，但与 Java 声称的相差甚远：

● Java 速度很慢，需要大量内存，因此无法在边缘设备中运行。

● 需要学习Java（现在JVM语言很多，但以前选择有限）。

● 编写JVM 实现并非易事，它们之间的差异导致“一次编写，到处调试”。

● 在浏览器中运行（小程序）需要插件。

而现在 WASM 解决了上述所有问题。WASM 相对简单、高效且体积小。很多语言都可以编译成WASM。主流浏览器已经有了成熟的实现。安全性甚至更好，通过 WASI 项目，您可以精确控制 WASM 可以做什么、可以读取什么输入、可以写入什么以及可以调用什么内核。

我们看到许多项目采用 WASM 作为他们的插件系统，包括 Envoy 和 Ethereum。这种趋势只会扩大，因为您可以对允许访问的插件进行精细控制，同时允许用户以他们喜欢的任何语言编写插件，这非常有意义。

WASM 可以替换容器的用例有很多，我希望看到更多 WASM 与 Kubernetes 集成，建立在 Krustlet 已经实现的基础上。更有趣的是，WASM 支持新的 PaaS 和 FaaS 平台，包括 Fastly 计算和 Cloudflare worker。

我们还将看到 WASM 在边缘设备中的使用，主要是因为它的可移植性和文件大小。

话虽如此，WASM 仍然面临许多挑战。比如它支持多种语言编译成WASM。虽然支持多种语言，但支持程度各不相同。Rust 语言目前位居榜首，因为它具有良好的支持并且可以创建相对较小的文件（如前所述，Rust 不包括垃圾收集和运行时）。此外，AssemblyScript（WebAssembly 的 TypeScript）非常流行。

虽然 WASM 还支持其他语言（包括 Go），但文件大小往往会因垃圾收集器实现或运行时特性而膨胀。其他语言的实现仍处于起步阶段。

许多重要的基础设施项目也是如此，例如 WASI，它定义了 WASM 如何与宿主环境交互。字节码联盟需要在快速构建生态系统中发挥重要作用。

供应链安全

作为一个行业，我们在这方面一直很糟糕（部分原因是安全行业的激励措施不完善）。供应链很幸运没有遭到大量黑客攻击。未来我们将看到越来越多的组织意外运行“病毒”版本的软件，因为攻击者已经能够在某些阶段注入他们自己的软件，无论是编译阶段、分发阶段，甚至是更新期间。在某些情况下，也可能会要求赎金，但我们会看到越来越多的高智商攻击先闯入一个组织，然后将其用作闯入另一个组织的踏板。

为了解决这个问题，我们必须认真思考如何证明在生产中运行的组件的出处。我们应该制定 SBOM 和类似的元数据标准实践，并大量采用 in-toto 和 Notary v2 等工具。GitOps 方法也可以发挥作用，在 CI 和部署之间提供明确的权限分离，并清楚地记录谁修改了什么以及为什么修改。

未来攻击的潜在影响已引起各国政府的关注，美国白宫发布命令审查美国政府的软件供应链，英国呼吁就供应链网络安全发表意见。希望大家共同努力，完善标准实践，构建工具生态系统，有效防范攻击。

乐观的预测是上述项目和方法（或其他类似方法）将被大量采用；悲观的预测是，破坏性越来越大的供应链攻击将越来越频繁地发生。

区块链和加密货币

虽然我认为区块链有其用途，但该领域的绝大多数公司都失败了。我们没有足够的用例来证明投资于这个生态系统的资金是合理的。

智能合约是我比较看好的一个领域。也许只是因为它让我想起了 Gradient，AI 能否建立一个由智能合约支持的帝国？（智能合约会写什么？没错，WASM）。

另一个潜在用途是在前面提到的供应链安全领域，我们可以使用区块链来识别软件的来源吗？

至于加密货币，我非常希望看到小额支付方式和廉价（接近零成本）的国际汇款。我确信这是加密货币的承诺之一，但尚未兑现。虽然有很多与加密货币相关的项目，但我不知道这是否可能。目前，像 Coinbase 这样的公司对类似服务的收费远高于股票经纪人。

我们必须停止对工作量证明等资源的荒谬浪费。在短期内，唯一真正的替代方案似乎是权益证明，我们必须转向这样的模型。老实说，我希望比特币死了，但从资金和支持者的数量来看，这在短期内不太可能发生。

GitOps 和 XX 作为代码

GitOps 的概念很简单，就是将 Kubernetes 集群所需的状态存储在 Git 中。如果集群的实际状态有偏差（这隐藏了很多不同的可能性），请进行协调。当您需要更改状态时，Git 存储库会更新，进而“协调”集群。这种方法的优点是显而易见的。我们可以通过克隆存储库来创建相同的集群，我们拥有集群变更的完整日志，并且我们拥有完善的机制来讨论和批准变更（拉取请求）。但是，GitOps 实现起来并不容易，并且有很多竞争技术，包括 Kubestack、Flux 和 Argo CD。

我们已经将 GitOps 应用到了 Kubernetes 下面的技术栈中，比如用 Terraform 启动了一个集群。随着微服务、无服务器、服务网格和 SaaS 组件（如队列和数据库）的兴起，曾经与应用程序相关的问题（如将多个功能连接在一起）已经在一定程度上推到了集群或基础设施层。显然，仅通过 YAML 文件来构建和定义集群是不够的。相反，我们需要成熟的编程语言。Pulumi 很早就看到了这一点并开始着手研究，但我认为我们可能会看到更多的迭代和潜在的解决方案。同样，WASM 允许用户说任何语言，所以也许是一块蛋糕。这在未来几年会变得更加清晰，但我认为很多手写的 YAML 将被 CDK 之类的工具所取代，

无服务器和 FaaS

由于上述原因，像 Lambda 这样的 FaaS 解决方案将得到广泛采用。虽然这是必然趋势，但这种方法并不整洁简单。为了有效地使用 FaaS，我们需要构建不同风格的应用程序架构。队列和消息传递基础设施将成为必不可少的组件，我们必须从根本上了解它们之间的交互，然后才能构建可靠的服务。以前可以通过数据结构和函数调用处理的功能现在必须在支持错误处理的分布式系统中进行改造和考虑。该领域的最佳实践和设计模式需要一些时间才能转化为标准和常识。

同时，我不清楚 Lambda 是否会成为这些问题的解决方案。Cloudflare 和 Fastly 的边缘计算 FaaS 产品非常出色，通过 WASM 提供出色的性能、可扩展性和语言灵活性。缺点是缺乏云提供商支持的基础设施，他们也在构建自己的 CDN（这实际上扼杀了他们的优势）。所有这些产品都是专有的，因此许多公司担心被“锁定”。出于这个原因，像 Knative 和 OpenFaaS 这样的开放替代品很受欢迎，并进一步细分了市场。

广义上的无服务器（FaaS 和 SaaS 应用程序，如数据库和队列）将成为主导范式，但前景依然坎坷。在接下来的几年里，我们会看到一些成功案例（“我们可以通过无服务器每月节省 10,000 美元”）和一些灾难性案例（“无服务器每月花费 10,000 美元，所以我们放弃了”）。

人工智能和机器学习

我一直在接触从事智能合约的人工智能公司，对我来说，这个领域太不真实了，更接近科幻。为了更好地了解该领域，我们可以看看 GPT3 和自动驾驶汽车的发展。AI能写小说吗？所有作者都可以使用 AI 作为合著者或编辑吗？美国有大量卡车司机，十年内会有多少司机被AI取代？有多少行业的多少工作岗位会被人工智能取代？还是人工智能只是一种炒作？

短期来看，最重要的变化似乎是基于GTP3的AI“帮手”和“自动补全”，这方面的尝试将层出不穷。如果你正在写一篇文章，人工智能可以帮助你自动完成一个句子。如果您正在开发 Web 应用程序，AI 可以帮助您完成某种方法。如果您正在写歌、创作绘画或构思工程计划，人工智能也可以成为您的助手。而那些拒绝使用人工智能的人将落后于时代。

我们在看云计算的发展，这也反映了AI运维的发展，指的是通过机器学习分析应用日志和遥测数据，找出问题，找出需要改进的地方。场地。

我不相信我们很快就能开发出通用人工智能，因此重大变化可能仅限于个别行业和特定用例。但这些领域的变化仍可能是一场彻底的革命。这些变化很可能是突然发生的，只有少数掌握了技术的公司会受益，社会经济分化进一步加剧。

我担心的是我们没有预料到的可能性，因为人工智能的变化几乎可以在一夜之间发生。科幻作家经常谈论“奇点”，广义上讲，是指人工智能跨越一个点，即变化加速超过人类预测或认知水平的点。有些观点可能被夸大了，但我绝对相信人工智能会产生我们没有预见到的重大社会影响。

混合动力技术的兴起

目前，内部基础设施、裸机和混合市场中的新老玩家都有很多活动。首先，我不是特别关注这个领域，所以我的一些观点可能不正确。

总的来说，公共云是要走的路，但我相信我们正在朝着本地基础设施和混合技术采用的方向发展。戴尔和HPE等传统硬件公司在此过程中可能犯了很多错误，但它们似乎都在朝着“XX-as-a-service”模式迈进，在这种模式下，消费者为他们使用的东西付费。起初最新区块链项目交流群，这种方法似乎与本地硬件背道而驰，但据说供应商会提供容量过剩的硬件，并承诺在需要时更快地交付。这种模式的美妙之处在于平衡承诺、资本支出和运营支出。您想每月降低每个实例的成本吗？然后签订 5 年合同和/或预购硬件。在确定您的商业模式时需要更灵活的模式吗？你可以签一份1年的合同，

HPE 的 GreenLake 和戴尔的 Project Apex 使用这种类型的模型。鉴于 IBM 最近的收购以及现有的产品和解决方案，我认为他们将在市场上采取类似的方法。Nutanix 也明显介入，为云资源和/或本地硬件提供软件控制平面。控制平面的重要性怎么强调都不为过，这种模式只有在能够轻松整合资源组合并维护基础设施的情况下才有效。新添加的 Oxide 大概也计划在该领域进行创新，在硬件和虚拟机管理程序的各个软件层之间提供更好的集成。另外，请注意，这与 Equinix 和 Scaleway 等裸机和数据中心公司目前提供和构建的完全不同，不同之处在于将“内部基础设施”理解为在自己的数据中心运行的设施，还是在其他数据中心运行的硬件？我必须拥有硬件，还是可以租用它？

在幕后，云提供商和芯片制造商之间存在一些有趣的动态。云提供商希望将芯片商品化，这样他们就可以每隔几年快速、廉价地更换它们。芯片制造商希望向云提供商销售尽可能多的芯片，同时保持对市场的控制。为了满足不同客户群的不同需求，芯片制造商可能会支持 HPE 和戴尔，以及任何促进内部基础设施和边缘计算平台多样化的举措。相比之下，云提供商已经开始构建自己的定制芯片并进入当地市场。

此外，云提供商与 Cloudflare 和 Fastly 等 CDN 提供商发生冲突。两家公司都开始提供无服务器计算服务，利用他们的数据中心尽可能接近客户。所谓临水楼先服务，所以在速度和成本上都有很大的优势。他们最大的缺点是无法访问 AWS 等提供的大量功能。通常你只能获得数据存储和计算服务，仅此而已。虽然我认为这些服务将大幅增长，但云提供商也在积极向 CDN 领域扩张以进行反击。

鉴于潜在的成本节约和避免“锁定”，我们将看到一些公司退回到内部基础设施和混合解决方案。云将继续占据主导地位，尤其是在初创公司中，但成熟的公司将衡量他们是否可以节省大量运营成本。那么，谁将是这场运动的最大赢家？传统硬件厂商、裸机和数据中心厂商、边缘计算厂商、云厂商还是管理平面软件厂商？

量子计算

量子计算也是一个非常感兴趣的领域，虽然我对这个领域的了解也有限。

鉴于量子计算需要真空和接近绝对零的温度，我们似乎不太可能很快看到量子笔记本电脑。事实上，量子计算机的成本高得令人望而却步，只有大公司和政府才能负担得起。然而，公众仍然可以使用量子计算，主要的云提供商宣布研究量子计算和出租量子计算。量子计算可能会导致 NP 完全问题的重大突破，例如分子模拟和优化逻辑问题。这也可能意味着只要能够提供量子计算机，破解诸如 TLS 之类的加密就不是问题。目前看来，量子计算将加速某些类别的问题，但不会很快破坏计算。

量子隐形传态似乎更有可能带来影响公众的重大突破，我们能否在地球的两端（甚至更远的地方！）之间实现比光速更快的高带宽通信？同样，我认为量子技术要真正影响大众还有很长的路要走。

原文链接：