mysql主机名可以写成（mysql主机地点 填什么）〔mysql 主机名〕

2018年纪 人云Meetup第一站，连合 vivo在深圳举行 Building Microservice 系列活动 第一期。本次技能 沙龙vivo、复兴 通讯 、华为、数人云共同派出技能 大咖 ，为开辟 者们带来有关微服务、容器化、设置 中心 、服务网格等范畴 的实战与干货分享 。

　　数人云Meetup每月一期，欢迎 各人 来面基、学习。本文为vivo云盘算 架构师袁乐林分享的“vivo云服务容器化实践”现场演讲实录。

　　本日 讲的内容重要 是先容 技能 配景 ，产物 的技能 架构，我们关键技能 的实践 ，前车可鉴 ，以及对下一代云服务架构的假想 。

　　技能 配景

　　vivo这些年的业务增长非常快，用户数已经上亿 ，服务器到了万级，业务域好几百，后端体系 的复杂度在敏捷 攀升 ，不但 是运维方面、架构体系复杂度也非常高，vivo技能 架构也是到了破茧化蝶的时间 。

　　我们做过容器 、假造 机与物理机性能对比测试。上面这张图是当时 做的性能测试架构图。得出了一些测试结论：

　　1.容器化app（4c8g）在性能上略优于非容器化app测试指标2.容器化app（32c64g）性能相较于裸跑同物理机有近4%左右性能斲丧 ，此中 TPS有3.85%斲丧 ，均匀 相应 时间3.95%（1毫秒）的增长 ，对业务哀求 无影响 。3.容器化app在12h的稳固 性测试中表现 正常4.容器化app在cpu相对配额，cpu绑定以及绝对配额场景下 ，业务性能CPU相对配额 CPU绑定 绝对配额。5.容器化app在组部件非常 ，单盘算 节点，控制非常 场景下，容器运行正常。

　　综上所述 ，容器化app性能上靠近 物理机，在多测试场景下，表现 相对稳固 可靠 。同时 ，对盘算 麋集 型app，相对权重配额能实现CPU资源利用 率最大化。

　　vivo容器化云服务框架

　　正是由于 这个性能测试数据的支持 ，就有了vivo容器化云服务框架 ，我们给它取名 Kiver，提供轻量级、高可靠的容器化生产方案。

　　在这个框架之上vivo一共有八个云服务，按照厥后 统计数据来看 ，MySQL加上其他两个服务占到80%的比例，这也非常符合“二八 ”原则 。

　　vivo整个云服务容器化产物 的架构，左边是运维主动 化的工具集 ，比如 日记 、监控等，日记 在业界应用非常广泛，我们用收罗 容器的数据 、容器的监控指标。

　　这里有两个日记 ，上面是中心 件的业务日记 平台 ，全部 业务基于中心 件日记 规范，输出日记 后都会送到这内里 网络 起来，但是这个业务日记 平台功能如今 比力 单薄 ，对新增长 的一些组件，比如 ECTD等不支持。vivo又引入了如今 容器范畴 比力 常见的日记 方案EFK，以后 会规划把两个日记 整合到一起 。

　　vivo在运维方面做了一些工具 ，如 vivo MachineCtl和 KiverCtl，两个工具重要 实现宿主机的主动 化，简单 来说可以把宿主机操纵 体系 主动 化地装起来 ，装完之后变成 Kiver的盘算 节点大概 控制节点。尚有 KiverPerfermance，是我们内嵌的一个小的性能测试插件。

　　再来看右边，是vivo的底子 办法 ，物理机和互换 机，网络装备 和防火墙等，上面是Docker，Docker容器假造 化技能 把物理机上面的相干 资源假造 化用起来。

　　右边有 Ceph 块存储 ，实现数据备份，上面是vivo自研的DevOps平台，做了调治 框架 ，右边是用harbor做的镜像堆栈 ，再往上就是云服务Portal，前面所说的那些云服务 ，同时也可以跑永生 命周期应用 。

　　宿主机主动 化实践

　　下面我们讲一下vivo的实践。如今 物理机一旦上了规模之后，装操纵 体系 就成为一件大事，我们提供了 vivoMachineCtl ，这个工具是一个下令 行给运维职员 利用 ，可以实现宿主机会合 化的参数设置 和主动 化。

　　利用 vivoMachineCtl，起首 和物理机管理卡做一个交互 ，交互之后拿到物理机的MAC地点 ，这里有个BMC，也有厂商叫iDrac卡，它可以取得这台服务器网卡的MAC地点 ，创建以MAC地点 定名 的Bootfile，指明如今 必要 装什么操纵 体系 ，和其他一些参数 。再进一步给它一个ipmi消息对服务器复位 ，然后服务器开始重启。

　　重启之后，服务器第一次会发dhcp哀求 ，拿到IP地点 ，之后会走一个pxe的协议，拿到bootfile，下载Bootfile所指明的小体系 和内存文件体系 文件下来 ，加载到物理机中，然后开始举行 操纵 体系 安装。这就是操纵 体系 安装的过程 。操纵 体系 安装完成之后，把安装类和文件体系 切换成正在启动的文件体系 ，在post阶段到会合 化的设置 中心 ，把相干 的设置 拉下来，包罗 IP地点 ，主机名和网关等信息 ，这是宿主机的主动 化摆设 。

　　KiverCtl实际 上就是把操纵 体系 的宿主机变成 盘算 节点大概 控制节点。盘算 节点有如下几个功能：第一，根本 的包安装，第二 ，Docker、Netplugin初始化，启动kiver-guard/flume/cadvisor容器，完成日记 和监控指标的收罗 。

　　控制节点上面有Etcd和Netmaster ，也会可选地把Prometheus/alertmanager/grafana/启动起来。vivoMachineCtl和KiverCtl实现了云服务器节点从物理机到宿主机的变化 。

　　业务日记 集成到日记 平台实践

　　这是vivo日记 收罗 的实践，在宿主机上做日记 分区，容器运行起来之后挂这个目次 ，每个容器起来之后会创建一个本身 的文件目次 。表面 有kiver-guard，用来侦听内核文件体系 的新日记 文件创建的关照 。

　　根据关照 会创建软件链接，链接到上一级Flume监控的日记 目次 ，由Flume推到kafka。大数据平台会来斲丧 这里的数据，业务日记 平台也会斲丧 这个数据，然后长期 化到ES里，末了 由中心 件日记 平台来实现对日记 的检索和展示。

　　为什么要这么做？当时 用的flume版本不支持主动 网络 递归子目次 下日记 新增内容的网络 ，完备 的文件可以网络 进去，但是日记 文件在递归子目次 下有不绝 地追加是输不进去的 。

　　kiver-guard本身 也是一个容器，它起来之后把宿主机日记 目次 挂上去 ，在容器内里 侦听日记 目次 下的create变乱 。

　　不管这些日记 路径有多深大概 在那边 ，都可以链接出来。做链接的时间 有一点必要 留意 ，要确保链接过来之后文件名称是唯一的 。有些容器被删除了 ，大概 日记 被轮转删除了，同样也会针对Delete变乱 ，侦测到delete是件之后删除上层flume监控日记 路径的对应链接。

　　底子 组件日记 网络 实践

　　底子 组件日记 采取 Etcd、Ceph 、CentOS、Netmaster等一些网上比力 热门的EFK组件 ，开箱即用。

　　监控与告警实践

　　这是监控和告警实践，在容器范畴 比力 常见，vivo采取 的是Promethus和Alertmanager 。Promethus采取 双节点 ，双拉（拉两遍），两个Promethus之间没有做主从，为了办理 高可用题目 ，挂了一个别的 一个还在。

　　之后接短信邮件中心 ，背面 接Grafana作为监控面板，前面用了telegraf。我们做的东西不但 仅有容器，尚有 其他的组件像Ceph 。我们用Cadvisor网络 容器监控指标。

　　我们对集群康健 做监控 ，也对集群资源利用 环境 举行 监控，集群的康健 性采取 telegraf可以调用外部shell脚本的特性。我们在控制节点写了脚本，用来查抄 Etcd的康健 环境 ，也和各个节点举行 通讯，查抄 各个节点是不是康健 。之后会返回数值，给出集群康健 状态码。

　　这个就是前面讲的自界说 的一些监控指标 ，这是集群的康健 查抄 ，这是集群的资源利用 率，大抵 两条数据链进来。一个脚本由telegraf去拉 ，推到Prometheus内里 ，末了 展如今 Grafana上面。另一个，由DevOps框架把数据写到Mysql内里 ，再由Grafana界说 Mysql的软件源 。

　　这边拉出来的自界说 的康健 指标支持返回码 ，这个返回码必要 翻译成笔墨 ，实际 上Grafana已经具备这个特性，我们可以去做一个映射 ，比如 1代表监控，2代表网络题目 等等，它可以主动 翻译来。

　　数据长期 化实践

　　说到云服务各人 都会关注这个题目 ，数据怎么做到长期 化，做到不丢。容器启动的时间 会挂在宿主机上面的一个数据目次 ，和日记 雷同 ，有容器的启动进程 ，直接写脚本也可以，创造二级目次 。

　　用主机名 ，是在容器默认的主机名，就是它的默认ID号。假如 这个ID已经存在就不消 创建，阐明 容器是起用一个旧的容器，末了 创建 软链接到数据目次 。如许 确保每个容器日记 数据都长期 化到宿主机 ，还可以确保容器重启后数据不丢 。

　　第二，数据本身 有一个单独的备份体系 ，它会每天 晚上破晓 2点跑一遍 ，把Mysql数据推到Ceph块存储当中，实现数据的可靠性。

　　集群可靠性实践

　　这是容器集群可靠性实践，最典范 的是三个副本 ，副本可以或许 实现数据和服务的可靠性。

　　失效重试，在集群各节点提供一个crontab定时任务 ，每隔一段时间探测一次docker服务进程 康健 状态 ，若不康健 ，则拉起Docker服务进程 。同时我们开启了docker的Restartalways选项，确保容器服务非常 退出后 ，能被重新拉起来。

　　关于隔离，起首 是分区隔离，宿主机业务日记 目次 /app/log独立分区，克制 日记 量过大时陵犯 宿主机体系 分区大概 业务分区磁盘。

　　第二 ，资源隔离，flume当时 是跑进程 的，我们做的第一件事变 是举行 容器化 ，之后做配额，限定 能利用 的资源利用 量，克制 大日记 传输时陵犯 宿主机过多资源 。

　　第三 ，故障隔离，开启dockerlive-restore选项，保障docker服务进程 不影响容器服务。

　　前车之辙

　　我们犯过一些错误 ，不负责物理机运营的童鞋大概 感受不显着 。假如 磁盘引导分区被粉碎 ，就大概 导致操纵 体系 被重装，这个题目 是很严峻 的。缘故起因 也很简单 ，服务器一样平常 有多引导的选项，比如 磁盘、网络 、CD，一样平常 在次序 上磁盘第一，网络第二 。

　　但假如 磁盘引导分区坏了 ，服务器会以为 没有操纵 体系 ，然后就从第二个上引导。这时间 不幸的事变 是，在你的网络环境 里假如 之前刚好装过操纵 体系 ，采取 了第三方开源的摆设 服务器，而没有把之前的文件删掉，那么它就会把那些操纵 重新装上。

　　办理 办法很简单 ，我们提供了定时任务 ，对两个小时前创建的引导文件，能望见 它的创建时间、访问时间 ，并举行 逼迫 性删除 。

　　第二个前车之辙，在网络 Ceph日记 时碰到 困难，当时 是用fluent-plugin-ceph插件来做。具体 的环境 是 ，第一，官方设置 文档不精确 ，由于 提交者没按官方文档格式编码，导致看到的设置 是一行 ，拿返来 根本不知道怎么办。第二，它和td-agent1.0 版本不兼容 。探索 出的办理 方法就是图片上表现 的办法。

　　下一代云服务架构

　　这是我们下一代云服务架构，与上一代的重要 区别在于 ，把编排框架换成了Kubernetes。如今 AI这块已经用起来了，AI部分 在线上大概有一百台物理机，跑Job任务 ，短任务 每天 可以跑到三万个，一次性可以变更 3000个容器，将来 会把这个些换成Kubnernetes ，包罗 我们的AI、云服务都会跑在Kubernetes上 。

　　XaaS on Kubernetes

　　假如 把云服务跑到Kubernetes上，第一个要做的事变 ，大概 会采取 ceph块存储做背面 的数据和数据长期 化。如今 vivo已经有了数据ceph块存储 ，但功能还不强大 。第二，要办理 pod漂移调治 题目 ，假如 不消 ceph块存储，pod失效调治 到其他节点上有题目 ，调已往 没用的，没有数据 。

　　第三，也是最常见的一个 ，固定POD IP，看到网上有人讨论这个事变 ，以为 容器坏了 ，没须要 把容器固定起来，由于 有违微服务的原则。这种观点不太对，有一些场景 ，比如 在vivo的企业IT架构内里 ，很多 东西都跟IP挂钩，比如 安全战略 ，它不是跟域名挂钩，而是PODIP挂钩，互换 机、防火墙等很多 的设置 都跟这个相干 。以是 vivo要干的很紧张 的事变 ，就是把POD IP固定。

　　如今 业界对这块也有一些实践 ，比如 京东近来 有这方面的分享，把PODIP放在一个APP的IP 小池子内里 ，小池子内里 尚有 IP的话 ，就从小池子里拿，没有的话就从大池子里去申请 。

　　添加小数微信：xiaoshu062

　　备注公司 、姓名、职位

　　小数将拉您进入相应技能 群