数字化IT架构-传统架构微服务下ESB总线到API网关的演进分析

Hello，大家好，我是人月聊IT。今天我再结合几张图，再进一步说明传统的ESB服务总线发展演进的整个过程。

大家都比较清楚，在传统单体架构下面，基于SOA服务架构的思想，采用ESB服务总线或者叫SOA集成平台进行企业内部的单体系统之间的接口集成，这是业界常用的一种做法。但是，随着整个传统IT架构朝微服务架构的转型，在整个微服务架构下面，你再用比较重的ESB总线集成就不太合适了。

图片

在微服务架构下面，我们为了实现集成就出现了三个东西。

• 服务注册发现中心
• 微服务网关
• API网关

所以要了解清楚整个ESB的演进过程，你首先要把服务注册发现中心、微服务网关、API网关三者之间的关系，先要把它搞明白。

对于服务注册发现中心，它的重点是解决一个大的微服务应用里面，多个微服务模块之间横向的集成和交付，它只需要从服务注册发现中心找到服务调用的地址，然后直接发起点对点的调用，因此服务注册发现中心我们经常也说它是一种去中心化的架构。

但是，如果你整个的微服务应用有前后端分离，或者是有APP移动端，这个时候你就需要有一个统一的服务的代理和统一的一个纵向的南北的流量出口，在这种情况下面，一般你就还需要搭建一个微服务网关。也就是说，微服务网关来实现统一的接口流量的代理，实现整个南北流量的管理，这个是服务注册发现中心和微服务网关的一个区别，在我前面也专门发过详细的一张图来进行讲解。

图片

在微服务网关以后，又出现了一个关键的东西叫API网关，所以你必须要了解清楚微服务网关和API网关之间的一个区别，因为两者它本质都是一个中心化的架构，本质都可以对南北流量进行流量的拦截和处理。但是API网关本身除了流量的代理和转发以外，它还增加了安全日志、限流熔断等各种的流量管控的能力。如果你是微服务网关，你看到它本身不带安全的能力，往往在微服务应用里面，你会通过类似于JWT来实现服务访问的安全，它本身也不带服务接口流量的限流熔断能力，你可以通过类似于sentinel来实现服务的限流熔断。

微服务网关，它核心的仅仅只是做流量的代理和转发。同时两者最大的一个区别，我在前面也讲过，微服务网关它本身管控的颗粒度是整个微服务，并不会管理到微服务提供的一个一个的API接口这个颗粒度。我在前面也专门举过一个例子，比如说我整个人力资源的微服务应用，人员管理它就是一个微服务，那么微服务网关只能管到人员这个微服务上面去，这个流量一开放，你整个人员微服务所有的接口都开放了。

但是，如果你是API网关，它具体可以管理到更新人员信息、查询人员信息、查询组织信息各种细粒度的API接口。也正是这个原因，我们一直在强调，如果你是一个大的微服务应用建设，你在内部直接建微服务网关就足够了，因为一个大的应用的内部权限，不用管到这么细。但是你当前同时建了人力资源供应链合同多个微服务应用，微服务应用之间它本身还有接口要交付，在这种情况下面，一定不可能把整个微服务模块全部开放出去，那么这个时候就一定要管到细粒度的一个个的API接口能力上面。也就是说，各个微服务应该把它需要做跨应用交互的接口，把它暴露出来，接到更上层的API网关上面去。

也正是这个原因，我们一般推荐的是什么呢？

对于一个大的集团企业，你要建很多个微服务应用，本身也是分包给了多个软件开发商来做，那么对于每个软件开发商，它去构建自己的微服务应用的时候，它只需要去做微服务网关，不应该去建API网关，而是应该你从企业级的角度去构建一个企业级所有的微服务应用共用的API网关，实现对所有API接口统一的管控和治理，这是我想强调的一个关键的区别。

那么整个IT架构转型的过程中，它本身是一个演进的过程，不可能说遗留的单体在同一个时间，一下子全部都转成微服务架构了。所以通常来说，我们是需要一个融合的网关引擎，这个引擎既支持传统的单体架构，又支持新的微服务应用，这个引擎它底层可以同时集成ESB总线、API网关、ETL集成、大文件传输、消息中间件等各种集成引擎的能力，这个也是我们推荐的一种做法。

那么在API网关以后还有什么发展演进呢？也就是我们讲的在微服务在云原生下，我们希望做到的是一种完全去中心化的架构，那么对于API网关本身能不能也彻底做到去中心化呢？

图片

回答是可以的，也就是说，对于API网关，随着整个的发展演进，我们是基于云原生服务网格的思路，把API网关对细粒度的API接口管控的能力，把它下发到每个微服务的边车端，在每个微服务端，你下放一个边车代理。

通过这个边车代理去拦截南北所有的流量，只要你拦截的流量，你就可以对这个流量进行相应的安全日志限流熔断处理，那么在这个时候，整个API网关，它的控制流和数据流就做到了一个彻底的分离。但是你仍然是需要一个统一的南北流量的出口，那么API网关剩下的内容就只有接口的转发和流量的代理这个事情了，那么这个事情就不一定是API网关的能力来做了，你可以借鉴硬件负载均衡的能力，借鉴类似ngnix的反向代理都可以去做流量的转发和代理，或者是你直接在类似于kubernetes上面去做ingress网关的扩展，完全就可以达到目的。

大家可能会说当前主流的服务网格下面的istio解决方案不是已经能够做到你刚才说的这些点了吗？回答也是一样的道理，传统的istio的去中心化的微服务治理，它管控的粒度是到微服务的粒度，它不是到微服务提供的每一个API接口的粒度，所以一般来讲，我们要做到我刚才最终的去中心化的API网关的这个效果，我们一般还需要对开源的istio整个解决方案，对它的envoy边车端的能力进行扩展，加上我们细粒度管控的类似于安全日志、限流的各种拦截插件，这个也是我们现在准备规划考虑要去做的一个事情。

简单总结就是整个IT架构的发展，ESB总线会逐渐朝API网关过渡，API网关为了进一步去中心化，它会借鉴服务网格的思路，形成一个去中心化的API网关能力。

好了今天的简单分享就到这里，希望对大家有所启发，再见。