袜子商店应用：一个可供参考的云原生应用

正文

请到「今天看啥」查看全文

初次运行之后，我们看到了持续维护该项目的好处。它既可以作为容器和微服务集中工具的测试平台，同时可以作为云原生系统的参照应用，这会非常有用。在接下来的几个月中，我们致力于将此演示应用转换为可以部署到生产的应用。我们对每个服务进行了彻底改进、按需替换数据存储、合并高耦合的服务、并添加日志和监控等标准功能。我们还建立了完整的持续集成和交付管道，最终会发布到 AWS 上 Kubernetes 集群的准生产环境中。

微服务

云原生应用必须足够灵活。我们需要快速而独立地部署，从而让我们在正确的时间做出正确的决定和变化。这能使组织架构变得敏捷。组织内部应该预期并鼓励变化而不是极力规避变化。云原生应用注重服务的独立性。系统的每一部分都不应该相互依赖，以避免造成级联故障。最后，云原生应用应该是技术无关的。为系统的一个部分选择编程语言，或者为特定数据集选型关系型数据库，不应对系统的其他部分造成影响。

显然，这些不是我们可以通过独立应用架构来实现的。虽然不是所有情况下都必要，但是云原生应用还是应该构建在微服务之上。在袜子商店应用中，我们积极地在应用中使用“微服务”的理念。

这给了我们诸多好处：我们能够利用多种持久化技术，即在不同的服务使用不同的数据存储。我们也可以为每个服务自由地选择语言。但真正的好处在于开发的速度。由于这是一个开源社区项目，短期内有很多开发人员参与。通过对服务进行适当的隔离，大家可以很容易地融入社区并快速修复 bug 或在某一服务中添加功能，而无需了解整个架构。

过分微服务化

有观点认为，一开始就使用微服务架构比转换现有的独立应用更加困难。其中一个原因是，在一个全新的项目中，服务之间的边界并不总那么清晰。如果你的服务沿着错误的边界进行划分，最终服务间的交互就会过多，而且这可能难以纠正。在我们袜子商店应用早期开发中就遇到这个问题。由于我们激进地对服务进行了划分，我们创建了一个登录服务和一个顾客服务。在我们的后续开发中，就发现它们之间的耦合度太高，他们应该是一个服务，而将它们合并成单个服务的过程又比预期设想的要更复杂。所以建议，在完全理清服务之前，尽量推迟对服务的拆分。

容器

请到「今天看啥」查看全文