高性能网关设计实践( 四 ) _网关设计

2、OpenResty 启动时，在请求的 init 阶段 worker 进程会去拉取这些规则，将这些规则编译成一个个可执行的 lua 函数，这一个个函数就对应了一条条的规则。

文章插图

需要注意的是为了避免重复去 MySQL 中拉取数据，某个 worker 从 MySQL 拉取完规则（此步需要加锁，避免所有 worker 都去拉取）或者后端集群等配置信息后要将其保存在 shared dict 中，这样之后所有的 worker 请求只要从 shared dict 中获取这些规则，然后将其映射成对应模块的函数即可，如果配置规则有变动呢，配置后台通过接口通知 OpenResty 重新加载一下即可

文章插图

经过路由规则确定好每个请求对应要打的后端集群后，就需要根据 upstream 来确定最终打到哪个集群的哪台机器上，我们看看如何动态管理集群。
后端集群的动态配置在 Nginx 中配置 upstream 的格式如下
【高性能网关设计实践】

upstream backend {    server backend1.example.com weight=5;    server backend2.example.com;    server 192.0.0.1 backup;}

以上这个示例是按照权重（weight）来划分的， 6 个请求进来， 5个请求打到 backend1.example.com, 1 个请求打到 backend2.example.com,如果这两台机器都不可用，就打到 192.0.0.1 ，这种静态配置的方式 upstream 的方式确实可行，但我们知道机器的扩缩容有时候比较频繁，如果每次机器上下线都要手动去改，并且改完之后还要重新去 reload 无疑是不可行的，出错的概率很大，而且每次配置都要 reload 对性能的损耗也是挺大的，为了解决这个问题， OpenResty 提供了一个 dyups 的模块来解决此问题，它提供了一个 dyups api,可以动态增，删，创建 upsteam ，所以在 init 阶段我们会先去拉取集群信息，构建 upstream ，之后如果集群信息有变动，会通过如下形式调用 dyups api 来更新 upstream

-- 动态配置 upstream 接口站点server {     listen 127.0.0.1:81;      location / {          dyups_interface;     }}-- 增加 upstream:user_backendcurl -d "server 10.53.10.191;" 127.0.0.1:81/upstream/user_backend-- 删除 upstream:user_backendcurl -i -X DELETE 127.0.0.1:81/upstream/user_backend

使用 dyups 就解决了动态配置 upstream 的问题
网关最终架构设计图

文章插图

通过这样的设计，最终实现了网关的配置化，动态化。
总结网关作为承载公司所有流量的入口，对性能有着极高的要求，所以技术选型上还是要慎重，之所以选择 OpenResty ，一是因为它高性能，二是目前也有小米，阿里，腾讯等大公司在用，是久经过市场考验的，本文通过对网关的总结简要介绍了 OpenResty 的相关知识点，相信大家对其主要功能点应该有所了解了。