Christian Posta谈如何处理微服务的数据

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
注册配置 MSE Nacos/ZooKeeper,118元/月
云原生网关 MSE Higress,422元/月
简介:

人们之所以会采用微服务架构,一个非常重要的原因就是这种架构允许不同的团队分工协作,各自推进,互不影响。那么怎样做才能实现微服务架构呢?最近Red Hat的首席中间件架构师、开源爱好者和Apache代码提交者Christian Posta在博客上发表了一篇文章分享了自己的看法,他认为单纯地使用Spring Boot、Dropwizard或者Docker并不意味着你已经走在了微服务的路上,要真正地实现微服务,必须要深入理解领域和数据。

对于数据,有人认为每一个微服务都应该拥有并控制自己的数据库,任意两个微服务都不应该共享同一个数据库,因为如果共享数据库就会有读、写竞争,数据模型冲突,协调难度大等问题;而统一的数据库则安全性更高,更便利,更容易理解和管理。那么在构建微服务的时候应该如何权衡、协调这些问题呢?Christian Posta认为对于一个正在构建微服务架构的企业,首先应该搞清楚下面四个问题:

领域是什么?实际情况是什么? 事务的边界在哪里? 微服务应该采用什么方式实现跨边界通信? 如果把数据库拿出来会怎样?
Christian Posta首先解释了什么是领域,他认为在构建微服务之前必须充分而深入的理解数据的含义、了解数据是如何产生与消费的。例如,如何给“书”下定义,如何用数据模型表示它:

书是带页码的东西?那报纸是书么(它也页码)?书有硬的封皮?书不是每天都出版?出版社可能会用一条记录表示某个作者的某本书,但是书店里面可能会有多本这样的书,如何表示这种关系呢?假如一本书太长必须分卷,应该如何处理?每一卷都是一本书,还是合到一起才算?

对于这种问题现实情况是没有万能的答案,关键是看“谁问的问题,上下文是什么”。不同的上下文对同一问题的理解可能不同,作为人类我们能很容易地理解“书”是什么,但是计算机不能,在构建软件和数据建模的时候必须使计算机对上下文清晰明了。为此领域驱动设计(DDD)能够帮助我们处理其中的复杂性,通过领域模型建立数据模型,然后在实体、值对象之间画出边界,这些边界或者边界里的组件可能就是最终的微服务。

在数据模型和边界确定之后就需要一些方式来协调不同模型使之保持数据的一致性,这就需要找出事务的边界在哪里。Christian Posta认为事务边界是业务不可变性的最小原子单元。无论是通过数据库的ACID特性还是通过两阶段提交来实现原子性,都无所谓,关键是要让事务的边界尽可能地小。例如,针对下面几个用例:

“允许客户搜索航班”  
“允许客户选择某个特定航班的座位”  
“允许客户预定某个航班”

可能会有三个有边界的上下文:搜索、预定和售票。搜索负责显示特定路线的航班以及给定时间范围内的旅游活动日程。预定通过客户的姓名、地址、经常乘坐的航班、座位喜好以及支付信息等安排预定流程。售票负责实际的订票和出票。这一阶段需要识别出每一个上下文中的事务边界从而实施约束/不可变性,保证不同上下文内的事务互不影响;但是此时并不需要100%的、严格的数据一致性,因此不需要考虑跨边界上下文的原子事务。例如,对于上面的场景:

预定流程可能会调用SeatAvailability服务让它在飞机上预留一个座位。这个座位预留的操作可能会实现为一个单独的事务(比如保留座位23A)并返回一个预留ID号。预定流程会关联该预留ID号并提交预定。无论是预留座位还是接受预定,它们各自都是一个单独的事务,可以独立处理,不需要借助于两阶段提交或者两阶段锁。

但是数据并不是孤立的,在某些情况下独立的事务需要组合到一起,那么微服务应该采用何种方式跨边界通信呢?Christian Posta认为微服务的价值在于自治,在于每一个系统都能够独立的变化,为了在实现自治的同时又保证业务需求,“事件机制”是非常好的选择。事件是不可变的数据结构,它会及时捕获与某个动作相关的信息,并被广播到其他节点,其他节点会监听它们感兴趣的事件,并根据事件的数据做出决策(存储数据、更新数据等)。例如,对于上面预定机票的场景:

当客户发起预定的时候,预定上下文会发布一个类似于“NewBookingCreated”的事件,售票上下文会消费该事件并与后端的票务系统交互。

使用事件的优点是:它能够避免边界之间昂贵的、不可能的事务模型;系统的各个部分能够独立变化,互不影响;系统的每个部分可以自己决定数据的更新周期,数据的存储方式,以及数据模式等;系统的可伸缩性、容错性和扩展性更好。当然,这种方式也有一些缺点:用户必须花费更多的精力研究CAP理论,了解存储或者队列的实现技术;调试的复杂度更高,实施的难度更高等。

最后,对于“微服务的数据应该存储到一个数据库中还是存储到不同的数据库中”,Christian Posta给出的答案是“没有具体的规则,这需要根据具体的场景进行权衡,标准是不要失去自治所带来的优点”。此外,Christian Posta还给出了一种通过Apache Samza构建事件流处理系统的思路,他认为这样做可以带来更多的好处:

可以将数据库看作是“当前状态”的记录,而不是真正的记录 可以引入新的应用程序,重新读取过去的事件并依据“已经发生的事情”检查它们的行为 可以自由地审计日志 可以引入新版本的应用,并通过回放事件对其进行非常完善的测试 可以非常容易地修改数据库的版本和模式,执行升级,只需要将事件在新数据库中重放即可 可以非常容易地迁移到全新的、不同类型的数据库

本文转自d1net(转载)

相关文章
|
4月前
|
SQL 数据库 微服务
微服务03,最简单的Demo,我们每个服务不能重复开发相同业务,微服务数据独立,不要访问其他微服务的数据库,微服务的特点之一是提供不能功能的数据库互相分割,微服务需要根据业务模块拆分,做到单一职责,
微服务03,最简单的Demo,我们每个服务不能重复开发相同业务,微服务数据独立,不要访问其他微服务的数据库,微服务的特点之一是提供不能功能的数据库互相分割,微服务需要根据业务模块拆分,做到单一职责,
|
4月前
|
消息中间件 Kafka 微服务
微服务数据问题之MetaQ设置同步异步刷盘如何解决
微服务数据问题之MetaQ设置同步异步刷盘如何解决
|
4月前
|
消息中间件 存储 微服务
微服务数据问题之异步刷盘如何解决
微服务数据问题之异步刷盘如何解决
|
2月前
|
存储 搜索推荐 数据库
MarkLogic在微服务架构中的应用:提供服务间通信和数据共享的机制
随着微服务架构的发展,服务间通信和数据共享成为关键挑战。本文介绍MarkLogic数据库在微服务架构中的应用,阐述其多模型支持、索引搜索、事务处理及高可用性等优势,以及如何利用MarkLogic实现数据共享、服务间通信、事件驱动架构和数据分析,提升系统的可伸缩性和可靠性。
38 5
|
3月前
|
安全 网络安全 数据安全/隐私保护
云原生技术探索:容器化与微服务架构的实践之路网络安全与信息安全:保护数据的关键策略
【8月更文挑战第28天】本文将深入探讨云原生技术的核心概念,包括容器化和微服务架构。我们将通过实际案例和代码示例,展示如何在云平台上实现高效的应用部署和管理。文章不仅提供理论知识,还包含实操指南,帮助开发者理解并应用这些前沿技术。 【8月更文挑战第28天】在数字化时代,网络安全和信息安全是保护个人和企业数据的前线防御。本文将探讨网络安全漏洞的成因、加密技术的应用以及提升安全意识的重要性。文章旨在通过分析网络安全的薄弱环节,介绍如何利用加密技术和提高用户警觉性来构建更为坚固的数据保护屏障。
|
3月前
|
Java 数据库连接 微服务
揭秘微服务架构下的数据魔方:Hibernate如何玩转分布式持久化,实现秒级响应的秘密武器?
【8月更文挑战第31天】微服务架构通过将系统拆分成独立服务,提升了可维护性和扩展性,但也带来了数据一致性和事务管理等挑战。Hibernate 作为强大的 ORM 工具,在微服务中发挥关键作用,通过二级缓存和分布式事务支持,简化了对象关系映射,并提供了有效的持久化策略。其二级缓存机制减少数据库访问,提升性能;支持 JTA 保证跨服务事务一致性;乐观锁机制解决并发数据冲突。合理配置 Hibernate 可助力构建高效稳定的分布式系统。
60 0
|
4月前
|
消息中间件 微服务
微服务数据问题之同步复制如何解决
微服务数据问题之同步复制如何解决
|
4月前
|
消息中间件 负载均衡 Kafka
微服务数据问题之Kafka实现高可用如何解决
微服务数据问题之Kafka实现高可用如何解决
|
4月前
|
消息中间件 存储 负载均衡
微服务数据问题之Kafka作为元数据节点如何解决
微服务数据问题之Kafka作为元数据节点如何解决
|
4月前
|
消息中间件 Kafka 索引
微服务数据问题之Broker宕机MetaQ保证数据的可靠性如何解决
微服务数据问题之Broker宕机MetaQ保证数据的可靠性如何解决