随着近几年微服务和云计算的快速发展，机器逐渐从物理机变成虚拟机，应用服务也逐渐从一个巨大的单体应用变成多个。由微服务组成的应用集群，更新迭代速度翻倍。传统的部署模式已经不能满足开发的日常更新需求，需要一个适合微服务的管理框架。技术栈和文档资源调度框架MESOS应用编排平台Marathonnginx动态修改上游dyupsnginx动态修改上游upsync使用Mesos进行机器资源管理首先是机器资源的管理。在微服务架构中，将原来单一的服务拆分成单个的单元应用。这些服务体积小，可以在配置较小的机器上独立运行。为了故障隔离，我们会尽可能的把这些服务部署在不同的虚拟机上，这样机器的数量就会成倍增加。对于运维来说，每一个新服务部署的时候，都需要检查现有机器的剩余资源是否满足新服务的要求。有时，由于评估不准确，可能会造成来回扩展、迁移或资源浪费。一开始，我们的架构可能是这样的。为了解决以上问题，我们可以使用MESOS（分布式资源管理框架），它可以让我们像使用电脑一样使用整个数据中心（一个资源池）。mesos在部署的时候分为两个角色：master和agent。当然，您可以在同一台机器上启动它们。在安装Mesos之前，需要先安装zookeeper。Mesos使用zk来实现高可用性和选举，包括一个masterleader和几个backupmaster来避免宕机。Mesosmaster负责管理各个Framework和Slave，并将Slave上的资源分配给各个Framework。Mesosagent负责管理本节点上的各个MesosTask，并为各个Executor分配资源（低版本为mesos-slave）。$cat>/tmp/bintray-mesos-el.repo<(master数量)/2`--work_dir$tree/etc/mesos-agent/etc/mesos-agent/|--containerizers#容器类型，默认mesos，可以添加docker，如：mesos,docker|--hostname|--ip|--log_dir|--master#masteraddress，格式为host:portorzk://host1:port1,host2:port2,.../pathorfile:///path/to/file|--resources#设置资源总大小，可以reserve设置小一些reservemachineresources`--work_dir$cat/etc/mesos/zk#设置mesos在zk中的存放目录zk://192.168.100.9:2181,192.168.100.110:2181,192.168.100.234:2181/mesos$systemctlstartmesos-master$systemctlstartmesos-slave当mesos服务启动时，agent会发送master节点上报机器资源，包括CPU、内存、磁盘等，当我们要发布一个服务时，只需要设置服务的CPU、内存、磁盘参数，mesosmaster会自动帮我们选择一台有足够资源运行的机器，如下图我们把微服务的启动交给Mesos管理，这样我们只需要关注整体的资源。MESOS提供了UI界面，可以直接访问mesosmaster的5050端口查看集群资源的使用情况。整体使用和Agent节点使用完成以上后，我们的架构就变成了这样使用Marathon进行微服务管理Marathon是一个基于Mesos构建的私有PaaS平台。它会自动处理硬件或软件故障并确保每个应用程序“始终在线”。我们使用Marathon来管理微服务有以下优势：1.支持容器和非容器，不限制服务启动类型、操作系统版本等2.美观强大的用户界面，可以在上面进行快速方便的应用配置UI3.支持约束，比如允许一个mesosagent节点只能运行一个应用程序。4.支持健康检查。可以配置http、https、tcp、command类型的监控检查。5.完整的RESTAPI，便于集成和编写脚本。这对后面的集成至关重要。添加存储库$sudorpm-Uvhhttp://repos.mesosphere.com/e...安装包$sudoyum-y安装mesosmarathonmarathon和mesoszk路径$cat/etc/default/marathonMARATHON_MESOS_USER="root"MARATHON_MASTER="zk://192.168.100.9:2181,192.168.100.110:2181,192.168.100.234:2181/mesos"MARATHON_ZK="zk://192.168.200.9:1181,192.168.100.110:2181/mesos"marathon_zk="zk://192.168.200.9:1181,192.168.100.110:214.18"systemctmarath/18startmarathon启动后，直接访问marathon的8080端口，可以看到一个漂亮而强大的UI界面。下面以springboot应用为例，在marathon上创建一个应用。当我们更新应用时，marathon会创建一个新的实例数相同的应用，并在健康检查通过后替换旧节点，所以不用担心新服务不启动旧服务停止导致上线事故。至此，我们已经可以在marathon上方便快捷地创建、升级、扩容、缩容日常应用。当服务健康检查失败或机器宕机时，marathon会自动启动其他节点上挂起的应用，大大提高了高可用性。使用nginxupsync/dyups模块进行平滑更改当我们的微服务可以随机分布在不同的机器上时，新的令人头疼的问题出现了。Nginx不知道后端节点的变化，不可能每次都手动修改上游节点重新加载nginx，这样成本太高了。我们的方案是对接微服务的注册中心。当服务注册或取消时，注册中心会更新。使用nginxupsync/dyups模块，可以同步动态修改upstream节点的能力，实现平滑变化。如果使用的注册中心是consul，推荐使用upsync模块，这样不需要开发，只需要简单的nginx配置就可以达到想要的效果。支持consulkv、consul_services、consul_health，upsync也支持etcd。推荐使用consul_health接口。upsync模块不是nginx的内置模块，使用时需要重新编译添加。wget'http://nginx.org/download/ngi...'tar-xzvfnginx-1.8.0.tar.gzcdnginx-1.8.0/./configure--add-module=/path/to/nginx-upsync-modulemakemakeinstall配置文件示例http{upstreamtest{upsync127.0.0.1:8500/v1/health/service/testupsync_timeout=6mupsync_interval=500msupsync_type=consul_healthstrong_dependency=off;upsync_dump_path/usr/local/nginx/conf/servers/servers_test.conf；包括/usr/local/nginx/conf/servers/servers_test.conf；}上游bar{server127.0.0.1:8090weight=1fail_timeout=10max_fails=3;}服务器{听8080；location=/proxy_test{proxy_passhttp://test;}位置=/bar{proxy_passhttp://bar;}位置=/upstream_show{upstream_show;}}}_upsync无法无法满足的的或者注册中心中心中心不是脚本的方式完成。这种方式虽然有点麻烦，但是可以高度定制化，支持http、C、luaAPI，基本可以满足大部分场景的需求。dyups模块还需要添加$gitclonegit://github.com/yzprofile/ngx_http_dyups_module.git编译为静态模块$./configure--add-module=./ngx_http_dyups_module编译为动态模块$时编译nginx./configure--add-dynamic-module=./ngx_http_dyups_module显示示例配置http{includeconf/upstream.conf;服务器{听8080;location/{#这里的上游必须是一个nginx变量proxy_passhttp://$dyups_host;}}服务器{听8088;local/{Return200"8088";}}server{Listen8089;本地/{Return200"8089";}}服务器{Listen8081;本地/{dyuperface;};使用dyups时，proxy_pass的upstream必须是nginx变量，否则不生效，切记。总体回顾经过以上调整，我们得到了如下优化的服务器资源自动分配，合理利用微服务提高高可用，降低OPS人力成本，管理维护更简单
