当前位置:首页 >  IDC >  服务器 >  正文

环信大学 | 构建一套适合微服务的高可用架构

 2021-03-02 16:02  来源: 互联网   我来投稿 撤稿纠错

  域名预订/竞价,好“米”不错过

随着近几年微服务与云计算的飞速发展,机器由物理机逐步变为了虚拟机,应用服务由庞大的单体应用逐渐变为了若干个微服务联合组成的应用集群,更新迭代的速度成倍上涨,传统的部署模式已无法满足开发日常更新需求,需要一套适合微服务的管理架构。

技术栈及文档

资源调度框架 MESOS

应用编排平台Marathon

nginx 动态修改 upstream dyups

nginx 动态修改 upstream upsync

使用Mesos 进行机器资源管理

首先,是机器资源的管理。在微服务的架构中,原有的单体服务被拆分成了一个个独立单元的应用程序,这些服务体量较小,可以独立运行在配置较小的机器上。为了故障隔离,我们会尽可能的把这些服务部署在不同的虚拟机上,这样机器的数量会成倍增加。对于运维来说,每个新服务部署时,需要先查看现有机器的剩余资源是否满足新服务的需求,有时可能因为评估不准确造成来回扩容、迁移,或者资源浪费。

开始时,我们的架构可能时这样的

为了解决上面的问题,可以使用 MESOS ( 布式资源管理框架),它可以 让我们像用一台电脑(一个资源池)一样使用整个数据中心。

mesos 部署时分为 master 和 agent 两个角色,当然,你可以在同一台机器启动它们。

安装Mesos 前需要安装zookeeper,mesos 使用zk 实现高可用和选举,包括一个 master leader 和 几个备份 master 避免宕机。

Mesos master 负责管理各个Framework和Slave,并将Slave上的资源非配给各个Framework。

Mesos agent 负责管理本节点上的各个Mesos Task,为各个Executor分配资源 (低版本为 mesos-slave)。

$cat>/tmp/bintray-mesos-el.repo<

#bintray-mesos-el-packagesbymesosfromBintray

[bintray-mesos-el]

name=bintray-mesos-el

baseurl=https://dl.bintray.com/apache/mesos/el7/x86_64

gpgcheck=0

repo_gpgcheck=0

enabled=1

EOF

$sudomv/tmp/bintray-mesos-el.repo/etc/yum.repos.d/bintray-mesos-el.repo

$sudoyumupdate

$sudoyuminstallmesos

$tree/etc/mesos-master

/etc/mesos-master/

|--hostname

|--ip

|--log_dir

|--quorum#quorum>(numberofmasters)/2

`--work_dir

$tree/etc/mesos-agent

/etc/mesos-agent/

|--containerizers#容器类型,默认mesos,可以添加docker,如:mesos,docker

|--hostname

|--ip

|--log_dir

|--master#master地址,格式为host:port或

zk://host1:port1,host2:port2,.../path或file:///path/to/file

|--resources#设置总资源大小,可以设置小些来预留更多机器资源

`--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界面,可以直接访问 mesos master 的5050 端口,查看集群资源使用情况。总体使用情况 及 Agent 节点使用情况

完成以上后,我们的架构变成了这样

使用Marathon 进行微服务管理

Marathon 是建立在 Mesos 上的私有 PaaS平台。它能自动处理硬件或者软件故障,并确保每个应用程序都"永远在线"。我们使用 Marathon 管理微服务有以下优势1. 支持容器和非容器,不受限于服务启动类型,操作系统版本等。2. 漂亮而强大的用户界面,可以在UI 上进行快捷方便的应用程序配置3. 支持约束条件,例如允许一个mesos agent 节点只运行一个应用程序。4. 支持健康检查。可以配置 http、https、tcp、command 类型的监控检查。5. 完整的REST API,易于集成和编写脚本。这个对于后期集成来说至关重要。

#Addtherepository

$sudorpm-Uvhhttp://repos.mesosphere.com/el/7/noarch/RPMS/mesosphere-el-repo-7-2.noarch.rpm

#Installpackages

$sudoyum-yinstallmesosmarathon

#marathonandmesoszkpath

$cat/etc/default/marathon

MARATHON_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,192.168.100.234:2181/marathon"

systemctlstartmarathon

启动后,直接访问 marathon 的 8080 端口,就能看到一个漂亮强大的 UI 界面。

我们以 springboot 应用为例,在 marathon 上创建一个应用程序

当我们更新应用程序时, marathon 会新建相同实例数量的应用程序,待 health check通过之后替换老节点,所以不需要担心新的服务没有启动期间老的服务停掉造成线上事故。到这里为止,我们已经可以在marathon 上方便快捷的进行日常应用的创建、升级、扩容、缩容。当服务健康检查失败或者机器宕机后,marathon 会自动在其它节点上启动挂掉的应用程序,大大提升了高可用性。

使用 nginx upsync/dyups 模块进行平滑变更

当我们的微服务可以随机分配在不同机器上时,便产生了一个新的令人头疼的问题。nginx 并不知道后端节点的变更, 也不可能每次都去手动修改 upstream 节点, reloadnginx,这样成本就太高了。我们的解决思路是和微服务的注册中心打通,当服务注册、注销时,都会对注册中心进行更新,利用 nginx upsync/dyups 模块 可以动态修改 upstream 节点的能力进行同步,做到平滑变更。如果使用的注册中心为 consul,建议使用 upsync 模块,这样无需开发,只需要简单的nginx 配置,就可以实现我们想要的效果, 支持 consul kv, consul_services,consul_health, 同时 upsync 也支持 etcd。建议使用 consul_health 接口。upsync 模块不是nginx 内置模块,使用时需要重新编译添加此模块。

wget'http://nginx.org/download/nginx-1.8.0.tar.gz'

tar-xzvfnginx-1.8.0.tar.gz

cdnginx-1.8.0/

./configure--add-module=/path/to/nginx-upsync-module

make

makeinstall

配置文件示例

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;

include/usr/local/nginx/conf/servers/servers_test.conf;

}

upstreambar{

server127.0.0.1:8090weight=1fail_timeout=10max_fails=3;

}

server{

listen8080;

location=/proxy_test{

proxy_passhttp://test;

}

location=/bar{

proxy_passhttp://bar;

}

location=/upstream_show{

upstream_show;

}

}

}

当upsync无法满足我们的需求或者注册中心不是 consul、etcd 时,我们可以考虑使用nginx dyups 模块。dyups 仅对外提供 upstream 的增删查改接口,和注册中心对比、修改的工作需要我们通过脚本的方式完成。虽然这种方式麻烦一些,但是可定制化程度高,支持 http, C,lua API,基本上可以满足大部分的场景需求。

dyups 模块也需要nginx 编译时添加

$gitclonegit://github.com/yzprofile/ngx_http_dyups_module.git

#tocompileasastaticmodule

$./configure--add-module=./ngx_http_dyups_module

#tocompileasadynamicmodule

$./configure--add-dynamic-module=./ngx_http_dyups_module

示例配置

http{

includeconf/upstream.conf;

server{

listen8080;

location/{

#Theupstreamheremustbeanginxvariable

proxy_passhttp://$dyups_host;

}

}

server{

listen8088;

location/{

return200"8088";

}

}

server{

listen8089;

location/{

return200"8089";

}

}

server{

listen8081;

location/{

dyups_interface;

}

}

}

特别注意,使用dyups 时, proxy_pass 时的 upstream 必须是 nginx 变量,否则不生效,切记。

整体回顾

经过以上调整,我们得到了以下优化

1.服务器资源自动分配,合理利用

2.提升微服务的高可用性

3.减低OPS人工成本,更加便于管理和维护

申请创业报道,分享创业好点子。点击此处,共同探讨创业新机遇!

相关文章

  • 强强联合!百望云入驻微软实验室,揭开数智发展新篇章!

    OpenAI是什么,随着ChatGPT的爆火,相信大家都并不陌生了。而微软也第一时间推出了AzureOpenAI加速计划,希望凭借OpenAI的卓越能力,为企业赋能,帮助越来越多的企业将AI大模型的基础能力,与企业场景相结合,开拓新的商业范式,引领行业变革。近日,以“智领新变共创未来”为主题的“微软

    标签:
    云服务
  • 新成果、新服务、新生态,HPE混合云领导者地位再提升!

    HPE扩大混合云和私有云产品的覆盖范围、灵活选项和创新功能,领导者地位再提升!HPEDiscover科技盛会上,HPE宣布了HPEGreenLake边缘到云平台、混合云服务、私有云产品组合的创新成果,以及合作伙伴生态系统的最新进展:·HPE完成对OpsRamp公司的收购;相关解决方案现已作为HPEG

    标签:
    云服务
  • 权威发布!白山云连续入选IDC边缘云报告

    近日,国际权威研究机构IDC发布《中国边缘云市场跟踪研究,2022H2》报告。作为创新的全球边缘云服务提供商,白山云得到IDC的持续关注与认可,凭借在边缘云领域的技术突破、产品迭代以及场景实践,再度入选报告,与行业伙伴一同撑起边缘云市场的巨大价值空间。IDC指出,在服务商与客户需求的共同推动下,边缘

    标签:
    云服务
  • 影响云服务器性能的主要因素有哪些?

    性能是企业和云服务提供商比较关心的问题。那么为什么性能很重要,在使用美国云服务器时影响性能的因素有哪些?让我们通过下面的文章一探究竟。

    标签:
    云服务器
  • 云服务器与物理机有哪些区别

    企业在选择方面都是需要考虑很多因素,物理机就是独立的一台服务器,可以理解成物理机为一个大房子,这个房子的归属权就在你手里,而云服务器是大房子里的一个房间。

    标签:
    云服务器

热门排行

信息推荐