微服务下的网关

为什么出现网关
微服务的架构体系中，可以简单的看做是一个大应用拆分为多个小应用，小应用可以自成体系，可以拥有自己的数据库、框架甚至于语言等等，各个小应用一般通过Rest接口的形式被第三方、H5或者APP去调用。这个时候必然会存在一种情况，某些页面需要多个服务组合才能得到用户需要的信息
在电商系统中，查看商品详情页，这个商品详情页包含商品的详情，价格，库存，评论等，这些数据对于后端来说位于不同的微服务系统之中，后台的系统是这样来拆分服务的：

商品服务：负责提供商品的标题，描述，规格等

营销服务：负责对产品进行定价，价格策略计算，促销价等

库存服务：负责产品库存

评价服务：负责用户对商品的评论，回复等

该处的缺点就是前端需要调用多次服务才能拿到我们想要的数据，为了解决这个问题我们可以做一层中间的聚合层，聚合层也就是我们通常所说的BFF(Back-end for Front-end)，BFF可以认为是一种适配服务，将后端的微服务进行适配(主要包括聚合裁剪和格式适配等逻辑)，实现上没太大限制，能做请求转发和数据转化即可，升级以后框架是这样的，之前我们系统处于这个阶段：

多个聚合层有很多跨横切面的代码是重复的，比如安全认证，日志监控，限流熔断等，随着时间的发展代码变得不可维护;

随着访问量、业务的增加，两个BFF层也满足不了我们的业务，需要抽象更多的BFF和采用集群部署的方式。

这里我们引入的我们本章的主角网关，由于网关的加入我们可以将所有的跨横切面的代码通通抽象到网关层，这样我们BFF层只需要关注服务适配的逻辑，另外也解决掉了之前业务单点、多节点的等问题，这个时候你可能又想，网关的部署也是单点了，这个时候你可以考虑在网关前挂一层NG或者F5，如果随着业务发展网关管理的服务越来越多，也可以将网关按照业务域进行整体的拆分。

到这里你一定了解到了为什么需要网关，写到这里我突然想到某个伟人说的一句话，没有什么是加一个中间层解决不了的，如果有，就加两个……，BFF也好、网关也好都是我们的中间层。