10个微服务架构设计的最佳实践

2. 独立的数据存储

===========

如果你的所有微服务都共享一个数据库，这就违背了使用微服务的目的。对这个数据库的任何的改变或者故障都会影响使用该数据库的所有微服务。根据微服务的需要选择正确的数据库，定制化基础设施以及对应数据的存储，并且让你的服务独占它。理想情况下，任何需要访问该数据的其他微服务只能通过拥有写权限的微服务提供的API来访问。

3. 使用异步通信实现松散耦合

================

为了避免构建出一个紧密耦合的组件网格（Mesh），可以考虑在微服务之间使用异步通信。

a. 对依赖的服务异步调用，如下例子。

例如：有一个服务A依赖服务B的例子。当服务B返回响应消息，服务A再返回成功给调用服务A的调用者。如果调用者对服务B的内容不关心，那么服务A可以异步调用服务B，并且这个时候可以立即返回成功给调用者。

b. 一个更好的选择是在微服务通信之间使用事件机制。你的微服务可以发布一个事件消息到消息总线上，可以用来通知一个状态的改变或者一个失败事件，并且任何对该事件感兴趣的微服务都可以获得该消息然后做出相应的处理。

例如：上面提到的披萨订单系统中，当客户的订单被接收到或者订单已经完成以及运输的状态消息都可以使用异步通信给客户发送通知消息。通知服务可以监听订单提交的消息事件然后将相应的通知推送给客户。

4. 使用熔断器快速实现故障容错

=================

如果你的微服务依赖于另一个系统来提供响应，并且该系统需要很长时间才会响应，那么你的总体响应SLA将会受到影响。为了避免这种场景并且快速做出响应，你需要遵循的一个简单的微服务最佳实践是使用熔断器来使外部的调用超时，然后返回一个默认响应或者错误。熔断器模式可以参考最下面的引用。这种方式可以隔离故障服务，而不会导致级联故障，可以让你的服务保持在健康的状态。你可以选择使用流行的产品，比如Netflix开发的Hystrix。这要比使用HTTP CONNECT_TIMEOUT和READ_TIMEOUT设置更好，因为它不会启动超出配置范围的其他线程。

5. 通过API网关代理微服务请求

==================

相比于系统中的每个微服务都单独提供API授权，请求/相应日志以及限流功能，使用一个单独API网关做这些事情会更有价值。调用你微服务的客户端可以连接到API网关而不是直接调用微服务接口。这种方式可以让你的微服务避免做那些额外的调用，并且微服务内部URL可以被隐藏，这可以让你更灵活的从API网关重定向流量到一个微服务的更新版本。当允许第三方访问你的微服务时，那么更有必要使用这种方式，因为你可以在请求到达微服务之前对传入流量进行限流以及拒绝来自API网关的未授权请求。你也可以选择一个单独的外部网关，让它可以接收外部网络的流量。

6. 确保API变更向后兼容

===============

你可以安全的对API进行变更并且快速的发布它们，只要这些改变不影响已有的调用者。一种可能的选项是通知你的调用者，让他们通过集成测试来对做出的变更进行验证。但是，这种代价会比较高，因为所有依赖项都需要在一个环境中排队，这会使你的协调工作变慢。一个更好的选项是对你的API使用合约测试。你的API消费者对API提供预期响应结果的合约。作为API提供者的你可以集成这些合约测试作为你构建的一部分并且这些可以安全的保证重大的API变更。消费者可以测试你发布的存根（stubs）作为他们构建的一部分。这种方式可以让你通过独立测试合约变更来更快速的发布产品。

7. 版本化微服务重大变更

==============

不可能让变更总是保持向后兼容。当你做了一个重大的变更的时候，同时需要继续支持老的接口，这时候可以暴露一个新版本的接口。消费者可以在方便的时候选择新的版本。但是有太多版本的API对于维护相应的代码人来说会是一场噩梦。因此，有一种规范的方法是通过和客户端一起协作或在内部将流量重新路由到较新的版本，从而弃用较旧的版本。

8. 使用专用基础设施托管微服务

=================

你已经开发出了满足所有检查的最好的微服务，但是使用了一个很差的托管平台，那么最终的效果依然会表现的很差。将你的微服务基础设施与其他组件隔离可以实现故障隔离和最佳性能。隔离微服务依赖的组件基础设施也同样重要。

例如：上面披萨订单的案例中，库存微服务使用库存数据库。使用专用的托管机器不仅对于库存微服务很重要，而且对于库存数据库同样也很重要。

9. 创建独立的发布通道

=============

你的微服务需要有一个单独的发布通道，这个通道不和你所在组织中的其他组件关联。这样的话你就不会和别人有冲突以及浪费和多个团队协调的时间。

10. 建立组织效率

===========

尽管微服务给你提供了独立开发和发布的自由，但是对于跨领域关注（cross cutting concerns）来说，某些标准还是需要遵循的，这样才不会让每个团队都花费时间为这些问题创建独特的解决方案。这在诸如微服务分布式架构中是非常重要的，在这种架构中，你需要能够连接难题（puzzle）中的所有部分才能看清全局。因此，对于API安全，日志聚合，监控，API文档，秘钥管理，配置管理，分布式追踪等，企业级解决方案是必须要有的。
总结

通过遵循这些微服务最佳实践，你可以获得一个松散耦合，分布式以及独立的微服务系统，同时你可以获得本文开头列出的微服务架构的真正好处。

最后

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。

因此收集整理了一份《2024年Web前端开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点！不论你是刚入门Android开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门！

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
友可以戳我获取！！**](https://bbs.csdn.net/topics/618191877)

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！