从新一期技术雷达看技术领域最新趋势

ThoughtWorks在每年都会出品两期技术雷达，这是一份关于技术趋势的报告，它比起一些我们能在市面上见到的其他各种技术行情和预测报告，更加具体，更具可操作性，因为它不仅涉及到新技术大趋势，比如云平台和大数据，更有细致到类库和工具的推介和评论，从而更容易落地。

不管你是个人开发者，对于新工具和技术有执着的追求，寄希望于从新工具和技术那里获取改进每日工作的灵感，或者你是技术领导者需要针对自己的系统做技术选型，以及对未来技术趋势的把握，技术雷达都会是一份很好的参考。

在本次分享中，ThoughtWorks中国区CTO、也是技术雷达创建者之一的徐昊将与大家分享最新期（第十九期）技术雷达的主题趋势与解读技术雷达的正确姿势。

ThoughtWorks 每年都会出品两期技术雷达，这是一份关于技术趋势的报告。对于不同层级和水平的技术从业者，可以从不同角度和分类进行解读，因此如何解读技术雷达就是变成一件很有意思的事情。不管你是个人开发者，对于新工具和技术有执着的追求，寄希望于从新工具和技术那里获取改进每日工作的灵感；或者你是技术领导者需要针对自己的系统做技术选型，以及把握未来技术趋势，技术雷达都会是一份很好的参考。

在技术雷达的四个象限（技术、工具、平台、语言 & 框架）中，布满了大量由 ThoughtWorks 技术专家们发现的、可以极大改善开发效率和品质的条目。它们大多数会分布在每个象限的试验和评估区域。这些条目具备创新和极客精神，可以很大程度上改善个人开发者的开发兴趣，保持对于新技术和技能的敏感度。

最新期技术雷达全景图

本文简单介绍了最新一期（Vol.19）技术雷达的四大主题趋势和部分 blip（技术点），在后续的直播中，笔者也会结合本期雷达聊一聊技术领域的最新趋势，以及 ThoughtWorks 在这方面的实践与教训。

粘性十足的云平台

云提供商知道他们正在严峻的市场中进行竞争。为了获胜，他们需要吸引用户注册并长期留住他们。因此，为了保持竞争力，他们在新增产品特性上你争我抢，使得彼此不相上下。这一点可以从本期雷达试验环中以下云提供商的排名看出： AWS、Google Cloud Platform 和 Azure 。

然而，一旦用户注册，这些云提供商就倾向于与用户建立尽可能高的粘性，以阻止他们使用其他提供商的服务。这通常表现为其云服务会与其服务和工具套件紧密集成。用户只有继续使用其云服务，才能获得更好的开发者体验。通常在用户决定是否将其部分或全部工作负载移动到另一朵云上，或发现云服务的使用和账单多到失控时，就能明显感觉到这种粘性。我们鼓励客户使用“架构适应度函数度量成本”的技术来监控运维成本，并将其作为衡量云供应商粘性的指标。或者使用 Kubernetes 和容器，并通过运用基础设施即代码来提升工作负载的可移植性，降低切换到另一个云提供商的成本。

在本期雷达中，我们还会介绍两个新的云基础设施自动化工具：Terragrunt 和 Pulumi。虽然我们支持通过粘性的高低来评估云提供商的新产品，但提醒你不要落入只使用通用云服务功能的陷阱。根据我们的经验，创建和维护与云无关的抽象层的开销，会超出退出某个特定云提供商的花费。

挥之不去的企业级应用反模式

无论技术如何快速变化，一些企业仍然想方设法地重新实现过去的反模式。雷达中的许多暂缓条目都在揭穿一些“新瓶装旧酒”的老把戏。比如：用 Kafka 重新创建 ESB 的反模式、分层式微服务架构、Data-hungry packages、过度庞大的 API 网关、Low-code 平台和一些其他有害的旧实践。一如既往的根本问题，是如何在隔离和耦合之间取得平衡：我们隔离组件，使其在技术角度便于管理。但是我们也需要协调组件，使其有助于解决业务问题。这就产生了某种形式的耦合。因此，上述旧模式就不断重新冒出来。新的架构和工具为解决这些问题提供了适当的方法，但这需要刻意去理解如何正确地使用它们，而不仅仅是使用崭新的技术去重新实现旧模式。

扫描二维码关注公众号，回复： 4248980 查看本文章

持之以恒的工程实践

随着技术创新步伐加快，新技术的发展呈现出一种从爆发到沉淀不断循环的模式。每当能够颠覆我们对软件开发固有认知的新技术出现时，这些新技术都会引起业界的争相追捧，容器化、响应式前端和机器学习都是很好的例子。这时技术处在爆发阶段。

然而，只有在明确如何与长期以来的工程实践（持续交付、测试、协作等）相结合之后，新技术才能真正地发挥功效，并进入沉淀阶段，为下一次爆发性扩张打下坚实的基础。在沉淀阶段，我们尝试在新技术的背景下应用实践，比如进行全面的自动化测试以及创建脚本代替重复操作，通常也会创造出新的开发工具。虽然表面看来技术创新是行业发展的唯一驱动力，但事实上，创新与持之以恒的工程实践相结合才是我们不断进步的基础。

速度 = 距离/时间

通常，我们会选取本期雷达中部分共性条目的精彩集锦展现在雷达主题中，但本主题涉及自技术雷达诞生以来出现过的所有条目。我们发现（并通过一些调研证明）雷达条目停留在雷达上的时间正在缩减。当我们在 10 年前启动技术雷达时，如果某个条目在雷达上的位置不再移动，它依然会保留两期（大约一年）时间，之后才会自动移出雷达。

然而正如标题中的公式所说，速度 = 距离/时间：软件开发生态系统中的变化一直在持续加速。在时间保持不变（依然是每年发布两次）的前提下，雷达中技术创新所跨越的距离明显地增大了。这为精明的读者提供了显著的证据：技术变革的步伐正在不断加快。我们不仅看到雷达中的各个象限在加速变化，也看到了客户对新兴的及多样化的技术选择所表现出的兴趣。因此我们将改变传统的默认模式：雷达不再默认保留其上的条目，它们是否出现在雷达上完全取决于它们当前的价值。我们在深思熟虑后做出了这项改变，并认为只有这样才能更好地跟上技术生态系统中前所未有的狂热变化节奏。

部分亮点抢先看

Event Storming（事件风暴）

快速市场响应能力是组织进行微服务转型的主要驱动之一。然而只有沿长期业务领域边界对服务（及其支持团队）进行清晰划分时，这种期望才可能实现。否则，现实需求只有在跨组织和跨服务的通力合作才下能完成，这自然会在规划产品路线图时产生冲突。良好的领域模型设计是解决此问题的方案，事件风暴（Event Storming）也迅速成为我们最喜爱的方法之一，它使我们能够迅速识别问题领域中的关键概念，并用最好的方式与各方利益相关人制定解决方案。

Microservice Envy

微服务已成为现代云计算系统中的领先的架构模式，但我们依旧认为团队在使用该架构时应谨慎。 Microservice Envy 特指那些盲目追赶微服务潮流的现象，很多团队在实践微服务时并没有简化其系统架构，大多数的实践方案只是将一些简单的服务聚合在一起而已。目前，Kubernetes 等平台简化了复杂的微服务系统的部署问题，其他服务提供商们也正在推进他们的微服务治理方案，这些强大的工具都可能裹挟团队走上微服务之路。但请千万谨记，微服务是通过开发复杂度来换取运维复杂度，并需要自动化测试、持续交付和 DevOps 文化提供坚实的支撑。

Observability as Code（可观测性即代码）

可观测性是运转分布式系统与微服务架构必不可少的一部分。我们依赖不同的系统输出来推断分布式组件的内部状态，比如分布式追踪、日志聚合、系统指标等，进而诊断问题所在，并找到根本原因。可观测性生态系统的一个重要方面就是监控——可视化以及分析系统的输出——并且在检测到异常时报警。传统的监控报警配置，都是通过图形界面的操作完成。这种方法导致控制面板页的配置不可重复，从而无法持续测试和调整报警，来避免报警疲劳或错过重要的报警，进而偏离组织的最佳实践。

我们强烈建议使用代码来配置可观测性生态系统，称为可观测性即代码（Observability as Code），并且采取基础设施即代码的方式搭建其基础设施。因此，在选择提供可观测性的工具时，要选择支持通过代码版本控制进行配置，并能通过基础设施持续交付流水线执行 API 或命令行的产品。可观测性即代码，是基础设施即代码中经常被遗漏的一部分，我们认为这一点非常重要，需要明确指出。

Four key metrics（四个关键指标）

2014 年首次发布的 DevOps 状态报告指出，高效团队创造了高效的组织。最近，该报告背后的团队编写了 Accelerate 一书，描述了他们在报告中使用的科学方法。两份材料的核心点都支持了软件交付性能的四个关键指标（Four key metrics）：前置时间、部署频率、平均恢复时间（MTTR）和变更失败百分比。作为帮助许多组织转型的咨询公司，反复使用这些指标测量，可以帮助组织确定他们是否在提高整体效能。每个指标都创造了一个良性循环，并使团队专注于持续改进：缩短交付周期，减少浪费的活动，从而使你可以更频繁地部署；部署频率迫使你的团队改进他们的实践和自动化流程；通过更好的实践，自动化和监控可以提高你从故障中恢复的速度，从而降低故障频率。

Run cost as architecture fitness function（架构适应度函数）

随着软件架构及其业务的演进，我们理应密切关注应用的运行成本，但发现并非所有的组织都如此。尤其是在使用无服务器架构时，开发者们认为无服务器架构会更便宜，因为他们只需按消耗的计算时间付费。然而几家主要的云服务提供商在热门的无服务器函数上定价十分精明，虽然无服务器在快速迭代上很有优势，但与专属云（或内部私有云）相比，它的开销可能随着使用量迅速增长。我们建议团队将应用的运行成本纳入架构适应度函数（Run cost as architecture fitness function）来考量，这意味着：追踪并权衡应用的运行成本与交付价值；当它们之间产生较大出入时，就需要考虑改进软件架构了。

Debezium

Debezium 是一个 Change Data Capture（CDC）平台，可以将数据库的变更以流的形式传入 Kafka 主题中。CDC 是一种流行的技术，具有多个使用场景，包括将数据复制到其他数据库中，为分析系统提供数据，从单块系统中提取微服务，以及令缓存数据无效等。我们一直在寻找这个领域的工具或平台（包括在之前的技术雷达中讨论过的 Bottled Water），而 Debezium 是一个极佳的选择。它使用了基于日志的 CDC 方法，意味着能以对数据库日志文件的变更响应的方式进行工作。Debezium 使用了 Kafka 连接，这使得它具有高度的容量伸缩性，以及对故障的系统韧性。它拥有包括 Postgres、MySQL 和 MongoDB 在内的多个数据库的 CDC 连接器。目前，我们正在一些项目上使用该平台，并取得了很好的效果。

Quorum

在区块链技术领域，Ethereum（以太坊）是一个领先的开发者生态系统。我们看到了一些新兴的解决方案，它们旨在将 Ethereum 这项技术传播到一些企业环境中。这些企业通常需要网络权限和交易隐私管理，另外还需要更高的吞吐量和更低的延迟。Quorum 就是其中的一个解决方案。

Quorum 最初由 J.P. Morgan 开发，其定位是“企业版的 Ethereum”。与创建了新的以太坊虚拟机（EVM）的 Hyperledger Burrow 节点不同，Quorum 的代码源自以太坊官方客户端的一个分支，所以能与以太坊一起进化。在保留了以太坊账本的大多数功能的前提下，Quorum 将共识协议从工作量证明机制更改为更高效的协议，并增加了私有交易支持。使用 Quorum，开发人员可以使用他们的以太坊知识来构建企业级的区块链应用，这些知识包括 Solidity 语言和 Truffle 合约。然而根据我们的经验，Quorum 还没有为应用于企业做好充足的准备，比如：它缺乏针对私有合约的访问控制机制，无法用于负载均衡，并且只支持部分数据库。所有的这些限制都为用户的部署与设计带来显著的负担。我们建议在使用 Quorum 的时候保持警惕，同时密切关注它的后续发展。

IPFS

在多数情况下，区块链不适合存储 BLOB 文件（如图像、音频），当人们开发 DApp 时，一种选择是将 BLOB 文件存放在一些链下的集中式数据存储中，这种做法通常会导致信任缺失；另一种选择是将它们存储在星际文件系统 IPFS 上，这是一种内容可寻址、版本化、点对点的文件系统。它旨在高效地分发大规模数据，并能阻止任何中心化机构删除数据，文件存储在不需要相互信任的对等节点上。IPFS 保存文件的每一个版本，这样你将永远不会丢失重要文件，我们将 IPFS 视为区块链技术的好的补充。除了区块链应用程序外，IPFS 还有一个愿景是对现有的网络基础设施进行去中心化重塑。

Resin.io

Resin.io 是一个物联网（IoT）平台。虽然只做了把容器部署到设备中这一件事，但它做得很好。开发人员使用一个软件即服务（ SaaS）的门户来管理设备，并为这些设备分发由 Dockerfile 定义的应用。该平台可以为多种硬件类型构建容器，并通过无线的方式部署容器镜像。Resin.io 使用 balena 来管理容器。而 balena 是一个基于 Mobby 框架的容器引擎，由 Docker 出品。该平台仍在开发中，有些功能尚需完善，也缺少一些特性（比如与私有容器注册服务协同工作）。但是目前的特性集 (包括从 Web 门户使用 SSH 访问一个设备上的容器) 表明了它的未来充满希望。

Knative

作为应用开发者，我们喜欢专心解决核心业务问题，而让底层平台来处理那些枯燥且困难的任务（如部署、容量伸缩及应用程序管理）。虽然无服务器架构往这个方向迈出了一步，然而大多数流行的产品都会与某个专有实现绑在一起。而这意味着供应商绑定。Knative 试图以开源无服务器平台的方式来解决此问题。它良好地集成了流行的 Kubernetes 生态系统。利用 Knative，可以对随时请求的计算进行建模（其间可以从一些框架中进行选择，如 Ruby on Rails、Django 和 Spring 等），可以订阅、交付和管理事件，可以集成用户所熟悉的 CI 和 CD 工具，可以从源代码构建出容器。该平台提供一组中间件组件，来构建以源代码为中心且基于容器（能够实现资源伸缩性）的应用。这使得它成为一个颇有吸引力的平台，当有无服务器需求时，值得对其进行评估。

Apache Atlas

随着企业数据需求的不断增长和多样化，对元数据管理的需求也在不断地增长。Apache Atlas 是一款用于满足企业数据治理需求的元数据管理框架。Atlas 支持元数据类型建模、数据资产分类、数据来源追踪和数据发现。但是，在搭建元数据管理平台的时候，我们也必须小心避免重蹈主数据管理的覆辙。

Cypress

运行端到端测试时经常会遇到一些棘手的问题，比如运行时间过长、测试过于零碎，还需要修复无头模式下运行的测试所导致的 CI 失败。我们的团队借助 Cypress 很好地解决了性能差、响应时间长、资源加载慢等常见问题。Cypress 是一款很有用的工具，可以帮助开发者构建端到端测试，还可以将所有测试步骤保存为 MP4 视频，便于检查错误。

VS Live Share

Visual Studio Code 是微软推出的免费 IDE 编辑器，可以跨平台使用。我们曾用它同时进行前端 React、TypeScript 和后端 GoLang 的开发，而无需在不同的编辑器之间切换，体验很好。Visual Studio Code 中的工具、语言支持和扩展插件数量都在迅猛增长，也越来越好用。我们要特别推荐在实时协作及远程结对编程时使用 VS Live Share。固然微软或 JetBrains 成熟的 IDE 对使用静态类型语言（如 Java 、.NET 或 C++ ）的复杂项目支持得更好，但我们也发现 Visual Studio Code 正逐渐成为基础设施开发组和前端开发组的首选工具。

Stanford CoreNLP

越来越多的项目需要处理非结构化的数据，而从文本中提取出有意义的业务信息是一项关键技术。Stanford CoreNLP 是一组基于 Java 的自然语言处理（NLP）工具集，支持英语、汉语和阿拉伯语等多种语言的命名实体识别、关系抽取、情感分析与文本分类，也提供了用于标记语料库和训练模型的工具。 Stanford CoreNLP 协助我们使用 NLP 领域的最新研究成果来解决各种业务问题。

LocalStack

使用云服务时面对的一个挑战是如何在本地进行开发和测试。 LocalStack 为 AWS 解决了这个问题。它提供了各种 AWS 服务的本地测试替身实现，包括 S3、Kinesis、Dynamodb 和 Lambda 等。它基于现有的最佳工具如 Kinesalite、Dynalite、Moto 等构建，并增加了进程隔离与错误注入的功能。 LocalStack 的使用很简单，并附带了一个简单的 JUnit 运行器以及 JUnit 5 扩展。我们在一些项目中使用过 LocalStack，并对它印象深刻。

Bitrise

构建、测试和部署移动应用，尤其是由一条流水线从代码仓库打通到应用商店的时候，会涉及许多复杂的步骤。虽然这些步骤可以由脚本或普通 CI/CD 工具提供的流水线自动完成，但对于专注移动应用开发，而不需要与后端的构建流水线做集成的小组来说，使用专用工具可以降低复杂度和维护开销。Bitrise 配置简单，并预置了一组完整的步骤，可以满足绝大多数移动应用开发所需。

PredictionIO

PredictionIO 是开源的机器学习服务框架。无论是普通开发者还是数据科学家，都可以利用它创建用于预测的智能应用。和所有其他智能应用类似，PredictionIO 由三个部分组成：数据收集和存储、模型训练、模型部署和服务暴露。开发者只需要基于它提供的相应接口实现数据处理逻辑、模型算法和预测逻辑，无需在诸如存储数据以及训练模型之类的事情上投入额外精力。从我们的经验来看，在不要求高并发处理的情况下，PredictionIO 能支持不同大小的数据集。大多数时候我们使用 PredictionIO 来为中小企业构建预测类智能服务，或者在构建复杂定制化预测引擎的过程中进行概念验证。

`Q#`

量子计算目前已经可供测试，但何时真正到来尚未明确。在硬件到位之前，我们已经可以通过语言和模拟器来实验和学习它。尽管 IBM 等公司已经取得了不错的进展，我们对微软在 Q# 语言及其模拟器（本地 32 量子比特，Azure 云上 40 量子比特）方面的工作更加关注。如果你想开始了解这项编程的前景，请查看他们在 GitHub 上的范例。

MockK

MockK 是用 Kotlin 编写的模拟库。它的核心理念是像 Coroutines 和 Lambda 表达式一样，为 Kotlin 提供一等公民级别的语言特性支持。不同于 Mockito 或 PowerMock 的蹩脚封装，作为原生的开发库，它能帮助开发团队在测试 Kotlin 应用时编写干净、简洁的代码。

WebFlux

Spring Framework 5 已发布一年有余，它采用了响应式流——一套非阻塞背压（Backpressure）式异步流式处理标准。在传统的 Spring MVC 模块之外，WebFlux 为在 Spring 生态下编写 Web 应用提供了一个响应式替代品。经过一系列应用的试用，WebFlux 给我们团队留下了深刻的印象，这种响应式（函数式）实现增强了代码的可读性和系统的吞吐量。但我们也确实注意到，采用 WebFlux 需要在思维方式上做出一些重大转变，建议在 WebFlux vs. Spring MVC 的技术选型中考虑这一点。

Jepsen

随着微服务架构越来越多被采用，相比以前，我们构建了更多的分布式应用程序。尽管解耦架构带来了许多好处，但证明整个系统正确性所需的工作量和复杂程度正急剧增加。Jepsen 提供了许多我们所需要的工具，来帮助我们验证协调任务调度程序的正确性，以及测试分布式数据库的最终一致性、线性一致性（ Linearizability）、可串行性（Serializability）。我们在一些项目中使用了 Jepsen，令人惊喜的是，我们可以测试驱动配置，注入和修复故障，验证系统恢复后的状态。

以上是从最新期技术雷达中随机摘取的几个 blip，这里有完整版《Technology Radar 技术雷达》，可以提前一探。剩下的内容我们直播再聊～