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