如何确定微服务扩展时的资源策略？

这个微服务扩展策略实际上要包含两方面，

一是科学地评估业务高峰时微服务的资源消耗情况；

二是构建微服务扩展资源模型。

第一个方面，一般通过压测来预先获取数据。如何构建压测场景，是科学评估的关键。我们可以看下一楼专家给的场景：

运营需要做一次活动，通过短信和 PUSH 的方式触达用户，推送约 6500W 用户预计 2 个小时内推送结束。压测场景下需要考虑短信、PUSH的历史转化情况，不能单纯以用户数来作为测试依据。

通过压测，我们可以获取到在设想的极限场景下各微服务的QPS，CPU/内存的水位。

第二个方面，微服务扩展模型。

首先是要建立不同的资源池。比如服务器资源池有高QPS类型，计算密集型，高带宽型，还有按照网络位置设立资源池，保证高安全性的微服务不要在低安全防护资源池里面扩展。

其次，资源调度机制。资源调度器要能够识别扩展触发场景，并选择相匹配的资源池进行调度。对于容器环境来说，我们需要构建更多的扩容触发条件，而不单单是CPU和内存占有率。比如博云公司的BOC容器管理平台，目前还支持网络流量，自定义触发等自动扩缩容策略。

在容量评估之前我们需要先了解下网站访问量的常用衡量标准：

Ø UV: 独立访客 ;

Ø PV: 综合浏览量 ;

Ø 并发量： 系统同时处理的请求数

Ø 响应时间： 一般取平均响应时间

Ø QPS ：每秒钟处理的请求数， QPS = 并发量 / 平均响应时间

Ø 带宽： PV / 统计时间（换算到秒） 平均页面大小（单位 KB ） 8

例如：运营需要做一次活动，通过短信和 PUSH 的方式触达用户，推送约 6500W 用户预计 2 个小时内推送结束，根据这样的活动规模，相关资源估算如下：

n 错误估算容量估算 ：推送用户量 /(26060)=9028

单机正常 QPS=1000 （水位 60% 极限） =600

因此需要服务器 9028/600=15 台

根据测试大概需要 15 台机器，

n 正确容量估算： 需要考虑短信、 PUSH 的历史转化情况，不能单纯看用户数，通过历史数据来看，短信点击率在 10% ， PUSH 点击率在 6% ，合计约 16% 的点击率，一般 2 个小时内是高峰期 , 每个用户约点击 8-10 个页面

点击用户数： 6500w*16%=1040W

2 小时 =26060=7200s

QPS=1040W*/7200=1444

单机 QPS=1000 （水位 60% 极限） =600

1444/600=2.4

预估需要新增 2.4 台服务器，实际上需要适当增加一些缓冲，通过综合计算再额外增加 3 台服务器即可。

提前做好压测，检测每个服务在链路上的执行情况吧。任何事情不能都是空口白话，还是需要验证过再决定。