有态度的前沿技术解析，第22期技术雷达如约发布！

技术雷达是ThoughtWorks每半年发布一期的技术趋势报告，它不仅是一份持续的技术成熟度评估，其产生还源于ThoughtWorks另一个更大宏大的使命—IT革命。我们一直深信，IT行业从定位、价值、实践和技术都会发生巨大的变革。然而任何宏观的变革，都会有一些微小的信号，我们需要持续关注这些微小的改变，这也就是技术雷达的由来。

技术雷达自2010年创办以来，已经走过10年、累计发布22期。它比那些我们能在市面上见到的其他技术行情和预测报告更加具体、更具可操作性，因为它不仅涉及到新技术大趋势，更有细致到类库和工具的推荐和评论，因此更容易落地。

经过半年的追踪与沉淀，ThoughtWorks TAB（ThoughtWorks技术咨询委员会）根据我们在多个行业中的实践案例，为技术者产出了第22期技术雷达，对百余个技术条目进行分析，阐述它们目前的成熟度，并提供了相应的技术选型建议。

（点击可查看清晰大图）

本期四大主题

Zoom 里的大象

"需求是发明之母"——谚语

随着相关技术缓慢成熟，许多公司已经实践了远程办公的想法。但是非常突然地，一场全球瘟疫大流行迫使全世界的公司迅速从根本上改变了他们的工作方式，以此来保护一些生产力。正如很多人已经注意到，“居家办公”与“在疫情期间被迫居家办公”是截然不同的，并且我们认为在这种新的背景下要实现完全的生产力，前方还会有一段路要走。

所以伴随这一期雷达，你还会拥有一期讨论我们以远程优先的方式制作雷达的体验的播客、一份关于远程优先生产力的建议的报告、一场涉及危机中的技术策略的网络研讨会，还有一些指向其他 ThoughtWorks 材料的链接，包括我们的 Remote Working Playbook 。我们希望这些材料与网络上其他材料一道，帮助组织在这片未知水域中安全航行。

X 也是软件

我们经常鼓励软件交付生态系统中的其他团队，采用敏捷软件开发团队所开拓的、有益的工程实践。但我们也发现这些工程实践在部分领域的应用进展缓慢，所以我们经常讨论这个主题。在本期技术雷达中，我们决定再次强调基础设施即代码以及流水线即代码，并讨论了基础设施配置、机器学习流水线等相关的领域。我们发现，通常负责这些领域的团队并不采用软件设计原则、自动化、持续集成及测试等久经考验的工程实践。我们理解有很多因素都会阻碍部分工程实践的快速发展，如软件（必然和偶然的）复杂性、缺乏知识、政治原因、缺乏合适工具等。但是，组织可以从敏捷软件交付实践中获得的好处也是显而易见的，所以值得为此付出一些努力。

数据视角的成熟和扩展

在本期技术雷达中，关于数据成熟度的主题横跨了多个条目和象限，特别是围绕分析数据和机器学习的技术和工具。我们注意到自然语言处理（NLP）领域中的许多持续创新；我们也欢迎机器学习的全生命周期工具套件的出现和持续发展，将经久不衰的工程实践与迭代中表现良好的工具组合结合起来，表明"机器学习也是软件"。最后，对于像微服务这样的分布式架构，我们看到了对数据网格的极大兴趣，这是一种能在分布式系统中有效地服务和使用大规模分析数据的方法。随着业界更加用心地思考数据在现代系统中的工作方式，我们也为这个领域的总体方向和开放的视角感到欢欣鼓舞，并期待在不久的将来能看到振奋人心的创新。

Kubernetes生态系统的寒武纪爆发

Kubernetes 市场主导地位的持续巩固，必然促成其生态系统的蓬勃发展。我们在工具、平台和技术象限中，围绕 Kubernetes 讨论了若干雷达条目。这表明该主题已无处不在。例如，Lens 和 k9s 简化了集群管理，kind 有助于本地测试，Gloo 则是一种可选的 API 网关。Hydra 是为在 Kubernetes 上运行而优化了的 OAuth 服务器，而 Argo CD 则使用 Kuberenetes 的原生预期状态管理功能，来实现一个持续交付服务器。这些发展表明，围绕Kubernetes 完全可以建立一个支持性的生态系统。Kubernetes 虽然提供了关键功能，但其抽象程度对于大多数用户而言，不是太细碎，就是太高深。为解决这些复杂性，相关工具就应运而生，以简化 Kubernetes 的配置和使用，或提供 Kubernetes 核心功能中所缺失的特性。随着 Kubernetes 继续占据主导地位，我们看到其繁荣的生态系统在不断发展和壮大，并能扬长避短。这个生态系统正日趋成熟，我们希望它会朝着一组新的更高层次的抽象去演化，以发挥 Kubernetes 的优势，而不是给出众多选择，让人莫衷一是。

象限亮点抢先看

将产品管理思维应用于内部平台

越来越多的公司正在构建内部平台，借此快速有效地推出新型数字化解决方案。成功实施这一战略的企业正将产品管理思维应用于内部平台。这意味着与内部消费者（开发团队）建立共情，并在设计上彼此协作。平台的产品经理要建立路线图，确保平台为业务交付价值，为开发者改善体验。不幸的是，我们也见到了一些不太成功的方式，团队在未经验证的假设、没有内部客户的情况下，打造出的平台犹如空中楼阁。这些平台尽管采用了激进的内部策略，但往往无法充分利用，还耗尽了组织的交付能力。和其他产品一样，好的产品管理就是为消费者创造喜爱的产品。

零信任架构

随着资产（数据、功能、基础架构和用户）跨越安全边界（本地主机，多云提供商以及各种SaaS供应商），组织的技术版图正在变得越来越复杂。这就要求企业安全计划和系统架构进行范式转变：从基于信任区和网络配置的静态、缓慢改变的安全策略，转变为基于临时访问权限的动态、细粒度的安全策略。

零信任架构(Zero trust architecture, ZTA)是组织针对其所有资产（设备、基础设施、服务、数据及用户）实施零信任安全原则的策略和流程，以及对最佳实践的践行（包括不论网络位置确保所有访问和通信的安全、强制基于最小权限原则并尽可能细粒度控制的策略即代码、持续监控和自动缓解威胁等）。技术雷达介绍了很多赋能技术，例如安全策略即代码，端点安全边车 和 BeyondCorp。如果准备进一步了解ZTA，请参阅 NIST ZTA 和 Google 在 BeyondProd 上发表的文章，以了解更多关于原则、赋能技术组件及迁移模式的信息。

预检构建

尽管相比 Gitflow 来说，我们强烈推荐 CI，但我们知道直接向主干提交然后在 master 分支上跑 CI，在团队过大的时候是低效的。构建会变慢或不稳定，也可能团队会缺乏在本地运行完整测试集的纪律。在这种情况下，一次红色的构建可以阻塞多名或多对开发者的工作。许多团队通常依赖功能分支来绕过这些问题，而不是解决潜在的根本原因——构建缓慢、不能本地运行测试或迫使许多人在同一位置工作的单体架构。我们不鼓励功能分支，因为它可能需要巨大的努力来解决合并冲突，并且还可能在解决冲突的过程中拉长了反馈周期和引入缺陷。取而代之的是，我们提议使用预检构建作为替代方案：它是基于 Pull Request 的构建，针对只在流水线运行期间存在的为每个commit建立的微型分支。为了自动化这一工作流，我们已经见到了类似 Bors 这样的机器人程序，它将合并 master 分支和删除迷你分支（当构建成功时）的工作自动化。我们正在评估这个流程，你也应该试试看，但请不要用它去解决错误的问题，因为这样的话可能会带来分支滥用，导致弊大于利。

用于业务分析的日志聚合

几年前，出现了新一代的日志聚合平台，该平台能够存储和搜索大量的日志数据，用来发掘运营数据中的趋势和洞见。这种工具有很多，Splunk是其中最著名的。由于这些平台可在整个应用程序范围内提供广泛的运营和安全可见性，因此管理员和开发人员越来越依赖于它们。当干系人发现可以使用“日志聚合进行业务分析”时，他们便开始乐于此道。但是，业务需求可能会很快超越这些工具的灵活性和可用性。旨在提供技术可观察性的日志通常很难对用户有深刻的理解。我们更喜欢使用专门为用户分析而设计的工具和指标，或者采用更具事件驱动性的可观察性方法，其中收集、存储业务和运营事件的方式可以用更多专用工具来重现和处理。

.NET Core

虽然.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，看起来很有前途，我们对此充满期待。

eBPF

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

Cosmos

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

Node泛滥

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

Figma

不论是对设计师，还是多角色团队而言，Figma 都已被证明是协作设计的首选工具。它允许开发人员和其他角色通过浏览器查看和评论设计，而无需使用桌面版本。和它的竞争对手（如Invision 或 Sketch）相比，Figma 将版本控制、协作设计和设计分享这些功能都集中到一个工具上，这使得我们的团队更容易一起想出新点子。我们的团队发现 Figma 十分有用，特别是在开启和促进远程分布式设计工作方面。除了实时设计和协作功能外，Figma 还提供了一个 API 以帮助改善 DesignOps 流程 。

用于机器学习的实验跟踪工具

机器学习的日常工作通常可以归结为一系列的实验，包括选择建模方法和网络拓扑，训练数据以及优化调整模型。数据科学家必须利用经验和直觉来做出一些假设，然后去评估这些假设对模型的整体性能的影响。随着这种实践的成熟，我们的团队发现对“用于机器学习的实验跟踪工具”的需求日益增长。这些工具可以用于帮助研究人员跟踪实验， 从而使这些实验变得更加的有条不紊。尽管这个领域还没有出现明确的赢家，但是已经出现了MLflow 这类的工具以及诸如Comet和Neptune这样的平台，它们使得整个机器学习的工作流程变得更加的严谨和可重复。

Gloo

随着 Kubernetes 和 service mesh 的日益普及，API 网关在云原生分布式系统中一直面临着生存危机。毕竟，许多 API 网关的功能，如流量控制，安全性，路由和可观察性等，现在都是由集群的入口控制器和网格网关提供。Gloo 是一个支持这种变化的轻量级API网关，它使用 Envoy 作为其网关技术，同时为外部用户和应用程序提供附加价值，如 API 的内聚视图等。Gloo 还提供了一套管理界面用于控制 Envoy 网关，并运行和集成了多个服务网格的实现，如 Linkerd，Istio 和 AWS App Mesh。尽管它的开源版本已经提供了 API 网关的基本功能，但它的企业版有一组更成熟的安全控件，如 API 密钥管理， OPA集成等。Gloo 是一个很有前途的轻量级 API 网关。它很好地适应了云原生技术和架构的生态系统，同时避免了在 API 网关中引入业务逻辑以迎合最终用户的陷阱。

Snowpack

Snowpack 是 JavaScript 构建工具领域中的一个有趣的新成员。与其他解决方案相比，Snowpack 的关键的改进是可以使用 React.js，Vue.js 和 Angular 等现代框架来构建应用程序，而无需打包器。由于省去了打包的环节，对代码的任何修改都几乎可以立即显示在浏览器上，因此开发过程中的反馈周期得到了极大的改善。为了达到这个神奇的效果，Snowpack 将 node_modules 中的依赖转换为单个的 JavaScript 文件，并将其放置于一个新的 web_modules 目录中，从这个目录中可以将它们作为 ECMAScript 模块（ESM）导入。对于 IE11 和其他不支持 ESM 的浏览器，它也支持一种变通方法。遗憾的是，目前还没有任何浏览器可以从 JavaScript 中导入 CSS，因此使用 CSS 模块 并不简单。

Karate

基于认为测试是唯一真正重要的 API 规范的经验，我们一直在寻找对测试有帮助的新工具。Karate 是一种 API 测试框架，其独特之处在于它不依赖通用编程语言，而直接使用基于 Gherkin 的语法编写测试。Karate 使用一种领域特定语言，来描述基于HTTP的API测试。我们的团队喜欢 Karate 为 API 规范带来的易读性，并建议将其应用于测试金字塔的较高层次，而非过量应用在细节的断言中。

Koin

随着 Kotlin 被越来越多地用于移动和服务端开发，其相关生态系统也在不断发展。Koin 是一个Kotlin框架，用于处理软件开发中的常规问题之一：依赖注入。尽管有多种 Kotlin 依赖注入框架可供选择，我们的团队更喜欢 Koin 的简单性。Koin 避免使用注解，而是通过构造函数或模仿 Kotlin 的延迟初始化，从而仅在需要时才注入对象。这与 Android 基于静态编译的 Dagger 注入框架形成鲜明对比。我们的开发人员喜欢此框架的轻量级本质及其内置的可测试性。

ERNIE

在上一期技术雷达中，我们加入了BERT—— NLP（Natural Language Processing，自然语言处理） 领域中的一个关键里程碑。去年，百度发布了 ERNIE 2.0（Enhanced Representation through kNowledge IntEgration），它在 7 个 GLUE(General Language Understanding Evaluation) 语言理解任务和全部 9 个中文 NLP 任务上的表现均优于 BERT。和 BERT 一样，ERNIE 也提供了无监督预训练语言模型。它可以通过添加输出层的方法来进行微调，以创建多种 NLP 任务的当前最优模型。ERNIE 与传统预训练方法不同之处在于，它是一个连续的预训练框架。它可以不断地引入各种各样的预训练任务，以帮助模型有效地学习语言表达，而不是仅使用少量的预训练目标进行训练。我们对 NLP 的进步感到非常兴奋，并期待在我们的项目中尝试。

Tailwind CSS

CSS工具和框架提供了预先设计的组件，帮助开发者快速实现想要的页面效果。但是随着开发的进行，它们变得难以定制。Tailwind CSS 提供了一种有趣的方法。为了便于定制，它仅提供了较低层次的CSS样式类来构建模块，且没有自带任何多余的复杂样式。较低层次CSS样式类广泛的覆盖，使开发者不需要编写任何新的样式类或CSS样式。从长远来看，这将产出更易于维护的代码。这样来看 Tailwind CSS 在可重用性和自定义创建可视化组件之间，提供了适当的平衡。