微服务的接入层设计与动静资源隔离

柔光的暖阳◎ 2022-05-17 08:10 150阅读 0赞

本文转载自网易云架构师刘超的个人公众号。

*  一、数据中心之外：DNS，HttpDNS，GSLB
 *  二、数据中心之外：CDN
 *  三、数据中心边界与核心：边界路由，核心交换，等价路由
 *  四、数据中心可用区中：负载均衡SLB，LVS，Haproxy
 *  五、数据中心可用区中：接入层nginx，接入层缓存
    
     *  接入层作用一：API的聚合。
     *  接入层作用二：服务发现与动态负载均衡
     *  接入层作用三：动静资源隔离，静态页面缓存，页面静态化
     *  接入层作用四：动态资源缓存
     *  接入层作用五：资源隔离
     *  接入层作用六：统一鉴权，认证，过滤
     *  接入层作用七：限流
     *  接入层作用八：灰度发布与AB测试

这个系列是微服务高并发设计，所以我们先从最外层的接入层入手，看都有什么样的策略保证高并发。

接入层的架构画一个简图来讲包括下面的部分  
![这里写图片描述][20180808202813639]  
接下来我们依次解析各个部分以及可以做的优化。

# 一、数据中心之外：DNS，HttpDNS，GSLB #

当我们要访问一个网站的服务的时候，首先访问的肯定是一个域名，然后由DNS，将域名解析为IP地址。

我们首先先通过DNS访问数据中心中的对象存储上的静态资源为例子，看一看整个过程。

我们建议将例如文件，图片，视频，音频等静态资源放在对象存储中，直接通过CDN下发，而非放在服务器上，和动态资源绑定在一起。

假设全国有多个数据中心，托管在多个运营商，每个数据中心三个可用区Available Zone，对象存储通过跨可用区部署，实现高可用性，在每个数据中心中，都至少部署两个内部负载均衡器，内部负载均衡器后面对接多个对象存储的前置服务proxy-server。

![这里写图片描述][20180808203158346]

(1) 当一个客户端要访问object.yourcompany.com的时候，需要将域名转换为IP地址进行访问，所以他要请求本地的resolver帮忙  
(2) 本地的resolver看本地的缓存是否有这个记录呢？如果有则直接使用  
(3) 如果本地无缓存，则需要请求本地的Name Server  
(4) 本地的Name Server一般部署在客户的数据中心或者客户所在的运营商的网络中，本地Name Server看本地是否有缓存，如果有则返回  
(5) 如果本地没有，本地Name Server需要从Root Name Server开始查起，Root Name Server会将.com Name Server的地址返回给本地Name Server  
(6) 本地的Name Server接着访问.com的Name Server，他会将你们公司的yourcompany.com的Name Server给本地Name Server  
(7) 本地的Name Server接着访问yourcompany.com的Name Server，按说这一步就应该返回真实要访问的IP地址。

对于不需要做全局负载均衡的简单应用来讲，yourcompany.com的Name Server可以直接将object.yourcompany.com这个域名解析为一个或者多个IP地址，然后客户端可以通过多个IP地址，进行简单的轮询，实现简单的负载均衡即可。

但是对于复杂的应用，尤其是跨地域跨运营商的大型应用，则需要更加复杂的全局负载均衡机制，因而需要专门的设备或者服务器来做这件事情，这就是GSLB，全局负载均衡器。

从yourcompany.com的Name Server中，一般是通过配置CNAME的方式，给object.yourcompany.com起一个别名，例如object.vip.yourcomany.com，然后告诉本地Name Server，让他去请求GSLB去解析这个域名，则GSLB就可以在解析这个域名的过程中，通过自己的策略实现负载均衡。

图中画了两层的GSLB，是因为分运营商和分地域，我们希望将属于不同运营商的客户，访问相同运营商机房中的资源，这样不用跨运营商访问，有利于提高吞吐量，减少时延。

(8) 第一层GSLB通过查看请求他的本地Name Server所在的运营商，就知道了用户所在的运营商，假设是移动，然后通过CNAME的方式，通过另一个别名object.yd.yourcompany.com，告诉本地Name Server去请求第二层的GSLB

(9) 第二层的GSLB通过查看请求他的本地Name Server所在的地址，就知道了用户所在的地理位置，然后将距离用户位置比较近的Region的里面的内部负载均衡SLB的地址共六个返回给本地Name Server

(10) 本地Name Server将结果返回给resolver  
(11) resolver将结果缓存后，返回给客户端  
(12) 客户端开始访问属于相同运营商的距离较近的Region1中的对象存储，当然客户端得到了六个IP地址，他可以通过负载均衡的方式，随机或者轮询选择一个可用区进行访问，对象存储一般会有三份备份，从而可以实现对存储读写的负载均衡。

从上面的过程可以看出，基于DNS域名的GSLB实现全局的负载均衡，可是现在跨运营商和跨地域的流量调度，但是由于不同运营商的DNS缓存策略不同，会造成GSLB的工作实效。

有的用户的DNS会将域名解析的请求转发给其他的运营商的DNS进行解析，导致到GSLB的时候，错误的判断了用户所在的运营商。

有的运营商的DNS出口会做NAT，导致GSLB判断错误用户所在的运营商。

所以不同于传统的DNS，有另一种机制称为httpDNS，可以在用户的手机App里面嵌入SDK，通过http的方式访问一个httpDNS服务器，由于手机App可以精确的获得自己的IP地址，可以将IP地址传给httpDNS服务器，httpDNS服务器完全由应用的服务商提供，可以实现完全自主的全网流量调度。

# 二、数据中心之外：CDN #

对于静态资源来讲，其实在真实的访问机房内的对象存储之前，在最最接近用户的地方，可以先通过CDN进行缓存，这也是高并发应用的一个总体的思路，能接近客户，尽量接近客户。

CDN厂商的覆盖范围往往更广，在每个运营商，每个地区都有自己的POP点，所以总有更加靠近用户的相同运营商和相近地点的CDN节点就近获取静态数据，避免了跨运营商和跨地域的访问。

在使用了CDN之后，用户访问资源的时候，和上面的过程类似，但是不同的是，DNS解析的时候，会将域名的解析权交给CDN厂商的DNS服务器，而CDN厂商的DNS服务器可以通过CDN厂商的GSLB，找到最最接近客户的POP点，将数据返回给用户。  
![这里写图片描述][20180808203650117]  
当CDN中没有找到缓存数据的时候，则需要到真正的服务器中去拿，这个称为回源，仅仅非常少数的流量需要回源，大大减少了服务器的压力。

# 三、数据中心边界与核心：边界路由，核心交换，等价路由 #

如果真的需要回源，或者访问的压根就不是静态资源，而是动态资源，则需要进入数据中心了。

刚才第一节中说到，最终GSLB返回了6个IP地址，都是内部负载均衡SLB的IP地址，说明这6个IP地址都是公网可以访问的，那么公网如何知道这些IP地址的呢？

这就要看机房的结构了。  
![这里写图片描述][20180808203738645]  
一个机房一般会有边界路由器，核心交换机，每个AZ有汇聚交换机，6个SLB是在AZ里面的，所以他们的IP地址是通过iBGP协议告知边界路由器的。

当用户从六个IP里面选择了一个IP地址进行访问的时候，可以通过公网上面的路由，找到机房的边界路由器，边界路由器知道当时这个路由是从哪个AZ里面给他的，于是就通过核心交换一层，将请求转发给某一个AZ，这个AZ的汇聚交换机会将请求转发给这个SLB。

如果一个AZ出现了问题，是否可以让对某个公网IP的访问给另一个AZ呢？当然是可以的，在核心路由和核心交换之间，可以做ECMP等价路由。当然也可以在边界路由上将外部地址NAT称为内部的一个VIP地址，通过等价路由实现跨AZ的流量分担。

# 四、数据中心可用区中：负载均衡SLB，LVS，Haproxy #

进入一个可用区AZ之后，首先到达的是负载均衡SLB，可以购买商用的SLB，也可以自己搭建，例如通过LVS实现基本的负载均衡功能。

LVS的性能比较好，很多工作通过内核模块ipvs完成。  
![这里写图片描述][20180808204257860]  
LVS可使用keepalived实现双机热备，也可以通过OSPF使用等价路由的方式，在多个LVS之间进行流量分担，往往作为统一的负载均衡入口，承载大的流量。  
![这里写图片描述][20180808204327350]  
有时候需要更加复杂的4层和7层负载均衡，则会在LVS后面加上haproxy集群，也即将LVS导入的流量，分发到一大批haproxy上，这些haproxy可以根据不同的应用或者租户进行隔离，每个租户独享单独的haproxy，但是所有的租户共享LVS集群。

如果有云环境，则haproxy可以部署在虚拟机里面，可以根据流量的情况和租户的请求进行动态的创建和删除。

![这里写图片描述][20180808204354147]

# 五、数据中心可用区中：接入层nginx，接入层缓存 #

在负载均衡之后，是接入网关，或者API网关，往往需要实现很多灵活的转发策略，这里会选择使用nginx+lua或者openresty做这一层。

由于nginx本身也有负载均衡机制，有的时候会将haproxy这一层和nginx这一层合并，LVS后面直接跟nginx集群。

## 接入层作用一：API的聚合。 ##

使用微服务之后，后端的服务会拆分的非常的细，因而前端应用如果要获取整个页面的显示，往往需要从多个服务获取数据，将数据做一定的聚合后，方能够显示出来。  
![这里写图片描述][20180808204426999]  
如果是网页其实还好，如果你用chrome的debug模式下，打开一个复杂的电商主页的时候，你会发现这个页面同时会发出很多的http的请求，最终聚合称为一个页面。

如果是APP的话，其实也没有问题，但是会有大量的工作要在客户端做，这样会非常的耗电，用户体验非常不好，因而最好有一个地方可以将请求聚合，这就是API网关的职责之一。这样对于前端APP来讲，后端接是似乎是一个统一的入口，则后端的服务的拆分和聚合，灰度发布，缓存策略等全部被屏蔽了。  
![这里写图片描述][20180808204450699]

## 接入层作用二：服务发现与动态负载均衡 ##

既然统一的入口变为了接入层，则接入层就有责任自动的发现后端拆分，聚合，扩容，缩容的服务集群，当后端服务有所变化的时候，能够实现健康检查和动态的负载均衡。

对于微服务来讲，服务之间也是需要做服务发现的，常见的框架是dubbo和springcloud，服务的注册中心可以是zookeeper, consul, etcd, eureka等。

我们以consul为例子，既然服务之间的调用已经注册到consul上，则nginx自然也可以通过consul来获取后端服务的状态，实现动态的负载均衡。

nginx可以集成consul-template，可监听consul的事件, 当已注册service列表或key/value 发生变化时, consul-template会修改配置文件同时可执行一段shell, 如 nginx reload

consul-template \\ -template “/tmp/nginx.hcl:/var/nginx/nginx.conf:service nginx reload” \\

consul-template模式配置相对复杂，需要reload nginx。

另一种集成consul的方式是nginx-upsync-module，可以同步consul的服务列表或key/value存储，需要重新编译nginx，不需要reload nginx。

upstream test \{  
server 127.0.0.1:11111;  
\# 所有的后端服务列表会从consul拉取, 并删除上面的占位server  
upsync 127.0.0.1:8500/v1/catelog/service/test upsync\_timeout=6m upsync\_interval=500ms upsync\_type=consul strong\_dependency=off;  
\# 备份的地址, 保证nginx不强依赖consul  
upsync\_dump\_path /usr/local/nginx/conf/servers/servers\_test.conf;  
\}

还有一种方式是openresty+lua，相对nginx-upsync-module, 可以加入更多自己的逻辑, init\_\*\_by\_lua 阶段通过http api 获取服务列表载入Nginx 内存, 并设置timer轮训更新列表，balancer\_by\_lua 阶段 读取内存的列表, 设置后端服务器。  
Lua实现 同样可以不reload nginx, 相比nginx-upsync-module 来说更加可扩展。

## 接入层作用三：动静资源隔离，静态页面缓存，页面静态化 ##

为什么静态资源需要隔离呢，静态资源往往变化较少，但是却往往比较大，如果每次都加载，则影响性能，浪费带宽。其实静态资源可以预加载，并且可以进行缓存，甚至可以推送到CDN。

所以应该在接入层nginx中配置动态资源和静态资源的分离，将静态资源的url导入到nginx的本地缓存或者单独的缓存层如varnish或者squid，将动态的资源访问后端的应用或者动态资源的缓存。

在nginx中，可以通过配置expires，cache-control，if-modified-since来控制浏览器端的缓存控制。使得浏览器端在一段时间内，对于静态资源，不会重复请求服务端。这一层称为浏览器端的缓存。

当有的请求的确到达了接入层nginx的时候，也不用总是去应用层获取页面，可以在接入层nginx先拦截一部分热点的请求。在这里可以有两层缓存。一是nginx本身的缓存proxy\_cache，二是缓存层的varnish或者squid。

在使用接入层缓存的时候，需要注意的是缓存key的选择，不应该包含于用户相关的信息，如用户名，地理信息，cookie，deviceid等，这样相当于每个用户单独的一份缓存，使得缓存的命中率比较低。

在分离了静态和动态资源之后，就存在组合的问题，可以通过ajax访问动态资源，在浏览器端进行组合，也可以在接入层进行组合。

如果在接入层聚合，或者varnish进行聚合，则可以让接入层缓存定时轮询后端的应用，当有数据修改的时候，进行动态页面静态化，这样用户访问的数据到接入层就会被拦截，缺点是更新的速度有些慢，对于大促场景下的并发访问高的页面，可以进行如此的处理。

## 接入层作用四：动态资源缓存 ##

在动静分离之后，静态页面可以很好的缓存，而动态的数据还是会向后端请求，而动态页面静态化延时相对比较高，而且页面数目多的时候，静态化的工作量也比较大，因而在接入层还可以通过redis或者memcached，对动态资源进行缓存。  
![这里写图片描述][20180808204604619]

## 接入层作用五：资源隔离 ##

接入层的nginx集群不是一个，而是不同的请求可以有独立的nginx集群。

例如抢券或者秒杀系统，会成为热点中的热点，因而应该有独立的nginx集群。

## 接入层作用六：统一鉴权，认证，过滤 ##

API Gateway的另一个作用是统一的认证和鉴权。

一种是基于session的，当客户端输入用户名密码之后，API Gateway会向后端服务提交认证和鉴权，成功后生成session，session统一放在redis里面，则接下来的访问全部都带着session进行。  
![这里写图片描述][20180808204702879]

另一种方式是通过统一的认证鉴权中心，分配token的方式进行。  
![这里写图片描述][20180808204726352]  
这是一个三角形的结构，当API Gateway接收到登陆请求的时候，去认证中心请求认证和授权，如果成功则返回token，token是一个加密过的字符串，里面包含很多的认证信息，接下来的访问中，API Gateway可以验证这个token是否有效来认证，而真正的服务可以根据token来鉴权。

## 接入层作用七：限流 ##

在大促过程中，常常会遇到真实的流量远远大于系统测试下来的可承载流量，如果这些流量都进来，则整个系统一定垮掉，最后谁也别玩。所以长做的方式是限流。

限流是从上到下贯穿整个应用的，当然接入层作为最外面的屏障，需要做好整个系统的限流。

对于nginx来讲，限流有多种方式，可以进行连接数限制limit\_conn，可以进行访问频率限制limit\_req，可以启用过载保护sysgurad模块。

对请求的目标URL进行限流（例如：某个URL每分钟只允许调用多少次）  
对客户端的访问IP进行限流（例如：某个IP每分钟只允许请求多少次）

对于被限流的用户，可以进行相对友好的返回，不同的页面的策略可以不同。

对于首页和活动页，是读取比较多的，可以返回缓存中的老的页面，或者APP定时刷新。

对于加入购物车，下单，支付等写入请求被限流的，可以返回等待页面，或者返回一个圈圈转啊转，如果过了一段时间还转不出来，就可以返回挤爆了。

对于支付结果返回，如果被限流，需要马上返回错误页面。

## 接入层作用八：灰度发布与AB测试 ##

在接入层，由于可以配置访问路由，以及访问权重，可以实现灰度发布，或者AB测试，同时上线两套系统，通过切入部分流量的方式，测试新上系统的稳定性或者是否更受欢迎。

[20180808202813639]: /images/20220517/61096580c73e4b5c94a64059f9cfeea0.png
[20180808203158346]: /images/20220517/041fe6e40bb54b9c829e160e04f8bf26.png
[20180808203650117]: /images/20220517/14e798ec109d4ccb906b04271cb8bdad.png
[20180808203738645]: /images/20220517/b8873351ead94d628038774c85b043fa.png
[20180808204257860]: /images/20220517/2e5f4ab493774c61adc4d51cb274cf47.png
[20180808204327350]: /images/20220517/a11921ce113b49ab913412900c98b2b4.png
[20180808204354147]: /images/20220517/a4c5490fe95e4804ae277610cda8c574.png
[20180808204426999]: /images/20220517/fdf8c20dc9b5427cb0322fd0088e7d9d.png
[20180808204450699]: /images/20220517/70537472b5834d3183d6e737fb9cdb95.png
[20180808204604619]: /images/20220517/7066b3e445e34ec0bdb88415cf61cab0.png
[20180808204702879]: /images/20220517/35835815c6e6470caf36ddccb4275abc.png
[20180808204726352]: /images/20220517/d860a863342e40f1914ec931cff7c866.png