技术、平台、工具、语言&框架，年底应该这样把握技术方向！

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

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

点击阅读原文，可获取全部技术雷达详细内容！

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

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

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

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

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

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

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

受 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），几乎成为了默认的选择。

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

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

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