微服务架构下的若干常用设计模式

禅あ思 2018-09-17 15:44:06 ⋅ 149 阅读

作者:向日葵Kevin

原文链接:https://www.toutiao.com/a6601430174107959811


在我们选择了用微服务架构来设计、交付数字化应用后,因微服务架构本身所带来的一些共性问题,比如各微服务团队之间的分工合作,数据存储,分布式事务,服务注册与发现等,必须得到很好的解决。幸运的是,我们已经有一些比较成熟的设计模式来解决上述问题。这些模式在我的一些项目中也有所应用。

一. 独立数据库设计模式

问题:

我们按照领域模型拆分了微服务,每个微服务由一个独立的团队负责开发

1. 我们希望这些微服务是松耦合的,能够独立部署,独立扩展

2. 某些情况下,不同的微服务有不同的数据存储要求,有的希望用SQL数据库,有的希望用No-SQL数据库

设计模式:

每一个微服务都拥有自己的数据库,一个微服务希望访问另外一个微服务的数据时,必须通过API访问,而不是通过数据库表的关联查询。

独立数据库设计模式

优点:

1. 微服务之间是松耦合的,某个微服务修改数据库表结构,不会影响其它微服务

2. 每个微服务都可以使用最符合自己需求的数据库

负面影响:

1. 跨数据库的数据查询需在应用程序本身完成,不能通过数据库表的关联查询完成

2. 处理跨多个微服务的事务是一个挑战

二. Saga设计模式

问题:

前面提到,当我们采用微服务模式,并且每个微服务都拥有自己独立的数据库,如何处理跨多个微服务的事务是一个挑战,即如何保证数据在多个微服务之间的一致性?

设计模式:

把一个跨多个微服务的长事务拆分成一个有多个本地事务的序列,即saga。每一个微服务更新本地数据库后发送一个事件到下一个微服务。如果其中一个微服务的事务失败,则触发一系列补偿事务,以取消前序微服务已完成的变更。

该设计模式有两种类型

无中心协调者saga模式:每一个微服务触发事件到下一个微服务,即每一个微服务知道自己要把事件送给哪些微服务

无中心协调者saga模式

有中心协调者saga模式:每一个微服务触发事件到中心协调者,由中心协调者确定发送什么指令到哪一个微服务。

有中心协调者saga模式

优点:

无需使用复杂的分布式事务协议(如2PC,3PC)

负面影响:

编程比较复杂,每个微服务需要实现补偿事务,参与事务的方法还需要实现冥等

为保证本地业务数据更新后可靠的发送事件,需要额外的解决方案

三. 事件溯源Event sourcing设计模式

问题:

前面提到,在采用saga设计模式处理跨多个微服务的长事务时,如何保证本地业务数据更新后可靠的发送事务?目前还没有一个成熟的机制来保证数据库(如MySQL)和消息队列服务(如RabbitMQ)之间的事务一致性。

设计模式:

在业务数据发生变化的时候,把触发改变化的事件记录到Event store事件表中,同时发送事件到事件总线(如RabbitMQ)。微服务定期扫描Event store事件表,对发送失败的事件重发。同时,因为Event store中保存了业务数据变化的所有事件,我们可以通过回放事件获取业务数据在任何时刻的状态。若希望在保存事件的同时,同步更新本地业务数据的最终状态,可以通过数据库的事务来确保两个数据操作的事务一致性。

事件溯源Event sourcing设计模式

优点:

解决了在事件驱动架构中可靠发送事件的问题

100%记录业务数据变化事件,可以通过事件回放追溯业务数据在任一时刻点的状态

负面影响:

编程更复杂

查询业务最终状态时,需要回溯业务数据的所有事件,导致查询效率低下,需要通过其他方法解决。

四. CQRS设计模式

问题:

当我们采用微服务架构,每个微服务都有自己独立的数据库,我们无法通过数据库表的关联查询实现跨微服务数据库的多表查询,甚至我们采用事件溯源设计模式,我们只保存了改变业务数据的事件,如何实现数据的高效查询?

设计模式:

把应用分成两部分,命令部分和查询部分。命令部分负责数据的增,删,修改,同时负责在业务数据变化的时候发送事件;查询部分负责数据的查询,同时负责监听业务数据变化事件,更新业务数据最新状态。

CQRS设计模式

优点:

在采用微服务架构后,提升查询效率

改进业务数据变化的命令模型和业务数据检索时的查询模型

负面影响:

增加了编程的复杂性

可能会有冗余数据和重复代码

复制延迟,最终一致的数据视图

五. API网关设计模式

问题:

当采用微服务架构后,客户端如何访问后台服务,客户端开发人员如何知道后台提供了哪些服务?

设计模式:

客户端通过API 网关访问后台服务

API网关设计模式

优点:

常见的API 网关除了把客户端请求路由到对应的微服务外,还提供安全,限流,监控等功能,同时也支持微服务开发者描述API的能力

负面影响:

增加了额外的网络时延-虽然对于大多数应用来说,这点网络时延对用户体验来说根本感觉不出来。

除了上面描述的5个常用设计模式,在微服务架构下还有以下设计模式也是经常用到的:

日志聚集设计模式: 把所有微服务产生的日志集中到一起,便于查询,比如开源的ELK,商业的Splunk都提供日志聚集解决方案。

分布式追踪设计模式:当客户端调用微服务的时候,生成一个唯一的trace id,用于跟踪客户端每一次后台API调用经历的所有微服务极其日志。每个微服务的日志都记录这个trace id及这次调用的开始结束时间和其它日志。

---------------END----------------

后续的内容同样精彩

长按关注“IT实战联盟”哦



全部评论: 0

    我有话说:

    「轻阅读」聊一聊6种常用架构设计模式(上)

      许多现代应用都需要在企业级规模上进行构建,有时甚至需要在互联网规模上进行构建。这些应用都需要满足可扩展性、可用性、安全性、可靠性和弹性需求。 在本文中,我将谈论一些设计模式,这些模式

    架构实战篇:认识一服务架构

    服务是一个新兴软件架构,就是把一个大型单个应用程序和服务拆分为数十个支持服务

    服务架构:搭建网站扫码登录功能设计

    信扫码登录大家都是应用比较多登录方式了,现在大购物网站像京东、淘宝等都支持使用APP扫码登录网站了。今天就APP扫码登录网站实例来举例说明服务架构搭建过程。

    老板逼你上服务了吗?

    “ 这些年软件设计规模越来越庞大,业务需求也越来越复杂,针对系统性能、高吞吐率、高稳定性、高扩展等特性提出了更高要求。   图片来自 Pexels可以说业务需求是软件架构能力

    精品推荐:服务架构静态数据通用缓存机制

    在分布式系统中,特别是最近很火服务架构,有没有或者能不能总结出一个业务静态数据通用缓存处理机制或方案,这篇文章将结合一些实际研发经验,尝试理清其中存在关键问题以及探寻通用解决之道。

    【分享】一次单体架构改造成服务架构拆分实践

    从5个方面设计这次服务拆分方案,以及经验总结!

    「转载」服务分布式架构中,如何实现日志链路跟踪?

    背景 开发排查系统问题得最多手段就是查看系统日志,在分布式环境中一般使用ELK来统一收集日志,但是在并发大时使用日志定位问题还是比较麻烦,我们来看下面图     上图

    【开源资讯】JWCloud 专业版 v1.0.0 发布,基于 SpringCloud 研发服务框架

    简介 JavaWeb_Cloud 服务平台是一款基于 SpringCloud 框架研发分布式微服务框架,主要使用技术栈包括: SpringCloud、Vue、ElementUI

    服务架构学习笔记(一):重新认识服务

    服务(Microservice)是服务化思路一种最佳实践方向,遵循SOA思路,各个企业在服务化治理道路上走时间长了,踩坑多了,整个软件交付链路上各个环节基础设施逐渐成熟了,服务

    架构实战篇:一个可供中小团队参考服务架构技术栈

    作者近年一直在一线互联网公司(携程,拍拍贷等)开展服务架构实践,根据我个人一线实践经验和我平时对Spring Cloud调研,我认为Spring Cloud技术栈中有些组件离生产级开发尚有

    码云推荐:一个优秀分布式spring boot/Spring Cloud API限流框架,特别适合服务架构

    一个优秀分布式spring boot/Spring Cloud API限流框架,特别适合服务架构.

    缓存架构设计要点

    缓存典型应用场景和设计要点

    「轻阅读」阿里云-开放平台高级技术家教你搭建服务架构四大金刚利器

    孔凡勇,花名云狄,阿里云-开放平台高级技术家,对高并发、高性能、高可、可伸缩分布式系统架构设计有丰富经验,Cloud Native坚定拥护者,坚守开发一线打磨匠艺架构师。

    「轻阅读」从MySQL高可用架构看高可用架构设计

    高可HA(High Availability)是分布式系统架构设计中必须考虑因素之一

    创业团队如何设计支撑百万并发数据库架构

    我们来聊一下对于一个支撑日活百万用户高并系统,他数据库架构应该如何设计?

    Spring中9种设计模式汇总

    Spring中9种设计模式汇总

    「转载」使用DDD指导业务设计一点思考

    领域驱动设计(DDD) 是 Eric Evans 提出一种软件设计方法和思想,主要解决业务系统设计和建模。DDD 有大量难以理解概念,尤其是翻译原因,某些词汇非常生涩,例如:模型、限界上下文

    架构设计原则 - 高并发

    高并发设计可以从以下几方面考虑:无状态拆分服务化消息队列数据异构缓存并发化1. 无状态无状态应用容易进行水......

    一分钟认识服务网关zuul及案例实操

    服务架构模式后端服务实例数一般是动态,对于客户端而言很难发现动态改变服务实例访问地址信息。