微服务架构在提升应用可扩展性、灵活性方面有着显著优势，但同时也带来了管理复杂性挑战并增加了运维开销。通过架构治理和可观察性，可以有效管理微服务，降低复杂性，提高系统弹性和工程团队效率。原文：Ending Microservices Chaos

微服务架构是构建可扩展网络应用的黄金标准。据 Gartner 估计，74% 的企业在其网络应用中使用了微服务，另有 23% 的企业计划很快采用微服务。

作为 IT 领导、架构师或开发人员，你可能已经体验过微服务带来的更快的部署速度、更好的故障隔离和更轻松的可扩展性。

然而，"天下没有免费的午餐"，老话说的没错，微服务也会带来巨大的运维开销和复杂性。微服务越来越多、组件依赖关系不明确、重复的服务以及循环依赖等反模式，都是微服务带来的混乱。

也许你已经看到了微服务混乱的常见症状：

• 工程速度急剧下降
• 新开发人员入职变得更加困难
• 故障或性能问题的平均恢复时间（MTTR，Mean time to recovery）增加
• 系统弹性降低，业务成果面临风险

虽然将单体应用解耦成微服务仍是最佳实践，但主动防范微服务带来的问题也是最佳实践。

通过架构治理（Architecture Governance）管理混乱

主动防范问题的最佳方法是利用架构治理 -- 管理和控制软件架构的规则、流程和实践的集合。

通过适当的软件架构治理，可以降低微服务的复杂性，更快提升开发人员的能力，减少平均故障间隔时间，提高系统弹性，同时建立有意识的文化。

(注意，本文讨论的是软件架构治理，而不是企业架构治理，后者已经存在了一段时间，关注重点是企业架构战略策略、流程和程序）。

但究竟如何建立架构治理呢？

无论是访问、数据还是架构治理，通常都只是制定一套规则。但对于架构治理来说，需要的不仅仅是规则，而是必须从架构的可观测性入手。

架构可观测性：良好治理的基础

要实施有效治理，首先需要全面了解软件架构。

架构可观测性可以提供持续、实时的架构视图，为团队提供必要的洞察力，从而有助于管理分布式应用的架构和互连性。

架构可观测性提供了来自工作系统的文档，展示了系统流、依赖关系、正在发生的变化以及系统的交互逻辑，能让团队透彻了解架构是如何工作的，如何从一个版本到另一个版本发生变化，以及变化是如何影响依赖的服务和资源。

没有这种可观测性，就会遇到麻烦。如果你已经构建了某个微服务项目，可能已经遇到了缺乏可观测性的后果：

• 难以管理的微服务
• 组件依赖关系不明确
• 服务重复
• 反模式，如增加中断风险的循环依赖关系
• 性能问题

整体应用的弹性、可扩展性和工程速度都面临高风险，而且情况只会变得更糟。缺乏可观测性的情况持续越久，架构就会变得越复杂、越难以管理。

良好的可观测性等于良好的治理

一旦有了良好的架构可观测性，就可以实时可视化架构层，了解系统是如何工作的，并随着架构的发展监控变化。

有了可观测性，团队就能在服务越来越多、依赖性管理不善等问题导致技术债务或系统故障之前，积极主动的加以解决。

一旦具备了可观测性，就能知道发生了什么和正在发生什么变化，从而可以创建和执行治理规则。

团队可以实施治理计划，对架构进行监控，控制变更，并在架构和代码演进的过程中主动应用标准和规则，从而有效构建和管理微服务。

听起来不错！但如何才能真正做到呢？我们用一个例子来看看在现实世界中如何构建。

实施架构可观测性和治理

首先，需要实现架构可观测性。

架构可观测性是一个发展迅速的新兴领域，以下示例将使用最前沿平台之一：vFunction，一个可提供软件架构可视化的 AI 驱动平台。

vFunction 利用 AI 和 OpenTelemetry 跟踪技术，使团队能够跟踪其架构的方方面面，并监控不同版本之间的变化，从而快速识别复杂的流程、架构技术债务和架构漂移。

例如，vFunction 可以帮助团队更好的了解分布式应用程序：

• 将架构可视化，并自动创建所有系统和数据流的可导出序列图。
• 识别漂移，如新服务或依赖关系。
• 识别资源独占性（如多个新服务访问同一个数据库表）相对之前版本的变化。
• 识别服务之间可能影响弹性的循环依赖关系。
• 确定可合并的重复功能/服务，以消除复杂性。
• 保持对全球微服务生态系统的最新实时了解。

vFunction 使用与 APM 工具相同的数据（因此可以直接安装），但使用不同的智能层来解决问题的架构根源，这对于管理因快速、频繁部署微服务而导致的蔓延和复杂性尤为重要。

vFunction 中可导出的序列流程图示例

执行规则以维持标准

在实现了可观测性后，就可以创建并执行治理规则了。vFunction 允许团队创建架构规则，可以根据规则实时监控架构，执行关键治理策略，只要部署或合并请求违反了规则，就可以阻止该操作。

管理组织可以执行如下规则：

• 依赖性要求。例如，某些服务应该或不应该与其他服务通信。
• 资源限制。
• 多个服务不应依赖于同一个数据库表。
• 变更不应增加服务的相互依赖性。
• 限制可能影响性能和弹性的新多跳流量。

vFunction 可以监控并发送上述各种相关告警。

通过实施有针对性的规则，团队可以创建适应性治理，指导开发人员维护优化、简洁、高效的架构，可以将架构管理融入代码和文化中。

结论

微服务的混乱可能会破坏开发速度、系统弹性和运营效率。架构治理为摆脱这种混乱提供了一条出路：一种重新控制架构并将其引向更高可扩展性和稳定性的方法。

无论你的组织刚开始采用微服务，还是已经陷入微服务蔓延的深渊，现在都是引入架构治理的好机会，从而可以确保架构高效、灵活，并为支持下一阶段的增长做好准备。

你好，我是俞凡，在Motorola做过研发，现在在Mavenir做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。为了方便大家以后能第一时间看到文章，请朋友们关注公众号"DeepNoMind"，并设个星标吧，如果能一键三连(转发、点赞、在看)，则能给我带来更多的支持和动力，激励我持续写下去，和大家共同成长进步！

本文由mdnice多平台发布