云原生微服务

能够认识到云原生微服务对应用程序设计的影响，描述无状态微服务，并比较单体和微服务架构。要充分利用运营模式，您需要以不同的方式思考应用程序设计。您需要考虑云原生微服务。此图像显示了一个应用程序，该应用程序被设计为小型微服务的集合。这些服务中的每一个都独立于其他服务。每个服务都是应用程序的特定域。您可能已经从服务的名称中收集到此示例是拼车服务。有司机、支付、行程管理和通知。这些都是基于业务域的单一用途的小型服务。请注意从一个服务到另一个服务的线路。这些都指向 REST API（代表性状态传输架构风格的应用程序编程接口）。没有服务正在访问另一个服务的数据库。事实上，数据库甚至不包括在图片中。这是一个使用微服务的云原生设计。它是无状态服务的集合。云原生意味着 “诞生在云上”，利用云必须提供的水平可扩展性。这些服务遵循 “十二因素应用程序” 中提出的指导方针，该指导方针描述了云原生应用程序的行为方式。这是由 Heroku 团队于 2011 年首次创建的。Heroku 是为我们今天拥有的云原生平台铺平道路的首批 platform-as-a-service 实现之一。应用程序被设计为无状态微服务的集合。无状态并不意味着应用程序没有状态。这意味着服务不维护状态，任何隐藏状态。状态保存在数据库中，每个服务在单独的数据库或持久对象存储中维护自己的状态。状态分离很重要。如果服务共享状态，你就不会有微服务。你只会有一个分布式单体。弹性和水平扩容是通过部署多个实例来实现的。一旦你把应用程序分解成多个独立的服务，你就可以根据需要独立扩展它们。例如，我可以在不扩展其他服务的情况下扩展通知服务。这利用了云平台无缝、无休止的水平扩容。失败的实例不是调试和修补，而是被杀死和重生。我们经常使用实例是 “牛而不是宠物” 的表达。不要太依恋你的实例。我们根据需要横向扩展它们，在不需要时横向扩展它们。一旦你将应用程序分解成许多小的微服务，你需要利用运营模式管道来帮助管理这些服务的持续交付。微服务这个词是由 Martin Fowler 和 James Lewis 创造的。他们说，“…… 微服务架构风格是一种将单个应用程序开发为一套小型服务的方法，每个服务都在自己的进程中运行……” 这些不仅仅是线程。这些是独立运行的完整进程，“…… 并与轻量级机制通信，通常是 HTTP 资源 API。” 我们现在使用 REST API 作为这些轻量级机制。Fowler 和 Lewis 想说，“这些服务是围绕业务能力构建的，并且可以通过全自动部署机制独立部署。” 您看到拼车应用程序中的每个服务都是围绕业务能力构建的，例如司机服务、乘客服务和通知服务。这些服务是可以独立部署的。例如，我可以在不重新部署其他所有内容的情况下升级通知服务。微服务使所有内容都可以独立部署，这一点尤为重要。与使用微服务相比，使用单体如何工作？假设您有一个具有计算、复制功能和待办事项的单体。当您部署此应用程序时，您必须将所有组件一起部署。我们可以将它们拆分为独立微服务的多个实例。如果我需要增加执行计算的能力，我可以横向扩展这三个实例，也许可以制作十个。我不必横向扩展待办事项或复制功能。能够独立扩展它们以充分利用云资源非常重要。每个微服务都有自己的数据库，它在其中跟踪自己的状态。我可以独立部署它们并独立更改数据库。我只需要更改并与我的团队协调来实现这一点，因为其他服务正在使用 REST API 进行通信。他们没有在数据库中选择彼此的表。假设我正在一个电子商务网站上工作，这是一个单体，我想更改客户表。我可能需要与订单团队和运输团队的人员协调来更改客户表，因为他们依赖它来完成订单和运输。使用微服务，不需要与其他团队协调，因为您只是在调用我的 REST API。你不在乎我的表是什么样子。你通过 API 进来。我可以从使用 SQL 数据库转变为非关系型数据库，你永远不会知道。你要求客户数据，我给你客户数据。这是单体架构和微服务架构之间的一个区别。对于微服务，每个服务都是松散耦合的，并通过 REST API 进行通信。在本文中，您了解到云原生架构是可独立部署的微服务的集合。无状态微服务每个都在单独的数据库或持久对象存储中维护自己的状态。微服务是松散耦合的服务，旨在实现可扩展性和与 API 的通信。