在各类系统设计中我们经常会使用这两者做信息的传递、系统的解耦，但是很难说出在什么场景上我们使用标准服务接口，什么场景使用标准消息，好像是都可以用。尤其在平台系统需要支撑各类业务场景的设计上，这类问题往往会是一个很难权衡的点。我们先看一下这两种方式的特点。
标准服务接口交互
高时效：耗时即为方法处理时间强一致：理论意义上的强一致，直接接口调用为强一致，soa调用需要分布式事务支持，明确能得到执行结果，对执行结果有后续处理语义清晰：有较清晰的函数名、参数、返回值以及类型，执行目的一目了然强耦合：受下游服务SLA影响而波动扩展性低：对接不同业务时需要增加代码/配置以调用不同的逻辑实现
标准消息交互
弱耦合：仅仅是数据的依赖，无系统依赖流量缓冲：可以积压防止下游服务承接不住扩展性高：消息能够被多个使用方订阅而不需要上游系统有任何变更无交互：仅仅是数据的传递，执行结果和上游服务无关
内容审核流程
用户的积分系统一般而言用户积分的积累可由很多种途径获取，比如下单、评论、分享等，积分和订单是两个完全不相关的领域，积分的过程也无须对下单等流程有影响，甚至说不应该感受到有积分的存在，为了做到这一点可以通过订阅交易下单等业务的动作事件来完成积分的统计。
积分交互
开放平台一般和有一些研发能力的外部业务方合作时，就会使用到开放平台来把平台的一部分能力提供给合作方，由开放平台提供开发者认证管理以及统一的鉴权、路由转发等，举个较为常用的电商商品管理的场景，第三方开发者在淘宝平台经营了一家淘宝店，想通过自己的ERP系统同步管理淘宝店的商品并且能够直接给商品做满减活动，第三方在上传商品的时候需要明确知道淘宝商品也已上传成功且返回商品id，创建活动也是类似要求，最后需要将淘宝商品id和活动id做关联。所以开放平台场景上需要同步请求内部系统，并且返回相关数据。
开放平台架构
有没有这两种方式结合的场景呢？即既有用标准接口又用标准数据的场景？
全链路打点系统我们以美团开源的分布式监控系统Cat来举例，Cat是一个实时和接近全量的监控系统，为美团各业务线提供系统的性能指标、健康状况、监控告警等，Cat在整体的设计上有一些要求
任务作业系统
文章为作者独立观点，不代表股票量化交易软件接口观点