2018年第一站人云云Meetup携手vivo，在深圳举办了第一期打造微服务系列活动。本次技术沙龙，vivo、中兴、华为、树人云联合派出技术专家，为开发者带来微服务、容器化、配置中心、服务网格等领域的开发者实战和干货分享。树人云聚会每月举办一次。欢迎大家面对面学习。本文为vivo云计算架构师袁乐林分享的《vivo云服务容器化实践》现场演讲实录。今天演讲的内容主要是介绍技术背景，产品的技术架构，我们关键技术的实践，前车之鉴，以及对下一代云服务架构的愿景。技术背景vivo这几年的业务发展非常迅速，拥有数亿用户、数万台服务器、数百个业务领域。后端系统的复杂度在快速增加，不仅是运维方面，还有架构系统的复杂度。high，vivo的技术架构也到了破茧成蝶的时候了。我们做了容器、虚拟机和物理机的性能对比测试。上图是当时做的性能测试架构图。得出了一些测试结论：1、容器化APP（4c8g）的性能略优于非容器化APP测试指标。2、容器化APP（32c64g）性能比裸跑和物理机提升近4%。损失，其中TPS损失3.85%，平均响应时间增加3.95%（1毫秒），对业务请求没有影响。3、容器化应用在12h稳定性测试中表现正常。4、相对CPU配额、CPU绑定、绝对配额场景下，容器化应用的业务性能为CPU相对配额>CPU绑定>绝对配额。5、当容器化应用出现组件异常、计算节点单一、控制异常时，容器运行正常。综上所述，容器化APP的性能接近于物理机，在多个测试场景下性能较为稳定可靠。同时，对于计算密集型应用，相对权重配额可以最大化CPU资源利用率。vivo容器化云服务框架正是因为有了这个性能测试数据的支持，才有了vivo容器化云服务框架，我们命名为Kiver，提供轻量级、高可靠的容器化生产解决方案。在这个框架之上，vivo一共有八项云服务。据后来统计，MySQL加上另外两个服务就占到了80%，这也很符合“二十八”的原则。vivo整个云服务容器化产品的架构图，左边是运维自动化的工具集，比如日志，监控等。日志在业界被广泛使用，我们用它来收集容器数据和容器监控指标。这里有两个日志。以上就是中间件业务日志平台。所有业务基于中间件日志规范，输出的日志会发送到这里收集。但是目前这个业务日志平台的功能比较薄弱，不支持一些新添加的组件，比如ECTD等。vivo也推出了EFK这种在容器领域比较常见的日志解决方案，未来计划将两种日志进行整合。vivo在运维方面开发了一些工具，比如vivoMachineCtl和KiverCtl。这两个工具主要实现上位机的自动化。简单来说就是可以自动安装上位机操作系统，安装后成为Kiver计算节点或控制节点。还有KiverPerfermance，这是我们嵌入的一个性能测试小插件。看右边，是vivo的基础设施，物理机和交换机，网络设备和防火墙等，最上面是Docker。Docker容器虚拟化技术将物理机上的相关资源虚拟化。右边是用于数据备份的Ceph块存储。最上面是vivo自研的DevOps平台，有调度框架。您还可以运行长生命周期应用程序。主机自动化实践下面说说vivo的实践。一旦物理机规模化，安装操作系统就成了一件大事。我们提供vivoMachineCtl，一个面向运维人员的命令行工具，可以实现宿主机的集中参数配置和自动化。使用vivoMachineCtl，首先与物理机的管理卡进行交互，然后获取物理机的MAC地址。有一个BMC，还有一个来自制造商的名为iDrac的卡。它可以获取本服务器网卡的MAC地址，并创建以该MAC地址命名的网卡。Bootfile指定了现在需要安装什么操作系统，以及其他一些参数。给它一个进一步的ipmi消息来重置服务器，服务器开始重新启动。重启后服务器会第一次发送dhcp请求，获取IP地址，然后经过一个pxe协议，获取bootfile，下载Bootfile指定的小系统和内存文件系统文件，加载到物理机，然后开始安装操作系统。这是安装操作系统的过程。操作系统安装完成后，将安装类和文件系统切换为正在启动的文件系统，进入后期的集中配置中心，拉取相关配置，包括IP地址、主机名等信息网关。自动部署主机。KiverCtl实际上是把操作系统的宿主变成了一个计算节点或者控制节点。计算节点有以下功能：一是基本包安装，二是Docker和Netplugin初始化，启动kiver-guard/flume/cadvisor容器，完成日志和监控指标的收集。控制节点上有Etcd和Netmaster，可以选择性启动Prometheus/alertmanager/grafana/。vivoMachineCtl和KiverCtl实现了云服务器节点从物理机到宿主机的转变。将业务日志集成到日志平台??的做法是vivo日志采集的做法。在宿主机上做日志分区，容器运行后挂起这个目录。每个容器在启动后都会创建自己的文件目录。外面有kiver-guard，用来监听内核文件系统新建日志文件的通知。根据通知，会创建一个软件链接，链接到上层Flume监控的日志目录，由Flume推送给Kafka。大数据平台会在这里消费数据，业务日志平台也会消费这些数据，然后持久化到ES中，最后由中间件日志平台检索并展示日志。你为什么要这样做？当时使用的flume版本不支持在recursive子目录下自动收集新的日志内容。可以收集到完整的文件，但是如果不断追加到递归子目录，日志文件将无法输入。Kiver-guard本身也是一个容器。唤醒后挂载宿主机的log目录，监听容器中log目录的create事件。不管这些日志路径有多深，在什么地方，都可以链接出来。链接时要注意的一件事是确保链接后的文件名是唯一的。一些容器被删除，或者日志被轮换删除。删除事件也将被检测到。检测到删除事件后，会删除上层flume监控日志路径对应的链接。基础组件日志收集实践基础组件日志使用了一些网上流行的EFK组件，如Etcd、Ceph、CentOS、Netmaster等，开箱即用。监控告警实践这是一种监控告警实践，在容器领域比较常见。Vivo使用Promethus和Alertmanager。Promethus采用双节点，doublepull（拉两次），两个Promethus之间没有master-slave。为了解决高可用问题，一个挂了，一个还在。之后连接到短信邮件中心，后面是Grafana作为监控面板，前面使用的是telegraf。我们做的不仅仅是容器，还有像Ceph这样的其他组件。我们使用Cadvisor来收集容器监控指标。我们监控集群的健康状况和集群资源的使用情况。集群的健康采用telegraf可以调用外部shell脚本的特性。我们在控制节点上写了一个脚本来检查Etcd的健康度，和各个节点通信，检查各个节点是否健康。之后会返回一个值，给出集群健康状态码。以上就是上面提到的一些自定义监控指标。这是集群的健康检查，这是集群的资源利用率。大致有两条数据链路。脚本由telegraf拉取，推送到Prometheus，最后显示在Grafana上。另一种是DevOps框架将数据写入Mysql，然后Grafana定义Mysql的软件源。此处拉出的自定义健康指标支持返回码。此返回代码需要翻译成文本。其实Grafana早就有这个功能了。我们可以做一个映射，比如1用于监控，2用于网络问题等，可以自动翻译。数据持久化实践说到云服务，大家都会关注这个问题，如何让数据持久化不丢失。当容器启动时，它会挂在主机上的一个数据目录中。和日志类似，有容器启动过程，也可以直接写脚本创建二级目录。加上hostname，就是容器中默认的hostname，也就是它的默认ID号。如果这个ID已经存在，就不需要创建，说明容器使用的是旧容器，最后建立了到数据目录的软链接。这样可以保证每个容器的日志数据持久化到宿主机上，也可以保证容器重启后数据不丢失。其次，数据本身有独立的备份系统，每晚凌晨2:00运行，将Mysql数据推送到Ceph块存储，实现数据可靠性。集群可靠性实践这是一个容器集群的可靠性实践，最典型的就是三副本，副本可以实现数据和服务的可靠性。失败重试，在集群的每个节点上提供一个crontab定时任务，每隔一段时间检测docker服务进程的健康状态，如果不健康，则启动docker服务进程。同时我们开启了docker的Restartalways选项，保证容器服务异常退出后可以重启。关于隔离，首先是分区隔离。主机业务日志目录/app/log独立分区，避免日志量过大时侵占主机系统分区或业务分区磁盘。二是资源隔离。Flume当时正在运行进程。我们首先做的是容器化，然后设置quotas来限制可以使用的资源量，避免在传输大日志时侵占过多的主机资源。第三，为了故障隔离，开启dockerlive-restore选项，保证docker服务进程不影响容器服务。过去我们犯过一些错误，不负责物理机运行的童鞋可能感觉不明显。如果磁盘引导分区损坏，则可能需要重新安装操作系统，这是一个严重的问题。原因也很简单。服务器通常有多个启动选项，例如磁盘、网络和CD。一般来说，磁盘是第一位的，网络是第二位的。但是如果磁盘引导分区坏了，服务器会认为没有操作系统，然后从第二个引导。这时候不幸的是，在你的网络环境中，如果你之前刚刚安装了操作系统，采用了第三方开源部署服务器，没有删除之前的文件，那么它会重新安装那些操作。解决方法很简单。我们提供定时任务。对于两个小时前创建的boot文件，可以看到它的创建时间，访问时间，强行删除。第二个错误是收集Ceph日志遇到困难，这是用fluent-plugin-ceph插件完成的。具体情况是，第一，官方配置文档不对，因为提交者没有按照官方文档格式编码，导致配置看成一行，拿回来不知道怎么办.二是不兼容td-agent1.0版本。我找到的解决方案是图中所示的解决方案。下一代云服务架构这是我们的下一代云服务架构。与上一代的主要区别是编排框架被Kubernetes取代。目前AI部分已经用上了。AI部分在线物理机约100台，运行Job任务，每天可运行30000个短任务，一次性调动3000个容器。未来这些都会被Kubernetes取代，包括我们的AI和云服务，都会运行在Kubernetes上。XaaSonKubernetes如果在Kubernetes上运行云服务，首先要做的是使用ceph块存储进行后续数据和数据持久化。目前vivo已经有了dataceph块存储，但是功能还不强大。第二，解决pod漂移调度问题，如果不使用ceph块存储，会出现pod故障调度到其他节点的问题，转移到其他节点也没用，就没有数据了。第三种也是最常见的一种是修复PODIP。看到网上有人讨论这件事，感觉容器坏了。没必要固定容器，因为它违反了微服务的原则。这种看法是不正确的。在某些场景下，比如invivo的企业IT架构，很多东西都是跟IP挂钩的，比如安全策略，不是跟域名挂钩的，而是跟PODIP挂钩的。许多配置如交换机和防火墙是链接在一起的。与此有关。所以，vivo要做的最重要的事情就是固定PODIP。目前，业内也有这方面的一些做法。比如京东最近就分享了这方面的内容，将PODIP放在一个APP中的一个小IP池中。申请。微信后台回复“127”公众号获取本次演讲PPT《vivo云服务容器化实践》。
