【.com快译】本文将介绍一些微服务最佳实践，并提出一些方法来帮助开发者设计、编排和保护微服务架构。了解这些实践将有助于开发人员成功开发项目。微服务的优势和挑战在深入研究微服务最佳实践之前，您应该首先了解微服务的优势和挑战，以及您应该使用它们的原因。简而言之，微服务是一种改进的软件架构，允许开发人员：更快地部署和扩展。较小的应用程序域允许自动化，从而加快部署和扩展速度。减少停机时间。限制不可用服务对关键业务功能的影响，增加其整体业务正常运行时间。确保可用性。保持微服务之间的功能离散，限制实例停机时的影响。当然，在采用微服务的所有好处的同时，它也带来了一系列新的挑战，包括服务间通信、安全性和可扩展性。服务之间的通信。对于单体应用程序，所有模块都可以固有地相互通信。因此需要管理证书，一旦请求通过身份验证和授权，就可以毫无问题地遍历代码路径。当开发人员将功能从单体架构中提取到微服务应用程序中时，曾经的内部功能调用变成了外部API调用，需要对此外部微服务进行身份验证和授权。安全层。身份验证和授权在单体应用程序中，可以在入口处处理一次。随着向微服务的过渡，每个微服务都需要执行一些身份验证和授权以实施访问控制。但是要求用户每次使用不同的微服务都要登录是不现实的，因此需要建立完善的认证策略。可扩展性。虽然微服务允许开发人员快速扩展独立功能，但有效地做到这一点需要良好的应用程序管理甚至更好的工具。可扩展性的有效性取决于开发人员的微服务编排平台，下面将对此进行更详细的讨论。微服务的最佳实践在快速概述了微服务的优势和挑战之后，下面将深入探讨微服务的一些良好实践。这些最佳实践将帮助开发人员创建一个强大、可管理、可扩展且安全的可互操作微服务系统。1.采用微服务策略的较小应用域需要遵循单一职责原则。通过限制单个服务的责任范围，可以减少该服务失败的负面影响。如果单个微服务承担太多责任，失败或不可用将对系统的其余部分产生多米诺骨牌效应。顾名思义，微服务是微型服务，保持微服务小型化的应用程序域可以专用于一个逻辑功能。如果出现任何问题，这将减少特定微服务的影响。此外，较小的服务更容易维护，从而更容易更新和更快的开发。那么这在实践中是什么样的呢？例如，假设微服务是一个接受请求以获取数据的API服务器，并且这些请求必须附有授权令牌。一开始，这是唯一需要授权令牌的微服务。为什么不将身份验证和令牌生成作为微服务的一部分？乍一看，优点是运动部件少，管理工作少。当然，拥有其他需要授权令牌的服务的开发人员会很快发现，原来的微服务既充当了API服务器，又充当了身份验证服务器。如果API服务器出现故障，其身份验证服务器也会出现故障。因此，所有其他需要授权令牌的服务也是如此。因此，考虑到未来的发展，开发者需要保持微服务的小型化。2.数据存储分离多个微服务连接到同一个数据库，本质上仍然是一个单体架构。单体应用程序仅在数据库层而不是应用程序层运行，这使得它同样容易受到攻击。每个微服务应该尽可能有自己的数据持久层。这不仅可以确保与其他微服务隔离，还可以最大限度地减少特定数据集不可用时的影响范围。有时，不同的微服务访问同一数据库中的数据似乎很有意义。然而，深入挖掘可能会发现一个微服务仅适用于数据库表的一个子集，而另一个微服务则适用于完全不同的数据库表子集。如果这两个数据子集完全正交，那么这将是将数据库分离为独立服务的一个很好的例子。这样，一项服务依赖于其私有数据存储，并且该数据存储的故障不会影响除该服务以外的任何服务。以文件存储为例。当采用微服务架构时，不需要单独的微服务使用相同的文件存储服务。除非存在实际的文件重叠，否则单独的微服务应该有单独的文件存储。这种数据分离增加了灵活性。例如，假设有两个微服务都与云计算提供商共享同一个文件存储服务。其中一个微服务定期访问大量文件，但这些文件很小，而另一个微服务只有几个经常访问的文件，但这些文件的大小非常大，达到数百GB。由于混合使用大小文件和定期访问，对两种微服务使用通用文件存储服务将降低优化成本的灵活性。如果每个微服务都有自己的数据持久层（当然它可以是一个单独的微服务），那么就可以更灵活地找到更适合该单个微服务需求的提供者或服务。成本优化、选项的灵活性以及对可能失败的单一解决方案的较少依赖是将数据与不同微服务分开的原因。3.通信渠道微服务之间如何通信需要慎重考虑，尤其是在关注事件方面。否则，单个不可用的服务可能会中断通信并可能导致整个应用程序崩溃。例如，在一个在线商店的微服务系统中，一个微服务接受网站上的订单；另一个微服务向客户发送一条文本通知，告知他们的订单已收到；第三个微服务通知仓库发货。最后，第四个微服务更新库存计数。微服务之间有两种通信方式：同步和异步。如果上面的示例是使用同步通信处理的，Web服务器可能会通过首先向客户通知服务发送请求来处理新订单。客户通知服务得到响应后，Web服务器向仓库通知服务发送请求，然后再次等待响应。最后，Web服务器向库存更新程序发送请求。这种同步方式如图1所示：图1微服务间的同步通信当然，在客户通知服务出现故障的情况下，通知客户的请求可能会超时或返回错误，也可能是web服务器无限等待寻求回应。那么仓库通知服务可能永远不会收到发送请求。而微服务之间的同步通信可以创建一个依赖链，如果链中的任何连接断开，该依赖链就会中断。在异步通信中，服务发送请求并继续执行而不等待响应。在一种可能的异步方法中，Web服务器可能会发送“通知客户端”请求，然后完成其任务。客户通知服务负责通知客户并向仓库通知服务发送异步请求，仓库通知服务负责向库存更新服务发送请求。这个例子如图2所示：图2微服务之间的链式异步通信当然在这个模型中，看到异步通信仍然会创建依赖链，单个服务的失败仍然可以中断应用程序。一种简单但有效的异步通信方法是采用发布/订阅模式。当感兴趣的事件发生时，生产者（在本例中为微服务）将该事件的记录发布到消息队列服务。对此类事件感兴趣的任何其他微服务都会作为该事件的消费者订阅消息队列服务。微服务只与消息队列服务对话和监听，彼此之间不通信。此示例如图3所示：图3消息队列服务促进异步通信消息队列是独立于所有微服务的独立服务。它负责接收发布的事件并通知订阅者这些事件的发生。这确保了一个微服务的失败（这可能意味着消息传递延迟）对其他相关但无关紧要的服务的影响最小。有很多工具可以完成这种异步通信（例如Kafka或RabbitMQ）。因此，有必要想办法将这些工具集成为微服务的异步通信主干。在某些情况下，需要微服务之间的同步通信。大多数请求-响应交互必然是同步的。例如，查询数据库的API服务器必须等待查询响应；获取缓存数据的Web服务器必须等待键值存储响应。当需要同步通信时，开发人员需要使用开源的KongGateway来确保他们的通信快速可靠地路由到正确的微服务。4.兼容性尽可能保持向后兼容性，这样消费者就不会遇到损坏的API。实现此目的的常见方法是遵循路径级兼容性保证，例如/api/v1或/api/v2。任何向后不兼容的更改都将转到新路径，例如/api/v3。然而，尽管作为软件工程师的开发人员尽了最大努力，有时API还是需要弃用，这样它们就不会一直运行。使用API网关请求转换插件，其微服务可以通过在原始API响应旁边轻松注入弃用通知或附加类似Kubernetes的“弃用标头”来提醒API消费者。5.微服务的编排微服务的编排是流程和工具成功的关键因素。开发人员可以在技术上使用systemd和Docker或podman之类的东西在虚拟机上运行容器，但这不能提供与容器编排平台相同级别的弹性。这会对采用微服务架构的正常运行时间和可用性优势产生负面影响。为了有效的微服务编排，开发人员需要依赖久经考验的容器编排平台；这个领域的明显领导者是Kubernetes。Kubernetes管理所有容器的配置和部署，同时处理负载平衡、扩展、高可用性副本集和网络通信问题。开发人员可以在本地部署Kubernetes，也可以在AzureKubernetesService、RedHatOpenShift或AmazonElasticKubernetesService中使用它。Kubernetes的内置调度、复制和网络功能使微服务编排比在传统操作系统上更容易。将Kubernetes与Kuma服务网格和KongIngressController相结合，创建可发现、可监控且有弹性的微服务。6.微服务安全随着应用程序包含越来越多的微服务，确保适当的安全性变得复杂。用于执行安全策略的集中式系统对于保护应用程序免受恶意用户、黑客和错误代码的侵害至关重要。无论是在虚拟机上还是在Kubernetes上运行，Kong都应该是开发人员的微服务安全故事的开始。Kong维护的大量安全插件可以轻松满足微服务的一些最常见需求，包括身份验证、授权、流量控制和速率限制。示例：使用Kong入口控制器进行速率限制为了演示一个有效的安全插件示例，将部署Kong的速率限制插件以展示Kong如何防止对应用程序的过多入站请求。我们将使用kind创建本地Kubernetes集群，然后按照以下说明部署KongIngress控制器。创建集群并部署KongIngressController后，第一步是设置速率限制插件。可以为不同的范围设置插件。将使用Kubernetes集群上的默认项目作为用例，并将插件范围限定为默认命名空间。然后创建一个“回声服务”和该服务的条目。本例取自《GettingStartedwithKong'sKubernetesIngressController》文档中的例子：最后要做的就是测试，会借用Kubernetes文档中的shell-demo进行集群内测试：进入前shellpod、kong是必需的-proxy的集群IP：现在，可以通过shell访问的pod和测试速率限制：大多数云提供商不需要使用中间pod来测试速率限制的额外步骤，这为开发人员提供了开箱即用的负载均衡器。在这种情况下，由于您使用的是kind，因此没有配置负载均衡器，并且此测试来自集群内部。如果有可用的负载平衡器，也可以在外部进行相同的测试。速率限制只是Kong如何满足整体微服务策略和最佳实践的安全考虑，并可以轻松提供全面解决方案的一个例子。Kong维护了几个插件和产品，使通信渠道万无一失，API更改影响最小，应用程序域易于管理。此外，它与大多数编程语言和供应商选项兼容。7.指标和监控基于微服务的架构可以导致成百上千个小型模块化服务的大规模扩展。虽然这为提高速度、可用性和覆盖范围带来了巨大潜力，但庞大的微服务系统需要一种战略性和系统性的监控方法。通过密切关注所有微服务，您将确保它们正常运行、可供用户使用并正确使用资源。当这些期望中的任何一个没有得到满足时，可以采取适当的行动来处理它们。目前有几种广泛采用的监控解决方案可以无缝集成到基础设施中。一些解决方案使用MetricsExporterSDK，可以通过向微服务添加一行或两行代码来集成它。其他的可以作为插件与API网关或服务网格集成，以监控网络问题和资源使用情况。通过监控您的微服务并清楚地显示数字，您可以就如何保持微服务健康和可用做出明智的决定。这样做，用户就会感到满意。当监控工具收集指标时，可视化工具和仪表板可以使用这些指标来帮助查看微服务背后的数字。例如，上周三晚上8点有多少用户在线？自发布此新功能以来，CPU负载增加了多少？产品运输API和发票API之间的延迟是多少？Epilogue微服务是一段激动人心的旅程。企业在开始时就可以从更快的部署和可扩展性、减少的停机时间以及整体提高的业务可用性中受益匪浅。然后添加编排平台，以及Kong及其插件支持的一些好的实践。以上只涵盖了Kong可以做的一小部分，因此强烈建议检查KongHub中可用的所有功能以简化微服务之旅。原标题：开发者的7个微服务最佳实践，作者：MichaelBogan
