凌晨三点半 阅读(94) 评论(0)

    最近在和小伙伴们做充电与通信程序的架构迁移。迁移前的架构是,通信程序负责接收来自充电集控设备的数据实时数据,通过Thrift调用后端的充电服务,充电服务收到响应后放到进程的Queue中,然后在管理线程的调度下,启动多线程进程数据处理。

Image

    随着业务规模的不断扩大和对系统可用性的逐步提高。现在这个架构存在很多的问题,比如:

1.充电服务重启,可能会丢数据。

2.充电服务重启会波及影响通信服务。

3.充电服务与通信服务面对的需求和变化是不一样,强依赖的架构带来很多的问题。

    为了解决上述的这些问题,项目组决定借助Kafka对程序进行改造 。总体思路是,通信服务收到数据后,把数据存储到kafka,然后通过一个异步任务处理框架实时消费Kafka数据,并调用业务插件处理。

    通过上面思路我们可以看到,系统整体架构仅是引入了一个MQ中间件,业务逻辑并没有发生本质的变化。但是在实际的压测中,却发现新架构下的程序性能比原来要慢很多。顺便说一下,压测场景是模拟10万充电终端离网上下线,短时间内会生成大约32万的消息量,遥信:10万,遥测:10万,电量10万,其他:2万。

    通过ANTS分析相关进程,发现MonitorDataUploader.AddToLocalCache方法占用了78%左右的CPU。此方法不是业务方法,是为了监控程序的运行情况而加入的埋点监控。通过进一步分析看,在30多万消息量下,会产生约1000万甚至更高的监控消息。在如此高的并发下,这部分程序存在很严重的性能问题,导致系统的资源占用很高,系统运行变慢。

Image

    OK。既然问题已经清楚,那就开始优化吧。虽然可以把监控埋点屏蔽,临时解决程序的性能问题。但是,这对一个互联网应用来说是要不得的。没有监控,系统的运行健康状况就一无所知,这对一个SLA要求99.95%的系统来说,是不现实的。所以,必须全力优化监控程序在上报海量监控日志上的性能问题。

    为了便于验证问题,写了一个模拟程序.通过模拟程序,很容易的再现了CPU占用很高的情况。

Image

Image

    代码实现中,监控消息的存储是通过BlockingCollection存储的,并且设置了Collection大小为1000万。

var cache = new BlockingCollection<MonitorData>(boundedCapacity);

Image

    通过阅读BlockingCollection 的说明,可以看到空构造函数可以不设置Collection的上限。看到这个解释,怀疑是限制了上线的Collection存在性能问题。与是把代码中对BlockingCollection 的构造改成空构造,再次测试。测试结果大出意料,性能表现有了非常好的提升。

Image

    为了进一步验证问题,把对BlockingCollection 的构造改了限制大小,并设置上线为1个亿。测试时消息总量为5000万,验证一下是否是BlockingCollection 达到上限后,引起的严重性能问题。通过测试数据看,CPU消耗与不限制时基本一致。通过此可以确定,BlockingCollection 在设置了容量上限后,如果消息超过容量,性能将会非常差。

Image

    通过上面的调优,在发送5000万监控消息的情况下,程序的CPU在60% 左右持续30s左右。虽然性能有所改善,但是还不是很尽如人意。 有没有更好的解决方案呢?通过不算的思考和尝试,终于找到了一个更好的解决方案:基于双缓存+线程级多桶式Collection。此种模式下性能表现如下,CPU平均在30%左右,持续时间在15s左右。性能又有近一倍的提升。具体实现方案下次再分享。

Image