技术雷达|有态度的前沿技术解析|188bet宝金博app下载思考方式

下载技术雷达第24期

本期主题

越来越多的组织正在采用平台团队的理念来开发产品，即成立一个专门团队，来创建和支持内部平台功能，并使用这些功能来加速应用程序开发，降低运维复杂性，并缩短产品上市时间。

我们在许多平台（特别是在云领域）上看到了相应的面向开发者的工具集成。例如，工件库，源码控制，CI / CD流水线，维基以及类似的工具，开发团队通常会手工挑选这些工具并按需拼接在一起。拥有合并的工具栈可以为开发人员带来更多的便利和更少的工作，但这套工具集却很少能代表最佳的解决方案。

太复杂以至于无法进入雷达

在技术雷达的命名法则里，对许多复杂主题的讨论，最终状态都会是“TCTB--太复杂以至于无法进入雷达（太复杂，BLIP）”。这些主题通常每年都会出现，包括monorepos，分布式架构的编排指南以及分支模型等等。就像软件开发中的许多主题一样，那里存在太多权衡，难以提供清晰明确的建议。

识别架构耦合上下文

在软件架构中，如何在微服务，组件，API网关，集成中心，前端等等之间确定一个适当的耦合级别，是几乎每次会议都会讨论的话题。随处可见的情况是，当两个软件需要连接在一起时，架构师和开发人员都在努力地寻找正确的耦合级别。我们需要花时间和精力去理解这些因素，然后因地制宜地做出这些决定，而不是寄希望于找到一个通用却并不恰当的解决方案。

加速产品上市的平台团队

越来越多的组织正在采用平台团队的理念来开发产品，即成立一个专门团队，来创建和支持内部平台功能（如云原生，持续交付，现代化的可观测性，认证和鉴权模式，服务网格等），并使用这些功能来加速应用程序开发，降低运维复杂性，并缩短产品上市时间。这种日趋成熟的做法值得欢迎，所以我们早在2017年，就将该技术引入技术雷达。但是随着成熟度的提高，我们发现组织在应用这项技术时，应避免使用一些反模式。例如，“用一个平台来统治一切”，可能并不是最佳选择。“构建一步到位的大平台”，可能要过数年后才能交付价值。本着‘一旦建好，就有人用’的初衷，到头来可能却是巨大的浪费。相反，使用产品思维，有助于根据产品客户的需求，来弄清每个内部平台所应提供的服务。但如果让平台团队只解决技术支持工单系统中所提交的问题，那么这种做法就又产生了老式的运维孤岛团队，出现相应的需求优先级失调的弊端，如反馈和响应缓慢，以及争夺稀缺资源等的问题。此外，我们还看到一些新工具和集成模式涌现出来，以有效划分团队和技术。

整合的便利性盖过单项最佳方案

随着以自动化，规模化和其他现代目标为特征的工程实践在开发团队中变得越来越普遍，我们在许多平台（特别是在云领域）上看到了相应的面向开发者的工具集成。例如，工件库，源码控制，CI / CD流水线，维基以及类似的工具，开发团队通常会手工挑选这些工具并按需拼接在一起。现在，诸如蔚蓝的DevOps等交付平台和GitHub.等生态系统已经将许多工具收入囊中。虽然各平台产品的成熟度不尽相同，但交付工具 “一站式服务” 的吸引力是毋庸置疑的。总的来说，似乎需要权衡的是，拥有合并的工具栈可以为开发人员带来更多的便利和更少的工作，但这套工具集却很少能代表最佳的解决方案。

太复杂以至于无法进入雷达

在技术雷达的命名法则里，对许多复杂主题的讨论，最终状态都会是“TCTB--太复杂以至于无法进入雷达（太复杂，BLIP）”，这意味着那些条目无法被分类，因为它们呈现出太多正反两面的特性，以及大量关于建议，工具的适用性和其他原因上的细微差别，这让我们无法用短短几句话总结它们。通常来说，这些主题会变成文章那播客，以及其他非雷达形式的内容我们热烈参与的一部分讨论，聚焦于这些主题：。它们很重要但过于复杂，无法形成一致的观点许多主题经历了一次又一次会议 - 而且有些是跟我们的部分客户一起 - ，最终进入了TCTB的状态，包括monorepos，分布式架构的编排指南以及分支模型等等如果你好奇为什么这些重要的主题没有进入雷达，可以确信的是，这并不是因为我们缺乏意识或者意愿。就像软件开发中的许多主题一样，那里存在太多权衡，难以提供清晰明确的建议。我们有时也会发现，可以对一些大的主题中的小部分提供建议，使其进入雷达，但这些大的主题对雷达来说，仍然过于微妙难以确认。

识别架构耦合上下文

在软件架构中，如何在微服务，组件，API网关，集成中心，前端等等之间确定一个适当的耦合级别，是几乎每次会议都会讨论的话题（参见上一主题“太复杂到无法进入雷达”）。随处可见的情况是，当两个软件需要连接在一起时，架构师和开发人员都在努力地寻找正确的耦合级别，许多常见的建议会鼓励极致地解耦，但这会使构建工作流变得非常困难架构中的耦合涉及许多重要的考虑事项：事物如何连接，理解每个问题域中固有的语义耦合，事物间如何相互调用，如何保证事务性正常工作（有时还会与其他棘手的特性，如可伸缩性结合在一起）除单体系统之外，如果没有某种级别的耦合，软件也就无从谈起。在现代架构中，找到正确的折衷方法来确定耦合的类型和级别是一项关键技能。我们确实看到了一些不好的实践，例如为客户端库生成代码，也看到了一些好的实践，例如明智地使用BFF模式。然而，通用的建议在这个领域是无用的，银弹是不存在的。我们需要花时间和精力去理解这些因素，然后因地制宜地做出这些决定，而不是寄希望于找到一个通用却并不恰当的解决方案。