最新一期技术雷达上，提出了哪些技术发展新趋势？

写在前面

ThoughtWorks 中一群资深技术领导组成的 ThoughtWorks 技术顾问委员会 （TAB） 创建了该雷达。 他们定期开会讨论 ThoughtWorks 的全球技术战略以及对行业有重大影响的技术趋势。这个雷达以独特的形式记录技术顾问委员会的讨论结果，为从开发人员到 CIO 在内的各路利益相关方提供价值。 这些内容只是简要的总结， 我们建议您探究这些技术以了解更多细节。

这个雷达是图形性质的， 把各种技术项目归类为技术、 工具、 平台和语言及框架。 如果某个条目可以出现在多个象限， 我们选择看起来最合适的象限。 我们还进一步将这些技术分为四个环以反映我们目前对其的态度。

本期四大主题

崛起的中国开源软件市场

星星之火，已成燎原之势！在态度和政策发生转变之后，包括阿里巴巴和百度在内的众多大型中国企业正在积极发布开源框架、工具和平台。中国软件生态正伴随着经济扩张而加速成长。从这个巨大而繁荣的软件市场向 GitHub 等开源网站发布的开源项目的数量必将持续增多，质量也将持续提高。中国企业为何热衷于将他们的众多资产开源出来？与硅谷等其他活跃的软件市场一样，各个企业对开发人员的争夺十分激烈。仅仅提升薪酬水平是不够的，让聪明的开发者一起在最前沿的开源软件上共事才能够持续激励他们，这是一个放之四海而皆准的通则。我们预期主要的开源创意会继续保持 README 文件中先有中文版后有英文版的趋势。

容器编排首选 Kubernetes

Kubernetes 及其在许多项目中逐渐增强的主导性推动了大量雷达条目的更新，以及更多的讨论。似乎软件开发生态系统正在 Kubernetes 及其相关工具的周边稳定发展，以解决有关部署、规模化和容器操作这些常见问题。诸如 GKE，Kops 和 Sonobuoy 这些雷达条目提供了托管平台服务和工具，以改善采用和运行 Kubernetes 的整体体验。事实上，它具备用一个调度单元来运行多个容器的能力，可以让服务网格（service mesh）和能够实现端点安全的 sidecar 得以实现。

Kubernetes 已经成为容器的默认操作系统——许多云提供商已经利用其开放的模块化架构来采用和运行 Kubernetes，而它的工具则可以利用其自身开放的 API 来访问诸如负载、集群、配置和存储等功能。我们看到更多的产品正在把 Kubernetes 作为一个生态系统来使用，使其成为继微服务和容器之后的下一个抽象层次。更多迹象表明，尽管面临分布式系统固有的复杂性，开发人员仍然可以成功地驾驭现代的架构风格。

成为新常态的云技术

本期技术雷达讨论中的另一个普遍性话题，无疑是近期的“多云”天气。 随着云提供商的技术能力越来越强大，且可以提供同样好用的功能，公有云正在成为许多组织中新的默认选择。当启动新项目时，许多公司已经不再问“为什么放在云端？”，而是问“为什么不放在云端？”。 诚然，某些类型的软件仍然要在公司内部私有地部署，但随着价格的下降和功能的扩展，云原生（cloud-native）开发的可行性越来越高。尽管主要的云解决方案提供商提供的基本功能都很相似，但它们也都提供了一些独特的产品特性，以针对特定类型的解决方案来实现差异化。因此，我们看到一些公司通过“多云”（Polycloud）策略来同时使用几个不同的云提供商，从中分别挑选最能满足其客户需求的平台专业能力。

各方对区块链的信任稳步增强

尽管加密货币市场仍然处于混沌状态，我们的许多客户已经开始尝试利用基于区块链的解决方案来处理分布式账本和智能合约的需求。雷达中的一些条目展示了区块链相关技术运用的成熟度，它们使用各种新技术和编程语言并以一些有趣的方式来实现智能合约。区块链解决了“分布式信任”与“共享且不可篡改的账本”这些老大难问题。如今，许多公司正致力于增强其用户对将区块链作为系统的底层实现机制的信心。许多行业存在着明显的“分布式信任”问题，我们期待区块链技术能持续找出解决这些问题的方法。

一、技术

轻量级架构决策记录

很多文档都可以被高度可读的代码和测试取代。然而，对于演进式架构来说，记录某些设计决策非常重要，这不仅有利于未来的团队成员理解，也有利于外部监督。轻量级架构决策记录是一种用于捕获重要的架构决策及其上下文和结果的技术。我们建议将这些详细信息进行版本化，而不是 wiki 或网站，这样所记录的内容就可以和代码保持同步。对于大多数项目，我们没有理由不采用这种技术。

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

过去 12 个月里，我们注意到对数字化平台这个主题的关注发生了急剧的增长。希望快速有效推出新数字解决方案的公司，正在建立内部平台，为交付团队提供自助服务，从而访问那些构建和运营自己的解决方案所必需的业务 API、工具、知识和支持。我们发现，当这些平台得到跟外部产品同等的重视时，它们的效率是最高的。将产品管理思维应用于内部平台，意味着与内部消费者（开发人员）建立共情，并在设计上彼此协作。平台的产品经理要建立路线图，确保平台为业务交付价值，为开发者改善体验。一些企业甚至为内部平台创建了品牌标识，并向同事推销平台的优势。平台产品经理将负责平台的质量、收集使用指标，并持续改进平台。将平台作为产品来处理，有助于创造一个蓬勃发展的生态系统，避免构建另一个停滞不前的、未充分利用的面向服务架构。

DesignOps

受 DevOps 运动的启发，包含一系列实践和文化转变的 DesignOps 横空出世。它可以帮助组织不断重新设计产品，而不在质量、服务一致性和团队的自主性上妥协。 DesignOps 提倡创建并不断演进设计的基础，最大限度降低创造新的 UI 概念及其变体的工作量，并与最终用户建立快速可靠的反馈机制。使用 DesignOps，设计正在从一种具体的实践演变成每个人工作内容的一部分。

混沌工程

在早期的技术雷达中，我们讨论了 Netflix 的 Chaos Monkey。Chaos Monkey 可以随机终止生产系统中的运行实例，并对结果进行度量，从而帮助验证系统在运行时对生产中断的应对能力。今天，人们有了一个新兴术语来描述这一技术的广泛应用：混沌工程。在生产环境的分布式系统中运行这些实验，可以帮助我们建立系统在动荡环境下依旧能够按预期工作的信心。如果想要更好地理解这个技术方向，请参阅混沌工程原理。

无服务器架构

无服务器架构迅速得到了需要部署云端应用的组织的认可，并且有着大量可供选择的部署方式。即便是相对传统和保守的组织，也在使用一部分无服务器技术。虽然可以使用的合适的模式仍在不断涌现，但大多数时候我们的讨论都会走向函数即服务 (Functions as a Service) （例如 AWS Lambda，Google Cloud Functions，AzureFunctions）。部署无服务器函数毫无疑问能够减少大量传统方式特有的，涉及服务器和操作系统配置和编排的工作量。然而 serverless 也并不是百试不爽的万金油。当前这个阶段，因为一些特别的需求，你必须做好能回退至容器化，甚至是实例化部署的准备。与此同时，无服务器架构的其他组件，比如后端即服务（Backend as a Service），几乎成为了默认的选择。

Service Mesh

现在越来越多的大型组织在向更加自组织的团队结构转型，这些团队拥有并运营自己的微服务，但他们如何在不依赖集中式托管的基础架构下，确保服务之间必要的一致性与兼容性呢？为了确保服务之间的有效协作，即使是自组织的微服务也需要与一些组织标准对齐。服务啮合在服务发现、安全、跟踪、监控与故障处理方面提供了一致性，且不需要像 API 网关或 ESB 这样的共享资产。服务啮合的一个典型实现包含轻量级反向代理进程，这些进程可能伴随每个服务进程一起被部署在单独的容器中。反向代理会和服务注册表、身份提供者和日志聚合器等进行通信。通过该代理的共享实现（而非共享的运行时实例），我们可以获得服务的互操作性和可观测性。一段时间以来，我们一直主张去中心化的微服务管理方法，也很高兴看到服务啮合这种一致性模式的出现。随着 linkerd 和 Istio 等开源项目的成熟，服务啮合的实现将更加容易。

二、平台

Kubernetes

自我们上次在技术雷达中提到 Kubernetes 至今，它已经成为我们大部分客户将容器部署到服务器集群的默认解决方案。而能替代它的其他产品不但没有获得如此的客户认同度，甚至在某些场景中，我们的客户会将他们的“引擎”都更换成 Kubernetes。Kubernetes 已经成为主流公有云平台上的首选容器编排平台。这些主流公有云平台包括微软的 Azure 容器服务以及 Google Cloud（参见 GKE）。此外市面上还有很多好用的产品，来不断丰富快速扩大的 Kubernetes 生态圈。与此同时，那些试图用一层抽象将 Kubernetes 隐藏起来的平台尚未成功地证明自己的价值。

.NET Core

作为一个开源的跨平台软件开发框架，.NET CORE 被越来越多地运用到实际项目中。该框架令 .NET 应用能在 Windows、macOS 以及 Linux 系统上进行开发和部署。.NET Standard 2.0 的发布增加了跨多个 .NET 平台的标准 API 的数量，这使得往.NET Core 迁移的路径变得更为清晰。有关.NET Core 对其上类库的支持性问题正在逐渐减少。一流的跨平台工具已经涌现出来，用于在非 Windows 平台上进行高效的开发工作。运用 Docker 镜像，能让.NETCore 服务可以轻松地集成到容器环境中。其社区发展的积极方向以及来自我们实际项目的反馈，都表明.NET Core 现在已经可以广泛地运用了。

TensorFlow Serving

机器学习模型已经开始渗入到日常的商业应用中。 当有足够的训练数据可用时，这些算法可以解决那些以前可能需要复杂的统计模型或试探法的问题。 随着机器学习从试验性使用转向生产环境，需要一种可靠的方式来托管和部署这些可远程访问的模型，并能随着消费者数量的增加而进行扩展。TensorFlow Serving 通过将远程 gRPC 接口暴露给一个被导出来的模型，解决了上述部分问题。这允许以多种方式部署训练完成的模型。TensorFlow Serving 也接受一系列的模型来整合持续的训练更新。其作者维护了一个 Dockerfile 来简化部署过程。 据推测，gRPC 的选择应与 TensorFlow 执行模型保持一致。 但是，我们通常都会对需要代码生成和本地绑定的协议保持警惕。

微信

常与 WhatsApp 被相提并论的微信，在中国正在成为名副其实的商业平台。很多人可能还不知道，微信还是最流行的线上支付平台之一。借助微信内置的内容和会员管理系统，一些小型企业现已完全依赖微信开展其业务。大型组织可以通过微信的一些功能把内部系统对接给员工使用。作为覆盖七成以上中国人的平台，微信是每一个想开辟中国市场的企业都需要考虑的重要商业因素。

语言服务器协议

大型 IDE 的威力很大程度上源于利用源代码分析出的抽象语法树（AST）来进一步分析和操作源代码的能力，比如代码补全，调用分析和重构。语言服务器将这种能力提取到单独的进程中，从而让任意文本编辑器都可以通过 API 来使用 AST。微软从他们的 OmniSharp 和 TypeScript 服务器项目中，提炼并引领了语言服务器协议（Language Server Protocol, LSP）的拟定。编辑器只要使用 LSP 协议就可用于任何具备 LSP 兼容服务器的编程语言的开发。这意味着我们可以继续使用自己喜爱的编辑器，同时也不必放弃各种编程语言的高级编辑功能——这对于很多 Emacs 瘾君子来说尤其利好。

三、工具

CIRCLECI

CIRCLECI 是一个持续集成引擎，它既可以在 SaaS 云服务上使用，又可以私有部署使用。它已经被我们很多开发团队在 SaaS 平台上当作常用 CI 工具。这些团队需要低摩擦（low-friction）和易于搭建的构建与部署流水线。CircleCI 2.0 的版本支持构建任务的工作流，并具备扇入（fan-in）和扇出（fan-out）流模式和手动触发模式，且支持移动开发。它也允许开发者在本地运行流水线。另外 CircleCI 能很容易地与诸如 Slack 及其他通知和报警系统进行集成。就像使用任何其他承载公司资产的 SaaS 产品一样，我们建议用户仔细查看 CircleCI 的安全实践。

GOPASS

GOPASS 是一个基于 GPG 和 Git 的团队密码管理解决方案。它的前身是 pass，并在此基础上增加了诸如多用户密码管理、层级式密码存储、交互式查找、基于时间的一次性密码（TOTP）, 以及二进制存储格式等功能。由于它的存储格式与 pass 基本兼容，因此可以直接从 pass 迁移过来。这意味着只需调用一次存储密钥就能将其集成到迁移的整备工作流中。

JSONITER

如果正在寻找用 Go 和 Java 编写的高性能 JSON 编码 / 解码工具，那就试试开源库 JSONITER，它与 Go 语言中的标准 JSON 编码包相兼容。

FLOW

FLOW 是一个针对 Javascript 的静态类型检查工具，它可以为整个代码库逐步增加类型检查。不同于通过定义另一种语言来实现静态类型检查的 Typescript 语言，Flow 可以被逐步添加到支持 ECMAScript 第 5、第 6 以及 第 7 版的已有 Javascript 代码库中。我们建议把 Flow 添加到持续集成部署流水线中，并从最关注的代码开始做静态类型检查。使用 Flow 能使代码更清晰，重构更可靠，并在构建过程的早期就捕获到类型相关的代码缺陷。

APEX

APEX 是一个能够轻松构建、部署和管理 AWS Lambda 函数的工具。有了 Apex，就能使用 AWS 尚未原生支持的包括 Golang、Rust 等在内的编程语言来编写函数。这一点是通过 Node.js shim 来实现的。它会创建一个子进程，并通过标准输入和输出来处理各种事件。Apex 还有很多不错的特性，可以改善开发者的体验。我们特别欣赏它能在本地测试函数的能力，以及在将变更运用到 AWS 资源之前能对其进行预演的能力。

Rendertron

JavaScript Web 富应用的一个老问题是如何使这些页面的动态渲染部分可供搜索引擎检索。为此开发人员采用了各种各样的技巧，包括使用 React.js 的服务端渲染，外部服务或预渲染内容。现在谷歌 Chrome 新的 headless 模式又贡献了一个新的技巧—— Rendertron，即 Chrome 的 headless 渲染解决方案。它在一个 Docker 容器中封装了一个 headless 的 Chrome 实例，可以作为独立的 HTTP 服务器来部署。无法渲染 JavaScript 的爬虫机器人可以被路由到此服务器来进行渲染。 虽然开发人员也可以部署自己的 headless Chrome 代理并配置相关的路由机制，但 Rendertron 简化了配置和部署过程，并提供了令爬虫机器人进行检测和路由的中间件示例代码。

四、语言 & 框架

Angular

在往期的雷达中，我们不确定是否应该强烈推荐 ANGULAR，因为从本质上来说，它是一个新的、整体上没那么让人兴奋的框架，仅仅是和那个我们曾经喜爱过的 AngularJS 同名而已。目前已经进化到第 5 个版本的 Angular，在提供向后兼容性的同时，有了稳定的改进。我们的一些团队已经在生产环境上应用 Augular，他们很满意最终的效果。基于这个原因，在这一期雷达中，我们把 Angular 移到了“试验”阶段，来表示我们的一些团队现在把它当作不二之选。然而我们的大多数团队，仍然会更倾向于选择 React, Vue 或者 Ember。

Spring Cloud

Spring Cloud 在持续演进的过程中增加了许多有趣的新特性。例如在 spring-cloud-streams 项目中，对 KafkaStreams 绑定的支持让采用 Kafka 和 RabbitMQ 通过连接器构建消息驱动的应用变得相对容易。正在使用该特性的 ThoughtWorks 的团队都认同它能在使用像 Zookeeper 这样的复杂基础设施时提供便捷性，也对构建分布式系统时需要解决的常见问题提供支持，例如使用 spring-cloud-sleuth 进行跟踪。目前我们已成功将它应用在多个项目中，不过大家仍然需要注意其适用场景。

Kotlin

对 Android 的完美支持为迅速发展的 KOTLIN 语言提供了额外的推动力，我们也正在密切关注 Kotlin / Native（基于 LLVM，可以将 Kotlin 代码编译为原生可执行文件）的进展。在使用 Anko 开发 Android 应用时，我们已经尝到了空指针安全、数据类和易于构建 DSL 的甜头。尽管初始编译速度慢，且只有 IntelliJ 才提供一流的 IDE 支持，但我们仍然建议尝试一下这种新颖简洁的现代语言。

Druid

Druid 是一个具有丰富的监控特性的 JDBC 连接池。它有一个内置的 SQL 解析器，提供了对数据库中执行的 SQL 语句语义级别的监控。注入或可疑的 SQL 语句将被拦截，并直接在 JDBC 层记录下来。查询也可以基于它们的语义进行合并。这是一个阿里巴巴开源的项目，它反映了阿里巴巴从自己的数据库系统中学到的教训。

Gobot

Go 语言能够被编译为裸片上运行的目标程序，这使得嵌入式系统开发领域对它的兴趣与日俱增 。GoBot 是一个用于机器人、物理计算和物联网 (IoT) 的框架，它基于 Go 语言编写，并且支持多个平台。我们在一个对实时性响应没有要求的实验性机器人项目中使用了 GoBot，并且用 GoBot 创建了开源的软件驱动。GoBot 的 HTTP API 使其与移动设备的集成十分容易，从而能创建更丰富的应用。

PyTorch

PyTorch 是 Lua 机器学习框架 Torch 在 Python 语言下的完整重写版。比起 TensorFlow，它还很新不够成熟，但在程序员的眼里它却很好用。 因其面向对象的特性和原生的 Python 实现，模型可以表达得更加清晰简洁，并可以在执行过程中调试。尽管最近涌现出了许多这类框架，但 PyTorch 拥有 Facebook 和广泛合作伙伴的支持，包括应该会继续支持 CUDA 架构的 NVIDIA。ThoughtWorks 的团队发现，PyTorch 在模型的设计开发及试验阶段拥有着明显的优势，但在大规模的生产环境中的训练及实现仍然离不开 TensorFlow。

Weex

Weex 是一套跨平台移动应用开发方案，采用了 Vue.js 的组件化语法。对于那些偏爱 Vue.js 简洁性的开发者，Weex 是一个开发原生移动应用切实可行的选择，但同时也能胜任非常复杂的应用。已经有大量的复杂的应用构建于 Weex 框架，其中包括中国最流行的两款移动应用程序——天猫和淘宝。Weex 最初由阿里巴巴开发，目前是 Apache 孵化项目。