三、自主開發一套,通過對各服務子系統的接口分析,發現直接使用nginx的反向代理和負載均衡來實現也不是那麼複雜,因此這個方案這麼誕生了php
3、使用nginx做爲api網關的調研
對於nginx的反向代理和負載均衡的資料網上已經有不少,這裏就不廢話了,直接看調研過程
這裏假設nginx的配置文件目錄爲/etc/nginx/
一、配置的考慮
考慮到nginx的配置文件大小有要求,因此在這裏不把配置直接寫入到nginx.conf,而是在nginx.conf裏面去include其餘目錄,好比
在/etc/nginx/目錄下新建api_servers.d目錄和api_rules.d目錄,分別用來存放api服務器的相關配置和api服務代理規則的相關配置,在http配置項中增長一行配置include /etc/nginx/api_servers.d/*.conf;
在提供網關服務的server中增長一行include /etc/nginx/api_rules.d/*.conf;
二、配置負載均衡和反向代理
在/etc/nginx/api_servers.d/目錄下新增一個文件api_test_servers.conf,內容以下
upstream api_testa_server {
server 192.168.1.101:80 weight=1 max_fails=3 fail_timeout=20;
server 192.168.1.102:80 weight=1 max_fails=3 fail_timeout=20;
server 192.168.1.103:80 weight=2 max_fails=3 fail_timeout=20;
}
upstream api_testb_server {
server 192.168.1.104:80 weight=1 max_fails=3 fail_timeout=20;
server 192.168.1.105:80 weight=1 max_fails=3 fail_timeout=20;
}
在/etc/nginx/api_rules.d/目錄下新增一個文件api_test_rule.conf(這裏以簡單的url匹配來舉例)
location ~(^\/ws\/apitesta)(.*) {
proxy_set_header Host $host:$server_port;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_buffering off;#緩存在其餘文章中會討論,在這裏暫只討論基本的功能,因此直接使用off
proxy_pass http://api_testa_server;
}
location ~(^\/ws\/apitestb)(.*) {
proxy_set_header Host $host:$server_port;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_buffering off;
proxy_pass http://api_testb_server;
}
nginx服務reload使配置生效
三、測試過程
nginx服務器的地址是192.168.1.100,服務的端口爲80端口,測試過程以下
1)、 執行wget http://192.168.1.100/ws/apitesta/phpinfo和wget http://192.168.1.100/ws/apitestb/phpinfo
分別重複執行此命令20次,查看192.168.1.101-105這5臺web服務器的web訪問日誌,發現101-103的/ws/apitesta/phpinfo訪問量分別爲五、五、10,104和105的web訪問日誌裏面對/ws/apitestb/phpinfo的訪問量都是10次
2)、 關閉192.168.1.102和192.168.1.104,重複上述測試過程,發現兩個url都可正常訪問
4、網關的搭建
從上述的調研結果來看,使用nginx的反向代理和負載均衡可實現對api服務器的負載均衡及高可用,那麼咱們須要解決的就是自注冊的問題和網關自己的擴展性。
對於自注冊和自注銷這個問題,對於咱們的業務系統來講,業務的上線與下線自己不是一個特別頻繁的事情,因此直接在api網關上搭建一個簡單的web服務便可,咱們稱之爲api網關係統,api網關係統基本功能以下:
一、註冊或註銷時須要從新生成nginx的反向代理和負載均衡配置文件(也就是上述的api_rules.d和api_servers.d目錄下的文件),而且網關服務器須要對nginx執行reload操做
二、須要對api服務的相關信息作持久化存儲
除了上述兩個基本功能還須要網關自己支持橫向擴展,這個仔細分析一下無非就是須要如下兩個問題
一、在任一個網關服務器上註冊或註銷一個api服務或一個api服務的一個服務器時都須要通知到全部的網關服務器,全部的網關服務器都須要從新生成配置而且reload各自的nginx服務,顯然的咱們想到了消息隊列裏面的topic消息(消息隊列的高可用等特性在這裏不進行特別延伸),全部的api網關服務器共用同一個消息隊列便可知足此要求
二、全部的網關服務器須要共同同一個網關配置信息,這個無非是共用一個數據庫(數據庫的高可用等特性在這裏不進行特別延伸)
api服務器自注冊至生效主要流程以下:
nginx
全部的網關服務器共用一個消息隊列,共用同一個存儲數據庫,各網關服務器上的網關信號處理進程向消息隊列訂閱相關的消息,當api服務器向網關服務器集羣中的某一臺服務器進行註冊時,全部的網關服務器都會收到reload消息,會從同一個數據庫中讀取同一個配置,而後從新生成nginx反向代理和負載均衡的相關配置文件,接着reload各自的nginx服務,固然這裏面的網關信號處理進程啓動時也會從新生成相關的配置。
web
至此一個基於nginx的API網關完成了,固然此文只介紹了一個實用性的主體思路,一些細節層面在這裏暫不作過多描述,由於nginx的資料在網上其實已經不少了。數據庫