在各类系统设计中我们经常会使用这两者做信息的传递、系统的解耦，但是很难说出在什么场景上我们使用标准服务接口，什么场景使用标准消息，好像是都可以用。尤其在平台系统需要支撑各类业务场景的设计上，这类问题往往会是一个很难权衡的点。我们先看一下这两种方式的特点（并非是优缺点）。
标准服务接口交互
高时效：耗时即为方法处理时间
强一致：理论意义上的强一致，直接接口调用为强一致，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对明确对数据的加工方式再提交到下游系统。
网友评论