前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >系统间的交互用接口还是用消息?

系统间的交互用接口还是用消息?

作者头像
架构之家
发布于 2022-12-28 09:49:38
发布于 2022-12-28 09:49:38
4640
举报
文章被收录于专栏:架构之家架构之家

在各类系统设计中我们经常会使用这两者做信息的传递、系统的解耦,但是很难说出在什么场景上我们使用标准服务接口,什么场景使用标准消息,好像是都可以用。尤其在平台系统需要支撑各类业务场景的设计上,这类问题往往会是一个很难权衡的点。我们先看一下这两种方式的特点(并非是优缺点)。

标准服务接口交互

高时效:耗时即为方法处理时间 强一致:理论意义上的强一致,直接接口调用为强一致,soa调用需要分布式事务支持,明确能得到执行结果,对执行结果有后续处理 语义清晰:有较清晰的函数名、参数、返回值以及类型,执行目的一目了然 强耦合:受下游服务SLA影响而波动 扩展性低:对接不同业务时需要增加代码/配置以调用不同的逻辑实现

标准消息交互

弱耦合:仅仅是数据的依赖,无系统依赖 流量缓冲:可以积压防止下游服务承接不住 扩展性高:消息能够被多个使用方订阅而不需要上游系统有任何变更 无交互:仅仅是数据的传递,执行结果和上游服务无关

再回到我们的系统设计上,需要申明一点的是没有最好的设计,只有最适合的设计。以内容创作的场景来举例,用户投稿的过程中判断内容的安全性即时提醒用户安全风险没风险则上传至平台并推荐给其他用户,这种方式可以做到最佳的用户体验。但是以我们现在的安全把控粒度我们需要检查内容是否涉黄、涉暴、自杀自残等很多违反社区规范的行为,整个模型、策略执行下来早已超出2、3分钟之外。对于强体验的C端应用来说真的无法容忍。基于这个技术限制的背景,所以就需要反向推动安全检测能力和投稿能力独立,内容安全业务负责检查内容的安全性,投稿业务负责保障用户能够把内容上传到平台并保障其体验。也就有了用户先上传内容,安全检查异步进行这种方式。

内容审核流程

用户的积分系统 一般而言用户积分的积累可由很多种途径获取,比如下单、评论、分享等,积分和订单是两个完全不相关的领域,积分的过程也无须对下单等流程有影响,甚至说不应该感受到有积分的存在,为了做到这一点可以通过订阅交易下单等业务的动作事件来完成积分的统计。

积分交互

开放平台 一般和有一些研发能力的外部业务方合作时,就会使用到开放平台来把平台的一部分能力提供给合作方,由开放平台提供开发者认证管理以及统一的鉴权、路由转发等,举个较为常用的电商商品管理的场景,第三方开发者在淘宝平台经营了一家淘宝店,想通过自己的ERP系统同步管理淘宝店的商品并且能够直接给商品做满减活动,第三方在上传商品的时候需要明确知道淘宝商品也已上传成功且返回商品id,创建活动也是类似要求,最后需要将淘宝商品id和活动id做关联。所以开放平台场景上需要同步请求内部系统,并且返回相关数据。

开放平台架构

有没有这两种方式结合的场景呢?即既有用标准接口又用标准数据的场景?

全链路打点系统 我们以美团开源的分布式监控系统Cat来举例,Cat是一个实时和接近全量的监控系统,为美团各业务线提供系统的性能指标、健康状况、监控告警等,Cat在整体的设计上有一些要求

  • 故障容忍:CAT本身故障不应该影响业务正常运转,CAT挂了,应用不该受影响,只是监控能力暂时减弱
  • 高吞吐,准实时:为快速发现故障、快速定位故障提供时效性 此外在监控和性能分析功能上有如下场景要求:
  • 一段代码的执行时间,一段代码可以是URL执行耗时,也可以是SQL的执行耗时。
  • 一段代码的执行次数,比如抛出异常记录次数,或者一段逻辑的执行次数。
  • 定期执行某段代码,比如定期上报一些核心指标:内存使用率、GC、线程数等指标。
  • 关键的业务监控指标,比如监控订单数、交易额、支付成功率等。 所以希望用户的打点需要有明确场景含义才能够方便后续的数据收集及处理上针对不同场景做聚合、计算。Cat为上述场景设计了四类带有明确含义的接口Cat.newTransaction、Cat.logEvent、Cat.MetricForCount、Cat.MetricForDuration,并通过SDK供业务研发集成使用。

链路监控

再介绍一个比较常见的任务提交到反馈的场景,有一个比较明显的不同点是系统需要让下游做一件比较耗时的任务,同时也希望获得任务运行的结果,比如BI报表生成。通常是提交任务时实时返回任务id,表示任务提交成功,内部执行完耗时的任务后再去通知业务系统。 任务作业系统

任务作业系统

总结

当明确想要让这个系统帮你“”“什么”,并且关心这个系统的“结果”,如果对时效有要求那就建议使用用标准服务接口进行交互,如果对时效无要求则可以参考任务作业系统,通过标准的服务接口交互快速返回,在有结果后通过回调告知业务系统。 当仅仅是做数据传递及事件感知,不想对上游系统有影响也不需要上游知道是否有这样的系统存在,则通过标准消息或事件来交互,如果在业务逻辑处理的过程中希望对该数据有有确含义的处理但并不想影响自身系统,则可以参考Cat监控系统,通过sdk对明确对数据的加工方式再提交到下游系统。

出处:https://www.jianshu.com/p/fb1356a9b542

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2022-11-01,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 架构之家 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
聊聊知乎订单系统迁移
本文主要介绍知乎订单系统后端语言栈的转型升级过程,包括其间踩过的一些坑和遇到的一些问题。一来是想通过本篇文章为其它应用服务转型提供借鉴经验,二来是总结对于订单系统的理解。鉴于文字功底不足,对于业务理解不充分的地方,欢迎留言交流。文章大纲如下:
知一
2021/12/07
8270
聊聊知乎订单系统迁移
业务高速增长场景下的稳定性建设实战
背景   静儿在2017年8月25日怀着“再也不要下班时间收到报警”的美好期待加入美团金融智能支付负责核心交易,结果入职后收到的报警一天紧似一天。核心交易是整个智能支付的核心链路,承担着智能支付百分之
静儿
2018/07/02
2K1
【云+社区年度征文】TeamLeader如何Owner老系统?
做互联网的童鞋们一定都有过这样的经历,看过很多架构书,看过很多架构师成长指南,看过很多优秀的案例分享以及讲座。所以当我们刚毕业的时候,对于大厂的认知一定都是这样的。
小诚信驿站
2020/12/15
1.1K0
【云+社区年度征文】TeamLeader如何Owner老系统?
美团点评智能支付核心交易系统的可用性实践
每个系统都有它最核心的指标。比如在收单领域:进件系统第一重要的是保证入件准确,第二重要的是保证上单效率。清结算系统第一重要的是保证准确打款,第二重要的是保证及时打款。我们负责的系统是美团点评智能支付的核心链路,承担着智能支付100%的流量,内部习惯称为核心交易。因为涉及美团点评所有线下交易商家、用户之间的资金流转,对于核心交易来说:第一重要的是稳定性,第二重要的还是稳定性。
静儿
2018/05/24
2.7K4
让你的系统“坚挺不倒”的最后一个大招——「降级」
前面两篇我们已经聊过了「熔断」(如何在到处是“雷”的系统中「明哲保身」?这是第一招)和「限流」(想通关「限流」?只要这一篇),这次我们聊的就是「高可用三剑客」中剩下的「降级」。
Zachary_ZF
2018/12/27
6580
如何构建 API 生态促进企业上下游合作
今天,互联网迈入了云原生的时代,DevOps持续开发运维的概念得到了普及。产品迭代速度极快,API数量爆发式增长,并且有70%到90%的业务是通过开源代码和第三方API来实现的。
石臻臻的杂货铺[同名公众号]
2022/12/22
4120
如何构建 API 生态促进企业上下游合作
如何设计一个秒杀系统?
这篇分享源自之前购买的极客时间课程《如何设计一个秒杀系统》,以及书籍《亿级流量网站架构核心技术》。
BookSea
2024/06/18
2840
如何设计一个秒杀系统?
写给供应链产品经理:浅谈订单系统的设计
订单管理是一个常见的管理问题,包含在企业的订单处理流程中。由于客户/用户下订单的方式多种多样、订单执行路径千变万化、产品和服务不断变化、发票开具难以协调,这些情况使得订单管理变得十分复杂。
物流IT圈
2019/08/09
4.4K0
秒杀系统架构解析:应对高并发的艺术
对于各大电商平台而言,爆款运营和促销活动的日常化已成为常态,而支撑这些的秒杀系统自然是不可或缺的一环。同时,秒杀活动的巨大流量就像一头洪荒之兽,若控制不当,可能会冲击整个交易体系。因此,秒杀系统在交易体系中便扮演着至关重要的角色。
ThoughtWorks
2024/07/04
8170
秒杀系统架构解析:应对高并发的艺术
战狼:业务高速增长下,如何保证系统的稳定性和高可用?
背景 2017年8月25日,我怀着“再也不要在下班时间收到报警”的美好期待,加入美团金融智能支付负责核心交易,结果入职后收到的报警一天紧似一天。核心交易是整个智能支付的核心链路,承担着智能支付百分之百的流量,不敢有丝毫的懈怠。   从17年下半年开始,我们的日单量增长迅速,而且压力和流量在午、晚高峰时段非常集中。在这种情况下,报警和小事故日益频繁,交易的稳定性面临着严峻的考验。下面是早期的可用性趋势图,仔细看的话,可以看到可用性有下降的趋势,旁边的总可用性显示只有4个9(99.998765%),美团点评排在
静儿
2018/07/02
1.1K0
汽车之家电商系统架构演进与平台化架构实践
作者 | 方利 编辑 | 贾亚宁   本文由大厂案例转载自汽车之家主机厂事业部 - 技术部高级研发工程师方利首发于之家技术公众号的文章。 汽车之家电商系统诞生在 2014 年,成长于 2016~2019 年,并经历多年双 11、818 晚会的洪峰考验,沉淀了稳定可靠、性能卓越的在线交易能力。随着业务中台的建设浪潮兴起,2019 年进入中台化建设阶段,输出其在汽车电商领域五年沉淀的能力,助力汽车电商行业发展,加速企业数字化转型!   一、架构演进 这个部分主要讲一下汽车之家电商系统的架构发展历程,每
深度学习与Python
2023/03/29
1.4K0
汽车之家电商系统架构演进与平台化架构实践
数据调度平台系统二大种类及其实现方法与流程
调度系统,更确切地说,作业调度系统(Job Scheduler)或者说工作流调度系统(workflow Scheduler)是任何一个稍微有点规模,不是简单玩玩的大数据开发平台都必不可少的重要组成部分。
TASKCTL 任务调度平台
2020/07/03
1.7K0
数据调度平台系统二大种类及其实现方法与流程
淘宝商品历史价格接口/商品历史价走势接口/天猫商品历史价格接口/淘宝商品价格接口代码教程
业务场景:作为全球最大的 B2C 电子商务平台之一,淘宝天猫平台提供了丰富的商品资源,吸引了大量的全球买家和卖家。为了方便开发者接入淘宝天猫平台,淘宝天猫平台提供了丰富的 API 接口,其中历史价格接口是非常重要的一部分。大家有探讨稳定采集淘宝(天猫)京东阿里拼多多等平台整站实时商品详情历史价格数据接口,通过该接口开发者可以更好地了解商品的情况,商品详情历史价格数据详细信息查询,数据参数包括:商品链接,商品列表主图、价格、标题,sku,库存,销量,店铺昵称,店铺等级,商品详情SKU属性,商品视频,商品优惠券,促销信息,详情属性描述,宝贝ID,区域ID,发货地,发货至,快递费用,物流费用等页面上有的数据完整解决方案帮助买家更准确地进行商品选购及商品分析。这个引起了我对技术挑战的兴趣。目前,自己做了压测,QPS 高、出滑块概率极低,API 整体稳定,可满足商品分析,竞品分析,品牌监控,商品搬家,商品上传,商城建设,淘宝客,erp 选品,店铺同步,CID 店铺订单回传接口等业务场景的性能需求,下面介绍接口封装代码教程:
wx19970108018
2023/04/14
1.1K0
淘宝商品历史价格接口/商品历史价走势接口/天猫商品历史价格接口/淘宝商品价格接口代码教程
美团配送实时特征平台建设实践
导读:2019年5月,美团正式推出新品牌「美团配送」,升级配送开放平台。那你知道支撑美团配送大脑的实时特征平台是如何建设的吗?如何实现每分钟生产千万级的实时特征?如何在70w+QPS的场景下实现4个9响应耗时在50毫秒的需求?本文将为大家介绍配送实时特征平台的发展历程,关键技术和实践经验。
Houye
2021/01/27
1.4K0
美团配送实时特征平台建设实践
高可用架构和系统设计经验
可用性是一个可以量化的指标,计算的公式在维基百科中是这样描述的:根据系统损害、无法使用的时间,以及由无法运作恢复到可运作状况的时间,与系统总运作时间的比较。行业内一般用几个9表示可用性指标,对应用的可用性程度一般衡量标准有三个9到五个9;一般我们的系统至少要到 4 个 9(99.99%)的可用性才能谈得上高可用。
Allen.Wu
2022/12/19
1.5K0
MQ(消息队列)常见的应用场景解析
提高系统性能首先考虑的是数据库的优化,之前一篇文章《数据库的使用你可能忽略了这些》中有提到过开发中,针对数据库需要注意的事项。但是数据库因为历史原因,横向扩展是一件非常复杂的工程,所有我们一般会尽量把流量都挡在数据库之前。 不管是无限的横向扩展服务器,还是纵向阻隔到达数据库的流量,都是这个思路。阻隔直达数据库的流量,缓存组件和消息组件是两大杀器。之前文章《Redis常见的应用场景解析》已经描述了最常用的缓存组件redis的应用场景,那么今天,就重点说说MQ的应用场景。
itmifen
2018/07/24
5.2K0
MQ(消息队列)常见的应用场景解析
工作十年,在腾讯沉淀的高可用系统架构设计经验
👉腾小云导读 在系统的开发过程中,很多开发者都为了实现系统的高可用性而发愁。本文从研发规范层面、应用服务层面、存储层面、产品层面、运维部署层面、异常应急层面这六大层面去剖析一个高可用系统的架构设计需要有哪些关键的设计和考虑。希望腾讯的经验方法,能够给广大开发者提供参考。内容较长,您可以收藏后持续阅读。 👉看目录点收藏,随时涨技术 1 高可用系统的架构设计思想     1.1 可用性和高可用概念     1.2 高可用系统设计思想 2 研发规范层面     2.1 方案设计和编码规范     2.2 容量规划
腾讯云开发者
2023/03/14
5.5K0
工作十年,在腾讯沉淀的高可用系统架构设计经验
如何设计一个秒杀系统
秒杀已经成为电商不可缺少的一步分了,所谓 买到就是赚到,可以成功吸引到一大堆用户,那程序员面对这些用户该怎么办呢。我们该如何设计秒杀呢?
憧憬博客
2020/10/09
7920
干货 | 上线效率提升8倍,携程门票活动直连平台实践
作者简介 Harry,携程资深后端开发工程师,负责直连平台建设,关注系统高可用、数据驱动等领域。 一、前言 携程门票活动供应商直连平台(以下简称“直连平台”)通过API对接多个供应商的订单和商品系统,实现自动化信息同步和状态流转。 随着业务的高速发展,供应商的对接需求与日俱增,这不仅对直连平台接入供应商的上线效率提出更高的要求,同时供应商系统的物理网络限制、稳定性参差不齐等情况也给直连平台带来不小的挑战。 本文将从提高供应商接入效率和增强系统稳定性两个方面分享直连平台的实践经验。 二、背景 2.1 系统介绍
携程技术
2022/09/02
1.2K0
干货 | 上线效率提升8倍,携程门票活动直连平台实践
得物从零构建亿级消息推送系统的送达稳定性监控体系技术实践
本文分享的是得物针对现有的消息推送系统的消息送达耗时、实时性、稳定性等方面问题,从零到一构建完整的消息推送质量监控体系和机制的技术实践。
JackJiang
2024/01/25
2590
得物从零构建亿级消息推送系统的送达稳定性监控体系技术实践
推荐阅读
相关推荐
聊聊知乎订单系统迁移
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档