本篇文章给大家谈谈API与ESB 、ServiceMesh、微服务究竟关系如何？-esb soa 微服务，以及对应的知识点，文章可能有点长，但是希望大家可以阅读完，增长自己的知识，最重要的是希望对各位有所帮助，可以解决了您的问题，不要忘了收藏本站喔。

导读

我之前提到过要引入一个API网关。事实上，无论是微服务、服务网格，还是云原生、数字化建设，API网关都是一个绕不开的话题。由于网上对API网关的介绍参差不齐，所以今天我们不再简单介绍API网关的基础知识和功能，而是开门见山地讲一下ESB、ServiceMesh、微服务和API网关之间的关系。

[[421537]]

01 API 网关的核心

随着微服务场景的广泛使用，API网关逐渐引起了大家的关注。聚合接口和服务来提供前端调用和业务封装是API网关的主要场景。

02 API与ESB 、ServiceMesh、微服务的关系

替代ESB的场景

ESB架构负责东西向服务之间的访问控制以及南北向流量的控制。使用API网关的方案更加灵活。其大小的大小、动态配置的灵活性、自助式的消费模式，都更加符合不断变化、多元化的数字化新架构。如果规划得当，API网关不仅可以替代ESB，还可以作为整个网络域甚至整个企业的网关。这是服务集中化的第一步。

服务网格中的应用

ServiceMesh的概念其实很容易理解。所有流量均通过代理服务接管，非业务治理、监控等功能均通过代理服务实现。那么这个代理服务（proxy）就是API网关的另一个应用场景。劫持流量并添加您想要的自定义。

与其他场景相比，这里的网关功能没有太大变化，但使用地点却有很大不同。在ServiceMesh场景中，网关是一个非常小、轻量级的代理单元，各个业务运行单元都会与代理单元一起启动，所以在ServiceMesh场景中，通常称为sidecar。换句话说，ServiceMesh中的Sidecar是一个API网关应用。例如，Istio框架下，数据面Sidecar是Envoy（基于C++语言的API网关）。

微服务网关

值得一提的是微服务场景下的API网关。这个场景不就是最基本的应用吗？事实上，事实并非如此。微服务网关也是API网关场景化改造的结果，比如SpringcloudGateway、Zuul等。两种是基于netty框架使用Java语言开发的微服务网关，主要应用于Springcloud微服务场景。

03 总结

因此，根据不同的使用场景和不同的应用方式，可以根据API网关进行自由调整。我们博云内部，至少涉及三个网关，多个场景的使用。

第一类：企业级API网关，主要以提供服务能力、承载企业级流量为主，因此对网关的性能要求极高。我们使用的组件是基于openresty+lua的kong来解决问题的，其性能保证了整个企业的交互压力。

第二种：微服务的网关主要是微服务的封装，但不是重点或难点。通过很多项目的交付，发现微服务的需求很容易满足，但过渡计划却比较困难。所谓过渡方案，是指非微服务应用需要与微服务应用统一管理时，通过API网关的sidecar方案。博云内部使用SpringcloudGateway，在其上进行协议转换、服务检测等功能，实现单体应用和传统架构系统的统一管理和治理。

第三种：服务网格，主要是数据平面的sidecar部分。与上面的不同的是，上面的微服务框架基本已经确定是Springcloud，而服务网格原本使用的是博云内部的Istio框架。 Istio框架下的Sidecar使用的是Envoy。我们在Envoy 上扩展了ESB 场景和传统架构兼容场景，增加了协议支持、协议转换、数据采集、链路采集等功能，以实现复杂的微服务改造需求。

阵而战，兵法之规律、用之妙，全在于一心。 API网关的技术已经几近成熟，在合适的场景中合理使用将会发挥巨大的作用。

好了，关于API与ESB 、ServiceMesh、微服务究竟关系如何？-esb soa 微服务和的问题到这里结束啦，希望可以解决您的问题哈！