Day963.如何拆分数据 -遗留系统现代化实战

这篇具有很好参考价值的文章主要介绍了Day963.如何拆分数据 -遗留系统现代化实战。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

如何拆分数据

Hi,我是阿昌,今天学习记录的是关于如何拆分数据的内容。

如何拆分数据,这个场景在建设新老城区,甚至与其他城市(外部系统)交互时都非常重要。

作为开发人员,理想中的业务数据存储方式是什么样呢?

当然是负责一个业务的数据都在一张或几张名称相关的表中,这样通过名称就可以一目了然,查找起来很方便。

不过很遗憾,现实有时候总是事与愿违,遗留系统中负责处理一个业务的数据,有的放在这张表,有的放在那张表,总是不在一起,名称甚至都没关系;而一张表中也有可能存放几种业务的数据。


一、共享数据库

拆分数据的第一个模式是什么?不要拆分

不拆分真的可行么?这需要先分析一下拆分的必要性。

遗留系统的数据拆分是个认知负载非常高的工作,不同的数据混杂在一起,具有不同业务含义的数据也往往存放于一张表中,要想彻底拆分干净十分不容易。

如果不需要不停机更新(大多数企业的业务系统其实都不需要)、没有严苛的可用性和弹性需求,或者数据量没有大到无法接受的程度,就没有必要拆分数据库。

这时,共享数据库(Shared Database)也是一个可以接受的选择。在架构现代化-微服务分享了基于服务的分布式架构,就是一种共享数据库的分布式架构。

Day963.如何拆分数据 -遗留系统现代化实战

共享的数据分成两种情况。

  • 第一种是不同的服务访问同一数据库的不同 Schema
  • 第二种是不同的服务访问同一数据库的同一 Schema。

第一种情况相当理想,因为不同业务领域的数据在逻辑上是隔离的,数据的所有权非常清晰。一个服务如果想访问其他服务的数据,在发现 Schema 不同后,一般不会跨 Schema 去读表,而是通过代码依赖或者数据库视图来访问。

第二种情况要差一些,所有模块都可以随意访问任意的表,操作这些数据的业务逻辑散落在各个服务中,很难知道一张表到底归谁所有。

一个服务,不管是粗粒度的领域服务还是微服务,都可以看成是行为和状态的组合,它封装了一个或多个状态机。这些状态其实就是数据,如果改变这些数据的行为分散在系统的不同位置,你其实很难正确实现这个状态机。

对于第二种情况,应该尽量避免,或者只是作为一个过渡阶段,最终仍然要按逻辑或者物理的方式来隔离不同的数据。


二、数据库视图

外部系统需要连接数据库来读写它所需要的数据,这里要要绝对避免共享数据库。

因为在这种情况下,数据的所有权将不再仅属于当前系统,不同的团队都能随意修改数据,很快就会变得混乱不堪,不同系统间的集成也会成为大问题。

这时可以采取的一种方式是,为不同的外部系统创建不同的 Schema,在 Schema 中提供数据库视图(Database View),这些视图访问主 Schema 中的表。

外部系统就能以只读的方式访问你的数据了。由于视图提供的是全部数据的一个有限的子集,外部系统只能访问想让它访问的数据,比如部分表以及表中的部分字段,其他数据得以隐藏。

这样就能最大程度地避免数据所有权的模糊。

Day963.如何拆分数据 -遗留系统现代化实战


三、数据库包装服务

可以访问数据库视图的,不仅仅是外部系统,还可以包括气泡上下文中的基于防腐层的仓库。

但视图的方式只能提供只读数据,如果外部系统希望写入数据,应该如何处理呢?

可以对数据库进行一层薄薄的封装,形成一个服务,将数据库的细节隐藏在这个**数据库包装服务(Database Wrapping Service)**之后,将数据库依赖转换成服务依赖。

通过在数据库外放置一个明确的包装层,可以很清楚地知道哪些数据是属于你的,哪些数据是别人的。

Day963.如何拆分数据 -遗留系统现代化实战

如果系统是基于 Web 的,甚至可以在原系统之中去开发这个包装服务。

最好把它当做一个气泡上下文,去开发一个全新的服务,不要让本就混乱的遗留系统雪上加霜。

如果遗留系统不是基于 Web 的,那就更推荐使用这种模式了。

数据库包装服务除了可以提供写能力外,在读能力上也比数据库视图更灵活。

提供的并不局限于一张表或表中的部分字段,还可以提供更加复杂的数据映射。

这种包装服务看似很薄,但它也可以作为一个中间步骤,为后续更深入的数据拆分打下基础。


四、报表数据库

如果外部系统或气泡上下文是一个报表系统或服务,需要读取大量的数据,数据库包装服务的方法就不太适用了。

因为这个包装服务的所有权是你的,而不是外部系统的,它们无法灵活地定制查询。而数据库视图也有点力不从心,因为业务数据和报表的流量都压在一个数据库上,这显然不是你想看到的。

更好的方式是使用报表数据库(Reporting Database)模式,它会为报表这类只读的服务单独构建一个数据库。这个数据库可以是业务数据库的远程复本,也可以是一个完全不同的、更适合报表的数据结构(如大宽表),并通过某种方式来做数据的转换和映射。

对于后一种实现,可以使用与业务数据库完全异构的数据库,这样更加灵活。

但它也带来了一定的开销,就是需要自己去实现一个数据映射的工具

Day963.如何拆分数据 -遗留系统现代化实战

报表数据库模式有时也叫做数据库即服务接口(Database-as-a-Service Interface),因为这种思想已经远远不止用于报表这个单一场景了。

随着大数据的兴起,很多数据项目也使用类似的方式,将业务数据映射到数据仓库或数据湖中,再由数据流水线去进行处理。


五、变更数据所有权

四种模式,都是基于一个共享的数据库,并没有涉及到拆分数据库这个真正棘手的问题。

之所以先讲四种共享数据库模式,是想让知道,在不拆分数据库的情况下,也有一些方案可以选择。

如果要拆分数据,最简单的场景就是在基于服务的分布式架构中,不同服务访问单体数据库中的不同 Schema。

因为不同业务领域的数据已经由 Schema 隔离开了,只需要少量改动,就可以将不同 Schema 中的数据迁移到单独的数据库中。

如果不同服务访问的是单体数据库中的相同 Schema,就会麻烦得多,因为数据并没有从逻辑上进行隔离。但简单的情况怎样处理,已经知道了,那稍微复杂一些的情况就好办了,只要把它转换成简单的情况就可以了。

所以只需要把同一 Schema 下的数据,用 Schema 隔离开。

那新的问题就来了,怎么隔离呢?

不同的领域服务访问的表都是交织在一起的,根本不知道哪些表属于哪个领域服务或组件。其实,可以回忆一下架构现代化-微服务的内容,如果组件之间边界不明显,可以使用战术分叉的方式将“拆”变为“删”。

其实数据拆分也是一样的,也可以将整个 Schema 复制一份,在新的 Schema 中删除相应的领域服务没有访问到的表,剩下的就是与领域服务有关的所有表了。

Day963.如何拆分数据 -遗留系统现代化实战

再对访问的表做个分组处理。需要依据的原则是,谁写数据谁就拥有这张表

因此,可以把执行写操作的表,当作是真正归属于当前领域服务的,保持不动即可;而只读的表应该归其他领域服务,所以可以把这些表调整成视图。

如果目标是拆分 Schema,到这一步就差不多结束了。但如果目标是独立的数据库,还要在独立的数据库中将这些视图转换为表,将原数据库中的数据冗余到新库中,并通过 CDC 和事件拦截等方式同步数据。

如果不想冗余数据,你还可以将连表查询转换为 API 调用。

具体来说就是,拆分新库和老库中不同表的连表查询,提取出新库的查询,在单体或其他领域服务中把老库的表封装成 API。

然后在独立出来的领域服务中,把新库的数据和调用 API 得到的数据组装起来。

在封装老库的 API 时,可以使用数据库包装服务模式,也可以使用更加开放的聚合 API 模式。

后者不像前者那样只提供基础的 CRUD 服务,而是将一个聚合的所有操作都暴露为 API。

比如在订单服务中,下完一个订单后,会连带着对库存表进行操作。用数据库包装服务的话,库存服务就会封装一个修改库存表的 API,而聚合 API 则会提供一个减库存的 API。

两者乍看上去似乎差别不大,但其实体现出了完全不同的封装策略。

这种将混杂在一起的数据拆分出来,各自归属各自服务的过程,叫做变更数据所有权(Change Data Ownership)

在这个过程中,有的时候是在 A 中先查出数据,然后调用 B 得到 B 的数据,然后在 A 中进行组合;

有的时候是在 A 中查出部分数据,根据这些数据去调用 B,得到最终结果。

到底怎么调用其实不重要,只要数据的所有权划分清楚了就好。


六、在应用中同步数据

在拆分数据的时候,出发点可能并不是解耦,而是想换一个更加合适的数据库,来解决特定的问题。

比如社交领域中的好友关系,可能想用图数据库来替换关系型数据库,来得到更好的查询性能。

建议先拆再换,而不要想着一次性连拆带换。

做遗留系统现代化这种高认知负载的任务,尤其要记住的一点就是,一次只做一件事,将认知负载降到最低

那么当数据库拆分出来之后,如何切换到异构数据库呢?

一个比较稳妥的办法——在应用中同步数据


来看看它的增量演进方案,一共分四步。

  • 第一步,批量地复制数据。如果老库在业务上是允许停机的,可以直接停机导数据。如果不允许停机,在复制数据的过程中会产生新的数据。这就需要通过 CDC 等方式来保证这部分变动也能同步到新库中。
  • 第二步,同时写入新旧两个库,但只从旧库中读数据。由于新库刚刚部署不久,很可能会出问题,所以要在应用程序中“双写”新旧两个库,以确保两个库中都有同样的业务数据。一旦新库出现问题,业务也不至于受影响。
  • 第三步,同时写入新旧两个库,但只从新库中读数据。当对新库的基础设施有了信心之后,就可以把读操作也转移到新库中。这时我们仍然双写数据,因此出现任何问题都可以回退。
  • 第四步,当新旧两库同时运行一段时间后,对新库的方方面面都有了十足的信心,此时就可以删掉旧库(或 Schema),彻底迁移到新库中了。除了做异构数据库的迁移,这种方式也同样适用于拆分微服务时的数据解耦。为了保证拆分数据的正确性,在增量演进的时候,也必然需要保证新旧两个库的数据同步。

在同步时,由于有开关的存在,因此需要在新旧系统中都实现数据的双写

除此之外,该模式也可以用于先拆数据再拆服务的情况。

拆分服务的时候,有时会先拆代码,再拆数据库,有时则反之,先拆数据库再拆代码。


七、先拆代码还是先拆数据库?

目标是微服务架构,那么只有代码和数据库都拆分出来且独立部署了,整个任务才算结束。因此拆分工作,就有三种顺序可选:

  • 先拆数据库
  • 先拆代码或同时拆分。

拆分数据库(包括拆分成单独的库或拆分出新的 Schema),意味着以前的事务性操作会变成非事务的,你需要访问新旧两个库,然后在代码中对数据进行集成。这会造成新旧两个库的不一致。

虽然早晚都会遇到这样的问题,但我仍然建议你先拆分代码,因为拆分代码的认知负载相对低一些,采用战术分叉的方式拆分,也会更简单。这能让你快速得到一些短期收益,比如代码的解耦、服务的独立部署。而且从单体到基于服务的分布式架构这条演进路线,也是十分清晰和成熟的。

可以随时停止,随时重启。而数据库拆分则要困难得多,一旦先拆数据库,又发现很长时间看不到收益,团队的士气会严重受挫。不过无论如何,都不建议同时拆分

一次只做一件事,是原则。有些架构师可能还希望在拆分数据库的同时重新设计数据库,增加或修改一些表,通常都建议不要贪心,保持克制,尽量先拆再改。

一次做多件事,任务的范围会越来越发散,导致最终迷失方向,忘了初心。

遗留系统本身就是认知负载非常高的系统,不要再人为地增加认知负载了。

八、小结

拆分遗留系统的数据时,可以选用的一系列模式,第一张表是在拆分数据库时,可用于数据同步的几种模式:

Day963.如何拆分数据 -遗留系统现代化实战

第二张表是在拆分服务时,可用于数据共享的几种模式

Day963.如何拆分数据 -遗留系统现代化实战

数据库的解耦,是无论如何都会面对的问题,也是架构现代化中最困难最复杂的部分。

很多时候,代码的拆分其实就相当于数据的拆分。文章来源地址https://www.toymoban.com/news/detail-435870.html


到了这里,关于Day963.如何拆分数据 -遗留系统现代化实战的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Day967.团队拓扑学 -遗留系统现代化实战

    Hi,我是 阿昌 ,今天学习记录的是关于 团队拓扑学 的内容。 看看最近这几年来新诞生的组织结构模型—— 团队拓扑学 (Team Topologies)。 尽管组件团队、特性团队和 Spotify 模型,都为团队的组成提供了不错的建议,但团队的类型应该是什么样并没有一致的标准。 如果所有

    2024年02月06日
    浏览(47)
  • 《遗留系统现代化》读书笔记(基础篇)

    目录 为什么要对遗留系统进行现代化? 什么是遗留系统?  遗留系统的现代化价值 总结 遗留系统的四化建设 代码现代化 架构现代化 DevOps 现代化 团队结构现代化 总结 本文地址:《遗留系统现代化》读书笔记(基础篇)_陆业聪的博客-CSDN博客  你现在所写的每一行代码,

    2024年02月16日
    浏览(49)
  • 龙智案例:某大型零售企业如何打造高速、现代化的ITSM体系

    在2023 DevOps国际峰会·北京站的现场,我们对话了龙智咨询顾问胡若愚,他为我们奖助了一位零售业的大型客户是如何在数字化浪潮中,凭借龙智提供的Jira Service Management产品及服务,打造现代化ITSM平台,提升客户满意度。 某零售巨头如何借助Jira Service Management创客户满意度新

    2024年02月12日
    浏览(40)
  • 现代化个人博客系统 ModStartBlog v9.3.0 支持Laravel 9

    ModStart 是一个基于 Laravel 模块化极速开发框架。模块市场拥有丰富的功能应用,支持后台一键快速安装,让开发者能快的实现业务功能开发。 系统完全开源,基于 Apache 2.0 开源协议。 丰富的模块市场,后台一键快速安装 会员模块通用且完整,支持完整的API调用 大文件分片上

    2024年04月18日
    浏览(45)
  • 定义现代化实时数据仓库,SelectDB 全新产品形态全面发布

    导读:9 月 25 日,2023 飞轮科技产品发布会在线上正式召开,本次产品发布会以 “新内核、新图景” 为主题,飞轮科技 CEO 马如悦全面解析了现代化数据仓库的演进趋势, 宣布立足于多云之上的 SelectDB Cloud 云服务全面开放 , 增加了全新的私有仓库(BYOC)产品模式,同时发

    2024年02月07日
    浏览(38)
  • 现代化个人博客系统 ModStartBlog v7.3.0 首页热门博客,UI优化调整

    ModStart 是一个基于 Laravel 模块化极速开发框架。模块市场拥有丰富的功能应用,支持后台一键快速安装,让开发者能快的实现业务功能开发。 系统完全开源,基于 Apache 2.0 开源协议。 丰富的模块市场,后台一键快速安装 会员模块通用且完整,支持完整的API调用 大文件分片上

    2024年02月11日
    浏览(47)
  • 【数据架构】Data Fabric 架构是实现数据管理和集成现代化的关键

    DA 领导者应该了解数据编织架构的关键支柱,以实现机器支持的数据集成。 在日益多样化、分布式和复杂的环境中,数据管理敏捷性已成为组织的任务关键优先事项。为了减少人为错误和总体成本,数据和分析 (DA) 领导者需要超越传统的数据管理实践,转向现代解决方案,例

    2024年02月16日
    浏览(40)
  • 【JavaScript精通之道】掌握数据遍历:解锁现代化遍历方法,提升开发效率!

    ​ 🎬 岸边的 风 :个人主页  🔥  个人专栏  :《 VUE 》 《 javaScript 》 ⛺️  生活的理想,就是为了理想的生活 ! ​ 目录  📚 前言  📘 1. reduce方法 📘 2. forEach方法 📘 3. map方法  📘 4. for循环 📘 5. filter方法 📘 6. for...of循环 📘 7. Object.keys方法 📘 8. Object.values方法 📘

    2024年02月10日
    浏览(44)
  • 抓住智慧教育发展机遇 华云数据用数字化推动教育现代化

    随着云计算、大数据等新一代信息技术的不断发展,知识获取方式和传授方式发生了革命性变化,教育领域的数字化改革随之日渐加速。日前,国家智慧教育平台正式上线,该平台是国家教育公共服务的综合集成平台,聚焦学生学习、教师教学、学校治理、赋能社会、教育创

    2023年04月26日
    浏览(86)
  • 洋州影院购票系统:如何用Java、Spring Boot、Vue和MySQL实现现代化管理

    ✍✍计算机编程指导师 ⭐⭐个人介绍:自己非常喜欢研究技术问题!专业做Java、Python、微信小程序、安卓、大数据、爬虫、Golang、大屏等实战项目。 ⛽⛽实战项目:有源码或者技术上的问题欢迎在评论区一起讨论交流! ⚡⚡ Java实战 | SpringBoot/SSM Python实战项目 | Django 微信小

    2024年01月21日
    浏览(56)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包