Get 技术领域最新趋势！

本文内容均来自 ThoughtWorks 中国区 CTO、也是技术雷达创建者之一的徐昊与大家分享最新期（第十九期）技术雷达的主题趋势与解读技术雷达的正确姿势 Chat 活动，心急的小伙伴可直接点击文末【阅读原文】链接免费查看。

ThoughtWorks 每年都会出品两期技术雷达，这是一份关于技术趋势的报告，由 ThoughtWorks 技术战略委员会（TAB）经由多番正式讨论给出，它以独特的雷达形式对各类最新技术的成熟度进行评估并给出建议，为从程序员到 CTO 的利益相关者提供参考。

它比那些我们能在市面上见到的其他技术行情和预测报告更加具体、更具可操作性，因为它不仅涉及到新技术大趋势，更有细致到类库和工具的推荐和评论，因此更容易落地。

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

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

本期四大主题

粘性十足的云平台

云提供商知道他们正在严峻的市场中进行竞争。为了获胜，他们需要吸引用户注册并长期留住他们。

因此，为了保持竞争力，他们在新增产品特性上你争我抢，使得彼此不相上下。这一点可以从本期雷达试验环中以下云提供商的排名看出： AWS、 Google Cloud Platform 和 Azure 。

我们鼓励客户使用 架构适应度函数度量成本的技术来监控运维成本，并将其作为衡量云供应商粘性的指标。

在本期雷达中，我们还会介绍两个新的云基础设施自动化工具：Terragrunt 和 Pulumi。

虽然我们支持通过粘性的高低来评估云提供商的新产品，但提醒你不要落入只使用通用云服务功能的陷阱。

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

无论技术如何快速变化，一些企业仍然想方设法地重新实现过去的反模式。雷达中的许多暂缓条目都在揭穿一些“新瓶装旧酒”的老把戏。

因此，上述旧模式就不断重新冒出来。新的架构和工具为解决这些问题提供了适当的方法，但这需要刻意去理解如何正确地使用它们，而不仅仅是使用崭新的技术去重新实现旧模式。

持之以恒的工程实践

随着技术创新步伐加快，新技术的发展呈现出一种从爆发到沉淀不断循环的模式。

在沉淀阶段，我们尝试在新技术的背景下应用实践，比如进行全面的自动化测试以及创建脚本代替重复操作，通常也会创造出新的开发工具。

虽然表面看来技术创新是行业发展的唯一驱动力，但事实上，创新与持之以恒的工程实践相结合才是我们不断进步的基础。

速度 = 距离 / 时间

通常，我们会选取本期雷达中部分共性条目的精彩集锦展现在雷达主题中，但本主题涉及自技术雷达诞生以来出现过的所有条目。我们发现（并通过一些调研证明）雷达条目停留在雷达上的时间正在缩减。

然而正如标题中的公式所说，速度 = 距离 / 时间： 软件开发生态系统中的变化一直在持续加速。在时间保持不变（依然是每年发布两次）的前提下，雷达中技术创新所跨越的距离明显地增大了。

因此我们将改变传统的默认模式：雷达不再默认保留其上的条目，它们是否出现在雷达上完全取决于它们当前的价值。我们在深思熟虑后做出了这项改变，并认为只有这样才能更好地跟上技术生态系统中前所未有的狂热变化节奏。

象限亮点抢先看

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 连接器。目前，我们正在一些项目上使用该平台，并取得了很好的效果。

Resin.io

RESIN.IO 是一个物联网（IoT）平台。虽然只做把容器部署到设备中这一件事，但它做得很好。开发人员使用一个软件即服务（ SaaS）的门户来管理设备，并为这些设备分发由 Dockerfile 定义的应用。

该平台可以为多种硬件类型构建容器，并通过无线的方式部署容器镜像。Resin.io 使用balena 来管理容器。

而 balena 是一个基于 Mobby 框架的容器引擎，由 Docker 出品。该平台仍在开发中，有些功能尚需完善，也缺少一些特性（比如与私有容器注册服务协同工作）。但是目前的特性集（包括从 Web 门户使用

Apache Atlas

随着企业数据需求的不断增长和多样化，对元数据管理的需求也在不断地增长。APACHE ATLAS 是一款用于满足企业数据治理需求的元数据管理框架。

Atlas 支持元数据类型建模、数据资产分类、数据来源追踪和数据发现。但是，在搭建元数据管理平台的时候，我们也必须小心避免重蹈主数据管理的覆辙。

Cypress

运行端到端测试时经常会遇到一些棘手的问题，比如运行时间过长，测试过于零碎，还需要修复无头模式下运行的测试所导致的 CI 失败。

我们的团队借助 CYPRESS 很好地解决了性能差、响应时间长、资源加载慢等常见问题。

Cypress 是一款很有用的工具，可以帮助开发者构建端到端测试，还可以将所有测试步骤保存为 MP4 视频，便于检查错误。

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 ，并对它印象深刻。

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 的技术选型中考虑这一点

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

作者简介：

徐昊，ThoughtWorks 全球技术策略顾问、中国区首席技术官，同时也是北京Java 用户组（BJUG： Beijing Java User Group）和 Agile China 创始人。

他从2003年起开始实践极限编程等敏捷方法，2005年开始，多次以敏捷教练的角色帮助国内外多个团队实施极限编程。

他在Scrum和FDD等敏捷方法、以及敏捷交付和敏捷项目管理等方面的经验极为丰富。

Chat 简介：

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

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

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