技术雷达最新动向：超级应用程序趋势不再、平台也需产品化

机器学习（Machine Learning）曾是一片只有一小部分拥有相关工具和资源的幸运儿才能发挥创造的领域。幸运的是，随着各种规模设备计算能力的增长，开源工具的出现，更严格的对隐私和个性化信息保护意识以及法规要求，造就了一个蓬勃发展的生态系统，我们看到机器学习也逐渐成为主流。联邦学习等技术能够使 ML 模型为敏感信息提供隐私保障。TinyML 可以让模型在资源受限的设备上执行，将推理转移到边缘，这既可以释放资源，又可以提高敏感数据的隐私性。Feature Stores 为应用程序开发的模型 - 视图 - 控制器设计模式提供了类似的好处，使得数据整理、模型训练和推理之间的分离更为清晰。诸如 Stable Diffusion 之类的公开可用模型既突出了机器学习的惊人能力，也突出了对源数据和道德的关注。ML 组件也比以往任何时候都更容易连接在一起，从而使得通过自定义业务模型和功能强大的通用模型来创造性的构建 ML 体验和解决方案更为容易。我们对这一领域的新功能表示赞赏，并热切期待未来的进步。

在我们的技术雷达会议期间，“平台”仍然是最常提到的词语之一，因为这个概念在业界非常普遍。它以许多不同的表现形式出现，包括聚焦业务或领域的平台，还有基础设施或者开发者体验平台。从根本上说，组织在所有平台上遇到问题或感到失望的根因是没有正确地将它们作为产品对待。例如，许多旨在供开发者使用的平台缺乏在其它类型产品中所期望的用户调研与上下文分析。平台所有者需要验证他们对开发者需求的假设，并响应实际的使用模式。像任何好的产品一样，平台需要持续的支持。它必须发展并适应开发者不断变动的需求。此外，像项目经理和业务分析师等角色所需的经常与传统应用程序的范围不同。“平台即产品”的隐喻仅当作为一种实践而不是一个时髦短语而被完全采纳时才会生效。

我们都知道，任何形式的中心化都会导致限制、瓶颈、和不必要的暴露。所以我们一直在努力寻找打破这些耦合点的新方法，这些方法也在我们技术雷达的更新中被重点提及。而基于无冲突复制数据类型（CRDTs）的研究，使得数据应用可以不使用中心化的数据库，这种本地优先的软件 / 应用技术鼓励开发者们去考虑围绕点对点的数据构建应用而不是使用中心化的数据库。正如机器学习的主流化主题中所展示的一样，将数据所有权移至边缘节点能让开发者更好地利用不同设备的功能，例如面容识别等的许多功能可以在边缘节点进行，保持所用的数据永久保存在本地。

软件工程师们已经了解到主要围绕领域概念和业务功能构建应用架构的价值。虽然根据领域逻辑划分 UI 代码的技术问题仍然很重要，但它已经不是首要问题了。随着移动应用的成熟，它们通常会变得越来越大，有时会发展为所谓的超级应用程序。这些应用包含许多服务，完全可以视为一个个平台。虽然有些应用没有那么大，但多年来积累的很多功能通常也可以分解为各种模块，许多公司发现移动应用也能从同样的模块化方法中受益。模块化的应用程序可以由多个自主团队编写，这带来了许多有据可查的好处。然而会增加额外复杂度的是，满足应用商店的上架要求，并且支持原生 iOS，Android 以及基于 web 的版本，还得进行微调以适应每种版本的特点。虽然对于这些移动开发固有的独特难题，我们看到了更好的框架支持，但总的来说，尽管有好处，许多组织很难将模块化方法引入到移动开发中。

我们继续推荐团队实施威胁建模——一系列有助于在开发过程中发现潜在威胁并对其进行分类的技术——但是我们想要强调的是，这件事不是只在项目开始时做一次就能一劳永逸的，团队需要避免 security sandwich 现象。这是因为，在任何软件的整个生命周期中，由于外部事件以及需求和架构的调整，可能会出现新的威胁，而现有的威胁将继续发展。这就意味着，威胁建模需要定期重复——重复的频率视情况而定，需要综合考虑诸多因素，例如执行的成本和对业务的潜在风险等。如果结合其他技术使用，例如建立跨功能的安全需求来发现项目所采用的技术有什么公共风险，以及使用自动化安全扫描，这时威胁建模将变得非常有用处。

我们看到许多客户项目正在使用联邦学习 (ML)。传统上机器学习模型训练时需将数据放在集中运行模型训练算法的地址。在隐私角度上，这存在问题，特别是当训练数据包括敏感或者可用于身份识别信息时；用户也许不愿意分享数据，当地的数据保护法律也可能不允许我们将数据转移至一个中心化的位置。联邦学习是一个去中心化的技术，它使模型可以在大量不同来源的数据集上训练，并让数据保持在远端，例如用户的设备上。尽管网络带宽和设备的算力限制目前仍是这项技术重大的挑战，但是我们喜欢联邦学习的思路，让用户可以完全控制自己的个人信息。

Great Expectations 已经成为了我们的团队在数据质量领域的默认选择，这也是为什么我们建议采纳它 — 不仅仅是因为没有更好的替代方案，更多的是因为我们的团队在几个客户项目中都报告了它非常好的表现。Great Expectations 作为框架，允许用户搭建用于标记数据流水线中的异常或质量问题的内置控件。正如单元测试在构建流水线中运行一样，Great Expectations 在数据流水线的执行过程中进行断言。我们喜欢它的简单性和易用性 — 无需数据工程技能，保存在 JSON 里面的规则都可以被我们的数据领域专家修改。

我们成功地用  Clumio Protect 备份了 AWS 数据，特别是针对 S3 。作为一个商业 SaaS 解决方案，Clumio Protect 还可以备份一系列其他 AWS 服务，并在无法通过互联网访问的地方离线存储数据。我们负责处理大规模数据保护和恢复的团队发现 Clumio Protect 很容易设置和维护；当 S3 存储桶特别大的情况下，其性能远远超过原生的 AWS 备份服务。

Delta Lake 是由 Databricks 实现的开源存储层，旨在将 ACID 事务处理引入到大数据处理中。在使用了 Databricks 的 data lake 或 data mesh 的项目中，我们的团队更喜欢使用 Delta Lake 存储，而不是直接使用 AWS S3 或 ADLS 等文件存储类型。Delta Lake 此前一直是 Databricks 的闭源项目，最近成为了开源项目，并且可以在 Databricks 之外的平台使用。但是，我们只建议使用 Parquet 文件格式的 Databricks 项目将 Delta Lake 作为默认选择。Delta Lake 促进了需要文件级事务机制的并发数据读 / 写用例的发展。我们发现 Delta Lake 与 Apache Spark batch 和 micro-batch 的无缝集成 API 非常有用，尤其是其中诸如时间旅行（在特定时间点访问数据或还原提交）以及模式演变支持写入等功能，尽管这些功能有一些限制。

Bun 是一个新的 JavaScript 运行时，与 Node.js 或 Deno 相似。然而不同于 Node.js 或 Deno 的是，Bun 使用 WebKit 的 JavaScriptCore 构建，而不是 Chrome 的 V8 引擎。Bun 被设计为 Node.js 的直接替代品，它是一个单独的二进制文件（使用 Zig 编写），能够充当 JavaScript 和 TypeScript 的打包器、转译器 (transpiler) 与包管理器。Bun 目前正在 beta 测试，所以我们可以预计有一些漏洞或是与一些 Node.js 库的兼容性问题。然而， Bun 是从头开始构建的并且带有一些优化，包括快速启动和改进的服务端渲染，我们认为它值得评估。

React Query 通常被描述为 React 缺失的数据获取库。获取，缓存，同步和更新服务器状态是许多 React 应用程序常见的需求，尽管这些需求易于理解，但众所周知，正确地实现这些需求非常困难。React Query 提供了一种基于 hooks 的更直接的方式。它与现有的基于 promise 机制的异步数据获取库协同工作，如 axios、Fetch 和 GraphQL。作为应用程序开发人员，你只需要传递一个解析数据的函数，其余的事情可以留给框架完成。该工具开箱即用，但也可以按需进行配置。它的开发者工具也能帮助刚接触此框架的开发人员理解其工作原理，遗憾的是，其开发者工具尚不支持 React Native。对于 React Native，你可以使用第三方开发者工具插件 Flipper。基于我们的经验，React Query 的第三版为我们的客户提供了生产环境所需的稳定性。

当我们着眼于减少一款应用程序的碳足迹——运行软件间接导致的二氧化碳排放——时，注意力通常被导向让软件更加高效上。思路很明确：更高效的软件只需要更少的电力和服务器，从而减少发电与制造服务器所带来的碳排放。另一个策略是使应用程序 _ 具有碳意识 _。这是因为同样的工作负载并不总是具有相同的碳足迹。例如：在较冷气候的数据中心运行时，用于空调的电力需求会减少；或者，在能够使用更多的可再生能源（更多的阳光，更强的风力）时，碳基来源的电力需求会减少。借助 Carbon Aware SDK，软件工程师们可以查询数据源来发现对于给定的工作负载而言碳密集度更低的选项，然后将它移动到不同的位置或是在不同的时间运行它。这对那些对于时间和延迟都不敏感的大型工作负载来说是有意义的，例如训练机器学习模型。虽然这个 SDK 和可获取的数据源还不是很全面，但是我们相信是时候开始探索如何能让我们的系统具有碳意识了。

以上是我们在最新一期技术雷达中随机摘取的几个条目

欲获取整版技术雷达，请点击左下角阅读原文查看或下载