InfoQ|谈谈微服务设计中的 API 网关模式( 三 )

  • 服务发现
  • 健康检查
  • 安全性
  • 从表面上看 , API 网关和 Service Mesh 似乎解决了相同的问题 , 因此好像是多余的 。 它们确实解决了相同的问题 , 但是应用在不同的场景 。 API 网关被部署为业务解决方案的一部分 , 被外部的服务发现 , 处理纵向的流量(面对外部客户端) , 但是 , Service Mesh 是用来处理横向流量(在不同的微服务之间) 。
    实现 Service Mesh 可避免在您自己的代码中出现一些弹性交互 , 例如熔断器、服务发现、健康检查以及服务观察 。 对于少量的微服务 , 应考虑使用其他替代方法来进行故障管理 , 因为 Service Mesh 集成可能代价太大了 。 但对于大量的微服务 , 它的收益是显著的 。
    结合这两种技术可能是确保应用程序正常运行时间和弹性伸缩能力的一种有效方法 , 同时又可以确保您的应用程序易于使用 。 将两者视为同样的产品是不对的 , 最好将两者视为在涉及微服务和 API 的部署中相辅相成的工具 。
    InfoQ|谈谈微服务设计中的 API 网关模式
    本文插图
    API 网关实现的注意事项:
    • 可能产生的单点故障或者瓶颈
    • 由于通过 API 网关进行了额外的网络跳转以及复杂性风险 , 响应时间增长了 。
    原文链接:
    InfoQ 读者交流群上线啦!各位小伙伴可以扫描下方二维码 , 添加 InfoQ 小助手 , 回复关键字“进群”申请入群 。 大家可以和 InfoQ 读者一起畅所欲言 , 和编辑们零距离接触 , 超值的技术礼包等你领取 , 还有超值活动等你参加 , 快来加入我们吧!
    点个在看少个 bug ??


    推荐阅读