mPaaS简介
服务端总体架构图
移动网关服务MGS**
移动网关服务(简称MGS)是连接移动客户端与服务端的此组件产品,简化了移动端与服务端的数据协议和通信协议,从而能够显著提升开发效率和网络通讯效率。网关是连接客户端和服务端的桥梁使客户端来通过网关来访问后端的接口
使用mPaaS网关有以下优点:
1. 简单配置即可识别多种终端连接异构的后端服务
2. 自动的生成移动端sdk实现前后端的分离提高开发效率
3. 是可以支付服务注册发现与管控实现服务聚合与集成降低管理成本和安全风险
4. 是提供优化后的数据协议与通信协议提高网络通信质量和效率
MGS支持
·API注册
·API配置
·API限流
·API授权
·API模拟
·API缓存
·API测试
·API分析
·数据加密
MGS架构图
MGS是mPaaS中和APP业务关系最密切的服务,为了最大化可用性,有如下保障措施:
1. mgs要求至少两个实例保证最基本的高可用
2. mgs进程有守护进程,假设mgs进程意外崩溃,可以马上拉起
3. mgs运行时不依赖数据库,因此即使数据库出问题,mgs依然可以正常服务
· MGS的管控聚合在mAppcenter控制台上,页面上的请求都会经mAppcenter里的nginx路由
· 当有配置变更时,除了会写入数据库,还会通过动态配置服务进行推送,实时更新内存中的数据
· mPaaS其他组件的rpc服务也会通过MGS暴露
· 容量估算,一个4C8G的MGS实例可以支撑:
1. 数据加密场景:ECC 1700/tps、国密1000/tps、RSA 300/tps
2. 数据不加密场景:5000/tps
MGS**日常运维 -核心态监控**
资源使用情况 | |||||
---|---|---|---|---|---|
• CPU/内存/硬盘 < 90% • 负载情况 load5 < 取整(实例core个数 2 80%),比如实例是4C,那么阀值为6 • 端口:80,12200,8081 |
|||||
应用运行情况 | ||||||
---|---|---|---|---|---|---|
主要基于API摘要日志home/admin/logs/gateway/gateway-page-digest.log进行相关统计 • 网关秒级QPS -对列值求行数,统计整个mgs集群的秒级qps总和 • API秒级QPS - 网关秒级QPS,按照operationType、appid、workspaceId进行分组统计 • API错误监控 – 统计结果码非1000求行数 • API耗时_秒级 – 耗时时间取平均值 • 金融云网关大盘 - 网关运行大盘,包含网关QPS、网关错误、网关RT、API统计、CPU/内存/磁盘等核心关键监控项,可作为日常巡检、压测、变更查看项 |
||||||
MGS**日常运维 - 常见操作**
应用重启 | ||
---|---|---|
• 场景: 容器异常、应用卡死等 • 操作步骤:通过Local云游 -产品运维找到MGS产品 - mpaasgw应用,选择对应容器创建重启运维单; |
||
应用扩容 | |||
---|---|---|---|
• 场景: 性能不足、重大活动等 • 操作步骤:通过Local云游 - 产品运维找到MGS产品 - mpaasgw应用,点击应用扩容(ps:阿里云底座下需要先扩容ecs,并且需要考虑新机器到后端业务服务器的网络连通性) |
|||
应用升级 | ||
---|---|---|
• 场景: BUG FIX、客户需求 • 操作步骤:参考MGS通用升级方案 |
||
问题排查 | |||
---|---|---|---|
•按照网关结果码分析 – 网关结果码链接 •按照traceid到目标网关服务器中查找日志 – 链接 •根据其他关键字在网关集群中查找日志 – 链接 |
|||
实时发布服务MDS
MDS架构图
MDS重要知识点 | |||||
---|---|---|---|---|---|
• MDS有三个资源请求路径,分别如下: 1.资源检查,手机端通过rpc请求访问由MGS暴露的MDS服务,检查是否有资源更新 2.资源上传,各种资源包的上传,都通过mAppcenter路由到mcube,并最终存入对象存储中 3.资源下载,所有资源包的下载路径都由mdsweb暴露,下载路径会在上传时由mcube生成 • • MDS的管控聚合在mAppcenter控制台上,页面上的请求都会经mAppcenter里的nginx路由 • • 当有配置变更时,直接先写入数据库,然后定时刷新到内存中 • • 灰度发布时的白名单等信息会从缓存中读取 • • 容量估算,1个4C8G实例: 1.mcube:RPC 3000 QPS 2.mdsweb: 100M的包同时15个线程下载,额外还需考虑带宽情况 |
|||||
MDS日常运维 - 核心态监控
资源使用情况 | ||
---|---|---|
• CPU/内存/硬盘 < 90% • 负载情况 load5 < 取整(实例core个数 2 80%),比如实例是4C,那么阀值为6 • 端口:MCUBE:80,12200,7001 MDSWEB:80,12200,7001 |
||
应用运行情况 | |||
---|---|---|---|
有发布时重点关注: | |||
• mcube API调用量 | • 升级请求量 | 升级时间窗灰度人数统计 | |
• mcube API耗时 | • 热修复请求量 | 热修复时间窗弧度人数统计 | |
• mdsweb请求量 | • 离线包请求量 | 离线包时间窗灰度人数统计 |
MDS日常运维 - 常见操作
应用重启 | ||
---|---|---|
• 场景: 容器异常、应用卡死、进程oom等 • 操作步骤:通过Local云游 -产品运维找到对应产品,选择对应容器创建重启运维单; |
||
应用扩容 | ||
---|---|---|
• 场景: 性能不足、重大活动等 • 操作步骤:通过Local云游 - 产品运维找到对应产品,选择对应应用,点击应用扩容(ps:阿里云底座下需要先扩容ECS) |
||
应用升级 | ||
---|---|---|
• 场景: BUG FIX、客户需求 • 操作步骤:参考MCUBE通用升级方案、MDSWEB通用升级方案 |
||
问题排查 | |||
---|---|---|---|
• 热修复请求: mcube-dynamicResource.log • 离线包请求: mcube-nebula-dynamicResource.log • 升级请求: mcube-upgrade.log • 时间窗灰度:mcube-timeAndList-count.log |
• 白名单灰度:mcube-whitelist-monitor.log • 资源上传:mcube-web.log • 升级详情:mcube-upgrade-data.log |
||
消息推送服务MPS
MPS架构图
MPS重点知识点
| • MPS针对不同手机厂商有不同的推送方式,分为以下两种:
1.三方推送,目前主要针对苹果,华为和小米手机,走厂商自己的渠道进行推送
2.直接推送,主要针对国内安卓手机,由mcometgw与手机直接建立TCP长链接进行推送
• 消息推送最终都是通过设备标识进行推送,因此如果需要用户维度的推送,要在用户登陆时将用户和设备进行绑定,当用户登出时,再将该绑定关系解绑。
• 缓存中保存客户端链接信息
• 苹果,小米,华为的推送因为走他们自己的渠道,因此需要在控制台上进行对应的接入配置。苹果需要特别注意选择正确的证书,很容易混淆开发和生产
• 容量估算,1个4C8G实例
1.mcometgw:自建渠道连接建立 10W
2.yunpushcore:简单消息推送 300/tps ,第三方渠道下发 150/tps | | |
| —- | —- | —- |
|
|
MPS日常运维 - 核心态监控
资源使用情况 | ||
---|---|---|
• CPU/内存/硬盘 < 90% • 负载情况 load5 < 取整(实例core个数 2 80%),比如实例是4C,那么阀值为6 • 端口:yunpushcore:80,12200(sofa)/20880(dubbo); mcometgw:8000 |
||
应用运行情况 | ||
---|---|---|
有发布时重点关注: | ||
ISO推送监控 | 待发消息秒级监控 | 消息回执监控 |
华为渠道推送监控 | mcometgw长链接总量 | 无绑定关系推送监控 |
小米渠道推送监控 | mcometgw推送监控 |
MPS日常运维 - 常见操作
应用重启 | ||
---|---|---|
• 场景: 容器异常、应用卡死、进程oom等 • 操作步骤:通过Local云游 -产品运维找到对应产品,选择对应容器创建重启运维单; |
||
应用扩容 | ||
---|---|---|
• 场景: 性能不足、重大活动等 • 操作步骤:参考MPS通用扩容方案(ps:阿里云底座下需要先扩容ECS) |
||
应用升级 | ||
---|---|---|
• 场景: BUG FIX、客户需求 • 操作步骤:参考MPS通用升级方案 |
||
问题排查 | ||
---|---|---|
• 推送问题主要查看yunpushcore的日志: grep ‘xxxxx’ /home/admin/logs/yunpushcore/.log • 如果是长链接建链问题查看mcometgw的日志:grep ‘xxxxx’ /home/admin/mcometgw/logs/.log • 一般可以建议通过msgid进行日志搜索查询 |
||
MSS功能
MSS重要知识点
· MSS主要有以下使用场景: | ||
---|---|---|
1.手机终端 APP 之间社交通信 2.动态配置信息全设备推送 3.数据在线推送到手机终端 APP |
• MSS的管控聚合在mAppcenter控制台上,页面上的请求都会经mAppcenter里的nginx路由
• 缓存中保存客户端链接信息
• 多设备同步表示支持单个用户的多个设备之间的数据同步,即同一个用户在切换设备的情况下仍然会收到在上一个设备上已经收到过的数据
• 容量估计,一个4C8G的MSS实例:
1.用户在线,消息入库并下发 200/tps2.用户不在线,消息仅入库 400/tps | | |
|
MSS日常运维 - 核心态监控
资源使用情况 | ||
---|---|---|
• CPU/内存/硬盘 < 90% • 负载情况 load5 < 取整(实例core个数 2 80%),比如实例是4C,那么阀值为6 • 端口:msync2 80,12200,8666,7001 |
||
应用运行情况 | ||
---|---|---|
有数据同步时重点关注: | ||
• msync连接监控_连接总数 | • 推送量到达量 | |
• 建连断连监控 | • msync_数据写入总量 | |
• init_state监控 | • 链接时长 |
MSS日常运维 - 常见操作
应用重启 | ||
---|---|---|
• 场景: 容器异常、应用卡死、进程oom等 • 操作步骤:通过Local云游 -产品运维找到对应产品,选择对应容器创建重启运维单; |
||
应用扩展 | ||
---|---|---|
• 场景: 性能不足、重大活动等 • 操作步骤:参考MSS通用扩容方案(ps:阿里云底座下需要先扩容ECS) |
||
应用升级 | ||
---|---|---|
• 场景: BUG FIX、客户需求 • 操作步骤:参考MSS通用升级方案 |
||
问题排查 | ||
---|---|---|
主要看以下两个日志: | ||
• 同步到客户端:/home/admin/logs/msync/mobilesync-sync.log • 业务推送:/home/admin/logs/msync/mobilesync-sync-data.log |
MAS功能
MAS架构 - AntStack底座
MAS架构 - 阿里云底座
MAS重要知识点
| • 实时数据包括:
1.基础大盘:报活,启动速度,hot页面等
2.性能分析:闪退,卡顿,卡死
3.组件分析:热修复
• 离线数据包括:
1.行为分析
2.留存分析
3.页面分析
• MAS的管控聚合在mAppcenter控制台上,页面上的请求都会经mAppcenter里的nginx路由
• 原始日志表,如果阿里云底座存在odps中,antstack底座则是hdfs
• 容量估算,主要考虑日志存储量,300万用户,日活15万,投递速度500 QPS,存储10天需要存储空间1.2T | | | | —- | —- | —- | | |
MAS**日常运维 -核心态监控**
资源使用情况 | ||
---|---|---|
• CPU/内存/硬盘 < 90% • 负载情况 load5 < 取整(实例core个数 2 80%),比如实例是4C,那么阈值为6 |
||
• 端口: | ||
• masweb:80,7001 • mdap:80,7001 • mesdb:4200 |
• explorer:8047,9090 • zk: 2181 • kafka 9092 |
应用运行情况 | ||
---|---|---|
• 查看移动分析页面数据是否正常展示 • flume错误 • 日志投放量 |
||
MAS日常运维 - 常见操作
应用重启 | ||
---|---|---|
• 场景: 容器异常、应用卡死、进程oom等 • 操作步骤:通过Local云游 -产品运维找到对应产品,选择对应容器创建重启运维单; |
||
应用扩容 | ||
---|---|---|
• 场景: 性能不足、重大活动等 • 操作步骤:参考MAS通用扩容方案(ps:阿里云底座下需要先扩容ECS) |
||
应用升级 | ||
---|---|---|
• 场景: BUG FIX、客户需求 • 操作步骤:参考MAS通用升级方案 |
||
问题排查 | ||
---|---|---|
• 主要看mdap的日志投递情况: /home/admin/logs/mdap/ 下不同日志类型对应到不同的日志文件 |