本文将讨论什么是横切关注点，解析它们存在的必要性，并探讨如何以尽可能轻松的方式来处理这些关注点。
译自 Why Microservices Aren’t Working for You，作者 Ned Harris 长达十多年来一直在帮助大型和小型组织解决软件开发和交付的问题。 他是一个终生学习者，热衷于分享他的观察结果，特别是当涉及到提高开发人员的工作效率和工作满意度时。
一位应用开发者、一位安全团队成员和一位站点可靠性工程师(SRE)走进了公司的聚会。他们能相处愉快吗？
如果他们在一个利用微服务的组织工作，答案可能取决于他们能否避免谈论工作。这些团队中的每一个可能都会在心里为其他团队贴上标签......横切关注的人。这三个团队之间可能会有很多推拉，SRE 要求集中式日志记录和监控，安全团队施加严格的规则，而开发者需要处理的这些横切关注的问题比他们正在开发的实际服务还要多。
我认为我们都应该学会和睦相处，欣赏每一个团队带来的价值。我们所需要做的就是使每一个团队的关注更容易管理。
让我们来看看横切关注是什么，为什么它们需要存在，以及如何用尽可能最不痛苦的方式解决它们。我们会发现，我们用于解决横切关注的方法也会减轻服务之间可能存在的不太完美的 API 合同之间的冲突。
横切关注是依赖于或必须为系统的其他部分提供支持的项目。例如，一个简单服务的开发者可能会被要求解决 SRE 团队的关注，SRE 团队希望将开发者的服务整合到一个集中式日志解决方案中。对于开发者来说，这意味着不去花时间构建服务的核心功能，而是为围绕该服务的基础设施工作。这对一个没有签约做这项任务的开发者来说极其令人沮丧。
不仅仅是基础设施：即使是相互交互或相互依赖的其他服务也可以被认为是横切关注。期望两个或多个 API 之间有完美的合同关系并不总是现实的。这些关注有可能困扰开发者，并导致他们花更多的时间在他们领域之外的工作上。
这导致人们对当前微服务模式的状况产生了相当大的愤世嫉俗。关于微服务乌托邦的最初承诺似乎已经破灭，一个合理规模的团队可以专注于一个狭窄范围的解决方案，他们可以依靠干净的向后兼容的合同(API)，但是通过一些没计划的范围扩展，开发者获得的任何初始的时间和焦点节省已经耗尽。在那些“如何微服务”的文章和视频中，方便地忽略了如何解决横切关注的问题。
采用微服务的关键点之一是关注分离的承诺。只要每个微服务以干净的合同的形式提供向后兼容的 API，开发者就应该可以自由地关注服务。那么，怎么回事呢？
许多声称消除横切关注的工具简单地将那些关注从开发者转移给其他人，或者更糟的是，用全新的关注取代了一整套旧的关注。
例如，服务网格解决方案可以将诸如安全策略、可观测性、集中式日志记录和流量路由等关注从服务上移到基础设施上。这意味着服务的开发者不再负责自己实现这些类型的策略，但底层的关注并没有消失。这些关注现在是管理服务网格团队的责任。
之前被要求通过他们可以合理化和测试的方式解决这些关注的服务开发者，现在有两种选择：1) 推进他们的服务，祈祷一切在新的网格环境下正常工作；或者 2) 想办法将新的网格策略融入他们的开发人员工作流程中。第一种选择很可能会导致许多错误的 CI/CD 运行；后者只是增加了另一组横切关注。
没有任何神奇的模式可以使横切关注消失。需要对服务进行观察，以确保它们处于健康状态。日志需要对负责故障排除的利益相关方可访问。当解决方案由许多微服务组成时，需要有一种跟踪请求生命周期的方法，这样如果事情表现不佳，可以确定涉及了哪些服务。
除了可观测性和诊断之外，我们还必须考虑整个系统。所有这些微服务共同努力完成一个更大画面的解决方案。就像两个音准完美的歌手仍然可能曲调不和谐一样，两个或多个完美运行的微服务也可能阻碍系统的更大目标。
因此，我们不应该试图消除横切关注，而应该努力减少它们对开发者生产力的影响。
我们可以减少这些横切关注对开发者影响的最好方法是尽早在开发过程中暴露它们。为了解决横切关注或任何其他形式的额外复杂性，开发者将不得不执行许多迭代。随着这些迭代接近生产，它们在时间和压力方面的成本会越来越高。因此，解决这些横切关注的最佳和成本最低的时间应该是开发过程的早期。这是开发者控制力最大，可以快速迭代的时机。
不幸的是，这些横切关注往往直到开发生命周期的后期才被解决。这对开发者来说是一个非常缓慢的反馈循环，因为他们试图理解如何使他们的代码与他们能见度有限且控制力更少的环境协同存在。
这种情况的主要原因是过度依赖固定的流水线来汇聚所有这些关注。开发者受限于流水线才能从更大的类似生产的环境中获得任何反馈。复杂性越高，开发者测试的内容与需要通过才能被提升到生产中的内容之间的差异就越大。
开发者需要的是一个在开发环境中解决生产复杂性的能力，使他们能够以最快、最经济的方式进行大部分迭代。
Garden等工具通过允许创建定义基本操作(如构建、部署、运行和测试)的便携式流水线来解决这些挑战。这些操作可以表达依赖顺序，并且因为它是图格式，所以它可以隔离和只运行完成给定任务所需的步骤，使其非常快速高效。
这样的标准可移植格式不仅描述了部署应用程序的步骤，还考虑了其他横切关注。这是因为Garden可以引用其他Garden项目，允许关注分离，例如由另一个拥有并管理服务网格策略的团队。
定义了图和外部源后，开发者可以执行简单的Garden命令，如garden deploy或garden test，在几秒钟内获得反馈。这意味着开发者可以合理化并测试那些通常只在软件开发生命周期中暴露的关注，例如拉取请求和完整的CI/CD运行之后。
这创建了一个快速的反馈循环，使开发者能够很快了解他们正在开发的代码是否与另一个团队的策略或甚至其他服务存在冲突。与另一个团队合作找出最好的解决方案，将比在敲响生产之门时容易得多。
拥有一个可移植的流水线意味着开发者在其环境中使用的相同图也可以在 CI/CD 流水线中利用。(事实上，使用 Garden 可以将 CI/CD 流水线简化为几个命令。)这可以开启一个新范例：我们不再从本地开发向生产方向工作，而是开始设想一个用可移植的流水线定义我们的生产状态的世界，并简单地将图分发给底层阶段，在生产、CI/CD 和开发环境之间留下无差异。
尽管横切关注和其他复杂性给开发者社区造成了痛苦，但应该注意到，这种痛苦也影响了安全、站点可靠性工程师、管理者和其他不能忽视这些关注的利益相关方，因为它们太难或者太麻烦来管理。希望当这些不同的团队在下次聚会见面时，他们都可以一起玩得开心，作为真正的合作者，甚至朋友！
查看Garden，深入了解我们如何解决这些挑战，让我们以新的信心拥抱复杂性。