ThoughtWorks 技术雷达发布四大技术趋势

上周，ThoughtWorks 在北京发布了其最新一期的技术雷达。会上，ThoughtWorks 中国区 CTO 徐昊和中国区高级敏捷咨询师陈加兴分别对该期技术雷达所包含的四大主题及接下来可能会产生“浪潮效应”的一些技术趋势进行了分享。InfoQ 也对两位的预测观点做了梳理和总结，以为软件开发者和决策者提供可借鉴的行情统计和经验洞察。

ThoughtWorks 技术雷达拟定依据

ThoughtWorks 在每年都会出品两期技术雷达，这是一份关于技术趋势的报告。相对于一些根据量化指标制定而出的分析报告和行业预测报告而言，技术雷达中的象限和条目均由行业内一线工作者的经验和具有洞察力的人员筛选得出。他们根据对软件研发的理解和判断，对技术进行过滤，最终拟定而成。徐昊相信，统计数据不能代表任何问题，富有洞见力的一线工作人员以及对软件开发有着充分运用、领先理解的开发者，其所持观点才能为行业预测带来更精准的价值，并将其积累的真实经验带到更多的技术开发者和决策者面前。

11 月期技术雷达图概览

本期技术雷达依旧是以技术、工具、语言和框架、平台四方面内容为切入方向，同时每个象限内又由中心向四周依此分为“采用”、“试验”、“评估”、“暂缓”四大维度，以通过这四大不同维度表示每一项技术的成熟度。

用徐昊的话来解释，即在“采用”象限里的技术条目，只要场景恰当，就应该是技术开发者或决策者选择采纳的默认选项。“试验”环里，强调的是这项技术拥有足够的成功可能性，它们大多属于较新的技术领域，有较大发展潜力，只要在合适且风险可控的情况下，开发者即可尝试使用。此外，“评估”和“暂缓（proceed with caution）”象限则需要开发者对收益、风险、成熟度等条件评定下再谨慎使用。

通过直观的图形展示，技术雷达能将相关领域中值得注意的或新的技术提炼并表述出来。例如这一次在“采用”环的 14 项技术条目中，就有 9 项是新入围条目，包括 Pipelines as code、Babel（JavaScript 编译器）、Grafana（白板生成工具）等。

四大主题预示下一波技术浪潮

根据对技术雷达上众多技术条目的总结，ThoughtWorks 也看到行业内一线在软件开发及使用上的整体情况和趋势，从而总结了本期技术雷达的四大主题。

• 容器即进程，PaaS 即机器，微服务架构即编程模式

目前行业内一批企业客户在引入容器时，常把 Docker 按照以前虚拟机的使用方式加以同等对待，将应用程序部署在 Docker 中。因此，ThoughWorks 提出要将 Docker 设想为一个进程，可以在任何地点随时启动并销毁，不会随着业务迁移而增加搭建时长。

其次，ThoughWorks 也发现许多大型企业正将开发者工具部署在他们自身平台内，从而形成了一整套开发语言生态。因此，PaaS 应该就是一个部署目标平台，并非围绕开发者提供的工具，或者是一些在线开发工具。

此外，由于容器化和强调松耦合，微服务风格的架构呈现了一个更抽象的开发者世界，为企业提供了更高层次的运行隔离。在 ThoughWorks 总结中，决策者应将微服务架构看作新的编程模式，这也意味着需要抛弃以前一些旧的观念，去认知和实践微服务这种新架构模式。

• 智能释放的力量

随着 Nuance Mix 和 TensorFlow 等通过框架进入到实用领域，以前看上去很复杂的人工智能、机器学习等技术，也因为云计算和智能算法具体数据的大维度开放，离商业应用越来越近。而这些因素的综合演变也将促成一系列新的工具，包括商品计算、特殊定制的硬件（如 GPUs）、云端资源等。

• 团队结构的全局影响

面向企业客户的市场一线团队，不再是只有短暂生命周期的项目团队，而要把互联网的产品思维引入到企业级项目中来，即产品思维高于项目运作。其次，应该在企业级项目里构建全功能团队，项目团队要建全自己的力量，向产品团队靠拢，把互联网的产品思维真正引入到内部 IT 项目中。例如，这两年 ThoughtWorks 一再强调，微服务不仅仅是一种技术，而是将它看作重新构建一线开发团队战斗力的一种文化或方法。

• AR/VR 渐入佳境

虽然像 OpenVR 和 Unity 这样的软件开发平台已非常成熟，但新的 NLP 工具及硬件提供的接近自然的交互，为 AR/VR 技术的采用提供了较大助力。在建立实验室探索下一代应用时，ThoughtWorks 发现，由于通过抽象介质向用户直接传递沉浸式体验，因此 VR 在远程协作和讲述时有惊人的移情作用。但同时挑战也在于，创作和交付 VR/AR 内容应用的技能和能力远远跟不上硬件发展的步伐。

枚举最令人兴奋的几大技术条目

在 ThoughtWorks 团队梳理出 110 项技术条目同时，徐昊和陈加兴也对其中几项较新或具有较大拓展潜力的技术模型进行了解读和分享，例如 Anemic REST、APIs as a product、IndiaStack、CMS as a platform 等。

这些模型大多分布在“试验”、“评估”、“暂缓”三大维度内。这也意味着，即使很多技术条目在目前阶段并没有庞大的利益产出以证明其未来可能释放的价值，但其形成的影响并不会掩埋其创新上的成败。限于文章篇幅，InfoQ 主要选取了分享中三则较为典型的技术成果进行展示。

• Anemic REST（贫血 REST）

谈论微服务越来越火热的今天，很少人会想到其技术是基于 RPC 的调动方式实现的。而 REST 里面最吸引人的地方，即它属于迁移或迁转的一种过程，可自然的鉴定业务的当前及未来的状态，使企业划定业务的场景和业务边界，从而帮助企业更好的描述现在所产生的业务模型。

      

但一部分批评者职责 REST 导致了系统间繁琐低效的交互，且无法适应客户端需求的变化。ThoughtWorks 发现，这类问题出现的根源并不在 REST 本身，而是源于未能将领域作为一组资源来正确建模。通过模板化的 URL、简单地暴露静态分层数据模型开发一个服务，会导致出现贫血 REST。贫血 REST 是一个反模式，它与贫血领域模式密切相关，根据它所设计出来的服务，在 Richardson 成熟度模型中，会处于成熟度较低的层次。

此外，RSET 虽然能非常忠实的反映页面上的各类交互。但如果核心 API 是围绕极易发生变化的 UN 交换设计，那变化快速的 APIs 将无法跟随企业的发展和业务模式的转变一起成长。这样，REST 承诺的优点就无法恰当表现。因此，ThoughtWorks 将贫血 REST 放在了“暂缓”维度上。

• IndiaStack

IndiaStack 是一组开放 APIs，由印度研发。Open API 驱动了印度政府在认证服务、数字签名（eSign），统一在线支付和电子合同层（e-KYC）上的一系列数字创新，可以使印度公民通过统一的 ID 接入上述服务。

从这个层面上说，IndiaStack 实际上代表一组关系国计民生的微服务规范，在此规范上可实现印度人民网上支付等需求，以及与每个人生活息息相关的功能和内容，形成这样的规范其实是对每个公民的基本权利的保障。

由此，徐昊也得出一种反思——如果从政府的角度来讲，个人身份除了在实际物理空间存在特定指示外，难道不应该有一个开放网上服务，通过这种固定的身份表征让个人快速接入或关联一些政府相关的网站么？

印度的 IndiaStack 是很好的技术实验。它所传递的一种思想是：当我们真正见证到软件正成为整个行业乃至社会的核心驱动力时，我们也应该思考，政府在互联网环境中或信息化时代里应扮演怎样的角色、处于怎样的地位。

• Overambitious  API 网关

在亚马逊提供了 API 网关后，很多的大型企业也希望自己有能力开发这样的 API 网关（除了开源框架之外），他们不太满足于使用现有的开源框架，或者直接购买亚马逊的服务。

       

去年 5 月，ThoughtWorks 在其服务的一家企业中发现，对方正开发一个所谓的微服务框架，该框架主要是提供分布式事务和服务事务处理，而里面的“微服务”就是仅提供了数据 CRUD 操作，即上面提到的“贫血 REST”服务，通过网关进行各种流程编排、功能聚合和事务处理，但最终结果的确失败了。所以 ThoughtWorks 也提出，整个 API 网关应该是做轻量级服务的注册和发现，过度庞大的 API 网关产品，其功能在本质上就是反向代理，这助长了难以测试和部署的系统设计。