技术雷达是Thoughtworks每半年发布一次的技术趋势报告，它持续追踪有趣的技术是如何发展的，我们将其称之为条目。技术雷达使用象限和环对其进行分类，不同象限代表不同种类的技术，而环则代表我们对其作出的成熟度评估。
经过半年的追踪与沉淀，Thoughtworks TAB（Thoughtworks技术咨询委员会）根据我们在多个行业中的实践案例，为技术者产出了第25期技术雷达。对百余个技术条目进行分析，阐述它们目前的成熟度，并提供了相应的技术选型建议。
一、本期主题
适配到Kafka，还是改编自Kafka
本期技术雷达的许多话题（其中一些并没有进入本期最终版本），都是有关我们团队正在使用工具，来适配到Kafka，或改编自Kafka。其中一些工具允许使用更传统的kafka接口（例如ksqlDB、Confluent Kafka REST Proxy 和 Nakadi），而另一些则旨在提供额外的服务，如GUI前端界面和编排插件。我们猜测，存在大量这类工具的部分重要原因，来自Kafka某些组件深层的复杂性。组织越发需要及时改编Kafka，来适应现有的架构和流程。一些团队最终将Kafka作为下一代企业级服务总线 ，而这正是“便利背后的陷阱”主题的一个例证。但另一些团队则使用kafka来全局性地访问所发生的业务事件。后者认识到，有时使用集中式的基础设施，能更容易地适应业务的复杂性。所以他们会通过仔细的设计和治理，来避免复杂性的蔓延。无论怎样，这些都表明Kafka会成为异步发布/订阅大批量消息事实上的标准。
便利背后的陷阱
下面这个软件开发的反模式，在技术雷达诞生之初就已经存在了——开发团队一般为了图方便，而在其技术生态系统的复杂环节中，引入一些不合理的行为，从而欠下长期存在的技术债务，并会引发更糟的问题。这种例子不胜枚举，包括将数据库作为集成点，使用 Kafka 作为全局编排器，以及将业务逻辑代码混杂到基础设施代码中。现代软件开发为开发人员提供了许多隐藏上述不当行为的场所，这样缺乏经验或考虑不周的团队，经常因为没有仔细考虑不当耦合的长期后果，而陷入困境。不适当的团队结构和对康威定律的偏离，也让问题雪上加霜。随着软件系统变得越来越复杂，开发团队必须勤于创建与维护经过深思熟虑的架构和设计，而不是为了图方便而做出草率的决定。通常，考虑特定方法的可测试性，会使团队降低做出有问题决策的机会。如果不加合理设计，软件会逐渐趋于复杂。精心设计，加上更为重要的持续治理，可以确保进度压力或其他众多破坏力，不会导致团队为图一时之便而做出不正确的决策。
康威定律仍然有效
许多架构师会引用康威定律——来自1960 年代的观察：团队的沟通结构会影响到软件的设计，以证明团队组织的变化是合理的。我们对本期技术雷达中提名的几个条目的发现是，组织的团队结构在处理得当时，仍然是一个关键的推动因素，而在处理得不好时，则会变成严重的障碍。我们讨论的例子包括需要围绕平台团队进行产品思考，而不是将他们视为办公室文员；涉及效能的 团队拓扑 以及得到越来越多认可的团队认知负载 ；以及围绕程序员生产力而开发的新框架 SPACE。组织在工具上花费了大量资金，但许多组织通过关注构建软件的人，以及能让他们在特定组织内变得更高效的原因，发现了更好的生产力提升。
避免过度使用巧妙的技术
许多软件界人士都欣赏针对复杂问题的巧妙解法，但其实这些巧妙的解决方案往往都源于其自身引入的偶然复杂度。这种现象有很多例子。一种不幸但常见的实践是将用于编排或协调的代码藏到不合适的地方。例如，过度应用 Airflow、Prefect 等灵巧的工作流管理工具，以编排的方式管理复杂的数据流水线。也有很多 Nx 这样的工具用于解决单体式代码库导致的问题。团队通常不会意识到，这只是在两倍、三倍地增加偶然复杂度，而不会退后一步审视全局，想想当前的解决方案会不会比问题本身更糟糕。与其使用更多技术来解决问题，团队更应该分析根因，解决潜藏的本质复杂度并不断改进。例如数据网格就解决了关于组织及技术的基本假设，这些假设通常会导致过度复杂的数据流水线及工具。
雷达中平台相关条目变少
本期雷达中和平台相关的条目明显减少了，我们将其归因于一些行业标准的整合：大多数公司已经选择好了云供应商，他们几乎都基于 Kubernetes 和 Kafka 实现了容器编排和高性能消息系统的标准化。这是否意味着平台不再重要？或者说，我们是否正在经历一个盛衰周期？举个类似的例子，在数据库的发展史中，我们已经见证了一些飞速创新然后发展停滞的周期（如同 Stephen J. Gould 提出的“间断平衡”理论）。随着企业大规模地完成云迁移，行业或许已经进入了相对冷静期，等待着下一波颠覆式创新浪潮的到来。
二、部分象限亮点抢先看
交付核心四指标
采纳
为了度量软件交付的效能，越来越多的组织开始采用由 DORA 研究项目定义的交付核心四指标，即：更改前置时间、部署频率、平均修复时间（ MTTR ）和变更失败率。这项研究及其统计分析展示了高效能交付团队和这些指标的高度相关性，它们为衡量一个团队、甚至整个交付组织的表现提供了极佳的领先指标。
虽然我们仍是这些指标的支持者，但自从我们最早开始监控它们以来，也得到了一些教训。我们也持续看到被误导的度量方式，这些方式使用的工具仅基于持续交付（ CD ）流水线。在衡量稳定性指标（ MTTR 和更改失败百分比）时，仅依赖 CD 流水线数据提供的信息并不足以确定部署失败对真实用户的影响。 只有包含真实事故（如用户服务降级）的数据时，稳定性指标才有意义。
与其它所有指标一样，我们建议始终牢记度量这些指标的终极目的，并使用它们反复思考和学习。例如，在花费数周时间构建复杂仪表板工具之前，可以考虑定期在团队回顾会议当中进行 DORA 快速检查。这样的做法能够使团队有机会思考哪些能力应被提升以改进这些指标，这比过于详细的开箱即用工具更有效。
CBOR/JSON 双重协议
试验
尽管 CBOR 协议并不是什么新鲜事物，然而我们发现越来越多的数据交换场景都在使用它，尤其是在多种类型的应用程序需要互相通信的时候，比如服务与服务之间、浏览器与服务之间等等。Borer 是 CBOR 编码器/解码器的 Scala 实现，它允许互相通信的两端通过协商自由选择二进制或者传统 JSON 作为消息格式，这一点我们认为非常有用。同样的消息，既能够以普通文本在浏览器里显示，又能够表示为精简高效的二进制，这是非常实用的特性。在未来，随着物联网、边缘计算以及其他受限环境计算的逐渐兴起，我们认为 CBOR/JSON 混合协议会更加流行。
Comby
评估
本期技术雷达引入了两款使用抽象语法树表示进行搜索和替换代码的工具。它们与jscodeshift有相似的定位，但包含适用于多种编程语言的解析器。尽管它们有一些相似之处，但它们在某些方面还是有所不同。其中Comby工具的独特之处，在于其简单的命令行界面，该命令行界面是根据awk和sed等Unix工具的精神设计的。虽然 Unix 命令基于操作匹配文本的正则表达式，但 Comby 使用特定于编程语言结构的模式语法，并在搜索之前解析代码。这有助于开发人员在大型代码库中搜索结构模式。和sed一样，Comby 可以用新的结构替换它匹配的模式。这对于大型代码库进行自动批量更改，或在一组微服务存储库中进行重复更改非常有用。由于这些工具相当新，我们希望看到一系列尚未发现的创造性用途。
Vite
评估
快速反馈是优质开发体验的关键。代码更改后，得到反馈前等待的一两分钟可谓最影响开发流程的。可惜随着应用规模和复杂性的增长，流行的前端构建工具大多已经不够快了。之前我们介绍了esbuild，它通过编译为本机语言而非JavaScript来实现，显著地改善了性能。Vite基于esbuild构建，相比其他工具带来了重大改进。它主要由两个部分组成：一个开发服务器，基于原生ES模块提供了丰富的内建功能，如极快的模块热更新（HMR）；以及一套构建指令，它使用Rollup打包你的代码。不同于大多数旧工具，Vite依赖于ES模块，它不提供shim和polyfills，这表示它不兼容那些不支持ES模块的旧浏览器。如果要支持旧浏览器，我们部分团队会在开发时使用Vite，而生产构建时使用其他工具。
Konga
评估
用来管理 Kong API网关 的Konga，是一个开源UI平台。它曾在往期技术雷达中位于试验环。我们的团队喜欢它快捷的配置和丰富的功能，因为这可以使团队能轻松地试验和试用配置。另外它是开源的，这使团队不必担心软件使用许可成本。
GitHub Actions
试验
虽然曾在技术雷达中提出慎用的建议，但我们依然看到了用户对于GitHub Actions的持续热情。尽管如此，之前的建议依然有效——对于复杂工作流来说，GitHub Actions还不算成熟的CI/CD工具。例如，它不能重新触发工作流中单独的一个job，不能在composite action中调用其他的action，也不支持共享库。另外，虽然GitHub Marketplace 生态圈具备显著的优势，但让第三方的Github Actions访问自己的构建流水线，会带来以不安全的方式共享机密的风险（我们建议遵循GitHub 的安全加固建议）。尽管有种种顾虑，但在GitHub源代码旁直接创建构建工作流的便利性，对很多团队还是有着不小的吸引力。另外，还可以使用act 在本地运行Github Actions。和以前一样，我们建议审慎地权衡Github Actions的优缺点。但我们的很多团队还是非常喜欢它的简单性。
ClickHouse
试验
ClickHouse 是用于实时分析的开源柱状在线分析处理（OLAP）数据库。它起始于2009年的一个实验项目。从那以后，它已经发展成一个高性能且可线性扩展的分析数据库。它兼备高效查询处理引擎和数据压缩功能，使其适合在不进行预聚合的情况下，运行交互式查询。我们已经使用过ClickHouse，并且对它的高性能印象深刻。
lifelines
试验
lifelines 是一个用 Python 编写的进行生存分析的库。它最初是为出生和死亡事件而开发的，现在已演变成一个用来预测任何持续时间的完整的生存分析库。除了医疗使用案例（例如用来回答：这个人能活多久？），我们也已经在零售和制造业中用它来回答类似 用户对一个服务订阅了多久？ 或我们应该什么时候做下一个预防性的维护？这样的问题。
Three.js
试验
我们第一次提到 Three.js 是2017年，在雷达的“评估”环上。在这之后，这个 web 3D 渲染库得到了快速的改进和发展。随着 WebGL API 标准的改进，以及对 WebXR 的支持，Three.js成为了一个可以用来营造沉浸式体验的工具。与此同时，浏览器对 3D 渲染和 WebXR 设备 API 的支持也得到提升，使得 web 成为一个越来越有吸引力的 3D 内容平台。尽管还有别的 3D 渲染库，我们团队还是更喜欢 Three.js，特别是和 react-three-fiber 一起用的时候，能抽象掉一些底层细节。不过，开发者仍然需要注意性能问题，有时还需要重构数据来优化渲染速度。
以上是我们在最新一期技术雷达中随机摘取的几个Blip，欲获取整版技术雷达，请点击此处进行查看或下载
