微服务和容器：选择哪个？

为什么选择微服务？为什么选择容器？

微服务是一种有吸引力的 DevOps 模式，因为它们能够加快上市速度。由于每个微服务都是独立开发、部署和运行的（通常使用不同的语言、技术堆栈和工具），微服务允许组织“分而治之”，并更有效地扩展团队和应用程序。当管道未锁定在工具集、组件依赖项、发布流程或基础结构的整体配置中时，可以更好地扩展开发和操作。它还可以帮助组织轻松确定哪些服务不需要扩展以优化资源利用率。

容器提供定义良好、隔离的运行时环境。容器支持将所有内容打包到 Docker 类型文件中，该文件通过管道在一致环境中作为单个容器提升，而不是交付项目及其所有变量。除了隔离和一致的环境之外，容器还具有非常低的运行容器进程的开销。这种对从开发到生产的环境一致性的支持，以及极快的配置、启动和扩展，加速并简化了开发和运营。

为什么要在容器中运行微服务？

在容器化环境中运行基于微服务的应用程序非常有意义。Docker 和微服务是天然的伴侣，构成了现代应用程序交付的基础。

在高层次上，微服务和Docker一起是DevOps的PB&J，因为：

• 他们都旨在做好一件事，而这些事情是互补的。
• 你需要学习擅长一个的东西可以很好地转化为另一个。

更具体地说：

目的

• 微服务（通常）是专注于应用程序某个方面的单个进程，尽可能隔离运行。
• Docker 容器在定义明确的环境中运行单个进程。

复杂性

• 使用微服务，您现在需要部署、协调和运行多个服务（数十到数百个），而以前您可能拥有更传统的三层/整体式架构。虽然微服务支持敏捷性，尤其是在开发方面，但它们也带来了许多技术挑战，主要是在运营方面。
• 容器有助于解决这种复杂性，因为它们可以轻松快速地在容器中部署服务，主要面向开发人员。

缩放

• 微服务使缩放更容易，因为每个服务都可以独立于其他服务进行缩放。
• 容器原生集群编排工具（如 Kubernetes）和云环境（如 Amazon ECS 和 Google Container Engine （GKE））提供了根据负载和业务规则轻松扩展容器的机制。

系统理解

• 微服务和容器本质上都迫使您更好地理解系统——如果您不彻底了解您的架构、拓扑、功能、操作和性能，就无法成功使用这些技术。

挑战

• 管理微服务和大规模 Docker 部署给企业 IT 带来了独特的挑战。由于组织必须精通哪些内容才能成功部署和修改微服务和容器，因此在大规模操作容器和微服务的挑战和最佳实践方面存在相当多的重叠。
• 管道变化增加。编排交付管道变得更加复杂，移动部件也越来越多。将整体架构拆分为多个微服务时，管道数可能会从 50 个跃升至<>个（或者设置了多少个微服务）。您需要考虑需要多少个不同的团队，以及是否有足够的人员来支持每个微服务/管道。
• 测试变得更加复杂。 需要考虑的测试量更大，包括集成测试、API 合约测试、静态分析等。
• 部署复杂性增加。虽然缩放容器化应用相当容易，但首先需要进行大量活动。在发布到生产环境之前，必须在整个管道中多次部署它以进行开发和测试。随着如此多的不同服务独立开发，部署数量急剧增加。
• 监视、日志记录和修复变得非常重要，并且越来越困难，因为有更多的移动部件和不同的分布式服务构成了整个用户体验和应用程序性能。
• 有许多不同的工具链、架构和环境需要管理。
• 需要考虑现有的遗留应用程序，以及如何将这些应用程序与基于容器或微服务的应用程序的新服务和功能进行协调。
• 治理和审计（特别是在企业级别）变得更加复杂，因为如此大的分布式环境，组织必须同时支持容器和微服务，以及传统的发布和整体应用程序。

除了这些常见的挑战之外，微服务和容器也各有其独特的挑战。如果您正在考虑使用微服务，请了解：

• 分布式系统是双重崇拜的，需要强大的系统理解能力。
• 服务组合很棘手，更改成本可能很高。从整体式架构开始，避免过早分解，直到您彻底了解应用程序的行为。
• 需要考虑进程间故障模式，尽管抽象在纸面上看起来不错，但它们容易出现瓶颈。
• 注意事务边界和外键关系，因为它们会使分解变得更加困难。
• 考虑使用基于事件的技术来进一步减少耦合。
• 对于API和服务SLA：“在你做的事情上要保守，在你接受别人的东西上要自由”
• 状态管理是硬事务、缓存和其他有趣的事情......
• 测试（特别是服务之间的集成测试）和监视（由于服务数量的增加）变得更加复杂。
• 服务虚拟化、服务发现以及 API 集成点的正确设计以及向后兼容性是必须的。
• 故障故障排除：“每次停电都是谋杀之谜。
• 即使服务很小，也必须考虑部署占用空间。
• 您一切都依赖网络 - 您需要考虑带宽、延迟和可靠性。
• 如何处理旧版应用程序：重写？忽视？混合？

容器挑战：

• 安全性是一项关键挑战——既因为它仍然是一项相对较新的技术，也因为下载图像的安全问题 le.容器是OpSec的黑匣子：更少的控制，容器内部的可见性较低，现有工具可能不精通容器。确保签名和扫描图像，验证库等;还要强化容器环境;尽早放弃权限，并使用细粒度的访问控制，这样它就不全是根。明智地使用凭据（容器服务可以提供帮助）。
• 监控非常棘手，因为容器实例可能会连续丢弃或扩展。需要将日志记录和监视配置为停用过期的容器，或保存日志和数据（业务数据、引用数据、合规性数据、日志、诊断）来自其他（临时）实例。
• 了解什么在何处运行，以及为什么运行，并避免映像膨胀和容器蔓延。
• 由于容器托管和集群编排市场仍在兴起，我们看到用户尝试在多个环境中运行容器，或使用不同的集群编排工具和API。这些早期采用者需要管理容器，同时最大限度地降低锁定到特定云供应商或点工具的风险，或者必须投入大量工作（和陡峭的学习曲线）来重写复杂的脚本，以便重新调整其部署或...