总执行代码:
# coding=utf-8
import unittest,os,time
import HTMLTestRunner
import threading
import sys
sys.path.append('C:/Users/Dell/Desktop/CARE/program')#使用编辑器，要指定当前目录，不然无法执行第20行代码
def creatsuite():
casedir = []
list = os.listdir(os.path.dirname(os.getcwd()))#获取当前路径的上一级目录的所有文件夹,这里可以改成绝对路径(要搜索的文件路径)
for xx in list:
if "baidu" in xx:
casedir.append(xx)
suite =[]
for n in casedir:
testunit = unittest.TestSuite()
unittest.defaultTestLoader._top_level_dir = None
#（unittest.defaultTestLoader(): defaultTestLoader()类，通过该类下面的discover()方法可自动更具测试目录start_dir匹配查找测试用例文件（test*.py），
并将查找到的测试用例组装到测试套件，因此可以直接通过run()方法执行discover）
discover = unittest.defaultTestLoader.discover(str(n),pattern='tet_*.py',top_level_dir=None)
for test_suite in discover:
for test_case in test_suite:
testunit.addTests(test_case)
suite.append(testunit)
return suite, casedir
def runcase(suite,casedir):
lastPath = os.path.dirname(os.getcwd())#获取当前路径的上一级
resultDir = lastPath+"\\run\\report\\" #报告存放路径
now = time.strftime("%Y-%m-%d %H.%M.%S",time.localtime())
filename = resultDir + now +" result.html"
fp = file(filename, 'wb')
proclist=[]
s=0
for i in suite:
runner = HTMLTestRunner.HTMLTestRunner(stream=fp,title=str(casedir[s])+u'测试报告',description=u'用例执行情况：')
proc = threading.Thread(target=runner.run,args=(i,))
proclist.append(proc)
s=s+1
for proc in proclist:
proc.start()
for proc in proclist:
proc.join()
fp.close()
if __name__ == "__main__":
runtmp=creatsuite()
runcase(runtmp[0],runtmp[1])
由于停服维护的需求(服务越来越多的原因),此前编写的shell脚本执行速度缓慢(for循环,这就会很慢),为提高执行速度,参考很多资料,完成此脚本,实现并发执行机制.(当然这是测试脚本,有需要的同学,拿去改ba改ba,应该就可以用了)
此处脚本参考了https://www.jb51.net/article/86053.htm
第一个就是并发本身所带来的开销即新开处理线程、关闭处理线程、多个处理线程时间片轮转所带来的开销。实际上对于一些逻辑不那么复杂的场景来说这些开销甚至比真正的处理逻辑部分代码的开销更大。所以我们决定采用基于协程的并发方式，即服务进程只有一个(单cpu)所有的请求数据都由这个服务进程内部来维护，同时服务进程自行调度不同请求的处理顺序，这样避免了传统多线程并发方式新建、销毁以及系统调度处理线程的开销。基于这样的考虑我们选择了基于Tornado框架实现api服务的开发。Tornado的实现非常简洁明了，使用python的生成器作为协程，利用IOLoop实现了调度队列。
第二个问题是数据库的性能，这里说的数据库包括MongoDB和Redis，我这里分开讲。
先讲MongoDB的问题，MongoDB主要存储不同的用户对于验证的不同设置，比如该显示什么样的图片。
一开始每次验证请求都会查询MongoDB，当时我们的MongoDB是纯内存的，同时三台机器组成一个复制集，这样的组合大概能稳定承载八九千的qps，后来随着我们验证量越来越大，这个承载能力逐渐就成为了我们的瓶颈。
为了彻底搞定这个问题，我们提出了最极端的解决方案，干脆直接把数据库中的数据完全缓存到服务进程里定期批量更新，这样查询的开销将大大降低。但是因为我们用的是Python，由于GIL的存在，在8核服务器上会fork出来8个服务进程，进程之间不像线程那么方便，所以我们基于mmap自己写了一套伙伴算法构建了一个跨进程共享缓存。自从这套缓存上线之后，Mongodb的负载几乎变成了零。
说完了MongoDB再说Redis的问题，Redis代码简洁、数据结构丰富、性能强大，唯一的问题是作为一个单进程程序，终究性能是有上限的。
虽然今年Redis发布了官方的集群版本，但是经过我们的测试，认为这套分布式方案的故障恢复时间不够优秀并且运维成本较高。在Redis官方集群方案面世之前，开源世界有不少proxy方案，比如Twtter的TwemProxy和豌豆荚的Codis。这两种方案测试完之后给我们的感觉TwemProxy运维还是比较麻烦，Codis使用起来让人非常心旷神怡，无论是修改配置还是扩容都可以在配置页面上完成，并且性能也还算不错，但无奈当时Codis还有比较严重的BUG只能放弃之。
几乎尝试过各种方案之后，我们还是下决心自己实现一套分布式方案，目的是高度贴合我们的需求并且运维成本要低、扩容要方便、故障切换要快最重要的是数据冗余一定要做好。
基于上面的考虑，我们确定基于客户端的分布式方案，通过zookeeper来同步状态保证高可用。具体来说，我们修改Redis源码，使其向zookeeper注册，客户端由zookeeper上获取Redis服务器集群信息并根据统一的一致性哈希算法来计算数据应该存储在哪台Redis上，并在哈希环的下一台Redis上写入一份冗余数据，当读取原始数据失败时可以立即尝试读取冗余数据而不会造成服务中断。
