请选择 进入手机版 | 继续访问电脑版

设为首页 收藏本站
思科社区 关注
思科社区

搜索
热搜: 邮件服务器
查看: 419|回复: 1

【原创翻译】一篇看尽微服务的设计模式(1)

[复制链接]
发表于 2020-2-8 18:30:50 | 显示全部楼层 |阅读模式

引言:让我们通过本文来详细了解微服务架构的各种设计模式。
如今,微服务架构实际上已经成为了现代应用开发的首选。虽然它能够解决大部分的程序问题,但是它并非一颗百试不爽的“银弹”。在采用这种架构之前,我们应当事先了解可能出现的各种问题及其共性,预先为这些问题准备好可重用的解决方案。那么,在开始深入讨论微服务的不同设计模式之前,让我们先了解一下微服务架构的一些构建原则:
1.  可扩展性
2.  可用性
3.  弹性
4.  独立、自主性
5.  去中心化治理
6.  故障隔离
7.  自动调配
8.  通过DevOps实现持续交付
在现上述各条原则的同时,我们难免会碰到一些挑战。下面我们来具体讨论可能出现的各种问题、及其解决方案。
1.分解模式
A. 按照业务功能分解
问题
微服务是有关松散耦合的服务,它采用的是单一职责原则。虽然我们在逻辑原理上都知道要将单个应用分成多个小块,但是在实际操作中,我们又该如何将某个应用程序成功分解成若干个小的服务呢?
解决方案
有一种策略是按照业务功能进行分解。此处的业务功能是指能够产生价值的某种业务的最小单位。那么一组给定业务的功能划分则取决于企业本身的类型。例如,一家保险公司的功能通常会包括:销售、营销、承保、理赔处理、结算、合规等方面。每一个业务功能都可以被看作是一种面向业务、而非技术的服务。
B. 按照子域分解
问题
按照业务功能对应用程序进行分解只是一个良好的开端,之后您可能会碰那些不易分解的所谓“神类”God Classes)。这些类往往会涉及到多种服务。例如,订单类就会被订单管理、订单接受、订单交付等服务所使用到,那么我们又该如何分解呢?
解决方案
对于“神类”的问题,DDDDomain-Driven Design,领域驱动设计)能够派上用场。它使用子域subdomain)和边界上下文bounded context)的概念来着手解决。DDD会将企业的整个域模型进行分解,并创建出多个子域。每个子域将拥有一个模型,而该模型的范围则被称为边界上下文。那么每个微服务就会围绕着边界上下文被开发出来。
注意:识别子域并不是一件容易的事,我们需要通过分析业务与组织架构,识别不同的专业领域,来对企业加强了解。
C. 刀砍模式(Strangler Pattern
问题
前面我们讨论的设计模式一般适用于针对那些“白手起家”的greenfield应用进行分解。但是我们真实接触到的、约占80%的是brownfield应用,即:一些大型的、单体应用monolithic application)。由于它们已经被投入使用、且正在运行,如果我们简单按照上述方式,同时对它们进行小块服务的分解,将会是一项艰巨的任务。
解决方案
此时,刀砍模式Strangler pattern)就能派上用场了。我们可以把扼杀模式想象为用刀砍去缠在树上的藤蔓。该方案适用于那些反复进行调用的Web应用程序。对于每一个URI(统一资源标识符)的调用来说,单个服务可以被分解为不同的域和单独的子服务。其设计思想是一次仅处理一个域。这样,我们就可以在同一个URI空间内并行地创建两套独立的应用程序。最终,在新的应用重构完成后,我们就能“刀砍”或替换掉原来的应用程序,直到最后我们可以完全关闭掉原来的单体应用。
2.集成模式
A. API网关模式
问题
当一个应用程序被分解成多个小的微服务时,我们需要关注如下方面:
1.  如何通过调用多个微服务,来抽象出producer(生产者)的信息。
2.  在不同的渠道上(如电脑桌面、移动设备和平板电脑),应用程序需要不同的数据来响应相同的后端服务,比如:UI(用户界面)就可能会有所不同。
3.  不同的consumer(消费者)可能需要来自可重用式微服务的不同响应格式。谁将去做数据转换或现场操作?
4.  如何处理不同类型的协议?特别是一些可能不被producer微服务所支持的协议。
解决方案
API网关将有助于解决在微服务实施过程中所涉及到的上述关注点:
1.  API网关是任何微服务调用的统一入口。
2.  它像代理服务一样,能够将一个微服务请求路由到其相关的微服务处,并抽象出producer的细节。
3.  它既能将一个请求扇出fan out,输出)到多个服务上,也能汇总多个结果,并发回给consumer
4.  鉴于通用API无法解决consumer的所有请求,该方案能够为每一种特定类型的客户端创建细粒度的API
5.  它也可以将某种协议请求(如:AMQP)转换为另一种协议(如:HTTP),反之亦然,从而方便了producerconsumer的处理。
6.  它也可以将认证与授权存储库从微服务中卸载出去。
B. 聚合器模式
问题
虽然我们已经在API网关模式中讨论了如何解决聚合数据的问题,不过我们此将做进一步的讨论。当我们将业务功能分解成多个较小的逻辑代码块时,有必要思考每个服务的返回数据是如何进行协作的。显然,该责任不会留给consumer,那么我们就需要理解producer应用的内部实现。
解决方案
聚合器模式将有助于解决该问题。它涉及到如何聚合来自不同服务的数据,然后向consumer发送最终响应。具体说来,我们有如下两种实现方法:
1.  复合微服务composite microservice)将会去调用全部所需的微服务,整合各种数据,并在回传之前转换数据。
2.  API网关API Gateway)也能对多个微服务的请求进行partition(分区),并在发送给consumer之前聚合数据。
我们建议:如果您用到了任何业务逻辑的话,请选用复合微服务;否则请采用API网关方案。
C. 客户端UI合成模式
问题
当各种服务按照业务功能和子域被分解开发时,它们需要根据用户体验的预期效果,从一些不同的微服务中提取数据。在过去的单体应用中,我们只要从UI到后端服务的唯一调用中获取所有的数据,并刷新和提交到UI页面上便可。如今,情况则不同了。
解决方案
对于微服务来说,UI必须被设计成单屏、单页面的多段、多区域的结构。每一段都会去调用单独的后端微服务,以提取数据。像AngularJSReactJS之类的框架都能够实现为特定的服务合成UI组件。通过被称为单页应用Single Page ApplicationsSPA)的方式,它们能够使得应用程序仅刷新屏幕的特定区域,而不是整个页面。
3.数据库模式
A. 按服务分配数据库
问题
您可能会碰到如何定义数据库架构的微服务问题。下面是具体的关注点:
1.  服务必须是松散耦合的,以便能够被二次开发、部署和独立扩容。
2.  各个业务交易需要在横跨多个服务时,仍保持不变。
3.  某些业务交易需要从多个服务中查询到数据。
4.  数据库有时需要根据规模需求被复制与分片。
5.  不同的服务具有不同的数据存储需求。
解决方案
为了解决上述需求,我们需要通过设计为每个微服务配备一个独享的数据库模式。即:该数据库仅能被其对应微服务的API单独访问,而不能被其他服务直接访问到。例如,对于关系型数据库,我们可以使用:按服务分配私有表集private-tables-per-service)、按服务分配表结构schema-per-service)、或按服务分配数据库服务器database-server-per-service)。每个微服务应该拥有一个单独的数据库ID,以便它们在独享访问的同时,禁止再访问其他的服务表集。
B. 按服务共享数据库
问题
上面讨论的按服务分配数据库是一种理想的微服务模式,它一般被前面提到的greenfield应用和DDD式的开发。但是,如果我们面对的是需要采用微服务的单体应用就没那么容易了。
解决方案
按服务共享数据库的模式虽然有些违背微服务的理念,但是它对于将前面提到的brownfield应用(非新建应用)分解成较小的逻辑块是比较适用的。在该模式下,一个数据库可以匹配不止一个的微服务,当然也至多23个,否则会影响到扩容、自治性和独立性。
C. 命令查询职责隔离(Command Query Responsibility SegregationCQRS
问题
对于按服务分配数据库的模式而言,我们如何在微服务的架构中,实现对多个服务进行联合查询数据的需求呢?
解决方案
CQRS建议将应用程序拆分成两个部分:命令和查询。命令部分主要处理创建、更新和删除之类的请求;查询部分则利用物化视图materialized views)来处理各种查询。它通常配合事件溯源模式event sourcing pattern)一起创建针对任何数据的变更事件。而物化视图则通过订阅事件流,来保持更新。
D. Saga模式
问题
当每个服务都有自己的数据库,而且业务交易横跨多个服务时,我们该如何确保整体业务数据的一致性呢?例如:对于某个带有客户信用额度标识的电商应用而言,它需要确保新的订单不会超出客户的信用额度。但是,由于订单和客户分属不同的数据库,应用程序无法简单地实现本地交易的ACID(原子性、一致性、隔离性、持久性)特性。
解决方案
Saga代表了一个高层次的业务流程,它是由一个服务中的多个子请求,并伴随着逐个更新的数据所组成。在某个请求失败时,它的补偿请求会被执行。其实现方式有如下两种:
1.  编排Choreography):没有中央协调器,每个服务都会产生并侦听其他服务的事件,以决定是否应采取行动。
协调Orchestrator):由一个中央协调器(对象)负责集中处理某个事件(saga)的决策,和业务逻辑的排序。
  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
平均得分0 (0 评价)
发表于 2020-2-10 11:23:59 | 显示全部楼层
感谢版主分享,谢谢!

相关链接:
【原创翻译】一篇看尽微服务的设计模式(1)
  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
平均得分0 (0 评价)
您需要登录后才可以回帖 思科 CCO 登录 | 思科 CCO 注册   

本版积分规则

Archiver | 思科社区  

GMT+8, 2020-3-28 23:29 , Processed in 0.101902 second(s), 36 queries .

京ICP备11014401号-17

© 2020 思科系统.版权所有 重要声明 | 保密声明 | 隐私权政策 | 商标 |

快速回复 返回顶部 返回列表