微服务架构设计原则

目录

单一责任原则

类似于编写函数代码,每个函数只提供一个具体的功能。

例如:你正在构建用于订购披萨的微服务。你可以基于单一责任原则构建下述组件来提供完整的服务,诸如:

  • InventoryService
  • OrderService
  • PaymentService
  • UserProfileService
  • DeliveryNotificationService

InventoryService 仅仅有获取或更新披萨种类或配料库存相关的API,同样的,其他也只会提供对应功能的 API。

独立数据存储原则

如果你的所有微服务都共享一个数据库,这就违背了使用微服务的目的。因为对这个统一数据库的任何的改变或者故障都会影响到使用该数据库的所有微服务。

根据微服务的需要选择正确的数据库,定制化基础设施以及对应数据的存储,并且让微服务独占它。理想情况下,任何需要访问该数据的其他微服务只能通过拥有写权限的微服务提供的 API 来访问。

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

在这里插入图片描述

同步调用还是异步调用?

  • 同步调用:简单,一致性强,但是容易出调用问题,性能体验上也会差些,特别是调用层次多的时候。
  • 异步调用:既能减低调用服务之间的耦合,又能成为调用之间的缓冲,确保消息积压不会冲垮被调用方,同时能保证调用方的服务体验,继续干自己该干的活,不至于被后台性能拖慢。不过需要付出的代价是一致性的减弱,需要接受数据最终一致性。还有就是后台服务一般要 实现幂等性,因为消息发送出于性能的考虑一般会有重复(保证消息的被收到且仅收到一次对性能是很大的考验)。最后就是必须引入一个独立的 Broker(e.g. MQ),如果公司内部没有技术积累,对 Broker 分布式管理也是一个很大的挑战。

为了避免构建出一个紧密耦合的组件网格(Mesh),可以考虑在微服务之间使用异步通信。例如:服务 A 依赖服务 B。当服务 B 返回响应消息,服务 A 再返回成功给调用服务 A 的调用者。如果调用者对服务 B 的内容不关心,那么服务 A 可以异步调用服务 B,并且这个时候可以立即返回成功给调用者。

一个更好的选择是在微服务通信之间使用事件机制。你的微服务可以发布一个事件消息到消息总线上,可以用来通知一个状态的改变或者一个失败事件,并且任何对该事件感兴趣的微服务都可以获得该消息然后做出相应的处理。例如:上面提到的披萨订单系统中,当客户的订单被接收到或者订单已经完成以及运输的状态消息都可以使用异步通信给客户发送通知消息。通知服务可以监听订单提交的消息事件然后将相应的通知推送给客户。

REST 还是 RPC?

  • REST:基于 HTTP 协议,更容易实现,服务端技术选型也更灵活些,各个语言都能支持,同时能跨客户端,对客户端没有特殊的要求,只要封装了 HTTP SDK 就能调用,所以相对使用的广一些。
  • RPC:传输协议更高效,安全更可控,特别在一个公司内部,如果有统一个的开发规范和统一的服务框架时,他的开发效率优势更明显些。

通过 APIGW 代理微服务请求

相比于系统中的每个微服务都单独提供 API 授权,使用一个单独 APIGW 做这些事情会更有价值。调用微服务的客户端可以连接到 APIGW 而不是直接调用微服务的接口。这种方式可以让微服务避免做那些额外的调用,并且微服务内部 URL 也可以被隐藏,这可以更灵活的从 APIWG 重定向流量到一个微服务的更新版本。

当允许第三方访问微服务时,那么更有必要使用这种方式,因为可以在请求到达微服务之前对传入流量进行限流以及拒绝来自 APIGW 的未授权请求。

确保 API 变更向后兼容

你可以安全的对 API 进行变更并且快速的发布它们,只要这些改变不影响已有的调用者。一种可能的选项是通知你的调用者,让他们通过集成测试来对做出的变更进行验证。但是,这种代价会比较高,因为所有依赖项都需要在一个环境中排队,这会使你的协调工作变慢。

一个更好的选项是对你的 API 使用合约测试。你的 API 消费者对 API 提供预期响应结果的合约。作为 API 提供者的你可以集成这些合约测试作为你构建的一部分并且这些可以安全的保证重大的 API 变更。消费者可以测试你发布的存根(stubs)作为他们构建的一部分。这种方式可以让你通过独立测试合约变更来更快速的发布产品。

版本化微服务的重大变更

不可能让变更总是保持向后兼容。当你做了一个重大的变更的时候,同时需要继续支持老的接口,这时候可以暴露一个新版本的接口。消费者可以在方便的时候选择新的版本。

但是有太多版本的 API 对于维护相应的代码人来说会是一场噩梦。因此,有一种规范的方法是通过和客户端一起协作或在内部将流量重新路由到较新的版本,从而弃用较旧的版本。

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

如果微服务依赖于另一个系统来提供响应,并且该系统需要很长时间才会响应,那么微服务的总体响应 SLA 将会受到影响。为了避免这种场景并且快速做出响应,你需要遵循的一个简单的微服务最佳实践就是使用熔断器来使外部的调用超时,然后返回一个默认响应或者错误。

熔断模式可以隔离故障服务,而不会导致级联故障,可以让整个服务系统保持在健康的状态。我们可以选择使用 Netflix 开发的 Hystrix,这要比使用 HTTP 的 CONNECT_TIMEOUT 和 READ_TIMEOUT 更好,因为它不会启动超出配置范围的其他线程。

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

将微服务基础设施与其他组件隔离可以实现故障隔离和最佳性能,隔离微服务依赖的组件基础设施也同样重要。

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

创建独立的发布流水线

微服务需要有一个单独的 CI/CD 流水线,这个独立的流水线不和你所在组织中的其他组件关联。这样的话你就不会和别人有冲突以及浪费和多个团队协调的时间。

建立组织效率

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

©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页
实付 49.00元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值