微服务网关实战01-网关介绍

微服务已经普及好多年，现在国内的公司基本都会采用微服务架构来搭建最新的系统或者改造已经现成的系统。这里面，有个很重要的概念，就是网关，最近一段时间针对他，我们结合实战来剖析该如何应用在系统上。

网关，又称网间连接器、协议转换器，一个网络连接到另一个网络的“关口”。

听起来是不是很拗口，简单理解一下：你有一块地，你用围墙围起来，然后在里面建造3个猪窝出售猪仔（没错，跟某场养猪一样），一个养白猪，一个养黑猪，一个养黄猪，接着你在围墙打一个门，里面所有的猪仔的进出只能通过这个门进出，这个门就叫做网关，里面的猪窝就是各个原子服务，专门提供不同的猪仔。

其中，原子服务为了安全，一般不对外开放，好比你猪仔吃什么，喝什么，别人不用管，只需要知道有猪仔就行，所有买卖猪仔的行为，只能通过这个门。如图一所示

 

编辑搜图

图一：买猪仔的图

这里，我们可以看出，网关有几个作用

1、重定向：要什么颜色的猪仔，告诉我，我给你就行

2、鉴权：哪些人可以买，我说了算

3、日志：今天谁来买，买了多少猪仔，买什么颜色的猪仔，一清二楚

4、限流：每次只能限定多少人来买，超过的话，就等等吧，毕竟太忙猪仔妈妈生产不过来。

目前，普通的企业级开发用基本就会用到这些，高并发的情况很多时候并不常见，如果出现，此时做法就是：增加猪窝的数量，增加大门的数量，加上Nginx，一般都是足够的。

接下来，我们来聊聊网关中的聚合服务。

现在网上的网关很少介绍到这方面，微服务在企业级开发落地中，有个很比较恶心的问题，因为企业级并发量不大，但是业务复杂，把各个服务进行切分后，发现经常合起来展示数据。

有几种做法参考一下

1、前端多次请求：

做法：前端访问网关，然后根据需要的数据进行多次组合，多次数据转换

问题：当前端与网关并不是在一个网段，此时会增加请求量，从而增加服务器的压力，同时会导致数据难以维护，运维层面会增加，不建议这么做。

2、搭建聚合原子服务：

做法：如图二，搭建聚合服务，请求通过网关后，直接定位到聚合服务上，由聚合服务来请求后端的服务

问题：解决数据维护的问题，但是却多了一个网络请求，就是从网关-->聚合服务-->原子服务，俗话说：做多错多。要想个法子来解决

 

编辑搜图

图二聚合服务

3、聚合网关服务：

做法：考虑到现实很多公司并没有那么大的并发量，没有那么多的资源等等，把聚合服务移动到网关上面来

问题：解决了前端多个请求问题，解决多了一个网络请求的问题，但是这样做会把网关变得很重，但是针对很多小公司，却很实用。

以上三种做法，我其实最喜欢第二种，但是架构设计过程中，因地制宜才是最重要，根据业务量不断发展，不断优化，不断更新架构设计，目前我们使用的是第二种，因为量能关系。

但是在这系列文章中，我们将会介绍第二种方式的做法，采用的技术框架版本如下如下，应该都是最新版的

springboot：2.2.5.RELEASE

springcloud：Hoxton.SR1

网关：zuul

考虑到现在很多公司用zuul的比较多，就用这个来做，spring gateway目前用于生产的比较少，不坑大家了，基本上体量没那么大的，正常是够用的。

从第二章开始我们将会一步一步搭建这个网关服务。