初创互联网公司技术架构变迁之路

阅读量：5025 次

发布时间：2019-06-12

本文共 3806 字，大约阅读时间需要 12 分钟。

分享在一个典型的互联网创业公司中，技术如何快速响应业务变化，不断重构优化系统架构，满足业务的需求。

图1 最开始的系统架构

这样的系统能不能应对今后快速的业务发展？性能问题会不会成为持续增长的交易量的瓶颈？系统能不能撑得住访问高峰期的大规模并发访问？

性能优化成为这个时候最重要的工作，于是安排专门的工程师进行性能测试和性能优化，从架构、代码、数据库、运维各个层面梳理系统状况，发现系统瓶颈，进行针对性优化。

一、性能测试

校园零食购物的特点是在晚上10点左右进入高峰，在此前后一小时的交易量大概占整天交易量的一半，也就是说，如果要设计一个日订单100万的系统，其实要承受的交易压力是每小时50万单。

当初按照二八法则推算峰值每秒单量为556笔『500000 * 0.8 / (60 * 60 * 0.2)』，以此为基准根据Nginx日志分析后端接口调用频率，推算出接口调用比率前20的请求，以此构造测试场景。

在执行性能测试时，我们使用Jmeter作为性能测试工具，利用了云服务提供的系统资源监控作为基础，同时抓取应用服务线程快照和MySQL数据库slow.log分析系统瓶颈。脚本分别如下：

//抓取应用服务线程快照jstack `jps | grep -v grep | grep -v Jps|awk '{print $1}'`//MySQL数据库slow.log分析mysqldumpslow mysql-slow.log

二、架构优化

性能测试结果并不乐观，我们结合互联网领域常用技术架构模式以及自身性能瓶颈，进行了架构优化重构。

虽然系统此前使用了分布式缓存对热点数据进行缓存，但是比较随意，哪些数据需要缓存，失效策略如何设置都没有认真分析和设计。性能测试后决定规范缓存使用，尽可能将各种频繁读取的数据全部缓存起来，并将Redis服务器做集群和主从复制部署。

此外还使用第三方CDN服务进行静态文件访问加速，产品图片、JavaScript文件、CSS文件等都通过CDN加速，同时通过Nginx反向代理服务器提供静态文件的前端缓存。

性能测试发现，系统主要瓶颈点在数据库上，虽然使用Redis将热点数据缓存起来，但是数据库依然在并发量达到一定程度后表现出系统过载的情况。于是对数据库进行主从分离。

优化后的系统架构如图2。

图2 优化后的系统架构

三、H5响应压缩优化

性能测试发现App应用比移动Web端响应速度更快，分析发现H5响应内容因为包含了大量HTML，数据包大小远远大于App响应包。因此决定采用Nginx作为反向代理的同时，对HTML内容进行压缩。

开启Nginx gzip压缩的指令如下：

#config gzip;    gzip on;    gzip_min_length 1k;    gzip_buffers 4 16k;    gzip_comp_level 2;    gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript image/jpeg image/gif image/png  application/json;

关于gzip_types，我们针对JSON数据也开启gzip压缩，降低App响应数据包大小，提高响应性能。图3是开启gzip前后的性能测试结果对比：

图3 H5页面开启压缩前后性能对比

四、SQL语句与索引优化

性能测试过程中发现，由于此前主要精力都在关注如何快速实现业务，大量数据库查询语句写得比较随意，索引设计非常不合理。

结合性能测试中Mysql数据库slow.log分析，定位慢查询SQL追加index，然后利用解释执行计划explain优化SQL。在此简要列举几处示例。

（1）某字段类型为varchar类型，根据查询关键字段查询时，写入值为Int类型，导致无法命中索引。

优化前：

select * from aa where aa.bb = 1449220364536130715;

优化后：

select * from aa where aa.bb = '1449220364536130715';

（2）查询条件左边写入函数，导致无法命中索引。

优化前：

select * from cc where date_format(dd,'%Y-%m-%d')=(DATE_SUB(CURDATE(),INTERVAL 1 DAY));

优化后：

select * from cc where dd=(DATE_SUB(CURDATE(),INTERVAL 1 DAY))

（3）追加Index时，计算数据唯一性巧妙添加左前缀索引，提高索引命中率，保证索引字段唯一性。

利用如下SQL计算索引命中率：

select count(distinct left(pinyin_initial,3))/count(*) as sel3,count(distinct left(pinyin_initial,4))/count(*) as sel4,count(distinct left(pinyin_initial,5))/count(*) as sel5,count(distinct left(pinyin_initial,6))/count(*) as sel6,count(distinct left(pinyin_initial,7))/count(*) as sel7from city;

以此算出城市拼音缩写长度为3时，命中率和唯一性比较高，则写下如下SQL：

ALTER TABLE `city` ADD INDEX `index_on_pinyinInitial` USING BTREE (pinyin_initial(3));

五、数据库连接池优化

数据库的访问优化也比较重要，宅米后台系统开发使用了Mybatis + C3P0组合，在做性能测试的时候发现在某些情况下有较为严重的性能问题。在高并发情况下，长时间施加压力，应用程序出现不能访问的状况。

上网查找资料，发现很多人也遇到了C3P0的”APPARENT DEADLOCK”问题。

将C3P0切换成国产数据库连接池Druid之后，状况明显好转，类似问题再未出现过。

六、缓存使用优化

经过对数据库和缓存应用的一系列优化后，缓存的命中率保持在90%以上，进一步研究后发现，Redis使用依然有提升的空间。

应用程序访问Redis的时候，可以通过使用Jedis的pipeline减少redis通信次数，有效提升性能。Jedis是基于socket通信实现的，每次与Redis通信都会消耗相当的网络连接时间，pipeline则是以打包批量的形式执行命令，图4是执行5000次set操作的响应时间对比：

图4 Jedis pipeline性能测试结果

七、订单数据冷热分离

随着业务的持续发展，订单表的数据会越来越多。按我们现在日订单量20万单预估，月订单量则为600万单，年订单量则达到7200万单，而且日订单量还在不断的增加，用不了多久，数据量就会超过MySQL的极限。

一开始我们考虑使用分布式数据库的方案，对订单表进行水平切分，使用订单号进行hash，将订单数据切分到多张表上。进一步分析后发现，订单数据具有明显的冷热不均的特点，即刚刚创建的订单是热数据，不同应用以各种方式访问修改这些订单。经过一段时间以后，特别是订单完成后，订单访问频率急剧降低，而且只有订单查询这一种操作。于是我们考虑采取冷热数据分离的策略，以控制热库中数据总量，保障订单表数据量始终维持在一个可以接受的范围内，进而提供稳定的数据访问性能。订单数据冷热分离方案如图5。

图5订单数据冷热分离

八、系统性能监控

性能测试和性能优化虽然对系统做了充分的改进，但是实际线上性能表现究竟如何，出现紧急性能问题时如何快速应对，还必须要对生产环境进行性能监控。在此简要列举一些宅米的性能监控报警要点：

除了系统自身监控，很多系统故障和性能问题会直接反应到业务上。如果系统响应缓慢甚至宕机，那么实时订单量也会受到影响，因此监控实时交易也可以发现系统问题。图6是实时交易监控图，在这里例子中，21:33订单量突然降到零，虽然系统监控指标正常，但是可以断定系统必定出了问题，马上打开应用日志查看，发现有个Bug导致某个外部资源死锁，立刻手工释放该资源，系统恢复正常。