第四范式机器学习平台研发部，专注于大数据和容器技术的测试实践

预测服务
　　下面一个场景是预测服务的。预测服务的架构一般都满复杂的，为了实现高可用，负载均衡等目的，所以一般都是标准的服务发现架构。以etcd这种分布式存储机制为载体。 所有的预测服务分别以自注册的方式来提供服务。
　上面的一个图是一个比较流行的预测服务的架构。当然我做了相应的简化，隐去了一些细节。所有的部署任务由master写入ETCD。 所有agent以自注册的方式将自己的信息写入ETCD以接受master的管理并执行部署任务。 而router也同样读取etcd获取所有agent提供的预测服务的信息并负责负载均衡。 有些公司为了做高可用和弹性伸缩甚至将agent纳入了kubernetes的HPA中进行管理。由此我们需要测试这套机制能实现他该有的功能。例如：
　　router会按规则把压力分发到各个agent上。
　　把某个agent的预测服务被kill掉后，router会自动切换。
　　预估服务挂掉，agent会自动感知并重新拉起服务。
　　agent被kill掉后，也会被自动拉起。
　　如果做了弹性伸缩，需要将预测服务压到临界点后观察系统是否做了扩容等等。
　　性能测试
　　我们要接触的性能测试跟互联网的不太一样。我们知道预测服务仍然还是访问密集型业务。但是模型调研的过程是属于计算密集型业务。我们要模拟的情况不再是高并发。而是不同的数据规模，数据分布和数据类型。我们日常的性能测试都是需要在各种不同的数据下跑各种不同的算子和参数。所以我们首先需要一种造数机制，能帮助我们按需求生成大规模的数据。我们选择的是spark，利用分布式计算在hadoop集群上生成大量的数据。
　　原理也很简单，接触过spark的同学肯定都知道在spark中生成一个RDD有两种方式， 一种是从文件中读取，另一种是从内存中的一个list种解析。第一种方式肯定不是我们想要的， 所以从内存中的list解析就是我们选择的方式。假如我们想生成一个10亿行的数据。就可以先使用python 的xrange造一个生成器以防止内存被撑爆。然后用这个生成器初始化一个有着10亿行的空的RDD，定义并操作RDD的每一行去生成我们想要的数据，然后设置RDD的分片以及消耗的container，内存，cpu等参数。提交到集群上利用集群庞大的计算资源帮助我们在段时间内生成我们需要的数据。 前两天我再一个3个节点的集群上造过一个1.5T的数据，大概用了5个小时。这样一开始的时候我们是写spark脚本来完成这些事。后来需求越来越多，我们发现可以造数做成一个工具。把表和字段都提取到配置文件中进行定义。就这样我们成立了shannon这个项目。慢慢的从造数脚本到造数工具再到造数平台。
　　它的架构特别简单，就是对原生spark的应用，这里我就不展示spark的架构是什么样了。就贴一下造数工具的设计图吧。
　简单来说shannon分了3层。最底层是基本数据类型层。负责字段实例化，定义并实现了shannon支持的所有数据类型。例如，随机，枚举，主键，unique key，控制分布，大小，范围等等。
　　测试环境管理
　　常见的测试场景我们基本上都说完了。 我们再说一说测试环境管理的问题。 为了能够保证研发和测试效率，一个能够支撑大规模测试环境的基础设施是十分必要的。为什么这么说呢？
　　●首先但凡是涉及到机器学习的业务，运行时间都非常慢。 有时候做测试的时候跑一个模型要几个小时甚至一天都是有的。也就是说，我们运行测试的成本比较高。如果在运行测试的途中环境出了什么问题那么损失还是很大的。多人共用一套环境难免会有互相踩踏的情况，例如一个RD在测试自己的模块，另一个人上来把服务重启了。这时候我们心里一般就是一万头某种动物飘过。所以我们一般希望每个人都能拥有一套独立的环境甚至一个人多套环境。这就增加了测试环境的数量。尤其是团队越来越大的时候，测试环境的数量已经到达了一个恐怖的量级。
　　●其次如果各位所在的公司也像我们一样做TO B的业务，那么我们的测试环境就需要多版本管理，要有能力随时快速的搭建起特定版本的产品环境供开发，产品，测试，以及技术支持人员使用。所以这无疑又增加了环境管理设置的复杂度。
　　●再有就是随着环境数量的扩张，我们的环境从单节点走向集群，这时候我们对环境调度能力的要求会比较高，例如我们要对环境的资源进行计算和限制，保证最大化利用资源的同时不会撑爆系统。例如我们要保证系统有足够的冗余，在某些环境出现故障的时候能够自动检测出来并在冗余节点进行恢复。例如我们需要能够实现多租户管理，执行资源管控，限制超售行为. 例如我们希望系统有一定能力的无人值守运维能力等等。
　　所以我们经过一段时间的讨论和实验，引入了k8s+docker来完成这个目标。docker的优势大家应该都知道，快速，标准化，隔离性，可迁移性都不错。 通过镜像我们可以迅速的将测试环境的数量提升一个量级，镜像的版本管理正适合TO B业务的多版本管理。 之所以选择k8s，是因为k8s相较于swarm和mesos 都拥有着更强大的功能和更简单的部署方式。刚才说的预测服务需要部署很多个agent，使用k8s的话只需要设置一下replica set的数量，k8s就会自动帮我们维护好这个数量的实例了，很方便 。k8s的调度机制能很轻松的满足我们刚才说的对于灾难恢复，冗余，多租户，高可用，负载均衡，资源管理等要求。所以我们当初怀揣着对google莫名的憧憬走上了k8s的踩坑之旅。
　首先说一下我们都用容器做什么。主要三大类，第一种是诸如testlink，jenkins这种基础服务。第二种是产品的测试环境，这是占比最多的。然后就是我们的测试执行机器了。例如UI自动化，我们采取的是分别将selenium hub和node docker化的做法。如下图：
　当UI自动化的case增多的时候，分布式运行往往是最好的解决方案。 目前我们通过这种方式容器化了20个浏览器进行并发测试。这些镜像都有官方的版本，使用起来还是蛮方面的。
　　然后说一下比较关键的网络解决方案，我们从单机到集群，中途历经了集中网络模型的变化。从一开始的端口映射，到利用路由规则给容器分配真实的ip，再到给每个容器在DHCP和DNS服务器上注册和续租。到最后我们演进出了下面这个k8s的网络模型。
　　我们知道每个docker宿主机都会自己维护一个私有网络。如果想让容器跨主机通讯或者外部访问容器。一般就是通过三种方式： 端口映射，路由规则以及overlay网络。我们选择在k8s中引入的overlay网络是weave，以解决夸主机通信问题。安装kube-dns实现服务发现。之后为了能让外部访问容器服务， 使用了k8s提供的ingress机制来实现。这个ingress网络其实就是在集群中启动一个容器，这个容器既能访问容器网络的同是还监听了宿主机的80端口。容器里是一个nginx，它会负责帮忙转发请求。nginx负责转发的有servicename和path，这里我们是无法使用路径进行转发的。所以我们在公司内部的DNS上做了泛域名解析。所有testenv为后缀的域名都会解析成集群的master节点的ip。这样我们的请求就能命中nginx中固定的servicename并做转发了。通过这种机制我们就可以很方面的访问容器提供的服务。当然ingress的缺点是暂时还无法做4层转发。如果要访问4层协议的服务暂时还是只能暴露node port。
　　我们这个测试环境的管理平台主要的架构是这样的：
　　集群中所有的镜像都过公司内部搭建的镜像仓库进行共享，我们在集群之上安装了各种服务来满足测试环境的需要。例如使用NFS做数据持久化，Heapster+Grafana+InfluxDB做性能监控，kube-DNS做服务发现，dashboard提供web管理界面，weave做集群网络，ingress做服务的转发。并且我们在这个整体上针对k8s的APIserver做了一层cli的封装。我们尝试过脚本管理，web服务管理，但是发现大家对这些方式的接受度都不高。我们面对的大多数都是一帮做梦都在写代码的人，所以我们换做提供一个cli的方式可以让使用者更灵活来定制自己需要的服务。通过这种形式，我们在公司内部搭建了一个可以提供测试资源的私有云，配合jenkins我们可以很方便的一键部署我们需要的环境并执行UT,接口,UI自动化测试等等，并提供一个详细的测试报告。下面是我们的部署一个环境后所提供的测试报告。
好了，关于k8s+docker的内容我暂时就讲到这，其实这块内容比较多，完全可以单独拉出来当做一个topic来讲了。但是今天由于时间限制我们先讲这么多吧。我今天的分享也就到此结束了。关于人工智能类产品的测试我们也属于摸着石头过河，还有很多不足的地方。