最近几年好像大家都开始对微服务着迷，而一旦你开始使用微服务架构，也许你需要一些规则，帮助你成功运行它们

挑战 1：难以全面监控

在容器化应用中，回滚一个“坏”版本的难度增加。无论是逐步将单体应用拆分为微服务，还是从头构建新系统，都会面临更多服务需要监控的挑战。这些服务可能：

• 使用不同的技术和语言
• 运行在不同的机器或容器上
• 使用 Kubernetes（K8s）或类似技术进行容器化和编排

单一的运维指标已不足以适应高度分散的系统。团队现在需要处理数百甚至数千种指标、事件和告警，并从中筛选出有效信号。

解决方案

DevOps 监控应从扁平化数据模型转向分层模型，通过这种模型，团队可以随时监测高级系统和业务 KPI。当出现偏差时，团队必须能够深入到指标的层级结构中，查明具体的微服务和发生故障的容器。为了实现这一点，DevOps 工具链可能需要在数据存储和可视化方面进行调整。像 Prometheus 和 Grafana 7.0 这样的开源时序数据库工具，能有效支持这一目标。

挑战 2：跨服务日志记录

服务器每天生成的 IT 日志量巨大，造成了存储和处理成本的激增。在微服务架构中，日志变得更加分散。一个简单的用户操作可能涉及多个服务，每个服务都有其独立的日志记录框架。要排查问题，需要从所有相关服务中提取日志，才能发现根本原因。

解决方案

关键是理解单个业务请求如何在不同服务之间“流动”。这要求对传统单体程序在顺序业务执行期间的事件记录方式进行较大的改动。尽管已有一些框架帮助开发人员处理这一挑战，但对于希望将单体架构重构为微服务的企业，向异步、跟踪驱动的日志记录转变仍是一项艰巨的任务。

挑战 3：服务间的部署影响

由于微服务架构紧密关联，一个服务的细微变更可能会导致另一个服务出现性能或行为问题。当前的故障可能源于另一个团队未预料到的代码中断。这不仅会引发应用的不稳定，还可能造成团队间的摩擦。虽然微服务让代码部署更加灵活，但部署后验证代码行为的难度却增加了。

解决方案

企业应建立共享的发布日历，并在部署相关微服务时，分配专门资源来严格测试和监控整个应用的行为，以减少部署中的潜在问题。

挑战 4：难以找到问题的根本原因

在锁定问题服务并收集到堆栈跟踪和日志中的所有必要数据后，找到问题的根本原因依然可能十分困难。问题往往需要详细分析每个失败事务的状态，确定确切的失败原因。挑战在于，开发人员需要具备很强的预见性，提前判断并记录他们将来可能需要的诊断信息。

解决方案

当错误的根源跨越多个微服务时，制定一个集中化的根因分析方法至关重要。团队需要考虑哪些信息是诊断未来问题所必需的，以及在何种层级记录这些信息，同时平衡性能和安全因素。

挑战 5：版本管理

从单体架构的层次模型转向微服务的图模型时，版本管理变得尤为重要。大约 80% 的应用程序代码往往来自第三方库，因此在不同微服务间有效管理共享的第三方代码，避免“依赖地狱”，至关重要。如果某个微服务使用了第三方代码的旧版本或脆弱版本，可能会带来安全隐患。在微服务架构中，允许各团队在独立的仓库中管理依赖性是不合适的。

解决方案

公司需要在构建流程上投入，利用集中式 artifact 仓库（如 Artifactory）来管理第三方库和共享的工具代码。团队应仅允许在独立仓库中存储自己的业务代码，从而有效控制依赖关系，避免潜在的冲突和安全风险。