微服务架构:拆分单体应用的难点

拆分单体应用为服务的难点

从表面上看,通过定义与业务能力或子域相对应的服务来创建微服务架构的策略看起来很简单。但是,你可能会遇到几个障碍:

  • 网络延迟。
  • 同步进程间通信导致可用性降低。 
  • 在服务之间维持数据一致性。
  • 获取一致的数据视图。
  • 上帝类阻碍了拆分。

让我们来看看每个问题,先从网络延迟开始。

网络延迟

网络延迟是分布式系统中一直存在的问题。你可能会发现,对服务的特定分解会导致两个服务之间的大量往返调用。有时,你可以通过实施批处理API在一次往返中获取多个对象,从而将延迟减少到可接受的数量。但在其他情况下,解决方案是把多个相关的服务组合在一起,用编程语言的函数调用替换昂贵的进程间通信。

同步进程间通信导致可用性降低

另一个需要考虑的问题是如何处理进程间通信而不降低系统的可用性。例如,实现createOrder()操作最常见的方式是让Order Service使用REST同步调用其他服务。这样做的弊端是REST这样的协议会降低Order Service的可用性。如果任何一个被调用的服务处在不可用的状态,那么订单就无法创建了。有时候这可能是一个不得已的折中,但是在第3章中学习异步消息之后,你就会发现其实有更好的办法来消除这类同步调用产生的紧耦合并提升可用性。

在服务之间维持数据一致性

另一个挑战是如何在某些系统操作需要更新多个服务中的数据时,仍旧维护服务之间的数据一致性。例如,当餐馆接受订单时,必须在Kitchen Service和Delivery Service中同时进行更新。Kitchen Service会更改Ticket的状态。Delivery Service安排订单的交付。这些更新都必须以原子化的方式完成。

传统的解决方案是使用基于两阶段提交(two phase commit)的分布式事务管理机制。但正如你将在第4章中看到的那样,对于现今的应用程序而言,这不是一个好的选择,你必须使用一种非常不同的方法来处理事务管理,这就是Saga。Saga是一系列使用消息协作的本地事务。Saga比传统的ACID事务更复杂,但它们在许多情况下都能工作得很好。Saga的一个限制是它们最终是一致的。如果你需要以原子方式更新某些数据,那么它必须位于单个服务中,这可能是分解的障碍。

获取一致的数据视图

分解的另一个障碍是无法跨多个数据库获得真正一致的数据视图。在单体应用程序中,ACID事务的属性保证查询将返回数据库的一致视图。相反,在微服务架构中,即使每个服务的数据库是一致的,你也无法获得全局一致的数据视图。如果你需要一些数据的一致视图,那么它必须驻留在单个服务中,这也是服务分解所面临的问题。幸运的是,在实践中这很少带来真正的问题。

上帝类阻碍了拆分

分解的另一个障碍是存在所谓的上帝类。上帝类是在整个应用程序中使用的全局类。上帝类通常为应用程序的许多不同方面实现业务逻辑。它有大量字段映射到具有许多列的数据库表。大多数应用程序至少有一个这样的上帝类,每个类代表一个对领域至关重要的概念:银行账户、电子商务订单、保险政策,等等。因为上帝类将应用程序的许多不同方面的状态和行为捆绑在一起,所以将使用它的任何业务逻辑拆分为服务往往都是一个不可逾越的障碍。

Order类是FTGO应用程序中上帝类的一个很好的例子。这并不奇怪:毕竟FTGO的目的是向客户提供食品订单。系统的大多数部分都涉及订单。如果FTGO应用程序具有单个领域模型,则Order类将是一个非常大的类。它将具有与应用程序的许多不同部分相对应的状态和行为。图6显示了使用传统建模技术创建的Order类的结构。

图6 Order这个上帝类承载了太多的职责

如你所见,Order类具有与订单处理、餐馆订单管理、送餐和付款相对应的字段及方法。由于一个模型必须描述来自应用程序的不同部分的状态转换,因此该类还具有复杂的状态模型。在目前情况下,这个类的存在使得将代码分割成服务变得极其困难。

一种解决方案是将Order类打包到库中并创建一个中央Order数据库。处理订单的所有服务都使用此库并访问访问数据库。这种方法的问题在于它违反了微服务架构的一个关键原则,并导致我们特别不愿意看到的紧耦合。例如,对Order模式的任何更改都要求其他开发团队同步更新和重新编译他们的代码。

另一种解决方案是将Order数据库封装在Order Service中,该服务由其他服务调用以检索和更新订单。该设计的问题在于这样的一个Order Service将成为一个纯数据服务,成为包含很少或没有业务逻辑的贫血领域模型(anemic domain model)。这两种解决方案都没有吸引力,但幸运的是,DDD提供了一个好的解决方案。

更好的方法是应用DDD并将每个服务视为具有自己的领域模型的单独子域。这意味着FTGO应用程序中与订单有关的每个服务都有自己的领域模型及其对应的Order类的版本。Delivery Service是多领域模型的一个很好的例子。如图7所示为Order,它非常简单:取餐地址、取餐时间、送餐地址和送餐时间。此外,DeliveryService使用更合适的Delivery名称,而不是称之为Order。

图7 Delivery Service的领域模型

Delivery Service对订单的任何其他属性不感兴趣。

Kitchen Service有一个更简单的订单视图。它的Order版本就是一个Ticket(后厨工单)。如图8所示,Ticket只包含status、requestedDeliveryTime、prepareByTime以及告诉餐馆准备的订单项列表。它不关心消费者、付款、交付等这些与它无关的事情。

图8 Kitchen Service的领域模型

Order Service具有最复杂的订单视图,如图9所示。即使它有相当多的字段和方法,它仍然比原始版本的那个Order上帝类简单得多。

图9 Order Service的领域模型

每个领域模型中的Order类表示同一Order业务实体的不同方面。FTGO应用程序必须维持不同服务中这些不同对象之间的一致性。例如,一旦OrderService授权消费者的信用卡,它必须触发在Kitchen Service中创建Ticket。同样,如果Kitchen Service拒绝订单,则必须在Order Service中取消订单,并且为客户退款。在第4章中,我们将学习如何使用前面提到的事件驱动机制Saga来维护服务之间的一致性。

除了造成一些技术挑战以外,拥有多个领域模型还会影响用户体验。应用程序必须在用户体验(即其自己的领域模型)与每个服务的领域模型之间进行转换。例如,在FTGO应用程序中,向消费者显示的Order状态来自存储在多个服务中的Order信息。这种转换通常由API Gateway处理,将在第8章中讨论。尽管存在这些挑战,但在定义微服务架构时,必须识别并消除上帝类。

我们现在来看看如何定义服务API。

6 定义服务API

到目前为止,我们有一个系统操作列表和一个潜在服务列表。下一步是定义每个服务的API:也就是服务的操作和事件。存在服务API操作有以下两个原因:首先,某些操作对应于系统操作。它们由外部客户端调用,也可能由其他服务调用。另次,存在一些其他操作用以支持服务之间的协作。这些操作仅由其他服务调用。

服务通过对外发布事件,使其能够与其他服务协作。第4章将描述如何使用事件来实现Saga,这些Saga可以维护服务之间的数据一致性。第7章将讨论如何使用事件来更新CQRS视图,这些视图支持有效的查询。应用程序还可以使用事件来通知外部客户端。例如,可以使用WebSockets将事件传递给浏览器。

定义服务API的起点是将每个系统操作映射到服务。之后确定服务是否需要与其他服务协作以实现系统操作。如果需要协作,我们将确定其他服务必须提供哪些API才能支持协作。首先来看一下如何将系统操作分配给服务。

把系统操作分配给服务

第一步是确定哪个服务是请求的初始入口点。许多系统操作可以清晰地映射到服务,但有时映射会不太明显。例如,考虑使用noteUpdatedLocation()操作来更新送餐员的位置。一方面,因为它与送餐员有关,所以应该将此操作分配给Courier Service。另一方面,它是需要送餐地点的DeliveryService。在这种情况下,将操作分配给需要操作所提供信息的服务是更好的选择。在其他情况下,将操作分配给具有处理它所需信息的服务可能是有意义的。表4显示了FTGO应用程序中的哪些服务负责哪些操作。

表4 FTGO应用程序的系统操作映射到具体的服务

把操作分配给服务后,下一步是确定在处理每一个系统操作时,服务之间如何交互。

确定支持服务协作所需要的API

某些系统操作完全由单个服务处理。例如,在FTGO应用程序中,Consumer Service完全独立地处理createConsumer()操作。但是其他系统操作跨越多个服务。处理这些请求之一所需的数据可能分散在多个服务周围。例如,为了实现createOrder()操作,Order Service必须调用以下服务以验证其前置条件并使后置条件成立:

  • Consumer Service:验证消费者是否可以下订单并获取其付款信息。
  • Restaurant Service:验证订单行项目,验证送货地址和时间是否在餐厅的服务区域内,验证订单最低要求,并获得订单行项目的价格。
  • Kitchen Service:创建Ticket(后厨工单)。
  • Accounting Service:授权消费者的信用卡。

同样,为了实现acceptOrder()系统操作,Kitchen Service必须调用Delivery Service来安排送餐员交付订单。表2-3显示了服务、修订后的API及协作者。为了完整定义服务API,你需要分析每个系统操作并确定所需的协作。

表5 服务、修订后的API及协作者

总结

  • 微服务中的服务是根据业务需求进行组织的,按照业务能力或者子域,而不是技术上的考量。
  • 有两种分解模式:

        按业务能力分解,其起源于业务架构。

        基于领域驱动设计的概念,通过子域进行分解。

  • 可以通过应用DDD并为每个服务定义单独的领域模型来消除上帝类,正是上帝类引起了阻碍分解的交织依赖项。

本文摘自《微服务架构设计模式》,经出版方授权发布。

原文链接:https://mp.weixin.qq.com/s/2qrEH2_ZwE0HD1M5bQ4i5A

Image placeholder
IT头条
未设置
  94人点赞

没有讨论,发表一下自己的看法吧

推荐文章
SOA架构和微服务架构的区别是什么?

来源:rrd.me/fqdANSOA架构和微服务架构的区别首先SOA和微服务架构一个层面的东西,而对于ESB和微服务网关是一个层面的东西,一个谈到是架构风格和方法,一个谈的是实现工具或组件。1.SOA

微服务架构之「 服务注册 」

微服务架构是一个庞大复杂的工程,为什么说它庞大复杂呢?因为想要做好微服务,就必须先要建设好微服务所需的一系列基础设施和组件。我在前面的文章《架构设计之「微服务入门」》中已经初步介绍过了这些组件,包括:

微服务架构中如何构建一个数据报告服务?

场景描述在微服务架构中,每个微服务负责自己的数据库,微服务A是不允许直接连接微服务B的数据库进行操作的。现在有2个微服务,一个是订单服务,一个是用户服务。有一个数据报告的需求:生成一份包含用户信息的订

微服务架构的四大金刚利器

Photo@ChristopherCampbell 文 | 孔凡勇概述互联网应用发展到今天,从单体应用架构到SOA以及今天的微服务,随着微服务化的不断升级进化,服务和服务之间的稳定性变得越来越重要,分

一个知名网站的微服务架构最佳实现

译者:蓝梦,十余年研发经验,现就职于某上市互联网公司。作者:小马,Medium 首席架构师。译者有话说,如果你的项目正在从单体升级为微服务而忧心;或者你在实践微服务过程中手忙脚乱,本文都是你不容错过的

金融行业微服务架构解析

转载本文需注明出处:微信公众号EAWorld,违者必究。引言:对于微服务,每个人都有自己的理解,与互联网企业的大量落地相比,微服务在传统金融行业还没有普及,这首先是传统金融行业线上系统需求更新和版本迭

微服务架构的四大杀手锏

Photo@ChristopherCampbell 文 | 孔凡勇概述互联网应用发展到今天,从单体应用架构到SOA以及今天的微服务,随着微服务化的不断升级进化,服务和服务之间的稳定性变得越来越重要,分

大神讲解微服务治理的技术演进和架构实践

摘要:随着业务的发展,规模扩大,服务越来越多,需要协调线上运行的各个服务,保障服务的SLA;基于服务调用的性能KPI数据进行容量管理,合理分配各服务的资源占用;对故障业务做服务降级、流量控制、流量迁移

清晰架构(Clean Architecture)的Go微服务: 日志管理

良好的日志记录可以提供丰富的日志数据,便于在调试时发现问题,从而大大提高编码效率。记录器提供的自动化信息越多越好,日志信息也需要以简洁的方式呈现,便于找到重要的数据。日志需求: 无需修改业务代码即可切

从五个方面入手,保障微服务应用安全

随着计算机、互联网技术的飞速发展,信息安全已然是一个全民关心的问题,也是各大企业非常重视的问题。企业一般会从多个层次着手保障信息安全,如:物理安全、网络安全、系统安全(主机和操作系统)、应用安全等。对

算术运算符实现秒数拆分

提示用户输入整数类型的秒数并使用变量记录 将秒数转换为时分秒并使用变量单独记录 打印最终的转换结果

路由多版本拆分

在RouteServiceProvider服务中加入如下代码,并在map方法中调用即可。/** *路由加载多版本 */ protectedfunctionmapAppRoutes(){ //获取路由文

一站式入口服务|爱奇艺微服务平台 API 网关实战

写在前面在互联网业务微服务化改造过程中,按照以往的服务治理体系,各服务需要单独实现限流、鉴权、监控、日志等通用功能,构建入口时资源申请、工单批复、多系统配置等一系列流程对精力消耗极大,学习成本较高

万字详解Oracle架构、原理、进程,学会世间再无复杂架构

学习是一个循序渐进的过程,从面到点、从宏观到微观,逐步渗透,各个击破,对于Oracle, 怎么样从宏观上来理解呢?先来看一个图,这个图取自于教材,这个图对于从整体上理解ORACLE 的体系结构组件,非

架构转型先行——金融业务场景下的新一代架构实践

  赵勇中国农业银行研发中心架构管理办公室主任工程师中国农业银行研发中心架构管理办公室主任工程师,十年以上金融行业信息化架构设计与管控经验。历经互联网金融、两地三中心、分布式核心银行等大型银行系统工程

数字转型 架构演进 2019中国系统架构师大会盛大召开

2019年10月31日~11月2日,由IT168旗下ChinaUnix社区主办的第十一届中国系统架构师大会(SACC2019)在北京隆重召开。自2009年举办以来,大会云集了国内CTO、研发总监、高级

阿里支付宝架构师:谈谈我眼中的高并发架构【好文】

来源:my.oschina.net/u/3772106/blog/1793561前言高并发经常会发生在有大活跃用户量,用户高聚集的业务场景中,如:秒杀活动,定时领取红包等。为了让业务可以流畅的运行并且

架构师眼中的高并发架构

前言高并发经常发生在有大活跃用户量和用户高聚集的业务场景中,如:秒杀活动、定时领取红包等。为了让业务可以流畅的运行并且给用户一个好的交互体验,我们需要根据业务场景预估达到的并发量等因素,来设计适合自己

前端微服务在字节跳动的落地之路

不少前端团队都面临着独石应用的工程巨大、理解困难和合作混乱的种种问题,微前端或许是一种比较好的解决方案,它允许我们为应用加入新功能而不影响整体结构。但同时,我们可能会付出一些代价,例如重复依赖、团

🚀 Hyperf 发布 v1.1.8 版本 | 企业级的 PHP 微服务云原生协程框架

更新内容 新增 #965新增RedisLua模块,用于管理Lua脚本; #1023hyperf/metric组件的Prometheus驱动新增CUSTOM_MODE模式; 修复 #1013修复Js

🚀 Hyperf 发布 v1.1.9 版本 | 企业级的 PHP 微服务云原生协程框架

更新内容 本周更新主要为DI组件新增了懒加载功能,配置为懒加载后,注入的对象为一个代理对象,在使用到时,才会实现对象的初始化。以及为DIContainer增加了set和define方法来动态的增加对象

🚀 Hyperf 发布 v1.1.9 版本 | 企业级的 PHP 微服务云原生协程框架

更新内容本周更新主要为DI组件新增了懒加载功能,配置为懒加载后,注入的对象为一个代理对象,在使用到时,才会实现对象的初始化。以及为DIContainer增加了set和define方法来动态的增加对象管

《PHP 微服务练兵》系列教程

本系列教程将从零开始使用PHP搭建微服务,涉及知识docker、mysql、Elasticsearch+Kibana日志分析系统、minio文件储存、阿里ACM配置中心、jenkens自动化测试部署、

基于JWT规范实现的认证微服务

本文由公众号EAWorld翻译发表,转载需注明出处。作者:MarceloFonseca译者:白小白 原题:Buildinganauthenticationmicro-servicewithJWTsta

微服务配置中心完全解读

本文作者:风卿,Nacos社区committer.在撰写这篇技术选型的文章之前,是比较犹豫的。因为,以其中一个开源项目开发者的身份,去写一篇三个开源项目的对比,即便很克制的去客观的比较,也很难有信服力