Load Balance/API 网关相关文章
http://www.servicemesher.com/blog/nginx-ingress-vs-kong-vs-traefik-vs-haproxy-vs-voyager-vs-contour-vs-ambassador/
Load Balance/API 网关相关文章
微服务架构中, 网关是很重要的一个环节, 总体感觉实施难度较大. 原因: 网关如果放在应用层上, 应用层就很重(Spring Cloud); 如果放在基础架构层上, 对于运维难度就大了不少.
网关方案和传统的LVS/Nginx主要差异:
1. 自动摘除不可用的服务,LVS和网关都有该功能.
2. 新增服务节点后, LVS需要手工修改配置, 网关方案会自动更新.
3. 鉴权限流等功能: API 网关具备, LVS不具备.
=============================
基础知识
=============================
谈谈基于 OpenResty 的接口网关设计, 了解 API 网关的功能以及架构
https://www.zybuluo.com/yishuailuo/note/844059
使用consul和又拍云slardar搭建API网关, 网关的分类(应用层网关和Infrastructure层网关)
https://afoo.me/posts/2017-01-29-build-api-gateway-with-consul-slardar.html
OpenResty动态负载均衡
http://moguhu.com/article/detail?articleId=91
LVS+DNS
https://blog.csdn.net/kumu_linux/article/details/8739089
OpenResty/Nginx 提供负载均衡特性, 当Nginx启动后, upstream 中的上游服务器就固定死了, 当上游服务器不可用时, Nginx会自动摘除, 但如果新增上游服务器后, Nginx并不能动态生效, 传统的做法是, 新增上游服务器后, 修改配置文件并让Nginx去reload配置. 修改配置文件可以由 consul-template 自动完成.
Nginx Reload 的问题:
第一是如果你频繁的 Reload 会有性能损耗
第二个是长时间处于 Shutting down的状态，如果连接里头有长连接，旧的进程会一直处于一个中间进程，这个时间是不定的，就是说你不知道到底什么时候Reload真正完成；
第三是进程内缓存失效，我们会把数据库的一些信息，一些代码全部缓存进本地，这样缓存就全部失效了。
动态修改upstreams, 能做到不需要reload nginx, 有两个实现:
1. 微博开源的 nginx-upsync-module
利用OpenResty搭建动态API网关 https://juejin.im/entry/5a3a360c5188252b145b3291
2. 又拍云开源的 slardar
使用consul和又拍云slardar搭建API网关 https://afoo.me/posts/2017-01-29-build-api-gateway-with-consul-slardar.html
又拍云叶靖：基于 ngx_lua 的动态服务路由方案 https://zhuanlan.zhihu.com/p/33685282
=============================
方案1(推荐)
=============================
应用层方案: 最有名的当然是Netflix的zuul
摘自: <<使用consul和又拍云slardar搭建API网关 https://afoo.me/posts/2017-01-29-build-api-gateway-with-consul-slardar.html >>
应用层网关: 这不意味着这种方案就最适合你， 比如Netfilx是因为使用AWS，对基础设施把控有限， 所以才不得不在应用层做了zuul这样的方案，如果通盘考虑， 这种方案不是最合适或者说最有效的方案。
但如果自己的团队对整体技术设施把控有限，且团队结构不完善，应用层方案也可能是最适合你的“快糙猛”最佳方案。
=============================
方案2(推荐)
=============================
服务发现模块: Consul
服务注册模块:服务程序通过Kong API注册
配置更新模块:Kong
负载均衡: Kong
缺点是:
Kong 需要依赖Postgresql或Cassandra, 架构就复杂多了.
优点是: 和其他方案相比, Kong基本上算一个开箱即用的方案.
云框架写的文档
https://github.com/cloudframeworks-apigateway/user-guide-apigateway
https://www.jianshu.com/p/5400bf1aceda
Kong整合Consul - Kong 最佳实践, 该文章有 整合 spring cloud 的说明
https://www.jianshu.com/p/2fe45645e277
apigateway-kong(五)集群搭建部署
www.cnblogs.com/zhoujie/p/kong6.html
http://www.cnblogs.com/zhoujie/p/kong1.html
Kong 集群介绍
http://blog.100dos.com/2016/08/01/kong-cluster-introduction/
HTTP API 网关选择之一 Kong 介绍
https://juejin.im/entry/58b2e2858d6d810058665aa3
=============================
方案3 (推荐)
=============================
服务发现模块: Consul
服务注册模块:服务程序自或consul配置方式注册,consul 负责注销
配置更新模块:微博 nginx-upsync-module
负载均衡: OpenResty或Nginx
=============================
方案4
=============================
服务发现模块: Consul
服务注册模块:服务程序自或consul配置方式注册,consul 负责注销
配置更新模块:又拍云开源的 slardar
负载均衡: OpenResty或Nginx
缺点是:
和微博 nginx-upsync-module 相比, 又拍云开源的 slardar, 可靠性如何? 是否有大规模使用?
=============================
方案5:
=============================
服务发现模块:consul
服务注册模块:registrator
配置更新模块:consul-template
负载均衡模块:nginx
对于每个biz node上启动的容器，位于每个node上的Registrator实例会监听到该节点上容器的创建和停止的event，并将容器的信息以consul service的形式写入consul或从consul删除。
对于内部服务来说, 位于每个nginx node上的consul-template实例会watch consul集群，监听到consul service的相关event，并将需要expose到external的service信息获取，按照事先定义好的nginx conf template重新生成nginx.conf并reload本节点的nginx，使得nginx的新配置生效。
对于内部服务来说（不通过nginx暴露到外部)，在被registrator写入consul的同时，也完成了在consul DNS的注册，其他服务可以通过特定域名的方式获取该内部服务的IP列表（A地址)和其他信息，比如端口(SRV)，并进而实现与这些内部服务的通信。
https://tonybai.com/2018/09/10/setup-service-discovery-and-load-balance-based-on-consul/
https://www.jianshu.com/p/9976e874c099
缺点:
(1) 引入的容器, 对于运维的技术要求比较高.
(2) 整体架构较为复杂.
=============================
方案6 :
=============================
服务发现模块:consul
服务注册模块:服务程序自或consul配置方式注册,consul 负责注销
负载均衡+配置更新模块:fabio(类似 nginx)
http://www.cnblogs.com/xishuai/p/services-registery-and-discovery-by-consul.html
https://www.cnblogs.com/xishuai/p/ubuntu-docker-consul-fabio-aspnet-core.html
https://my.oschina.net/xiaominmin/blog/1599763
缺点: fabio 相比 Nginx 小众
=============================
方案7 :
=============================
服务发现模块:consul
服务注册模块:服务程序自或consul配置方式注册,consul 负责注销
负载均衡+配置更新模块:Traefik
https://www.cnblogs.com/rancher-maomao/p/8633745.html
https://mritd.me/2018/05/24/kubernetes-traefik-service-exposure/
而 Fabio 的日志目前好像还是不支持合理的输出，好像只能 stdout；目前来看不论是组件复杂度还是维护成本都不怎么友好
缺点: 看起来 Traefik 要比 fabio 流行, 但相比 Nginx 还是很小众
