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