NoSQL微服务从设计到布置(五)事件驱动数据管理

https://github.com/oopsguy/microservices-from-design-to-deployment-chinese
译者:http://oopsguy.com

本书要介绍如何使微服务构建应用程序,这是本书的第五节。第一章介绍了微服务架构模式,讨论了下微服务的亮点和缺点。第二和第三章叙了微服务架构内通信方式的对照。第四章探索了与劳务意识系的始末。在本章中,我们小开了点调整,研究微服务架构中起的分布式数据管理问题。

5.1、微服务和分布式数据管理问题

单体应用程序通常兼有一个纯净的涉项目数据库。使用关系项目数据库的一个关键优点是公的应用程序可以使用
ACID
事务,这些业务提供了以下重点保障:

  • 原子性(Atomicity) – 所作出的变更是原子操作,不可分割
  • 一致性(Consistency) – 数据库的状态始终保持一致
  • 隔离性(Isolation)
    即使工作并发执行,但他俩扣押起更像是串行执行
  • 永久性(Durable) – 一旦事情提交,它以不得取消

因此,您的应用程序可以非常易地起作业、更改(插入、更新和去)多独执行,并交业务。

动关系数据库的另一样特别补是它提供了
SQL,这是均等种植丰富、声明式和标准化的询问语言。您可轻松地修一个查询来组合来自多只说明底多少,之后,RDBMS
查询计划程序用规定实施查询的极品方式。您不用担心什么看数据库等底部细节。因为若拥有的应用程序数据还存放于与个数据库中,因此十分轻查询。

异常倒霉之是,当我们转向微服务架构时,数据看将移得非常复杂。这是盖每个微服务所拥有的数量对眼前微服务来说是私有的,只能通过其提供的
API
进行走访。封装数据可包微服务松耦合,独立演进。如果多个劳务看同一之数量,模式(schema)更新得针对有服务进行耗时、协调的创新。

更不好之凡,不同的微服务经常利用不同类型的数据库。现代应用程序存储和拍卖在各种数码,而关系项目数据库并无总是最佳选项。在少数场景,特定的
NoSQL
数据库可能持有双重便宜之数据模型,提供了又好的性能与而扩展性。例如,存储和询问文本的劳动以文本搜索引擎(如
Elasticsearch)是合情之。类似地,存储社交图数据的劳务应该好采用图数据库,例如
Neo4j。因此,基于微服务的应用程序通常夹使用 SQL 和 NoSQL
数据库,即所谓的掺杂持久化(polyglot
persistence)方式。

一个分区的数量存储混合持久化架构具有众多长,包括了松耦合的服务及重新好之性及可扩展性。然而,它吗引入了有些分布式数据管理方面的挑战。

率先只挑战是何许兑现保护多独服务期间的作业工作一致性。要询问是题材,让咱们事先来拘禁一个在线
B2B 商店的以身作则。Customer Service
(顾客服务)维护客户有关的音,包括信用额度。Order Service
(订单)负责管理订单,并且要证明新订单,不得跨客户之信用额度。在是应用程序的单体版本被,Order
Service 可以大概地使用 ACID 交易来检查可用信用额度并创建订单。

相对而言,在微服务架构中,ORDER (订单)和 CUSTOMER
(顾客)表对那个各自的劳动都是私有的,如图 5-1 所示:

NoSQL 1

Order Service 无法直接看 CUSTOMER 表。它只能用客户服务提供的
API。订单服务或行使了分布式事务,也称为两品级提交(2PC)。然而,2PC
在当代使用中屡见不鲜是不可行的。CAP
定理要求而当可用性和 ACID
式一致性之间做出选择,可用性通常是还好的取舍。此外,许多现代技能,如大部分
NoSQL 数据库,都不支持
2PC。维护服务与数据库里的数一致性至关重要,因此我们用任何一样拟解决方案。

其次独挑战是哪些贯彻由多个劳务被寻找数据。例如,我们如果应用程序需要出示一个消费者与外不久前底订单。如果
Order Service 提供了用来检索客户订单的
API,那么你得运用应用程序端连接为找数据。应用程序从 Customer Service
中搜寻客户,并从 Order Service 中追寻客户的订单。但是,假而 Order
Service 仅支持通过主键查找订单(也许它用了只有支持因主键检索的 NoSQL
数据库)。在这种气象下,没有行之有效之方式来索所急需的数量。

5.2、事件驱动架构

许多应用使用了事件驱动架构当化解方案。在这个架构中,微服务在有一些主要事件时发布一个风波,例如更新工作实体时。其他微服务订阅了这些事件,当微服务接受至一个事件时,它好创新自己之业务实体,这或导致更多之风波于颁发。

您可行使事件实现跨越多服务的业务工作。一个工作由同样多元之手续做。每个步骤包括了微服务更新工作实体和通告事件所接触的生一样步骤。下图依次展示了什么以创造订单时利用事件驱动方法来检查可用信用额度。

微服务通过 Message Broker (消息代理)进行交换事件:

  • Order Service (订单服务)创建一个状态呢 NEW 的订单,并颁发一个
    Order
    Created (订单创建)事件。

NoSQL 2

  • Customer Service (客户服务)消费了 Order Created
    事件,为订单预留信用额度,并发布 Credit Reserved 事件。

NoSQL 3

  • Order Service 消费了 Credit Reserved
    (信用预留)事件并将订单的状态更改为 OPEN。

NoSQL 4

重复杂的状况可能会见提到额外的手续,例如当检讨客户信用的同时保留库存。

一经(a)每个服务原子地换代数据库并颁发事件,稍后又创新,(b)Message
Broker
保证事件至少让传送一次,您可兑现跨多服务的事情工作。需要注意的是,这些并无是
ACID
事务。它们才提供了还弱的保管,如最终一致性。该工作型称为
BASE 模型。

若还足以以事件来保护多单微服务预先在所独具的数的物化视图(materialized
view)。维护视图的劳务订阅了系事件并更新视图。图 5-5 展示了 Customer
Order View Updater Service (客户订单视图更新服务)根据 Customer
Service 和 Order Service 发布之轩然大波更新 Customer Order View
(客户订单服务)。

NoSQL 5

当 Customer Order View Updater Service 接收到 Customer 或 Order
事件不时,它会更新 Customer Order View 数据存储。您可以如 MongoDB
之类的文档数据库实现 Customer Order
View,并也每个 Customer 存储一个文档。Customer Order View Query Service
(客户订单相图查询服务)通过询问 Customer Order View
数据存储来拍卖得一员客户及近年来的订单的呼吁。

事件驱动的架构起几只优点和缺点。它会实现跨多服务并提供最终一致性事务。另一个好处是她还让应用程序能够保护物化视图。

一个败笔是那编程模型比下 ACID
事务越来越复杂。通常,您要兑现上工作以起应用程序级别之故障中还原。例如,如果信用检查失败,您要撤回订单。此外,应用程序必须处理不等同的数额。因为未提交的事务所做的变动是可见的。如果没有更新的物化视图中读取,应用程序依然可以看到不一致性。另一个缺点是订阅者必须使检测与大意重复的波。

5.3、实现原子性

以事件驱动架构中,同样是着原子更新数据库和发布事件相关问题。例如,Order
Service 必须在 ORDER 表中插一行数,并公布 Order Created
事件。这有限个操作必须原子完成。如果在更新数据库后可每当宣告事件前起劳务崩溃,系统以出现不一致性。确保原子性的业内措施是使用涉及到数据库和
Message Broker 的分布式事务。然而,由于上述原因,如 CAP
定理,这并无是我们怀念做的。

5.4、使用当地工作发布事件

贯彻原子性的同一种植办法是应用程序使用一味涉及地方工作之差不多步骤过程来发表事件。诀窍在于存储业务实体状态的数据库中发出一个当消息队列的
EVENT
表。应用程序开启一个(本地)数据库事务,更新工作实体状态,将事件插入到
EVENT 表中,之后提交业务。一个独的应用程序线程或进程查询 EVENT
表,将事件发表到 Message
Broker,然后运当地工作将事件标记为曾发表。设计要图 5-6 所展示。

NoSQL 6

Order Service 将一行记录插入到 ORDER 表中,并拿一个 Order Created
事件插入到 EVENT 表中。Event Publisher(事件发布者)线程或进程从 EVENT
表中询问未披露之轩然大波,之后发表这些事件,最后更新 EVENT
表以用事件标记为都宣告。

这种方法有好有坏。好处是其保证了为发表之轩然大波每次换代都未负让
2PC。此外,应用程序发布业务级事件,这些事件可以解推断的需要。这种方法的症结是它们很轻出错,因为开发人员必须要记得宣布事件。这种措施的局限性在于,由于那个简单的事体及查询功能,在行使一些
NoSQL 数据库时,实现起来以凡相同充分挑战。

拖欠措施通过为应用程序使用当地工作更新状态与发布事件来清除对 2PC
的仗。现在咱们来拘禁一下经应用程序简单地翻新状态来落实原子性的不二法门。

5.5、挖掘数据库事务日志

切莫依靠 2PC
来落实原子性的旁一样种办法是运线程或进程发布事件,该线程或进程对数据库的作业或者提交日志进行打通。当应用程序更新数据库时,更改信息于记录及数据库的事情日志被。Transaction
Log Miner 线程或进程读取事务日志并朝 Message Broker 发布事件。设计要图
5-7 所显示。

NoSQL 7

用这种方式的一个演示是 LinkedIn Databus 开源项目。Databus 挖掘 Oracle
事务日志并发表与转移相对应之风波。LinkedIn 使用 Databus
保持与记录系统一样的各种派生数据存储。

其他一个例证是 AWS DynamoDB 中之流机制,它是一个托管的 NoSQL
数据库。DynamoDB 流包含了于过去 24 小时内对 DynamoDB
表中的宗进行的更动(创建、更新与去操作),其以时间顺序排列。应用程序可以自流中读取这些改动,比如,将其看作事件发表。

作业日志挖掘出各种利益与弊端。一个利益是它能够确保让发布之风波每次换代都无因让
2PC。事务日志挖掘还好透过将事件发布和应用程序的政工逻辑分离来简化应用程序。一个最主要的通病是事情日志的格式对于每个数据库来说都是专有的,甚至在数据库版本里格式就生了改观。而且,记录受事情日志被的小级别更新可能麻烦对高级业务事件展开逆向工程。

事情日志挖掘消除了应用程序在做一样项事时对 2PC
的乘:更新数据库。现在咱们来看望外一样种好清除更新并只有因让波之不同方法。

5.6、使用事件起源

事件起源由此利用完全两样之、不刹车的法子来持久化业务实体,实现无
2PC
原子性。应用程序不存储实体的时状态,而是存储一多元状态改变事件。该应用程序通过回放事件来重建实体的目前状态。无论工作实体的状态何时发生变化,其都见面拿新事件追加到事件列表中。由于保存事件是一个纯粹操作,因此所有原子性。

倘了解事件源自的干活规律,以
Order(订单)实体为例。在风办法受,每个订单还与 ORDER
表中之某行记录相映射,也得投到比如 ORDER_LINE_ITEM 表中之笔录。

然而当以事件本源时,Order Service 将因为状态更改事件之形式储存
Order:Created(创建)、Approved(批准)、Shipped(发货)、Cancelled(取消)。每个事件涵盖足够的数据来重建
Order 的状态。

NoSQL 8

事件被持久化在波存储着,事件存储是一个事变数据库。该存储有一个用来添加和找实体事件之
API。事件存储还和我们前面描述的架中之 Message Broker
类似。它提供了一个
API,使得劳动能订阅事件。事件存储于装有感兴趣之订阅者派发所有事件。可以说事件存储是事件驱动微服务架构的支柱。

事件源自有几只便宜。它解决了贯彻事件驱动架构的关键问题之一,可以以状态发生变化时可靠地发布事件。因此,它解决了微服务架构中之多少一致性问题。此外,由于其持久化的是事件,而休是小圈子对象,所以它最主要避免了靶关系阻抗失配问题。事件本源还提供了针对业务实体所开变更的
100%
可靠的审计日志,可以兑现在其他时间点对实业进行时查询以确定状态。事件源自的其他一个第一利益是公的业务逻辑包括松耦合的交换事件业务实体,这让从单体应用程序迁移至微服务架构将转移得越来越容易。

事件本源同样发出毛病。这是同样种不同而生的编程风格,因此是上曲线。事件存储仅支持通过主键查找工作实体。您要利用命查询责任分开(CQRS)来落实查询。因此,应用程序必须处理最终一致的数。

5.7、总结

以微服务架构中,每个微服务都来温馨个人的多寡存储。不同之微服务可能会见利用不同之
SQL 或者 NoSQL
数据库。虽然这种数据库架构具有显著的优势,但她创造了片分布式数据管理挑战。第一个挑战是怎实现保障多单服务中间的政工工作一致性。第二只挑战是何许落实从多独服务中找数据。

大多数运使用的化解方案是事件驱动架构。实现事件驱动架构的一个挑战是怎样为原子的计创新状态与如何发布事件。有几乎栽艺术可以兑现这点,包括了以数据库作为信息队列、事务日志挖掘与波源自。

微服务实战:NGINX 与储存优化

by Floyd Smith

因微服务的仓储方涉及很数额及各种数码存储,访问与换代数据将更换得更复杂,DevOps
在护数据一致性方面面临着又充分之挑战。NGINX
为这种数据管理提供了第一支撑,主要发生三单方面:

  1. 数量缓存与微缓存(microcaching) – 使用 NGINX
    缓存静态文件以及微缓存应用程序生成的始末可减轻应用程序的负荷、提高性能并减少题材之来。
  2. 数存储的八面玲珑与可扩展性 – 一旦用 NGINX
    作为反向代理服务器,您的应用程序在创立、调整大小、运行和调整数据存储服务器的老时可得酷死之灵活性,以满足不断变动的需要 –
    每个服务都富有好之数码存储是死要紧的。
  3. 劳监控与治本,包括数据服务
    随着数据服务器数量的加,支持复杂操作以及有监控和管理工具显得非常主要。NGINX
    Plus
    内置了这些工具及应用程序性能管理合作伙伴的接口,如
    Data Dog、Dynatrace 和 New Relic。

微服务相关的数码管理示范可在 NGINX
微服务参考架构的老三颇模型中找到,其也您设计决策及履行提供了起点。

斯系列全部译文

https://github.com/oopsguy/microservices-from-design-to-deployment-chinese

网站地图xml地图