微服务为何需要相互通信？前端axios调用替代服务交互及事件总线作用疑问

为什么前端可以通过axios直接调用各微服务，还需要微服务之间相互通信？ #

• 避免前端逻辑冗余臃肿：如果所有跨服务的数据聚合、业务校验、计算逻辑都放到前端实现，首先会导致前端包体积变大、加载和运行性能下降，其次如果有多端（网页端、移动端、小程序）需求，相同的逻辑要在每一端重复实现一遍，后续迭代要同步修改多端代码，维护成本极高。
• 保障业务与数据安全：很多内部业务逻辑和敏感数据是不适合暴露给前端的，比如下单时的商品定价校验、库存扣减、用户余额校验这类核心逻辑，如果交给前端调度很容易被恶意篡改请求，造成资损。
• 保证数据一致性：跨多个微服务的操作如果靠前端调度，一旦出现用户断网、页面关闭、某个接口请求失败的情况，就会出现部分服务数据更新、部分未更新的不一致问题，后端微服务之间通信可以通过重试、补偿、分布式事务机制保证数据最终一致。
• 降低网络与权限成本：前端直接调用多个不同域名的微服务会面临跨域问题，且很多内部微服务不会对外部公网暴露，只能通过后端内网进行服务间通信。

前端+后端微服务场景下，事件总线、事件驱动架构的作用是什么？ #

• 实现服务解耦：事件发送方不需要感知有哪些服务需要消费数据，比如Posts服务发布了「商品信息更新」事件，不管是购物车、搜索、推荐哪个服务需要用到这个数据，Posts服务都不需要修改代码，服务之间没有强依赖。
• 异步削峰抗量：当出现短时间大量请求的场景（比如大促、热点商品上架），同步调用很容易把下游服务打挂，通过事件总线可以先把事件缓存下来，下游服务按照自己的处理能力异步消费，避免服务雪崩。
• 保证数据最终一致：跨服务的状态变更通过事件广播，搭配重试、死信队列机制，能保证所有相关服务的状态最终同步一致，比同步调用的强事务开销低很多。
• 便于业务扩展：后续如果新增其他服务需要消费Posts的数据，直接订阅对应事件即可，不需要修改现有服务的逻辑。

现有方案是否合理，还是应该通过前端axios实现数据交互？ #

你现在的方案是合理的，不推荐用前端实现这个交互流程，原因如下：

• 如果让前端先调用Posts接口拿数据，再传给购物车服务，首先前端要多发起一次网络请求，会拉长页面响应时间，还需要额外处理Posts请求失败、参数传输出错的边界情况，增加前端逻辑复杂度。
• 如果购物车服务需要基于Posts的数据做本地校验（比如校验要加入购物车的商品是否在售、价格是否有效），通过事件总线提前把Posts的增量数据同步到购物车的本地库，购物车处理请求时直接查本地库即可，响应速度远高于每次都跨服务调用Posts接口，也不会因为Posts服务故障导致购物车服务不可用。
• 只有当你这个操作是极低频的特殊场景，且购物车不需要对Posts的数据做持久化、前置校验的情况下，才可以考虑让前端聚合两个服务的接口数据，其余场景优先选择后端事件同步的方案。

内容的提问来源于stack exchange，提问作者Jan Tuđan