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