手里有锤子，看到的都是钉子

Source: Dev.to

介绍

在快速演进的技术世界中，我们常常看到组织（从 C‑层到架构师和工程师）急于采用最新的技术趋势，却没有进行适当的设计或真正理解业务需求。

未进行适当设计的结果是资源浪费（从人力时间到计算资源）、架构过于复杂，或资源利用不足。
在本文中，我将深入探讨常见的架构决策，并提供避免这些陷阱的建议。
让我们来看一些示例。

将所有内容迁移到公共云

示例

一家企业要求将所有工作负载完整地 lift‑and‑shift 到超大规模云，以实现“云原生”，包括传统 ERP 系统、大型机以及对延迟敏感的交易应用。

被误解的地方

• 某些工作负载存在严格的延迟、数据驻留或许可限制。
• 这些应用高度耦合、状态化，且设计为垂直扩展。
• 成本模型仅分析了基础设施节省，未进行深入评估。

出现的问题

• 由于出站流量费用、实例规模过大以及始终在线的资源，导致总体拥有成本上升。
• 低延迟系统的性能出现下降。
• 运维复杂度增加，却未获得弹性或韧性方面的收益。
• 错失了有针对性地进行现代化改造的机会（如混合部署或在合理情况下重构）。

使用 Kubernetes 适用于所有架构

示例

一个团队将所有应用——包括小型内部工具、批处理作业和简单 API——部署到共享的 Kubernetes 平台上。

被误解的地方

• Kubernetes 是一个编排平台，不是免费抽象层。
• 许多工作负载并不需要容器编排、自动伸缩或自愈。
• 组织在集群管理和安全方面缺乏运维成熟度。

出现的问题

• 开发人员的认知负担增加（YAML、Helm、网络、Ingress、RBAC）。
• 平台团队成为简单变更的瓶颈。
• 安全配置错误（权限过宽的服务账户、暴露的服务）。
• 与更简单的部署模型（VM 或托管 PaaS）相比，交付速度变慢。

为每个解决方案使用无服务器

示例

一位架构师规定所有新服务必须使用函数即服务（FaaS）实现。

被误解的地方

• 无服务器在事件驱动、无状态、突发性工作负载方面表现出色——而不适合长期运行或交互频繁的进程。
• 冷启动、执行时长限制以及状态管理的权衡被忽视。
• 可观测性和调试方式与传统服务有显著差异。

出现的问题

• 延迟峰值影响面向用户的 API。
• 复杂的编排逻辑分散在多个函数中，降低了可维护性。
• 与容器或虚拟机相比，持续工作负载的成本更高。
• 由于日志碎片化和分布式执行路径，排障变得困难。

使用生成式 AI 解决所有问题

示例

一家公司在客户支持、代码审查、安全分析和决策工作流中集成生成式 AI，但未明确使用案例。

被误解的内容

• 生成式 AI 产生的是概率性输出，而非确定性答案。
• 数据质量、上下文边界以及幻觉风险被低估。
• 对监管、隐私和知识产权影响未进行评估。

出现的问题

• 错误或误导性的回复被呈现为权威答案。
• 通过提示或训练反馈回路导致敏感数据泄露。
• 在未验证 AI 输出的情况下信任其结果，导致运营风险增加。
• 由于在低价值场景中过度使用，导致成本高昂且 ROI 不明确。

实用建议

• 从业务驱动因素开始，而非技术 – 首先定义成功指标：成本模型、性能要求、监管约束、交付速度以及运营所有权。技术应当遵循这些输入，而不是先行。
• 明确记录约束条件和非目标 – 延迟、数据驻留、许可证、团队技能和运营成熟度必须提前捕获。许多架构失败源于被忽视或隐含的约束。
• 在技术优势关键的场景中应用技术
  • 公有云：优先考虑弹性、托管服务和全球覆盖——而不是单纯的 lift‑and‑shift。
  • Kubernetes：在编排、可移植性和规模能够证明其复杂性合理时使用。
  • 无服务器：将其使用限制在事件驱动和突发负载上。
  • 生成式 AI：在概率性输出可接受且可验证的情况下使用。
• 默认倾向简洁 – 如果更简洁的架构满足需求，通常就是正确的选择。复杂性应当是经过证明的，而不是默认的。
• 持续验证假设 – 随着工作负载演变，重新审视架构决策。曾经合理的方案在环境变化时可能会变成技术债务。
• 奖励以结果为导向的架构 – 评估架构师和团队时关注业务影响、可靠性和成本效率——而不是采用流行平台的程度。

Summary

现代架构中反复出现的失败模式并非技术选择不佳，而是 在未充分理解问题之前就过早地承诺使用某种工具。云平台、Kubernetes、Serverless 和生成式 AI 在有意应用时非常强大——但若被视为通用默认则会带来危害。当架构师从解决方案出发时，他们会为了平台的优雅而优化，而不是业务成果。

About the author

Eyal Estrin 是一位经验丰富的云和信息安全专业人士。

Eyal Estrin – 架构师、AWS Community Builder，以及《Cloud Security Handbook》和《Security for Cloud‑Native Applications》的作者。拥有超过 25 年 IT 行业经验，他为工作带来了深厚的专业知识。

在社交媒体上与 Eyal 联系：

此处表达的观点仅代表他本人，并不反映其雇主的立场。