从数据闭环谈微服务拆分

简介: 从数据闭环谈微服务拆分

数据闭环,并不是说我们要将所有的功能全包揽在身上,不依赖其他业务方,也不依赖中台。而是想强调一件事,那就是业务问题排查过程尽量不要牵扯过多团队,因为数据链路越长越乱处理问题时效性越差,服务性能往往也不尽人意。我先分享个案例给你,或许能帮助你理解和产生共鸣。


我们有一个内容渠道是直播,渠道权限和创建直播间入口都是我们来维护的,但是创建直播后的内容保存接口是直播团队维护的,保存接口会校验达人权限和等级,而校验接口又是另外一个团队提供的,他们对我们缓存进行了封装。最近发现权限校验异常频发,原因是缓存和 数据库状态不一致。可是对于达人或者不知情的人来说,在达人创作平台上碰到的问题就应该由创作端来负责,可真正出现问题的环节不在我们这。


上面的例子暴露出了很多问题,比如业务不是独立性的、其他服务直接共享了缓存。没有备忘录,其他同事根本不会知道还有这种隐藏的逻辑。这就好比一个枚举类在这个系统上修改了,但是在另外一个使用到它的系统却没有同步修改,灾难往往就在不久的将来。想要避免这些问题,那就要做好服务拆分。业内推荐的微服务拆分一般有以下四种:


1、基于业务逻辑拆分


一个内容从达人生产到用户能看到,需要经过很多中间过程。涉及到用户成长体系、渠道权限管理、频道样式创作、内容机审人审质检等等。如果中间环节都拆分成单独的业务,而各种样式内容的站内站外分发交由各个频道独立处理,也就是内容从生产到审核都是在闭环的,那案例中的隐藏的大坑就不复存在。每三个同事负责每几个环节的微服务,哪个环节出现问题那就让负责这个环节的同事排查就可以了,不需要多方同时介入,大家各司其职。


按照业务逻辑拆分后,不仅能形成更稳定的接口,还能确保我们能够更好的反映业务流程的变化。另外,每个独立部署的业务都可以使用特定的专业技能进行开发,比如内容推荐算法。每个独立部署的业务都有主要负责的研发,产品也就不需要抢研发资源来满足需求。


2.基于可扩展拆分


我们部门负责京东内容生态的建设,服务业务方各种定制化需求,其他事业群比如国际站却以为我们是技术中台,然后要求我们做一个国际化的达人创作平台。不过说实在的,那怕小步慢跑也无法满足他们的需求,因为内容这么多环节都有可能涉及到兼容性问题,比如发现好货中的商品信息上游是否兼容、内容安全校验算法是否兼容等等。


因为我们不是技术中台,没必要将功能以可扩展性为目标进行组件化,实现整套开放赋能,毕竟组织架构影响着技术架构。在这件事情上,我们只能分享经验和体系架构,或者他们觉得某个功能能直接复用,我们肯定大大方方将其拆出来然后贡献出去,让其独立演化,仅止而已。


3.基于可靠性拆分


MCN机构达人生产内容然后引导用户购买商品所得到的佣金是他们的命根子,如果出现计算不准确、提现异常的情况,达人就会觉得有猫腻,产生不信任,就会主动离开。而内容由于机器审核异常导致短暂无法正常进入人工审核阶段,是可以接受。可以看出我们对佣金结算和审核系统的可靠性容忍程度截然不同。


另外,佣金结算是一个长期不迭代的、稳定的业务,而审核系统可能会经常引入新的校验逻辑而需要变更上线,也就意味着后者的上线变更可能会直接影响到结算业务。因为代码越是修改,引入不确定性的风险越大。那我们需要避免因为审核系统需求上线变更导致佣金结算业务受到影响。最好的方式就是将他们拆开。


也就是说,一个服务故障发生时产生的影响面很大,它就算系统中很脆弱的部分,我们必须将其拆分出去,将异常隔离。


4.基于性能拆分


我们内容人工审核是由外包团体承包的,时常收到他们反馈说,下午6点左右审核页面加载很慢,审核通过按钮需要点好几下才能生效。我们结合数据库IO告警和数据库慢查询来看,那个时间段应该是有人在跑大数据调度任务,可是很难定位到具体的任务。不知道读者有没有体验过这种因为数据源依赖导致个别业务性能受到影响,包括很难优化的数据库慢查询。因此,它们的数据源应该拆分掉,业务同理。

最后多说一点,不管采用何种方式拆分服务,或者何种组合拆分方式,都要注意数据流向,千万不能出现循环依赖,包括使用MQ解藕,那也算一种隐层的依赖。


好,如果文章有帮助到你,欢迎转发分享或者点个在看。

作者介绍:京东资深工程师-梁松华,在稳定性保障、敏捷开发、 JAVA高级、微服务架构方面有深入的理解


相关文章
|
7月前
|
JSON Java 数据格式
微服务——SpringBoot使用归纳——Spring Boot返回Json数据及数据封装——封装统一返回的数据结构
本文介绍了在Spring Boot中封装统一返回的数据结构的方法。通过定义一个泛型类`JsonResult<T>`,包含数据、状态码和提示信息三个属性,满足不同场景下的JSON返回需求。例如,无数据返回时可设置默认状态码"0"和消息"操作成功!",有数据返回时也可自定义状态码和消息。同时,文章展示了如何在Controller中使用该结构,通过具体示例(如用户信息、列表和Map)说明其灵活性与便捷性。最后总结了Spring Boot中JSON数据返回的配置与实际项目中的应用技巧。
543 0
|
7月前
|
JSON Java fastjson
微服务——SpringBoot使用归纳——Spring Boot返回Json数据及数据封装——使用 fastJson 处理 null
本文介绍如何使用 fastJson 处理 null 值。与 Jackson 不同,fastJson 需要通过继承 `WebMvcConfigurationSupport` 类并覆盖 `configureMessageConverters` 方法来配置 null 值的处理方式。例如,可将 String 类型的 null 转为 "",Number 类型的 null 转为 0,避免循环引用等。代码示例展示了具体实现步骤,包括引入相关依赖、设置序列化特性及解决中文乱码问题。
329 0
|
7月前
|
JSON Java fastjson
微服务——SpringBoot使用归纳——Spring Boot返回Json数据及数据封装——Spring Boot 默认对Json的处理
本文介绍了在Spring Boot中返回Json数据的方法及数据封装技巧。通过使用`@RestController`注解,可以轻松实现接口返回Json格式的数据,默认使用的Json解析框架是Jackson。文章详细讲解了如何处理不同数据类型(如类对象、List、Map)的Json转换,并提供了自定义配置以应对null值问题。此外,还对比了Jackson与阿里巴巴FastJson的特点,以及如何在项目中引入和配置FastJson,解决null值转换和中文乱码等问题。
948 0
|
7月前
|
存储 JSON NoSQL
微服务——MongoDB的数据模型
MongoDB采用文档(document)作为最小存储单位,类似关系型数据库中的行,使用BSON(Binary-JSON)格式存储数据。BSON是JSON的二进制扩展,支持内嵌文档和数组,新增了如Date、BinData等特殊数据类型,具有轻量、高效、可遍历的特点,适合非结构化与结构化数据存储。其灵活性高,但空间利用率略低。BSON数据类型包括string、integer、boolean等基本类型及date、object id等扩展类型。
167 0
|
10月前
|
存储 监控 供应链
微服务拆分的 “坑”:实战复盘与避坑指南
本文回顾了从2~3人初创团队到百人技术团队的成长历程,重点讨论了从传统JSP到前后端分离+SpringCloud微服务架构的演变。通过实际案例,总结了微服务拆分过程中常见的两个问题:服务拆分边界不清晰和拆分粒度过细,并提出了优化方案,将11个微服务优化为6个,提高了系统的可维护性和扩展性。
215 0
|
10月前
|
存储 消息中间件 SQL
微服务改造血泪史:数据库拆分踩过的那些坑!
本文复盘了传统项目改造成微服务架构时,数据库拆分过程中遇到的问题。主要问题包括:1. 数据库拆分过细,导致跨服务调用频繁,破坏服务独立性;2. 数据一致性难以保证,分布式事务管理复杂;3. 跨服务查询影响性能,复杂查询难以实现。初次改造时应避免过度拆分,逐步演进架构。
158 0
|
存储 搜索推荐 数据库
MarkLogic在微服务架构中的应用:提供服务间通信和数据共享的机制
随着微服务架构的发展,服务间通信和数据共享成为关键挑战。本文介绍MarkLogic数据库在微服务架构中的应用,阐述其多模型支持、索引搜索、事务处理及高可用性等优势,以及如何利用MarkLogic实现数据共享、服务间通信、事件驱动架构和数据分析,提升系统的可伸缩性和可靠性。
162 6
|
安全 网络安全 数据安全/隐私保护
云原生技术探索:容器化与微服务架构的实践之路网络安全与信息安全:保护数据的关键策略
【8月更文挑战第28天】本文将深入探讨云原生技术的核心概念,包括容器化和微服务架构。我们将通过实际案例和代码示例,展示如何在云平台上实现高效的应用部署和管理。文章不仅提供理论知识,还包含实操指南,帮助开发者理解并应用这些前沿技术。 【8月更文挑战第28天】在数字化时代,网络安全和信息安全是保护个人和企业数据的前线防御。本文将探讨网络安全漏洞的成因、加密技术的应用以及提升安全意识的重要性。文章旨在通过分析网络安全的薄弱环节,介绍如何利用加密技术和提高用户警觉性来构建更为坚固的数据保护屏障。
|
消息中间件 监控 Java
解锁Spring Cloud微服务架构的奥秘:深度剖析拆分原则,打造高内聚低耦合的业务创新引擎!
【8月更文挑战第3天】踏入微服务领域,Spring Cloud以丰富组件助力高效系统构建。微服务拆分需遵循原则确保系统高内聚低耦合且能适应变化。首要原则为单一职责,每个服务专注一个业务功能,降低复杂度并提高可维护性。其次,追求高内聚低耦合以减少服务间影响。围绕业务域拆分有助于保持逻辑清晰及团队协作。处理数据一致性问题时,考虑采用最终一致性模型。Spring Cloud提供Eureka、Zuul/Gateway、Sleuth和Config等工具支持服务发现、路由、跟踪及配置管理,共同构建灵活健壮的微服务架构。
236 2
|
敏捷开发 数据库 微服务
SpringCloud微服务拆分原则
SpringCloud微服务拆分原则
252 2

热门文章

最新文章