微服务环境频频崩溃？皆因缺乏统一性！文章指出传统 SDLC 各阶段环境割裂，维护成本高。利用 Kubernetes 和 Service Mesh (Istio/Linkerd) 构建统一的类生产环境是破局关键，实现请求级别流量控制和环境共享，提升 DevEx 并降低基础设施成本。
译自：Why Microservice Environments Break: Lack of Unification
作者：Anirudh Ramanathan
在一个典型的构建微服务的组织中，软件开发生命周期 (SDLC) 贯穿于一个由断开连接的环境组成的拼凑网络。代码从本地开发（通常在 Docker Compose 或单节点 Kubernetes 集群上）转移到充满模拟的持续集成 (CI) 管道中，再到仅部分真实的预生产设置中，有时还会经过用户验收测试 (UAT) 等其他阶段。每一步都会引入偏差、维护开销，并与实际生产环境产生更大的距离。
这些阶段中的每一个都引入了自己的环境，具有自己的维护负担、风险和故障模式。平台团队需要维护所有这些环境，即使它们都不是完全一致的。结果是摩擦、分歧和维护债务的稳步积累。
这就是微服务环境问题：默认情况下的碎片化。
我们走到这一步并不是因为我们粗心大意。我们走到这一步是因为我们用我们拥有的工具解决了真实的、困难的问题。现实情况是，我们不得不在速度和保真度之间做出权衡。
为每个开发人员提供生产环境的完整副本是不切实际的，尤其是在公司开始运行 20、30 甚至更多微服务之后。本地设置变得过于繁重、过于缓慢且过于脆弱。在另一个极端，使用模拟进行所有操作意味着更快的反馈，但以牺牲真实性为代价，并且真正的错误仍然会进入生产环境。
复杂性、速度和真实性之间的这种紧张关系塑造了我们今天所处的环境蔓延：
- CI 太慢？添加模拟。
- Staging 太脆弱？做一个更轻的。
- 开发人员在本地受阻？用脚本和存根来解决。
每一步在当时都是有意义的。但随着时间的推移，我们最终得到了一个分散的环境混乱，这些环境彼此之间不太能对话，并且肯定与生产环境不匹配。现在，我们的大部分精力都花在了保持这个结构正常工作上，而不是以有意义的方式改进它。
碎片化的环境在各个方面都造成了摩擦：
- Bug 出现得很晚或仅在 staging 中出现。
- 测试在 CI 中通过但在生产环境中失败。
- 本地开发设置变得缓慢且不可靠。
更大的问题是持续的苦工。平台团队最终将多个环境设置连接在一起，耗费了本可以用来改进 DevEx、抽象复杂性和实现更快交付的时间。他们没有推动组织前进，而是陷入了与基础设施的斗争。
每个补丁、更多的模拟和更重的脚本只会增加负担。
以下是让这一刻与众不同的原因：我们不再受困。
Kubernetes 提供了一个通用的编排平台，而像 Istio 和 Linkerd 这样的 服务网格 添加了关键的缺失部分：细粒度的、请求级别的流量控制。这些工具使开发人员能够在同一个共享集群中运行多个隔离版本的服务，而不会发生冲突。
这意味着您可以：
- 在每个请求的基础上路由流量，而不仅仅是每个服务。
- 部署微服务的隔离版本，而无需复制整个堆栈。
- 在开发、测试、staging 和验证之间安全地共享一个通用环境。
- 启用临时的、高保真度的环境，可以快速启动和关闭。
正如我之前所写的那样，这些基础设施能力最终使统一 SDLC 中的环境成为现实。您可以构建一个强大的、可重用的基础来支持一切，而不是维护许多不同的脆弱设置。
构建块就在这里。现在是如何以正确的方式将它们缝合在一起。
与其维护五个独立的环境，不如构建一个统一的、类似生产的环境，以支持开发、测试、质量保证 (QA) 和端到端验证。通过使这个环境成为多租户和动态的，团队可以避免在每个步骤中重新创建和修补现实。
这种统一大大简化了平台工程的负担。平台团队可以专注于堆栈的更高层：改善开发者体验、收紧反馈循环和加速交付，而不是以许多不同的方式解决相同的环境问题。
许多组织正在朝着统一的环境模型发展：一个在开发、测试及其他环节共享的、类似生产环境的基础。
例如，Brex 进行了这种转变，并在数百名工程师扩展测试的同时，开发人员的满意度得到了显著提高，基础设施成本降低了 90% 以上。强大的环境基础有助于其上的一切更快地移动并感觉更轻松。
在 Signadot，我们构建了一个托管平台，可以轻松地在您自己的 Kubernetes 集群中采用此模型。如果您感到碎片化环境的压力，那么您并不孤单。有一种更好的方法触手可及。