菜单

平台

采纳?

  • 虽然 .NET Core 之前已进入雷达的采纳环,表明它已成为我们 .NET 项目的默认平台,但我们觉得有必要再次关注一下 .NET Core。随着去年 .NET Core 3.x 的发布,. NET Framework的大部分特性,现在都已移植到 .NET Core 中。微软在.NET Framework最新一次发布中,强调.NET Core 是 .NET 的未来。微软已经做了大量工作,来使 .NET Core 达到容器友好。我们大多数基于 .NET Core 的项目,都是针对Linux的,并通常以容器形式进行部署。即将发布的 .NET 5 ,看起来很有前途。我们对此充满期待。

    历史信息
  • 如果正在构建和运行规模化的微服务架构,且已采用 Kubernetes,那么使用服务网格来管理所有架构切面,应当是一个默认选择。在众多服务网格实现中,Istio 是最主流的。它的功能十分丰富,包含服务发现、流量管理、服务到服务以及源到服务的安全性、可观察性(包括遥测和分布式追踪)、滚动发布及韧性机制等。其最新版本易于安装,并提供了控制面板架构,用户体验得到了改善。尽管我们承认维护自己的 Istio 和 Kubernetes 实例,不仅需要足够的知识,还需要一定的内部资源,可能并不适合能力不足的团队,但在我们的诸多项目中,Istio 在保证运维质量的同时,的确降低了大规模微服务的实现门槛。

    历史信息

试验?

  • Anka 是一组辅助 iOS 和 macOS 应用开发的工具,用于创建、管理、分发、构建和测试可复制的 macOS 虚拟环境。它为 macOS 环境带来了类似于 Docker 的体验,包括即时启动,用于管理虚拟机的命令行工具,以及用于对虚拟机进行版本化和打标记以便进行分发的注册表。我们已经使用 Anka 为客户构建了 macOS 私有云。在需要虚拟化 iOS 和 macOS 的环境时,这是一个值得考虑的工具。

    历史信息
  • 在不评判 GitOps 技术的情况下,我们想针对在 Kubernetes 环境中对应用的部署和监控,来讨论 Argo CD。鉴于其能在 Kubernetes 指定的目标环境中,自动将应用部署至所期望的状态,以及在下述方面带给我们的良好体验——排查失效部署的故障原因、验证日志以及监控部署状态,我们建议尝试使用 Argo CD。此外,用户甚至可以通过图表化方式,实时查看集群运行状态、变更如何传播以及 pod 如何被创建和销毁。

    历史信息
  • 大多数需要支持多语言的项目,都始于先以一种语言构建功能,然后再通过电子邮件和电子表格进行离线翻译,来管理其余语言的翻译工作。尽管这种简单的方法可行,但事情很快就会失控。因为接下来,会不得不持续为不同的语言翻译者回答相同的问题,导致翻译者、校对人员和开发团队之间的协作失去活力。在为数不多的几个有助于简化项目本地化工作流程的平台中,Crowdin 是其中之一。使用 Crowdin ,在开发团队持续构建功能的同时,平台可以将需要翻译的文本转变为在线工作流。我们喜欢 Crowdin 能促使团队持续和增量地完成翻译工作,而不是在最后阶段大批量地管理这些工作。

    历史信息
  • 几年来,Linux 内核已经内置 eBPF (extended Berkeley Packet Filter)虚拟机,并提供将eBPF 过滤器挂载到特定套接字(socket)的功能。但是 eBPF 能做的远不止包过滤。它允许以很少的开销,在内核中不同的地方,触发自定义脚本。尽管这不是新技术,但随着容器化部署微服务的流行,其价值逐渐显露出来。在这些系统中,服务到服务的通信可能很复杂,因此很难将延迟或性能问题与 API 调用关联起来。现在一些工具会内置eBPF脚本,用于收集和可视化数据包流量,或报告 CPU 利用率。随着 Kubernetes的兴起, 出现了基于 eBPF 脚本的新一代安全实施和检测工具,以降低大规模微服务部署的复杂性。

    历史信息
  • 谷歌的Firebase自2016年被我们纳入无服务器架构以来,发生了重大的演变。 Firebase 是一个综合性平台,可用于构建移动和Web应用,并运行在谷歌可伸缩基础设施上。我们尤其喜欢 Firebase App Distribution 和 Firebase Remote Config。前者可通过持续部署流水线,轻松发布应用程序的测试版本。而后者可以将配置更改,动态地推送给应用程序,而无须重新发布应用程序。

    历史信息
  • GraphQL 生态系统和社区正不断发展。其中,Hot Chocolate 是用于 .NET(包括 .NET Core 和 .NET Classic)的 GraphQL 服务器。该平台可用于构建和托管 schema,并能使用与 GraphQL 相同的基本组件(数据加载器,解析器,schema,操作和类型)对这些 schema 进行查询。Hot Chocolate 的开发团队最近增添了 schema 拼接功能,允许从单个入口点跨多个 schema(从不同位置聚合而成)进行查询。尽管该功能有被滥用的可能,我们的团队仍对 Hot Chocolate 感到满意,因为它提供了详尽的文档,并且能让我们迅速为客户提供价值。

    历史信息
  • 并非每个人都需要自托管的 OAuth2 解决方案,但若需要,可关注 Hydra。这是一款完全符合规范的开源 OAuth2 服务器及 OpenID connect 提供方。Hydra 具有用于开发环境的内存存储支持,以及用于生产环境的关系数据库(PostgreSQL)。无状态的 Hydra 平台,拥有类似九头蛇海德拉的魔力(在希腊神话中, Hydra 意指九头蛇海德拉。即使斩断它的一颗头,也会生出新的头。与之类似,Hydra 平台中无状态的服务器实例出一旦失效,平台会创建新的实例。——译者注),且易于在 Kubernetes 等平台上进行横向伸缩。根据性能要求,在对 Hydra 实例进行横向伸缩时,需要调整数据库实例的数量。由于 Hydra 并未提供任何开箱即用的身份管理解决方案,所以可以通过一个整洁的 API ,将现有的任何身份管理系统,与 Hydra 集成在一起。这种清晰地将身份管理与 OAuth2 框架其余部分相分离的设计,使 Hydra 与现有身份验证生态系统的集成更加容易。

    历史信息
  • OpenTelemetry 是一个开源可观测性项目,它合并了OpenTracingOpenCensus。OpenTelemetry 项目包含规范、库、代理和其他组件,以便从服务中捕获遥测信息,更好地观察、管理和调试服务。它涵盖了可观测性的三大支柱——分布式跟踪、指标和日志记录(目前处于 beta 测试版),且其规范通过correlations连接这三大支柱。这样就可以使用指标 来查明问题,找到相应的 跟踪 信息,以定位问题,并最终研究相应的 日志 ,以查找确切的根本原因。 OpenTelemetry 组件可以连接到后端可观察性系统,例如 PrometheusJaeger其他 系统。OpenTracing 的形成,是朝着融合标准化与工具简化而迈出的积极一步。

    历史信息
  • 对我们的很多客户来说,Snowflake 已被证明是一个健壮的 SaaS 大数据存储、数仓或数据湖解决方案。它拥有先进的架构,来扩展存储、算力和服务,以加载、卸载和使用数据。它也非常灵活,支持结构化、半结构化和非结构化数据。它为不同的访问模式(如用于数据科学的Spark和用于分析的 SQL),提供相应的 connector(数量正不断增加)。它也能运行在多种云平台上。对许多客户而言,我们建议公共系统(如大数据存储)要使用托管服务。然而,如果出于风险和法规的考虑,无法使用托管服务的话,那么 Snowflake 对于具有大数据量和大处理量的公司,是个不错的选择。我们已经成功地在中型项目中使用了 Snowflake ,但尚未在数据需要跨组织部门存储的大型生态系统中尝试过。

    历史信息

评估?

  • 我们看到了企业云策略的以下转变,即从无意而为的混合云,或从整个云的迁移,转向有意而为且精密复杂的混合云、多云或可移植云。在这种转变中,企业会从多个维度,来建立和执行下述云策略——基于风险、控制能力和性能情况,来决定将在何处托管其各种数据和功能;如何在降低运维成本的同时,充分利用企业内部的基础设施;如何既充分利用多个云提供商及其独特的差异化服务,又不会给构建和运行应用程序的用户带来复杂性和摩擦。

    Anthos 是谷歌针对上述转变而创建的平台。它通过一系列开源技术(例如 GKEService Mesh 和基于 Git 的配置管理系统),为实现混合云和多云策略,提供高级管理和控制平面(plane)。它支持在不同的托管环境(包括 Google Cloud 和本地硬件)上,运行可移植的数据流量和相关功能。尽管其他云提供商拥有类似平台,但 Anthos 打算在支持混合云的基础上更进一步,使用开源组件来让可移植云成为可能(但这还有待观察)。我们看到人们对 Anthos 的兴趣正在上升。尽管谷歌的托管混合云方案看似很有前景,但这并不是灵丹妙药,因为需要对现有云和本地系统进行更改。针对考虑使用 Anthos 的客户,我们的建议是,在 Google Cloud 生态系统的服务和其他选项之间,进行权衡取舍,以保持所选的服务,能得到合理的中立和控制程度。

    历史信息
  • Apache Pulsar是一个开源的 pub-sub (发布-订阅)消息与流媒体平台,与Apache Kafka在同一领域展开竞争。它提供了我们所期望的功能,如低延迟的异步及同步消息传递,可进行容量伸缩的消息持久化存储,以及多种客户端程序库。Pulsar 吸引我们的地方,是能轻易实现容量伸缩,尤其适合在多用户类型的大型组织中使用。Pulsar 原生支持多租户、异地备份、基于角色的访问控制和计费隔离。此外,我们还期望 Pulsar 能解决高容量数据系统中,消息日志无限增长的问题。在这些系统中,事件一旦持久化,就需要无限期地保存,并且订阅者可以从历史节点开始订阅消息。这是通过一个分层存储的模型来实现的。尽管 Pulsar 对于大型组织是一个有前景的平台,但依然有提升的空间。目前,安装 pulsar 需要管理ZooKeeper和BookKeeper以及其他工具。我们期待随着 Pulsar 的日益普及,用户很快能够得到更广泛的社区支持。

    历史信息
  • 自从我们在技术雷达中,对区块链这一领域作出初始评估 以来,该领域技术的性能有了极大的提升。然而,目前仍然没有哪个区块链平台能够达到“互联网级别”的吞吐量。各种区块链平台相继发展,产生了不少新的数据和价值孤岛。这使得区块链社区的关键主题一直是跨链技术。区块链的未来,可能是由若干独立且并行的区块链而组成的网络。这也是Cosmos的愿景。Cosmos 发布了 Tendermint 和 CosmosSDK,以使开发人员可以定制独立的区块链。这些并行的区块链,可以通过 IBC(Inter-Blockchain Communication,区块链间通信协议) 和 Peg Zone 来交换价值。对于 CosmosSDK ,我们的团队拥有丰富的经验。而 IBC 协议正在日趋完善。这种架构可以解决区块链的互操作性和可伸缩性的问题。

    历史信息
  • 通常需要先编写代码将数据带入机器学习模型,才能得出训练和预测结果。而 Google BigQuery ML能将模型带入数据,从而反转了这一模式。 Google BigQuery是一个数据仓库,能针对数据分析场景,使用 SQL 进行大规模查询。Google BigQuery ML 扩展了此功能及其 SQL 接口,通过利用 BigQuery 数据集,来创建、训练和评估机器学习模型,并最终运行模型预测,以创建新的 BigQuery 数据集。Google BigQuery ML 默认支持部分模型,例如用于预测的线性回归(linear regression),或用于分类的二元和多类回归(binary and multiclass regression)。另外,它还能导入已经训练好的TensorFlow模型(但功能有限)。尽管 BigQuery ML 及其基于 SQL 的方式,降低了使用机器学习做出预测和推荐的门槛(尤其针对一些需要快速探索的场景),但导致需要作出艰难的权衡——这种方式不利于模型训练的其他方面,例如道德偏差测试 (ethical-bias-testing),可解释性机器学习的持续交付

    历史信息
  • JupyterLabJupyter 项目的下一代基于 web 的用户操作界面。对于 Jupyter Notebook 的长期用户来说,JupyterLab 也值得一试,因为它提供一个用于 Jupyter Notebook、代码和数据的交互式环境。我们将 JupyterLab 视作 Jupyter Notebook 的一次进化。 JupyterLab 通过扩展其原有功能(允许将代码、可视化和文档存于一处),来提供更好的体验。

    历史信息
  • Marquez 是相对年轻的开源项目,用于数据生态系统中元数据的采集和托管。它使用简单的数据模型,来表现诸如世袭(lineage)、上下游数据处理作业及其状态之类的元数据,并用灵活的标签标记数据集的属性。Marquez 提供了简单的 RESTful API 来管理元数据,从而简化了与数据生态系统中其他工具集的集成。

    我们已将Marquez作为起点,轻松对其进行扩展,以适应需求,例如执行安全策略,并改用其领域语言等。如果需要一个小巧简单的工具,来完成数据处理作业和数据集的存储和可视化,那么 Marquez 是一个很好的开始。

    历史信息
  • Matomo (前身为Piwik)是一款开源的网站分析平台,可以完全控制对分析数据的访问。可以自托管 Matomo ,并保护网站分析数据的安全,防止第三方非授权访问。Matomo 还可以轻松地将网站分析数据与内部数据平台集成,为用户需求量身定制使用模型。

    历史信息
  • MeiliSearch是一个快捷、易用且易部署的文本搜索引擎。多年来,Elasticsearch 在具备容量伸缩特点的文本搜索领域,已成为流行选择。但是,如果数据量不大,无须进行分布式的文本搜索,但仍然想实现一个快捷的容错搜索引擎,那么就建议评估一下MeiliSearch。

    历史信息
  • Ultraleap (前身为 Leap Motion)在XR(Extended Reality,扩展现实)领域一直处于领先地位。它创造了出色的手部跟踪硬件,使用户的手可以融入虚拟现实世界中。Stratos 是 Ultraleap 的底层触觉、传感器和软件平台。它可以使用定向超声波,在空中产生触觉反馈。比如响应驾驶员的手势,以调节车内空调,并在交互界面上实现触觉反馈。看到这项技术,以及富有创造力的技术人员将该技术应用于各种场景,我们十分欣喜。

    历史信息
  • Trillian 是一种可加密验证的集中式数据存储。在去信任化和去中心化的环境中,可以使用基于区块链的分布式账本。然而,在企业应用环境中,当不需要使用会耗费大量CPU资源的共识协议时,建议尝试一下 Trillian。

    历史信息

暂缓?

  • 技术都有被滥用的趋势,尤其是广为流行的技术。比如现在所见到的“Node泛滥”现象,就是一种随意或误用 Node.js 的趋势。其中有两点很突出。首先,我们经常听到这样的说法——应该使用Node,这样只用一种编程语言,就能完成前后端的所有代码。对此,我们还是坚持认为多语言编程是一种更好的方法,尽管我们也将JavaScript作为一等语言。其次,我们经常听到团队将性能作为选择 Node.js 的理由。这种观点已经被大量比较合理的基准数据所否定,但其来源还是有历史原因的。当初, Node.js 变得流行时,还是首个使用非阻塞编程模型的主流框架。该模型让 Node.js 非常适合IO密集型任务(我们在2012年的Node.js文章中提到了这一点)。由于单线程的特点,Node.js 从来就不是计算密集型任务的理想选择。而现在,其他平台已经拥有功能强大的非阻塞框架(其中一些已经配备既优雅又现代的 API )。所以性能已不再是选择 Node.js 的理由。

    历史信息
无法找到需要的信息?

每期技术雷达中的条目都在试图反映我们在过去六个月中的技术洞见,或许你所搜索的内容已经在前几期中出现过。由于我们有太多想要谈论的内容,有时候不得不剔除一些长期没有发生变化的条目。技术雷达来自于我们的主观经验,而非全面的市场分析,所以你可能会找不到自己最在意的技术条目。

新的,移进/移出 ,没有变化