问题背景：
客户这边的合同比对需求，涉及到一个并发的场景，当多个用户同时调用比对后端微服务的时候，后端微服务出现的阻塞的情况。
微服务封装成http服务使用的是tornado。 后来诊断问题发现是由于tornado server单进程导致的。
问题描述：
首先分析造成阻塞的原因，如果是因为io阻塞，那么改成异步应该是有帮助的，但是如果是CPU密集型的，那么异步就解决不了问题了。这次比对后端正好是cpu密集型的问题。
这时候的解决办法无非是两种思路（1）充分利用已有的CPU字段，利用机器已有的多核来做（2）如果机器的CPU已经全被利用，那么只好给机器添加CPU，或者添加机器来做负载均衡
排查过程：
现有的机器是两台服务器，并简单配置了负载均衡，但是压力测试过程，显示系统的吞吐量并不大，同时每个机器的CPU使用率并没有占满，大概只是到了25%-50%的样子。这样看增加机器并不明智，因为已有的机器资源并没有被充分使用。
那么看最应该做的应该是充分利用的机器资源（因为这两个机器是专门给比对服务用的，所以不涉及资源的共享，同时暂时也不用关心抢占这台机器上其他服务的资源）
首先查看已有的机器的CPU资源配置，可以执行以下两条指令查看逻辑CPU和物理的数量：
查看逻辑CPU的数目：
#cat /proc/cpuinfo |grep "processor"|wc -l
查看物理CPU的数目：
#more /proc/cpuinfo |grep "physical id"|uniq|wc -l
发现每个机器逻辑cp8个，物理cp2个，而我们的比对服务只是使用了单进程，那么很明显如果我们可以利用空闲的多进程，那么系统的阻塞问题可以得到缓解，吞吐量可以大幅提升。
Tornado原来的服务采取listen端口的实现方式，这种方式默认的就是单进程。单进程的代码如下：
if __name__ == "__main__":
application.listen(8080)
tornado.ioloop.IOLoop.instance().start()
如果要想实现Tornado的多进程，首先放弃使用listen的方法，并在启动的时候指定进程数，实现方式如下：
http_server = tornado.httpserver.HTTPServer(application)
http_server.bind(options.port, options.host)
http_server.start(num_processes=0) # tornado将按照cpu核数来fork进程
tornado.ioloop.IOLoop.instance().start()
小小的分析一下：
原来的listen的方式之所以不可以，是因为listen是bind和start指令的简称，listen相当于
http_server.bind(options.port)
http_server.start(num_processes=1)
这里默认进程数按照CPU的数量来做，但是这个也不是进程开的越多越好，如果进程数目过多就会造成有的进程会出现饿死的状况。所以到底num_processes设置多少较好，还是根据实际情况测试一下，得出来才合理。
