如何用高防CDN加速提高系统吞吐量与降低时延初

看到标题，我们就需要思考，什么情况下需要提高系统吞吐量及降低时延？

我们看看下面场景：

一 系统资源增加规律

系统初始上线，对于多活最低配置的两个实例，一般来说在没有太多时延情况下，利用每个服务进程的线程数都是能够应付的。随着业务持续增长，CPU会成线性增长，对业务服务的内存，主要是动态分配部分与业务量有关，但不会非常明显的线性增长，但非业务服务如redis等中间件，内存和业务是可以用线性来表达其关系。只有两个实例时候，CPU峰值每台周期性超过50%，就需要注意扩容。如果下面条件满足，  必须紧急扩容应对：

sum（CPU利用率总和）/(n-1)>= 100%

n为实例个数，(n-1)表示一台出现问题只有n-1提供服务

当一台出现问题，整体利用率到达瓶颈，就会导致集群崩溃。

网络带宽与峰值的业务请求总量成正比，一般情况下瓶颈在互联网接入端，内网目前主流万兆网关能够应付普通业务。磁盘的空间，对于业务来说，只要是日志存放大小，与业务量也是成线性关系，但磁盘相对便宜，一般就无须花费太多时间来思考，给个几十G空间基本都能满足，但如果是非业务的中间件，则需要根据中间件功能来确定空间及使用的是机械硬盘还是SSD类型，对于SSD存储，则相对成本高好几倍，因此需要合理规划系统资源。

二 硬件扩容 -- 提高系统容量最简单方法

提高系统吞吐量，可以通过横向扩展实例个数或者增强单个服务的硬件配置，这些方法在一定程度可以提高系统吞吐量并在一定程度降低时延。是横向扩实例还是纵向单机硬件增强，就需要区别对待，一般而言，横向比纵向易操作，但带来的规模数扩大，导致运维等成本增加，在实践中需要平衡考虑，每个实例扩展CPU或内存需要根据实际使用情况，确定是两个指标都调整，还是调整单个资源，相对成本比集群一倍数的扩实例成本会低，但如果实例数较多，只扩充1个，成本相对会低。如果涉及消费kafka/MQ资源，还需要考虑分区数是否需要扩充，分区数增加也会带来成本增加。 因此需要基于运维和资源成本考虑如何扩容。

如下图CPU利用率峰值接近100%，如果是CPU随着业务线性增长，则需要启动硬件扩容，如果业务增长对现有内存不存在明显瓶颈，则可以通过CPU扩容解决业务增长导致的服务崩溃的可能。

三 数据存储瓶颈 

对于并发数量过万，时延要求低的系统，在实际实践当中，一般都是因为数据库/存储导致并发上不去。对于微服务来讲，都是可以通过实例数的扩展而进行容量增加，但最核心瓶颈，在于数据库读写非常难上去。因此，就有了数据库分库分表。对于大部分业务的数据存储，都能采用非关系型数据库，只有涉及事务一致性的场景，就只能依赖于关系型数据库，因此，支付、电商等使用关系型数据库是必然的。对于按字段做统计报表等，目前的ES等使用固态硬盘情况下，通过索引也能够满足速度要求。相对于关系型数据库，非关系数据库如MongoDB、Hbase等通过横向扩展分片，能够满足高并发要求，而关系型数据库只能有限扩展，详情可参考如下文章：

https://yq.aliyun.com/articles/700692

如果涉及非关键key查询，跨表查询等，效率方面也不会高，就需要业务层面进行合理分库分表，查询时候根据业务特点优化。

图片来源阿里云

如果查询数据时间较长，可以把数据库缓存至redis，降低时延。对于业务需要使用几张表数据，也可以全部加载至redis进行查询加速。

四 利用消息队列进行削峰

对于业务有短暂峰值，对数据一致性要求不是100%，利用MQ的缓存能力可以轻松应对数据洪峰。消息队列能够缓存足够数据，消费者可以根据实际能力进行批量数据处理，如果生产者需要消费者同步结果返回给生产者的上一级服务，如客户端请求转发网关更改账号信息，转发网关把数据中转给最终数据保存服务，此场景客户端会查询更改的记录，如果消费服务不及时，会存在数据不一致情况，因此消息队列用来削峰需要注意使用场景。

五 异步框架或协程

对于高并发场景，Java可以利用类似Netty NIO的通信框架，达到提高吞吐量的能力，C++也有tars等框架支持。如果是http协议，Tomcat也是有NIO模式的，如果是长链接高频率数据通信，http+json就力不从心了，RPC是业界通用解决方案。对于客户端非常低频（如超过分钟）与服务端通信，http短连接是一个提高开发效率且能降低并发连接数节省服务器资源的方案。

六 CDN及反向代理

如果是图片、视频等大文件下载，CDN是提高吞吐与降低时延一个必然选项。在高防CDN如今各大云厂商都提供，并且流量不大，还有免费，具体可以查询主流云厂商的CDN使用说明。

对于直接面向如手机APP的服务，一般采用Nginx作为反向代理，通过Ngnix配置多个Tomcat服务地址，提升接入端并发能力。