Mesos:服务发现与负载均衡

Mesos: Service Discovery & Load Balancing

这一章主要探讨是Mesos关于服务发现与应用的负载均衡的解决方案，主要侧重对服务发现与负载均衡进行讲解，需要明白的一点，Mesos作为 两层架构，Marathon作为Mesos的systemd服务，服务发现功能只需要向marathon提供即可，marathon启动的k8s、 Cloud Foundry都用自身的服务发现功能。

1、Service Discovery with Marathon-Bridge and HAProxy

服务发现的功能实现是为Dcos系统中的服务提供便捷的网络通信，它的侧重点在于对服务进行注册，更新，查询等功能，服务发现的实现方法较多， 主要有DNS、集中式服务路由、应用内部实现服务注册/服务发现等方式，Dcos服务发现功能采用的是Mesos-DNS策略，有关Mesos-DNS的 具体介绍详见上一篇文章。
通过Mesos-DNS的服务发现策略，可以通过辅助脚本利用Marathon REST API定时(通过linux crond服务)产生HAProxy 配置文件，通过diff 生成的hapxoy配置文件与已有的haproxy，来判断是否进行reload haproxy操作。

Mesos-slave默认想master提供的端口资源的范围是31000-32000，当marathon启动一个task 实例时，所在的mesos-slave会随意给其绑定一个或多个在其范围内的端口。需要注意的是应用绑定的实际端口(即mesos-slave分配给它的 端口)和应用在配置时所指定的形式端口(这是以后直接访问的应用端口)之间的区别，形式端口(即应用端口)是应用运行在marathon的一种命名空间， 不是直接绑定的，也就是说其他服务也可以绑定这样一个端口，只是服务不同而已，它间接的被负载均衡器所使用。

服务发现功能，允许marathon上的应用可以通过配置的端口与其他marathon应用进行通信，这样做的好处就是，无需知道实际分配的端口是 多少，例如: python的wsgi服务(配置时你指定的是80)需要跟mysql(配置时你指定的327)进行通信，这样你可以直接与localhost:327进 行通信即可。

HAProxy会把请求路由到具体的服务节点上，如果此服务路径不可达，它将继续将路由到下一个服务节点。需要注意的是，目前服务发现功能只支持marathon上的应用。

使用 HAProxy

Marathon附带一个简单的被叫做 haproxy-marathon-bridge 的shell脚本以及更高级的Python脚本 servicerouter.py(这个脚本在marathon/bin下面)。两个脚本都可以将Marathon的REST API列表中正在运行的任务推送到HAproxy的设置文件中，HAproxy是一个轻量级的TCP/HTTP的代理。haproxy- marathon-bridge提供了一个最小设置功能。 而servicerouter.py支持如SSL卸载，sticky连接和虚拟主机的负载均衡的更高级的功能。

负载均衡实现原理就是上述提及的，通过辅助脚本(这里是使用haproxy-marathon-bridge)利用Marathon REST API定时(通过linux crond服务)产生HAProxy 配置文件，通过diff 生成的hapxoy配置文件与已有的haproxy，来判断是否进行reload haproxy操作。

下图描述了在一个