微服务架构练习-2

Context

上回书我们开启了一个微服务的练习项目,并写了一个基于gRPC通信的Account Service和网关服务。这一回主要来讲讲我们做性能测试时候的故事~

dedeluoxixiexpress写了两个路由,/grpc/,/native/,在gprc路由下直接调用Account Service,这个Service会通过PeeWee去访问PostgreSQL数据库服务器。native路由下,直接用node.js通过node-postgres去访问PostgreSQL数据库服务器。

Test 1

Express牛逼的地方就在于它擅长处理高并发,而且做转发比nginx方便多了。所以我们就看看他的本事把。

第一项测试是比较用grpc和直接native请求的性能。

test1

用jmeter进行压力测试,先进行并发量1000的测试,结果发现native出现了很多数据库连接问题,大概是node-PostgreSQL的库做的不够好,没有做连接池和线程的优化,导致了数据库接收到了express过多的连接请求,就导致了连接失败产生错误,最后整个网关服务都死了。但是看grpc的测试,就可以发现网关一直没有报错,但是收到数据request请求之后产生response所耗费的时间会随着并发量的增加而延长。当jmeter的测试中设置了超时时间时,会出现较多的错误,但是express的网关服务还是很坚挺的。

Test 2

经过第一个测试,我们决定排除native的方法,我们认定用了微服务的方式,至少可以保证网关服务不会出现拒绝服务的情况,仅仅保持http的连接对于express来说还是可以搞定的。那么现在第二个测试主要就是测试使用了微服务后,它的并发量极限是多少。

在这之前需要对测试工具JMeter做一些了解。

JMeter

JMeter是怎么进行并发测试的呢?

在开始测试后,软件会开始建立线程,需要测试多少并发,就会建立多少线程,在建立完线程后,在每个线程中开始进行测试。所以经过观察我发现,它并不能很好的模拟一个高并发的测试,因为多线程其实 从原理上来说还是时间分片做的,所以每台电脑做多同时发送的网络请求数目就那么多,并不能模拟我想要的数量。

JMeter也知道这个问题,所以它提供了分布式测试的功能,说起来就是,自制DDos攻击,哈哈。

所以我们就发动了教研室里面的6台电脑,一起测试,每台就1000左右的并发测试,果然发现测试结果比用一台电脑惊醒6000并发测结果要糟糕的多。可能因为使用的全是超低配服务器,能做到这个性能已经不错了吧。

虽然似乎访问都有了结果,但是从数据库里面的时间变化量可知,存在数据库写入失败的情况。

Test 3

我怀疑,是不是数据库服务器实在是太垃圾了,所以我就买了一台比较好的服务器来做数据库服务器。

test3

为了测试微服务的横向扩展是否实现,特地又把那些便宜的服务器拿来当作微服务服务器来测试。这里在网关服务使用一个假负载均衡机制(随机调用)来进行测试。

从3个account service的log中可见,三个微服务都被临幸了。最后看7000左右的并发效果还是不错的,大概有10条以内会出问题,而且问题可能出在发送机这里。他们发不出去了!

Router Limitation

电脑不能同时发那么多数据,难道我们用的路由器就可以了嘛?

我们提高每台电脑的并发参数后,开始测试时,发现网内的其他电脑的网络速度变得很差了。甚至连ssh终端的连接都无法维持。所以这个测试可能就被限制住了……

Test 4

对于并发测试,我觉得已经很满意了,因为在这2天左右的时间里把grpc搞了搞,docker用得更熟了,还买了很多服务器…很多低端服务器。用这些低端服务器维持了这么高的并发,我觉得还是可以的了。所以接下来,在微服务中很重要的就是服务的发现和负载均衡。

在查询相关资料的时候我发现,nginx已经和gRPC融合了了。他官网还给出了例子,好好讲解了怎么样用nginx来配合使用gRPC。

幸好还剩一台服务器,所以设计了一套新的测试方案。

test4

用nginx自己来做负载均衡,说不定很科学。

但是测试的结果并不理想,比Test 3的效果还要差,至于这个原因嘛,下回分解把。