什么是微服务、容器和Kubernetes(3)

什么是微服务、容器和Kubernetes

您可以将一个巨大的单体应用程序作为容器，也可以拥有一群完全不使用容器的微服务。

容器是一种有用的资源分配和共享技术。这是 DevOps 人们感到兴奋的事情。微服务是一种软件设计架构。这是开发人员感到兴奋的事情。

它们是相关的，但不需要彼此。您可以将单体应用部署为容器，也可以拥有不受限制的、非容器化的微服务。

什么时候使用微服务？

微服务背后的想法并不新鲜。几十年来，软件架构师一直致力于将单体应用程序分解为可重用的组件。

微服务的好处

微服务的好处很多，包括：

• 更简单的自动化测试；
• 快速灵活的部署模式；
• 更强弹性扩缩容。

采用微服务的另一个好处是能够为工作选择最佳工具。

应用程序的某些部分可以从 C++ 的速度中受益，而其他部分可以从更高级别语言（例如 Python 或 JavaScript）的生产力提高中受益。

微服务的缺点

微服务的缺点包括：

• 需要更仔细的规划；
• 更高的研发投入；
• 过度设计的诱惑。

如果应用程序和开发团队足够小并且工作量不具有挑战性，则通常无需投入额外的工程资源来解决您尚未解决的问题并使用微服务。

但是，如果您开始看到微服务的利大于弊，这里有一些具体的设计注意事项：

• 计算和存储分离。随着您对 CPU 能力和存储需求的增长，这些资源具有非常不同的扩展成本和特性。从一开始就不必依赖本地存储，这将使您能够相对轻松地适应未来的工作负载。这既适用于文件系统等简单的存储形式，也适用于数据库等更复杂的解决方案。
• 异步处理。通过添加越来越多的相互调用的子进程或对象来逐步构建应用程序的传统方法随着工作负载的增长而停止工作，并且应用程序本身必须跨多台机器甚至数据中心扩展。将需要围绕事件驱动模型重新构建应用程序。这意味着发送事件（而不是等待结果）而不是调用函数并同步等待结果。
• 拥抱消息总线。这是必须实现异步处理模型的直接后果。随着您的单体应用程序被分解为事件处理程序和事件发射器，就需要一个健壮、高性能和灵活的消息总线。有多种选择，选择取决于应用程序规模和复杂性。对于一个简单的用例，像 Redis 这样的东西就可以做到。如果您需要您的应用程序真正是云原生的并自行扩展和缩减，您可能需要能够处理来自多个事件源的事件：从 Kafka 等流管道到基础设施，甚至监控事件。
• API 版本控制。由于您的微服务将使用彼此的 API 通过总线相互通信，因此设计用于保持向后兼容性的架构将是至关重要的。只需部署一个微服务的最新版本，开发人员就不应该要求其他人升级他们的代码。这将是向整体方法向后兼容的一步，开发团队必须在永远支持旧 API 和保持更高的开发速度之间达成合理的妥协。这也意味着 API 设计成为一项重要的技能。频繁的破坏性 API 更改是团队无法高效开发复杂微服务的原因之一。
  上一页1234下一页