为什么程序员一定要关注技术趋势？

十年前，数据几乎等同于关系数据库。如今，数据则可能呈现出各种形态，包括 NoSQL、时间序列、像 CockRoachDB 和 Spanner 这样提供全局一致性的 SQL 存储，以及提供聚合日志文件查询功能的事件流。随着数据源不断增长，数据规模越来越大，种类越来越多，变化速度越来越快，企业想要对这些数据做出更实时的响应，上述情况也就应运而生了。对于开发人员，每种形式的数据使用方法都存在固有的优缺点，如何取舍是个难题。架构师和开发人员应该密切关注各种工具和模型提供的新功能，同时保持勤奋好学，不要完全以对待现有工具的常用方法来使用新工具。我们必须认识到数据形势正在发生重大变革，并坚持寻找合适的策略和工具。

开发人员喜欢抽象层，原因很明显，因为他们可以将复杂问题封装到抽象层中，从而集中精力处理更高层级的问题。在前几期的技术雷达中，我们都阐述了这种发展趋势，很多团队在同时使用云和容器时都会采用这种方法。一开始他们关注的是 Docker 及其生态系统。然后焦点开始转向 Kubernetes。现在，我们发现主要活动总体上都集中在基础设施即代码方面，尤其是集中在 Terraform 生态系统上。虽然除了 Terraform，我们还推荐了其他工具，但是它在提供商社区中的采用率仍然让人印象深刻。本期雷达的内容重点包括 Terratest（用于测试基础设施代码），以及 GoCD 的新提供商（可以使用 Terraform 配置 GoCD）。

Kotlin 作为一项开源语言，不仅在 Android 环境中获得了广泛应用，而且还在向其他环境拓展，也在技术雷达中受到了持续密切的关注。由于不喜欢现有的语言选择，JetBrains 在内部开发了 Kotlin，并随后开源。Kotlin 似乎在各种开发人员中广受欢迎。它经常在各种平台和工具中用作通用甚至专用开发语言，而且在技术雷达中出现的频率也越来越高。此外，我们的项目团队也在采用该语言（Ktor、MockK、Detekt、HTTP4K）。这个新兴语言在实用性设计和先进工具中获得了广泛应用，并且形成了一个蓬勃发展的生态系统，取得了巨大的成功，对此我们深感欣慰。

随着“一切即代码”理念的盛行，以前难以改变的绝大多数环节（基础设施、安全、合规性和运营），几乎都变得可以通过编程来处理，这就意味着开发人员可以采用更完善的工程实践。然而，我们仍然经常看到，要么配置子系统异常复杂，要么过度依赖于可视化编排工具，逻辑渗透到配置文件中，以 YAML 编写的条件语法晦涩复杂，还有各种技术需要使用大量编排框架等情况。随着多语言编程、基础设施即代码和一切皆服务技术的出现，我们不再需要将各种组件都组合到单一内聚的系统中。因此，原本应位于系统边界内的逻辑就会泄漏到编排工具、配置文件和其他管道中。虽然有时候确有这种必要，但是我们建议各团队保持谨慎，考虑将此类代码放在开发人员执行测试、版本控制、持续集成和其他完善的工程实践的位置。请避免将业务逻辑放在配置文件中（并且避免使用要求将业务逻辑放在配置文件中的工具），尽可能减少必须执行的编排操作，不要让编排功能主导你的系统。

详尽的 DevOps 现状报告侧重于对高绩效组织的数据驱动型统计分析。这项研究持续多年，结果发表在 Accelerate，证明了组织绩效和软件交付效能之间存在直接关联。研究人员证实，只需四个关键指标就能区分低绩效、中绩效和高绩效人员：前置时间、部署频率、平均修复时间 (MTTR) 和变更失败率。的确，我们已经发现这四个关键指标（Four key metrics）是个简单却强大的工具，可帮助领导和团队专注于衡量并改进重要的环节。实施构建流水线是一个良好开端，以便你能够捕获四个关键指标，并使软件交付价值流可见。例如，作为 GoCD Analytics 的一等公民，GoCD 流水线能够衡量这四个关键指标。

机器学习的持续交付 (CD4ML) 模型（Continuous delivery for machine learning -CD4ML models），将持续交付实践应用于开发机器学习模型上，以便于随时应用在生产环境中。该方法解决了传统机器学习模型开发的两个主要问题：一个是训练模型和将模型部署到生产环境之间的周期过长，此过程通常包括将模型手动转换为可上线的代码；另一个问题是使用被过时数据训练过的产品环境模型。

机器学习模型的持续交付流水线有两个触发因素：(1) 模型结构的变动；(2) 训练与测试数据集的变动。要使其发挥作用，我们需要对数据集和模型源代码进行版本化。流水线通常包括用测试数据集来测试模型、按需使用 H2O 等工具来对模型作自动转换、以及将模型部署到生产环境以交付价值。

作为 ThoughtWorks 的开发人员，我们对于工作中可能涉及到的道德问题十分敏感。随着社会对科技的依赖程度日益增长，软件开发团队在制定决策时必须考虑道德问题。目前已经出现的一些工具，可以帮助我们思考自己所构建的软件会在未来产生什么影响。此类工具包括技术塔罗牌和道德风险手册（Ethical OS），这两类工具都获得了广泛好评。道德风险手册为我们提供了一个思维框架和一系列工具，可以促进我们围绕软件构建方面存在的道德问题展开讨论。该手册由 Institute of the Future（未来研究所）和科技与社会解决方案实验室（Tech and Society Solutions Lab）联合编制。其中探讨了一系列切实的风险，例如网瘾、多巴胺经济，而且还分析了很多值得探讨的场景。

我们在使用分布式账本技术 (DLTs) 方面积累的经验越多，遇到的当前智能合约（Smart contracts ）未完善之处就越多。从理论上来看，在账本上自动添加不可否认、不可逆的合约是个好主意。但如果在你考虑如何使用现代化软件交付技术来开发它们，以及出现实施方式之间的差异时，问题就出现了。不可变数据是一回事，但不可变业务逻辑则完全是另外一回事！一定要想清楚是否在智能合约中包含逻辑，这一点真的非常重要。我们已经发现，不同的实施方式之间存在截然不同的运营特征。例如，即使合约可以演变，不同平台对这种演变的支持程度也不一样。我们的建议是，在智能合约中加入业务逻辑之前，请认真考虑，并权衡不同平台的利弊。

我们已亲眼见证，组织通过使用版本火车（Release train）概念，从极低的发布频率成功转向更高频率。版本火车是一种用于协调跨多个团队或具有运行时依赖性组件的发布技术。无论所有预期功能是否已准备就绪，所有版本根据一个固定且可靠的时间表发布（火车不会等你，如果错过，就只能等下一趟了）。虽然我们完全支持关于定期发布和演示可用软件的纪律性，但从中长期来看，我们发现该方法存在一些严重缺陷，因为该方法会增加有关变更排序的临时耦合，而且如果团队赶着在给定时间范围内完工，质量可能会降低。我们更倾向于关注在必要的架构与组织的方法，来支持独立发布。虽然火车对于提升较慢团队的速度非常有用，但我们也看到它给快速团队带来了上限。所以我们认为，在使用该技术时，应尽量小心谨慎。

以太坊虚拟机 (EVM) 最初是为以太坊主网络设计的。但如今，大多数团队不再想要从头开始发明区块链；相反，他们会选择“超越以太坊的 EVM（EVM beyond Ethereum ）”。我们看到众多区块链团队选择对以太坊进行分支（如 Quorum）或实现 EVM 规范（如 Burrow、Pantheon），并添加他们自己的设计。这样做不仅是为了重用以太坊的设计，还可以利用其生态系统和开发人员社区。对于许多开发人员而言，“智能合约”的概念差不多等同于“以 Solidity 编写智能合约”。虽然以太坊本身具有一些限制，但围绕 EVM 生态系统的技术正在繁荣发展。

时序数据库（TSDB）已经问世一段时间了。随着符合时序模型的使用场景愈发常见，TSDB 日益成为主流。InfluxDB 仍然是 TSDB 的理想选择，主要用于监控场景。TICK Stack 就是一款以 InfluxDB 作为核心的监控解决方案。Influx 2.0 的 alpha 版最近引入了 Flux（一种用于查询和处理时序数据的脚本语言）。虽然 Flux 目前仍处于早期阶段，且无法断定能比 InfluxDB 获得更广泛的应用，但它承诺会比 InfluxQL 更强大且更具表达力，且能将时序分析工作交由数据库来完成。然而，InfluxDB 只有企业版才能提供集群支持，因此在项目中需要留意这个限制。

Istio 正逐渐成为将微服务生态系统付诸应用的标准基础设施。其开箱即用的横切关注点的实现，已经帮助我们快速实现了微服务。这些横切关注点实现包括：服务发现、服务之间和从请求到服务之间的安全性、可观测性（包括遥测和分布式跟踪）、滚动发布和弹性。Istio 是我们一直使用的服务网格技术的主要实现平台。我们非常享受它的每月发布及无缝升级所带来的持续改进。我们使用 Istio 来启动项目，从一开始就能获得可观测性（跟踪和遥测）和服务之间的安全性。我们正密切关注其在网格内外各处服务之间身份验证方面所做的改进。此外，我们希望看到 Istio 为配置文件建立最佳实践，从而在为服务开发人员提供自主权和为服务网格运营商提供控制权之间达到平衡。

GraphQL 生态系统和社区正不断发展。Hot Chocolate 是用于.NET（包括新的 core 和原先的传统框架）的 GraphQL 服务器。该平台可用于构建和托管 schema，并能用于处理针对这些 schema 的查询。Hot Chocolate 的开发团队近期增添了 schema 拼接功能，允许从单个入口点跨多个 schema（从不同位置聚合而成）进行查询。虽然该功能会被以多种方式误用，但还是值得对其进行评估。

无服务器架构的应用，让 FaaS 编程风格在开发人员之间越来越普及。该架构通过独立构建和部署的函数，帮助开发人员专注于解决核心业务问题。这些函数能响应事件、运行业务流程、在流程中生成其他事件，完成任务后随即消失，不再消耗资源。以前，AWS Lambda 或 Microsoft Azure Functions 等专有无服务器平台已实现这种编程范式。Knative 是基于 Kubernetes 的开源平台，用来运行 FaaS 工作负载。Knative 有几点突出之处：开源且适用于任何供应商；实现了 CNCF 无服务器工作小组白皮书中所定义的无服务器工作流；通过实现符合 CNCF CloudEvents 规格的事件接口，来确保跨服务的互操作性；尤其重要的是，它能够解决在运维混合 FaaS 与长期运行的容器化架构时所遇到的常见挑战。该平台易与 Istio 和 Kubernetes 集成。例如，通过在不同版本的函数之间切换流量，开发人员可以利用 Istio 实施金丝雀发布策略。对于处在相同 Kubernetes 环境中的长期运行的容器服务和 FaaS 程序，开发人员都可以享受到 Istio 所提供的可观测能力。我们预计，Knative 开源事件接口将继续支持更多底层源和目的事件的集成。

随着越来越多的团队拥抱 DesignOps，该领域的实践和工具也日渐成熟。UI 开发环境专注于用户体验设计师与开发人员之间的协作（UI dev environments），为 UI 组件的快速迭代提供了综合环境。目前在该领域可用的工具包括：Storybook、React Styleguidist、Compositor 和 MDX。这些工具既可以在组件库或设计系统的开发过程中单独使用，也可以将其嵌入到 web 应用程序中使用。通过使用这些工具，许多团队在开发准备工作中缩短了 UI 反馈周期并改善了 UI 工作的时间。于是，使用 UI 开发环境成为了我们合理的默认选择。

大量的精力仍然被浪费在部署本地开发环境和排查“works on my machine”（在我的机器上可以工作）的问题上。多年来，我们的团队已经采用“检查并实施”的方法，使用脚本化方法来确保本地开发环境的配置始终一致。Batect 是由 ThoughtWorker 开发的一款开源工具，可帮助轻松搭建和共享基于 Docker 的构建环境。Batect 作为构建系统的入口点脚本，能够启动容器来执行完全不依赖于本地配置的构建任务。对构建配置和依赖项的更改仅通过源码管理即可共享，无需在本地机器或 CI 代理上进行任何更改或安装。在该领域的其他工具中，我们偏向于使用 Cage，但我们也看到 batect 正在以符合我们团队需求的方向迅速发展。

Detekt 是一个适用于 Kotlin 的静态代码分析工具。它能够发现代码中的坏味道和复杂性。你可以通过命令行运行它，也可以使用其插件集成一些热门的开发者工具，例如 Gradle（用于在项目构建时执行代码分析）、SonarQube（用于除静态代码分析外的代码覆盖率统计）和 IntelliJ 等。Detekt 能够给 Kotlin 应用的构建流水线锦上添花。

在日志管理领域，Humio 是一款相对较新的工具。该工具完全从零开始构建，通过基于定制设计的时序数据库的内置查询语言，在日志提取和查询方面性能非常快。从提取、可视化和报警提醒的角度来看，该工具能够与几乎所有工具相集成。日志管理领域已被 Splunk 和 ELK Stack 主导，所以，有替代选择也是一件好事。我们将持续关注 Humio 的发展。

我们对于 Kubernetes 对行业产生的影响兴奋不已，但也担心随之而来的运维复杂度。保持 Kubernetes 集群启动并运行、管理在该集群上部署的软件包都需要特殊技能和时间。升级、迁移、备份等运维流程经常会是一项全职工作。我们认为 Kubernetes Operator 会对降低复杂度起到关键作用。该框架提供了一套标准机制，为在 Kubernetes 集群中运行的软件包描述了自动化运维流程。虽然 Operator 由 RedHat 发起和推广，但多个社区为常用开源软件包（如 Jaeger、MongoDB 和 Redis）开发的 Operator 已初露头角。

Apache Beam 是一个开源的统一编程模型，用于定义和执行数据并行处理流水线的批处理与流式传输。Beam 模型基于数据流模型，允许我们以优雅的方式表达逻辑，以便在批处理、窗口化批处理或流式传输之间轻松切换。大数据处理生态系统已经取得了长足发展，这可能会导致人们难以选择正确的数据处理引擎。允许我们在不同运行程序之间切换，这是选择 Beam 的一个关键原因。几个月前，它支持了 Apache Samza，这是除 Apache Spark、Apache Flink 和 Google Cloud Dataflow 之外的又一个新的运行程序。不同运行程序具有不同能力，且提供轻便的 API 是一项困难的任务。Beam 将这些运行程序的创新主动应用于 Beam 模型，并与社区合作以影响这些运行程序的路线图，从而试图达到微妙的平衡。Beam 具有包括 Java、Python 和 Golang 多种语言的 SDK。我们也成功使用了 Scio，它为 Beam 提供了 Scala 包装器。

与 Cypress 和 TestCafe 一样，Puppeteer 也是备受我们团队推崇的一款 Web UI 测试工具。Puppeteer 能够对无头浏览器进行细粒度控制，生成时间轴信息，以用于性能诊断等。我们的团队发现，相较其他基于 WebDriver 的同类工具，Puppeteer 更加稳定、快速和灵活。

Room 是一个数据持久化库，用于在 Android 上访问 SQLite。它支持使用最小限度的样板代码进行数据库访问，同时通过编译时 SQL 校验使数据库访问更加稳健。令我们开发人员感到满意的是，使用 LiveData 后，Room 能够与可观察查询完整集成。Room 是 Android Jetpack 组件之一，旨在简化 Android 应用开发。

Rust 最近一次在技术雷达中出现是 2015 年，自那以来，我们看到开发者对 Rust 的兴趣在逐渐提升。我们的一些客户正在使用 Rust 语言，尤其在围绕基础设施工具方面的使用最为常见，而在高性能的嵌入式设备中也可以见到 Rust 的身影。不断完善的生态系统以及语言本身的改进推动了人们的兴趣提升。语言的改进方面，包括了直接的性能增强，也包括了直观表现力的提高，例如非词法作用域的更改。大多数重大变化都包含在去年 12 月发布的 Rust 2018 标准中。

fastai 是一个开源 Python 库，能够简化对快速且准确的神经网络的训练。它基于 PyTorch 构建，已成为备受我们数据科学家欢迎的工具。fastai 可简化模型训练中的难点，如预处理、使用少量代码加载数据。该库根据深度学习最佳实践构建而成，对计算机视觉、自然语言处理 (NLP) 等提供开箱即用的支持。创始人的动机是为深度学习创建易于使用的库，使之成为一个改进版的 Keras。GCP、AWS 和 Azure 很快便接纳了 fastai，将其包含在机器学习的镜像中。fastai 的创建者意识到 Python 在速度和安全方面的限制，已宣布接纳 Swift 作为深度学习的替代语言。我们将密切关注其进展。