im即时通讯-微信红包、支付宝红包、聊呗红包、诚信红包、谈功能逻辑、容灾、运维、架构等。Q红包
时间：2020-10-20
im即时通讯-社交软件红包技术解密(9):谈功能逻辑、容灾、运维、架构等。Q红包
一、导言
春节期间，QQ推出了一系列春节红包，由AR技术支持，并以娱乐体验为导向。
红包系列包括三大游戏+除夕夜彩蛋，即“LBS+AR天空红包”、刷红包和面对面红包，以及“娱乐红包”(明星刷红包)。例如，2017年春节期间，总共发放了2.5亿个红包和30亿张优待券。根据企鹅智库提供的数据，移动QQ用户的渗透率在整个平台中排名第二，为52.9%(第一位是微信)。
第三，产品功能要求
3.1。红包类别
以2017年手q春节游戏的红包为例，有三种:刷一、AR图和扫福。
如下图所示:
社交软件红包解密技术(9):谈功能逻辑、容灾、运维、架构等。Q红包_1.jpg
3.2。体验这一过程
尽管红包有三种类型，但游戏商业方面的体验是一样的:
1)用户获得红包卡优惠券，打开后，显示一个(刷红包)或多个(ar map红包)游戏的套餐列表；
2)用户选择礼品包后，弹出区域服务组件；
3)礼包将在用户确认区域服务的相应角色信息后48小时内分发到账户。
经验如下:
社交软件红包解密技术(9):谈功能逻辑、容灾、运维、架构等。Q红包_2.png
3.3。背景要求
游戏红包的设计容量为80k/s，用于入场卡页面。上述体验过程涉及三个背景界面:
社交软件红包解密技术(9):谈功能逻辑、容灾、运维、架构等。Q红包_3.jpg
三个后台界面是:
1)礼品包列表:用户界面中礼品包的内容需要根据后台界面返回的礼品包列表进行排序和过滤；
2)区域服务选择:用户界面中弹出的区域服务组件需要后台界面返回用户区域服务角色信息；
3)接收礼包:用户点击“确认”按钮接收礼包，游戏道具在后台交付。
四.需求分解和分析
4.1。礼品包装清单
使用现有功能更容易解决此功能。有十种游戏，每种游戏有两种套餐:拉新(非注册用户，价值80元)/拉活跃(注册用户，价值20元)。一个用户只能获得这两个包中的一个，产品策略允许拉新用户获得较低价值的拉活动包，否则是不允许的。该页面显示按用户偏好排序的十个游戏，每个游戏显示一个新的包或一个活动的包。
为了减少当前除夕的流量负荷和灵活性，在红包活动之前，已经通过线下包/CDN提前发布了作为前端静态数据的十场比赛的包内容；在红包活动中，后台界面只提供前端包内容，根据用户偏好返回的游戏包列表进行过滤和排序，如果失败，有一个前端默认游戏包列表，以保证用户体验。
过滤:读取存储，用户已注册游戏返回到活动包，而用户未注册游戏返回到新包。
排序:两级排序，第一级排序读取并存储(关键是用户，值是用户注册的游戏列表)，用户注册的游戏(拉式激活)排在用户未注册的游戏之前(拉式新建)；第二级排序，用于提取新的游戏列表和活动游戏列表的内部，使用宙斯盾算法再次对这10个游戏的用户偏好进行排序。外部接口仅依赖CMEM存储和宙斯盾算法接口，这两个接口以及结合这两个数据给出最终个性化推荐包列表的接口可以并行扩展以支持100k QPS。
4.2。地区服务信息
该功能是现有功能。此角色信息的来源是IDIP，但由于接口速度慢(约2s)且容量低(小于10k/s)，因此在后台制作了一层缓存，永久缓存CMEM IDIP的服务信息，前台也有本地缓存。在实践中，前台缓存的命中率为60%，后台缓存的命中率为35%，多级缓存后到达IDIP的请求数仅为5%，这对IDIP影响不大
4.3。收到礼品包
该功能使用现有的能力来解决现有的困难。在游戏中心有许多日常递送的道具和平台。平台分为IEG-AMS/MP，MP交付也是发行游戏道具和q币的两个界面。因此，我们使用体系结构中的外观模式和AMS作为交付代理，屏蔽了底层交付的复杂性，并为游戏中心提供了统一的交付接口。不幸的是，从AMS到游戏的交付界面都是同步界面，交付能力低。拥有最高投递能力的《国王的荣耀》只承诺3k/s的投递速度，这显然不足以直接承担100k/s级别的红包投递，因此，这里的核心问题是排队解决生产/消费速度不平等的问题。
去年的红包被成功地放在本地文件中，并在后台接收到传递请求后返回给用户，然后本地守护程序以播放器提供的传递速度实际传递了一个本地守护程序的登陆文件，这相当于使用本地队列缓冲区。然而，该方案也存在一些问题，例如，如果某台机器无法恢复，就会丢失部分本地交付数据，并且对于每个高度并发的业务来说，再次执行这一组操作是不方便的和通用的。
从体系结构来看，实际上最合理的解决方案是，AMS作为交付代理提供异步交付能力，而用于解决生成/消耗速度不匹配的MQ构建在AMS内部，为服务提供通用的异步交付能力，因此服务方不需要考虑交付超出玩家能力的问题，新服务具有类似的场景，不需要重新开发。
游戏中心是业务端，AMS是平台端的能力，属于另一个中心的业务。因此，在开始的时候，我们准备提升AMS异步交付的能力，这样业务只需要调用交付接口，非常方便。
然而，事情并不像预期的那样顺利。他们与医疗辅助队发展部和项目经理见了几次面。他们还为异步交付制定了技术计划，但是几年前他们还有其他需求要做，没有时间支持它们。我与领导讨论过，最好将这种能力放在AMS中，使其具有通用性，以便将来在相同的场景中有商业用途。前台的一些学生开发了AMS功能，游戏中心业务端的前台和后台的学生可以合作完成AMS异步交付功能的开发，并应用到春节红包中，然后将此功能移交给平台端的学生进行维护，从而达到双赢的效果。
V.总体方案和项目分解
社交软件红包解密技术(9):谈功能逻辑、容灾、运维、架构等。Q红包_4.png
(注:由于此图大而清晰，请下载总体方案图(清晰且大)。zip (769.6 KB，下载次数:1次)来自此附件)
如上图所示，由于整个项目涉及多方开发，模块众多，整个模块的开发周期相对较长。作为第一阶段的开发，它跟不上基本边卡凭证的验收和安排的几次演练/压力测试。因此，按照“大系统、小工作”的原则，根据模块的重要性和紧迫性，分为若干个迭代，每个阶段都有独立的里程碑目标，并满足相应的验收/演习/压力测试要求:
第一阶段(方案图左侧部分)是功能需求:12月9日上线，通过卡片凭证功能验收，首次使用当前的同步传递界面，对性能没有特殊要求。
第二阶段(方案图右侧左侧部分)是性能要求:12月20日上线参加第一次演练，进行交付异步转换，要求直接面向用户的外部网络交付接口能够支持10万QPS的高峰流量。
第三阶段(方案图的右侧部分)是容错需求:12月27日上线参与第二次演练，对交付进行对账和补货改造，确保交付的可靠性。
第四阶段是监控需求:1月6日上线参与第三次演练，确认关键数据的采集，并将采集的数据统一显示在视图上，以便值班人员在除夕之夜能够了解红包系统的整体运行情况，实时生成数据报告。
六、实际需求发展
6.1。功能需求的开发
核心问题:不同场景中的数据一致性
{3.1后台礼品包推荐界面}供用户推荐礼品包。当用户收到它们时，他们需要通过{4.1 AMS外部网络交付新操作}的验证才能获得资格。背景推荐数据必须能够与AMS资格验证数据相匹配。否则，在后台推荐的礼包的用户在收到礼包时将无法通过AMS资格验证。
{4.1 AMS外部网络发货新OP}界面处理接收单个游戏礼品包的请求，资格检查操作判断用户是否注册了某个游戏。这是医疗辅助系统现有的一般功能。数据存储在医疗辅助队的CMEM。简化的描述是一个关键值模型。关键是uin+appid。如果有注册，则值为1，如果没有注册，则值为0(实际上，为了节省存储空间，请使用位图存储桶。有关详细信息，请参见号码包系统使用文档)。导入的数据源是产品在除夕夜前一周提供的10个游戏的完整数字包。每个游戏都有一个文件，文件内容
但是{3.1后台礼品包推荐界面}界面返回多个游戏的礼品包列表，需要获得十个游戏的用户注册状态。
如果您阅读AMS的现有接口/存储，有两个问题:
1)AMS号码套餐服务也承载相当于48k/s推荐列表接口的流量，需要扩展；
2)AMS号码包服务调用CMEM，虽然它可以一次请求合并10个键进行批量读取，但是请求CMEM的访问机器仍然需要读取多个缓存块，其性能不如单个键读取。
社交软件红包解密技术(9):谈功能逻辑、容灾、运维、架构等。Q红包_5.jpg
解决方案:异构数据冗余
后台重新组织数字包数据，并将其存储在后台应用的另一个CMEM中，其中键是uin，值是用户的注册appid列表，注册的游戏推荐拉式活动包，未注册的游戏推荐拉式新包。这样，你只需要查询CMEM一次，就可以知道十个游戏中每个游戏的包推荐类型是拉新的还是拉激活的。
AMS和后台使用相同数量的包数据，但是应用场景不同，数据组织形式不同，并且两个CMEM数据是同构和异构的，因此后台推荐的包可以通过AMS资格检查。
社交软件红包解密技术(9):谈功能逻辑、容灾、运维、架构等。Q红包_6.jpg
6.2。性能要求的发展
核心问题:用户的礼包流量远远超过游戏交付能力
红包活动具有时间短(每场5~30分钟)和用户参与人数多(1.5亿以上)的特点，且请求并发性高。游戏红包入口流量设计为80k/s，通过每个模块的流量衰减并增加。最终用户对礼包的要求估计为96k/s，而游戏方提供的十个游戏的总交付能力仅为5k/s(最大单个游戏为3k/s，以国王的荣耀为准)
社交软件红包解密技术(9):谈功能逻辑、容灾、运维、架构等。Q红包_7.jpg
解决方案:异步交付
缓冲队列用于解决生产和消费能力不平等的问题。在用户收到请求并到达AMS进行基本资格验证后，他将请求放入MQ，返回用户成功，并告知它将在48小时内到达。然后，后台传送守护程序从MQ读取请求，并通过速度限制组件的控制确保传送操作的速率不超过播放器的传送能力。所用的MQ是该部门最近建造的火箭MQ。有关详细信息，请参见《火箭MQ访问指南》。
社交软件红包解密技术(9):谈功能逻辑、容灾、运维、架构等。Q红包_8.jpg
6.3。容错需求的发展
核心问题:安全交付
在这三次活动中分发的礼品包总数估计接近4亿个。如何确保这些礼包能够交付给合法用户，并且其中许多不会频繁发送？如何防止高价值的道具被恶意用户刷走。内部开发人员有没有可能调用他们自己的接口并给自己发送礼品包？
解决方案:对账和补货/订单号/安全攻击/权限控制
A.订单号解决了不常发生的问题:
用户界面{4.1 AMS外部网络交付新OP}已成功调用，由UUID生成的全球唯一订单编号将附加到该请求中，并输入到MQ中。{4.3 AMS内部网络交付OP}将从MQ中取出消息，并在调用玩家的交付界面之前检查该订单编号是否已被使用。如果尚未使用，订单编号将在交付操作前以密钥的形式写入CMEM。如果相同的交付消息被重复交付，将会发现已经使用了订单号，并且将不会执行实际的交付操作。保证由订单号标记的同一个交付请求只交付一次。
社交软件红包解密技术(9):谈功能逻辑、容灾、运维、架构等。Q红包_9.jpg
B.对账和补充交付解决了许多问题:
传送失败是不可避免的，网络波动/播放器传送接口失败等问题可能导致呼叫传送接口失败。在同步收集环境中，用户可以通过重试在一定程度上解决这个问题。但是，对于异步交付，如果用户点击收集后，交付请求被{4.1 AMS外部网络交付新OP}放入MQ，即使游戏的实际交付界面在后台没有被实际接收到，用户也不会觉得不能再试，而是会抱怨。后台交付系统必须通过其自身的容错能力确保即使游戏方的交付界面不稳定并且偶尔出现故障，用户收到的礼包也能最终到达。这里，我们使用调节和补充方案。
对账:用户接收礼包调用的界面{4.1 AMS外部网络交付新OP}成功写入到期交付流程，而{4.3 AMS内部网络交付OP}调用玩家交付界面的真实交付流程。由于有些消息会在消息队列中累积，这部分称为队列累积流。因此，实际需要补充的自来水可以通过以下公式获得:
重新发出流失败=应有流-实际流-队列累积流。
由于订单号的存在，可以保证同一个投递请求不会重复发送，并且预先在队列中累积的消息的重发操作不会导致多次发生。因此，当队列中的累积流较少时，使用到期流和实际流之间的差异集作为失败重新发布流是合理的，但是在每个协调周期中，队列中累积的消息将被发送两次，这将导致性能的轻微损失。
在后台，增量调节功能每小时运行一次。如果检测到MQ消息的累积量低于某个阈值，将执行调节操作，并且将截取从上次调节到此时的到期/实际流量，并通过减去它们来获得重新发布的流量。
补货:根据对账操作获得的补发流程，调用游戏方的发货接口进行发货补货操作。
社交软件红包解密技术(9):谈功能逻辑、容灾、运维、架构等。Q红包_10.jpg
C.解决高价值道具防刷问题的安全攻击:
所有领奖请求都需要带来一个登录状态来验证用户，同时对高价值道具发起安全攻击，并向安全中心报告以供恶意用户验证，以防止被恶意用户刷走。
社交软件红包解密技术(9):谈功能逻辑、容灾、运维、架构等。Q红包_11.jpg
D.解决内部员工防盗问题的权限控制:
必须为装运的机器安装铁将军。用户需要使用RTX名称和令牌登录机器，并审核用户在机器上的操作行为；
传递模块需要对调用者进行严格的授权，调用者需要申请一个密钥，其中包括程序路径、程序MD5、部署模块等信息。，以确保传递函数不会被任意调用。
社交软件红包解密技术(9):谈功能逻辑、容灾、运维、架构等。Q红包_12.jpg
6.4。监控需求发展
核心问题:红包涉及多个系统的自有监控，数据收集困难
监控有两个主要要求:
1)我们的外部服务正常吗？如果有问题，如何快速找到并分析？
2)实时了解用户在整个系统中的行为漏斗模型，每一步的转化率是多少？
游戏红包涉及许多合作伙伴，如红包基地、商务前台、商务后台、/AMS/MQ平台等。每个系统都有自己的监控系统，并且数据源不一致。在活动当天逐个收集系统效率太低。
社交软件红包解密技术(9):谈功能逻辑、容灾、运维、架构等。Q红包_13.jpg
(注意:因为这张图片又大又清晰，请下载13张(清晰又大)。zip (855.33 KB，下载次数:1次)来自此附件)
解决方案:将每个系统的关键数据汇总到一个视图中
红包作为一个包含多个子系统的聚合系统，需要一个汇总各子系统关键数据的全局视图，这样才能全面监控核心业务指标，全面控制系统和业务，避免在监控系统中跳过搜索所消耗的有限时间，为快速响应和解决问题提供保障。
接口封装:尽管红包中涉及的多个子系统都有自己的报告方法和监控系统，但大多数关键数据都是通过HTTP查询接口提供的。通过封装，我们将接口的定义统一为键值的形式，以(监控项目id、开始时间、结束时间)为键，以值为(开始时间、结束时间)段中监控id值的总和。
配置:可以通过在一段时间内添加几个监控项目来定义对红包活动的监控。例如，刷一个红包，时间周期是从除夕的20: 00到20: 30，监控的项目是几页的点击、几个礼品包的分发、几个后台接口的请求、几个MQ的累积等等。
通过封装和配置接口，增加了一个红包活动，只需要增加一个时间段和几个监控项目的配置文件。例如，下图中的AR/画笔-画笔混合字段/画笔-画笔特殊会话通过三个配置文件定义了三个活动，添加一个活动只需添加一个配置文件，可以在一个视图上灵活切换，非常方便。
社交软件红包解密技术(9):谈功能逻辑、容灾、运维、架构等。Q红包_14.jpg
从上图中，我们可以实时看到实际交付和到期交付大致相等，队列没有累积，各级页面的用户转化率可以很容易地判断系统的健康状态和分析定位问题。
七.系统保证
第六部分讨论了业务需求的开发，但是在功能开发完成后，我们能不能把它放到网上安静地睡觉呢？
如果机器的一部分甚至整个机房都挂断了，服务是否可用？
外部服务突然失败，例如，MQ突然挂起，不能写消息。有服务吗？
假设在红包入口处是8W/s，但是如果是20W/s呢？系统会失败吗？有服务吗？
让我们从系统容灾/过载保护/灵活可用性/立体监控方面谈谈我们在这方面所做的一些工作。除夕夜出现各种问题时，系统仍能正常运行，用户也能正常体验服务，我们的信心从何而来？
7.1。系统容灾
容灾是指当整体服务的一部分出现异常时，另一部分可以被覆盖，不影响整体服务的使用，保证服务可用性和数据安全性。然而，容灾设计会增加系统的复杂性，增加成本和费用，并需要额外的费用和资源，因此容灾应考虑在合理的范围内。
容灾等级一般分为多机容灾、多机房容灾和多站点容灾。红包的后台服务主要利用普通组件的均衡负载和系统的容灾能力。该服务没有单点问题，部署在同一个地方，按照多机房容灾标准设计。
7.1.1接入层:
典型的GSLB+TGW+QZHTTP访问，GSLB解析域名，将请求带到最近的国际数据中心TGW访问机，TGW将请求转发到QZHTTP服务器，后者通过内部网专用线路实际提供网络服务。
gslb:global server load balance的缩写，意思是全局负载平衡，主要为域名解析提供附近的访问和流量调度。实现广域网(包括互联网)上不同区域的服务器之间的流量分配，保证离你最近的最佳客户服务器服务，从而保证接入质量；它综合判断服务器和链接，决定哪个服务器在哪个地方提供服务，从而保证不同地方的服务器群的服务质量。红包使用独立的sh.vip.hongbao.qq.com域名。
TGW:腾讯网关是一个实现多网络统一接入并支持自动负载平衡的系统。TGW通过内部网络隧道将外部网络中不同运营商的请求转发给服务器。当服务器返回数据时，它通过内部网络隧道将数据返回给TGW，然后通过tgw将数据发送给不同的运营商。红包TGW外网部署了上海电信联通双贵宾+香港CAP贵宾。
Qz HTTP: web服务器，负责将HTTP请求转换成逻辑层使用的WUP协议，部署在同一位置的多个机房中。量子HTTP是TGW的卫星。TGW将定期探测遥感器的状态，在一分钟内自动将故障遥感器从可用列表中剔除，并在TGW检测到遥感器恢复正常后自动将其添加回可用列表。TGW提供负载平衡和容灾。
7.1.2逻辑层:
逻辑层由SPP容器开发，礼品包列表/服务选择/礼品包交付三个功能为无状态服务。如果服务能力足够，随意启动一些服务器不会影响正常服务。L5用于负载平衡/容灾/过载保护。
L5:机器级容灾:业务程序调用L5应用编程接口从L5代理获取后台服务器的(IP，端口)，并使用(IP，端口)对应的后台服务器进行通信。访问完成后，调用L5应用编程接口报告访问接口和处理延迟。L5代理计数并报告L5应用编程接口报告的访问结果和处理延迟。当服务器出现故障时，L5将在1到2分钟内自动排除故障服务器。
7.1.3数据层:
CMEM作为K-V存储和火箭MQ作为分布式消息队列主要用于数据层。这两种服务分为访问层和存储层。L5用于访问数据层的逻辑层的访问层的负载平衡/容灾，而数据层的存储层采用一主一备两热备的容灾方式。该着陆盘支持在断电重启后重建存储器数据，并且支持多机容灾，但是不支持多机房容灾。
社交软件红包解密技术(9):谈功能逻辑、容灾、运维、架构等。Q红包_1.jpg
7.2、过载保护
红包入口处的流速据说是8W/s。如果底部有问题，达到20W/s怎么办？
每个模块的容量通过根据用户行为漏斗模型计算入口流量的转换率来设计。如果评估是错误的，并且转化率超过了设计能力，该怎么办？
过载保护方法应适用于可能超出设计容量的流量峰值，以确保系统可以拒绝一些超出容量的请求，并确保设计容量内的请求能够正常响应。
实施时要注意四点:
1)减少来自源的无效请求；
2)进入层的垃圾；
3)各层互不信任；
4)照顾用户的情绪。
7.2.1流量预加载:
CDN是页面访问的关键路径，离线包在首页制作并提前交付给客户，从而降低了CDN在除夕的流量压力。
7.2.2频率限制:
前台限制用户发起请求的频率，超过该频率的请求会提示用户不去后台就失败(仅允许请求每5秒去后台一次)，前台保护后台。
后台访问层根据压力测试数据配置每分钟CGI接口接受的请求数，丢弃超出接口处理能力的请求并发出警报。访问网守系统，配置IP/uin/refer和其他规则来限制恶意用户的刷请求，并确保服务的正常运行。
7.2.3下降开关:
前台调用后台接口，设置交换机以一定概率丢弃请求，提示用户在关键路径返回错误时稍后重试，并为非关键路径提供降级体验。结合频率限制功能，可以限制从前景到背景的流量比例。当比率设置为0时，模块关闭以保护背景。
7.2.4队列堆叠和丢弃:
后台逻辑层使用SPP框架。在处理消息之前，工作人员检查SPP消息队列中消息的等待时间是否超过预设阈值(500ms)。队列中累积时间过长的消息的前端已超时，这对用户来说毫无意义。该服务丢弃该请求，并发出警报以防止队列过载雪崩。
社交软件红包解密技术(9):谈功能逻辑、容灾、运维、架构等。Q红包_2.jpg
7.3、灵活性是可用的
灵活性是可用的。灵活性是为了保护系统，确保整个系统的稳定性和可用性。可供用户使用，尽最大努力为用户提供高质量的体验(也许是服务体验的一部分)。一个是从系统本身的角度，另一个是从用户的角度。只有在实际的实施过程中对二者进行分析和整合，系统才能真正的灵活和可用。关键问题是识别用户的核心需求，找出满足需求场景的核心需求作为关键路径，异常情况下可以放弃的需求作为非关键路径。
7.3.1识别用户的核心需求:
春节游戏红包用户有三个核心需求:
1)查看礼品包装清单；
2)选择区域服务的角色；
3)收到礼包。
另一些可以用作非关键路径，一些可以改善用户体验，没有一个会影响用户的核心需求。
7.3.2确保关键路径的可用性:
参见礼品包列表:作为页面的关键模块，在红包活动之前，十种游戏的礼品包内容已经通过离线包/CDN作为前端静态数据提前分发。在红包活动期间，后端界面仅提供前端包内容，用于根据用户偏好返回的游戏包列表进行过滤和排序。如果失败，也有一个前端默认游戏包列表，用户仍然可以看到包列表，但排序不够智能。
选择区域服务角色:除夕前一周，在游戏中心的主页和操作活动中增加一个后台界面请求，请求用户的区域服务角色信息提前在本地缓存，这不仅减少了除夕区域服务界面的请求量，也保证了游戏中心核心用户的区域服务信息的有效性。
接收礼包:RockemQ是接收操作的关键路径服务，用户需要编写RockemQ才能在收到礼包后成功。因此，业务部门已经在逻辑级别对消息队列进行了容灾。当RockemQ失败时，容灾开关可以打开，在写入调度流程后，接收操作将直接成功返回，而不是将消息写入RockemQ，而是采用分时协调的方法，而不是实时传递，实现消息队列的容灾效果。见6.3。容错需求的开发。
7.3.3放弃异常非关键路径:
前端页面显示模块性，隐藏未能请求数据的非关键模块；
红包页面被转移到游戏中心。游戏中心显示根据红点逻辑显示。仅显示文件夹上方的数据。默认情况下，不加载第二个屏幕数据。当用户向下滚动时，它将被再次加载。牺牲用户向下滚动将暂时减少干扰的体验。在后台请求压力；
当后台读取算法界面无法返回推荐排序时，使用默认的包排序；
当在后台读取CMEM界面返回的包时，默认情况下每个游戏都会返回一个低值的拉式激活包。
社交软件红包解密技术(9):谈功能逻辑、容灾、运维、架构等。Q红包_3.jpg
7.4、立体监控
“我们向外界提供的服务正常吗？如何证明我们的服务没有问题？”，是监控报警首先要回答的基本问题。有效的监控报警需要确保业务指标能够被完全监控，当发现问题时，能够有效地通知责任人，帮助分析问题。重点是“完整性”和“有效通知”，两者都是不可或缺的。春节红包监控报警从用户、业务和机器三个层面进行描述。
7.4.1用户级别:
从用户的角度监控系统是否存在问题，模拟用户从系统外部发起请求的行为，判断请求结果和延迟是否符合预期。使用ATT自动化用例。
ATT，自动测试，是一个由社会和开放平台测试组使用的测试管理工具，它是一个功能用例和自动用例管理的平台。通过模拟真实的用户访问、验证返回的数据、确认访问延迟和功能正确性，用户级监控手段可以从业务侧实现监控功能的正常运行状态。
7.4.2业务级别:
监控红包系统中各子业务模块是否正常运行可分为两种类型:
A.模块间调用监控:监控系统中模块间的调用是否正常，并使用模式调整系统。
B.模块中的状态监控:使用每个子系统构建的监控和报警系统，监控业务模块的当前状态是否正常。
春节红包的监控主要有两个方面:AMS礼包的剩余数量和消息队列中消息的累积数量。春节红包没有引起恐慌，因为准备的包裹数量足够了；因为队列生成速度远远超过消耗速度，所以设置的警报阈值为100瓦，但实际最终累积超过1200瓦，这将导致警报。
社交软件红包解密技术(9):谈功能逻辑、容灾、运维、架构等。Q红包_44.jpg
7.4.3机器级别:
网络管理系统用于监控机器的中央处理器/内存/磁盘/网络是否正常。
网络管理系统(TNM2)是一个非常强大的监控系统，用于收集服务器的中央处理器、内存、网络、输入输出等指标。它还可以对设备的异常进程和端口、磁盘利用率、硬件故障等进行报警。，并为外部系统提供丰富的调用接口。有关网络管理系统的监控能力，请参阅其网站主页上的TMP监控能力白皮书。
社交软件红包解密技术(9):谈功能逻辑、容灾、运维、架构等。Q红包_4.jpg
八.练习的验证
锻炼是一种将被动反应转化为主动服务的手段。演习前，设定演习目标和方法，演习期间核实和收集数据，演习后总结和提出改进计划。通过练习，我们可以实际验证用户的行为是否符合评估期望(灰色练习)，系统各模块的容量是否满足期望(压力测试练习)，各种容灾和灵活措施是否有效(异常练习)，并提前发现架构中的问题。
8.1。灰色练习
核心问题:实际的用户行为与评估预期一致吗
众所周知，游戏红包的入口流量被设置为最大80k/s。红包系统中每个模块需要支持的流量是多少？每个模块应该部署多少台机器来支持多少流量？这包括对用户行为的评估和每个模块的转换率？
解决方案:现有网络的灰色用户收集数据进行验证
用户验证游戏红包中现有网络的一部分灰度，并收集数据修正评估模型。
结果如下:
A.门票到游戏包列表页面的转化率估计为60%，但实际值为59%，评价与实际值相当接近；
B.服务组件数据的前端有一个缓存。评估请求缓存的命中率为60%，请求与后台的比例为40%，但实际比例为45%。评价与实际相当接近；
C.游戏包列表页上有10个游戏，每个用户平均会收到2个包，实际上是0.23个包，这与实际的有很大的不同。
社交软件红包解密技术(9):谈功能逻辑、容灾、运维、架构等。Q红包_5.jpg
从以上三个界面的流量评估来看，我们的开发和基于以往经验的产品所评估的大部分用户行为数据都比较接近实际情况，但是一些没有得到很好评估的界面的灰色数据与评估预期相差很大。根据灰色数据，我们再次修改了评估模型和模块容量设计，大大节省了接收接口的机器。活动当天的数据与从灰度获得的数据几乎相同，这也证明了灰度验证方法的准确性和可靠性。
8.2。压力测试练习
核心问题:系统能承受压力吗
细分可以分为两个问题:
A.系统能否正常处理系统容量内的合理请求；
b .系统是否能成功丢弃超出系统容量的多余请求。
]解决方案:全环节压力测试和单模块压力测试
在最理想的情况下，首先对红包的各个模块进行压缩测试没有问题，然后灰度用户利用当前的网络流量进入红包系统进行全链路压缩测试。但是，由于在使用当前网络流量进行练习时需要实际发送红包，成本较高，灰度500万用户的红包入口峰值仅为5k/s，远低于设计的80k/s，因此，系统的压力测试验证主要是通过单模块压力测试结合灰色练习获得的用户行为数据来评估系统的整体性能。
A.对于接口不在线的CGI服务器和SPP服务器，使用ApachBenchmark模拟请求压力测试；
B.在线接口方面，除了隔离现有的网络机，使用ApachBenchmark模拟和请求压力测量外，还使用了集团开发的压力测量系统，通过调整L5的重量，将现有的网络流量逐步引向压力测量机。
社交软件红包解密技术(9):谈功能逻辑、容灾、运维、架构等。Q红包_6.jpg
经验证，在V8机器上，包列表/区域服务接口CGI/服务器的QPS在5k/s到8k/s之间，包接收接口的QPS达到2k/s，部署足够的机器后，系统的80k/s请求可以正常处理。
在配置接入层CGI的限速选项后，超过限速(8k/s)的超额请求将由CGI直接返回，而不传递给后端进行处理；在配置了逻辑层SPP的超时丢弃之后，堆积在队列中超过超时时间(500ms)的堆积请求将被框架丢弃，而不进行实际处理。对于超出系统容量的请求，系统可以成功丢弃它们。
8.3。异常运动
核心问题:当系统异常时，各种灵活的逻辑/灾难恢复措施能否生效
系统中的灵活/容灾措施通常只有在系统异常时才会生效，这导致在实际的现有网络服务操作中无法测试灵活逻辑，并且容灾措施通常不能启用。因此，当操作环境确实异常时，仍然不知道灵活的逻辑/灾难恢复措施是否有效。
解决方案:验证灵活的逻辑和灾难恢复措施
在红包正式推出之前，通过模拟真实的异常故障场景，列出可能出现的关键故障问题，验证灵活的逻辑和容灾错误是否真实有效。
A.后台SPP将神盾的L5修改为错误的L5，并且SPP错误地调用神盾。预计后台仍然可以根据默认订单返回礼品包列表。
B.背景SPP将CMEM的L5修改为错误的L5，SPP打电话给CMEM时出错。预计后台仍然可以根据所有游戏推荐拉活动的礼品包，并返回礼品包列表。
C.SPP在后台随机停止，CGI在调用SPP时出错，预计服务将在短时间内部分失败。L5可在1~2分钟内启动错误的机器，服务将恢复正常。
d、打开MQ容灾开关，用户接收到的成功消息不会被放入MQ，而是由流水直接检查，期待游戏被成功接收。
E.前台用户的操作频率超过限制(5次/秒)，预计前台会直接返回取货，抓取包裹后请求不会返回后台。
F.前台通过设置主机调用后台接口指向错误的IP，前台调用后台推荐接口出错。预计首页仍然可以正确地将包列表显示为关键路径。
G.前台通过设置主机调用后台接口指向错误的IP，前台调用后台非关键信息接口出错，因此预期的首页隐藏非关键模块。
经学生测试，核对表中灵活的逻辑和灾难恢复措施准确有效，符合预期。
