微服务的架构体系中,可以简单的看做是一个大应用拆分为多个小应用,小应用可以自成体系,可以拥有自己的数据库、框架甚至于语言等等,各个小应用一般通过Rest接口的形式被第三方、H5或者APP去调用。这个时候必然会存在一种情况,某些页面需要多个服务组合才能得到用户需要的信息。举个栗子:
在电商系统中,查看商品详情页,这个商品详情页包含商品的详情,价格,库存,评论等,这些数据对于后端来说位于不同的微服务系统之中,后台的系统是这样来拆分服务的:
我们不做任何处理的时候,调用的时候是这样:
该处的缺点就是前端需要调用多次服务才能拿到我们想要的数据,为了解决这个问题我们可以做一层中间的聚合层,聚合层也就是我们通常所说的BFF
(Back-end for Front-end),BFF可以认为是一种适配服务,将后端的微服务进行适配(主要包括聚合裁剪和格式适配等逻辑),实现上没太大限制,能做请求转发和数据转化即可,升级以后框架是这样的,现在我们系统处于这个阶段:
这里会有两个问题
接下来我们再次升级我们架构,如下图:
网关的加入我们可以将所有的跨横切面的代码通通抽象到网关层,这样我们BFF层只需要关注服务适配的逻辑,另外也解决掉了之前业务单点、多节点的等问题,这个时候你可能又想,网关的部署也是单点了,这个时候你可以考虑在网关前挂一层NG或者F5,如果随着业务发展网关管理的服务越来越多,也可以将网关按照业务域进行整体的拆分。
功能点 | 描述 | 关键点 | 备注 |
---|---|---|---|
高性能 | 在技术设计上,网关不应该也不能成为性能的瓶颈 | 无状态设计,异步非阻塞的 I/O | |
高可用 | 因为所有的流量或调用经过网关,所以网关必须成为一个高可用的技术组件,它的稳定直接关系到了所有服务的稳定 | 集群化,热更新 | |
高扩展 | 因为网关需要承接所有的业务流量和请求,所以一定会有或多或少的业务逻辑。而我们都知道,业务逻辑是多变和不确定的,因此,我们需要支持能够通过配置执行不同的逻辑 | 插件化 |
• Pre Filter:请求被路由之前调用,身份验证
• Routing Filter:将请求路由到微服务
• Post Filter:远程调用后执行,HTTP Header、收集统计信息和指标、Response
• Error Filter:发生错误时执行