微服务从根本上改变了服务器端引擎的构建方式。微服务不是托管所有应用程序业务逻辑的单一巨型代码库，而是反映分布式系统模型，在该模型中，一组应用程序组件协同工作以满足业务需求。通过遵循十个基本的微服务最佳实践，您可以在没有不必要的架构复杂性的情况下实现高效的微服务生态系统。微服务架构的好处当从单体应用程序正确地迁移到微服务架构时，应该实现以下好处：您应该能够使用您选择的语言开发微服务，按照自己的步调独立发布它，并且独立扩张。由于组织中的不同团队可以独立拥有某些微服务，因此随着并行开发和重用的增加，上市时间应该会更快。您可以更好地隔离故障，因为可以包含一个特定微服务中的错误，因此它不会影响生态系统的其余部分。但是，如果您在构建微服务时不遵循正确的原则，您最终可能会遇到像这样纠缠不清的意大利面条。这很难维护，因为它需要与多个团队进行大量协调才能进行更改、发布或实现容错。充分利用微服务是一门科学，涉及多个学科。以下微服务最佳实践和设计原则将帮助您构建松散耦合、分布式和优化的微服务，以获得卓越的价值。微服务的10个最佳实践1.单一职责原则就像代码一样，只有一个原因可以改变一个类，微服务应该以类似的方式建模。构建可以更改多个业务上下文的臃肿服务是一种不好的做法。示例：假设您正在构建用于订购比萨饼的微服务。可以考虑根据各自支持的功能（如InventoryService、OrderService、PaymentsService、UserProfileService、DeliveryNotificationService等）构建以下组件。InventoryService只有API来获取或更新披萨类型或配料库存，同样其他API也将具有这些功能。2.为你的微服务提供单独的数据存储如果你使用一个由所有微服务共享的单体数据库，你就违背了微服务的目的。该数据库的任何更改或停机都会影响使用该数据库的所有微服务。选择适合您的微服务需求的数据库，为其维护的数据定制基础架构和存储，并使其对您的微服务而言独一无二。理想情况下，任何其他需要访问该数据的微服务只能通过具有写访问权限的微服务公开的API来访问它。3.使用异步通信实现松散耦合为了避免构建紧密耦合组件的网格，可以考虑在微服务之间使用异步通信。一。异步调用您的依赖项，如以下示例。示例：假设您有一个服务A调用服务B。在服务B返回响应后，服务A将成功返回给调用者。如果调用者对服务B的输出不感兴趣，服务A可以异步调用服务B，并立即成功响应调用者。b.更好的选择是使用事件在微服务之间进行通信。您的微服务会将事件发布到消息总线以指示状态更改或故障，无论哪个微服务对该事件感兴趣，都会对其进行处理。示例：在上面的比萨饼订单系统中，异步通信用于在捕获订单后或使用订单完成和交付状态消息时向客户发送通知。通知服务可以侦听订单已提交的事件并处理对客户的通知。4.使用断路器快速容错如果您的微服务依赖于另一个系统来提供响应，而该系统需要很长时间才能响应，那么您的整体响应SLA??将受到影响。为避免这种情况并快速响应，您可以遵循的一个简单的微服务最佳实践是使用断路器使外部调用超时并返回默认响应或错误。断路器模式在以下参考资料中进行了描述。这将隔离您的服务所依赖的失败服务，而不会出现级联故障，从而使您的微服务保持健康。您可以选择使用Netflix开发的热门产品，例如Hystrix。这比使用HTTPCONNECT_TIMEOUT和READ_TIMEOUT设置要好，因为它不会启动超出配置的额外线程。5.不是让系统中的每个微服务通过API网关代理你的微服务请求来执行API身份验证、请求/响应日志记录和节流，让API网关预先为你做这些会增加很多价值。调用您的微服务的客户端将连接到API网关，而不是直接调用您的服务。这样，您将避免从您的微服务进行所有这些其他调用，并且该服务的内部URL将被隐藏，从而使您可以灵活地将流量从API网关重定向到该服务的更新版本。这在第三方访问您的服务时更为必要，因为您可以限制传入流量并在API网关到达您的微服务之前拒绝未经授权的请求。您还可以选择拥有一个单独的API网关来接受来自外部网络的流量。6.确保您的API更改是向后兼容的您可以自信地更改您的API并快速发布它们，而不会破坏现有的调用者。一种可能的选择是通知您的呼叫者并让他们通过运行集成测试来签署您的更改。然而，这是昂贵的，因为所有依赖项都需要在一个环境中排队，这会减慢您的协调工作。更好的选择是为您的API使用合同测试。API的消费者根据他们对API的预期响应提供合同。作为提供者，您会将这些合同测试集成为构建的一部分，这些将防止破坏性更改。消费者可以针对您作为消费者构建的一部分发布的存根进行测试。这样，您可以通过独立测试合同变更来更快地投入生产。7.为破坏性变更对微服务进行版本控制并不总是可以进行向后兼容的变更。进行重大更改时，公开端点的新版本，同时继续支持旧版本。消费者可以在方便的时候选择使用新版本。但是，API版本太多会给维护代码的人带来噩梦。因此，有一种规范的方式可以与您的客户合作，或者在内部将流量重新路由到新版本，从而弃用旧版本。8.拥有专门的基础设施来托管你的微服务你可以设计出最好的微服务来满足所有的检查，但如果托管平台设计不当，它的性能仍然会很差。将您的微服务基础架构与其他组件隔离，以实现故障隔离和高性能。隔离微服务所依赖的组件的基础设施也很重要。示例：在上面的披萨订单示??例中，假设库存微服务使用库存数据库。不仅拥有具有专用托管的库存服务很重要，而且库存数据库也需要专用托管也很重要。9.创建一个单独的发布系列你的微服务需要有自己独立的发布工具，不应该绑定到组织中的其他组件。这样，您就不会踩到彼此的脚趾，也不会浪费时间与多个团队协调。10.建立组织效率虽然微服务给了你独立开发和发布的自由，但对于横切关注点，需要遵循某些标准，这样每个团队就不会花时间为这些问题创建独特的解决方案。这在像微服务这样的分布式架构中非常重要，您需要能够连接拼图的所有部分才能看到全局。因此，API安全、日志聚合、监控、API文档、机密管理、配置管理、分布式跟踪等都需要企业解决方案。最后，通过遵循这些微服务最佳实践，您应该最终得到一个松散耦合、分布式和独立的微服务系统，您可以在其中实现本文开头列出的微服务架构的真正好处。
