1.1 常见问题
1.1.1 RPC报错排查
1．客户端抓包
客户端抓包一般采用Charles或 Fiddler 工具，通过抓包工具，可以看到 RPC 请求的一些关键数据。然后通过抓包数据获取到 TraceId ，通过TraceId查询 MGS 日志。如图1-1所示。
图1‑1 抓包效果
2．常见错误码
（1）1000 为 API 调用成功，其他都是失败的错误码。
（2）1001-5999、7XXX 为网关错误。其中，7XXX 表示无线保镖验签或解密报错，请参考无线保镖结果码说明进行排查。除结果码外，您还可以查看响应 Header 中的 Memo 和 tips 字段，以了解更多错误信息。
1.1.2 安全机制
MGS通过加签机制和加密机制实现了数据通信的防伪造和防窃取特性，实现细节介绍如下。
1.防伪造
通过无线保镖机制来实现防止网络请求被篡改，验证请求合法性。无线保镖是一套保障移动平台应用完整性、应用执行环境可信性、数据机密性的专业完整的安全解决方案。无线保镖有如下特性:
（1）使用无线保镖SDK的加签，加密功能需要依赖加密图片。
（2）无线保镖不分配任何秘钥，三方加密图片的所有秘钥均由接入方自定义，只需按照规定传参即可。
（3）Android和iOS的加密图片都是和应用绑定的加密图片，加密图片根据用户App信息绑定生成。
整体实现机制如图3-7所示，流程如下：
（1）当在mPaaS控制台创建应用时，移动网关为每个应用随机生成一个唯一的加盐值。
（2）客户端根据Bundle ID或RSA证书，调用无线保镖安全黑匣子算法将加盐值保存安全图片里，无线保镖安全黑匣子可以保证图片中的信息不被窃取。
（3）客户端根据该次请求的数据内容进行乱序，添加时间因子后以安全图片中的加盐值进行加盐，并进行签名，将该签名与请求内容一起发送到移动网关。
（4）服务端使用收到改此次请求后，以相同的加盐值按同样规则计算签名。
（5）移动网关会对客户端带上的签名和上一步算出的签名进行比对，验证是否相等，来校验请求的合法性。
图1‑2 无线保镖签名机制
2.防窃取
对网络请求内容进行加密，如图1-3所示。流程如下：
（1）使用openssl工具生成一对非对称加密算法的公私钥，私钥保存在移动网关，公钥保存在客户端本地；
（2）客户端每次RPC请求生成一个新的对称密钥
（3）客户端使用公钥对对称密钥进行加密，得到加密后的SecKey
（4）同时客户端使用对称密钥对原始数据进行加密，得到加密的数据SecData
（5）将加密后的SecKey和SecData发送到移动网关
（6）移动网关使用私钥对接收到的SecKey进行解密并计算，得到对称密钥
（7）移动网关使用上一步解密得到的对称密钥，对接收到的加密数据SecData进行解密，得到原始数据。
通过以上的混合加密机制，既利用了非对称加密的安全性，也很好的结合了对称加密的高性能，实现了安全和性能的平衡。
图1‑3 安全加密机制
1.1.3 MGS压测
1.背景
随着越来越多的金融行业基于mPaas搭建并上线新的App，App整体架构的负载能力，各个环节的优化逐步成为各个客户关注的重点，尤其是作为连接服务端和客户端的MGS组件的性能，成为关注的重点。可以通过对MGS进行全链路的压力测试，来测试业务的负荷瓶颈，评估整体架构性能，排查出各节点的薄弱关系，从而优化系统资源，避免短板效应，同时也可以为后期上线提供准确的用户承载量作为限流数据支撑，避免新应用上线带来的突发流量导致系统异常。
2.链路梳理
通常我们可以简单的把负载性能=单机性能*机器总量这一公式套用到预估的方案中，但是在实际的场景下，常常会涉及到大量的业务节点，如防火墙，网关，数据库等环节，都有可能是导致整体业务性能的瓶颈，因而实际服务能力可能与预期存在较大误差。因此，如何基于MGS实现全链路的压测，成为客户压测方案关注的重点。
区别于以往的测试方案，全链路压测方案中最大的不同是视角上的不同，站在客户端角度上作为切入点，将整个服务端链路作为一个黑盒，以真实的request和response作为评估的依据，模拟真实的业务请求，真实的数据流量，真实的用户习惯，来达到得出尽可能真实的评估结果。
1) 请求阶段
如图1-4所示，是一个标准的MGS数据链路模型。而在全链路压测中，我们把整体的服务端实现视为一个黑盒，因而我们所需关注的焦点聚焦在前半段，重点可以概括为:
（1）客户端请求构建；
（2）客户端请求发送并通过MGS网关；
（3）客户端解析MGS网关返回的response并做出正确处理；
（4）实现高并发的客户端请求集群。
图1‑4 MGS通信链路模型
2) 链路实现
(1) 客户端请求构建
MGS移动网关RPC通讯是在HTTP协议基础之上的实现的一种标准化接口方式，在复用HTTP请求标准的前提下，定义了一套数据交换格式，采用Header，Body作为实际区分，可以近似理解为，通过Header中的Operation-Type做为真实api指向，将body部分依据规则封装后进行转发。在该步骤中，我们以JMeter作为实现方案，Jmeter灵活的脚本特性可以良好的实现客户端的真实请求模拟。
(2) 压测集群环境部署
对于压测来说，需要的重点侧重于真实，真实的流量入口，真实的并发数量，才能得出真实的结果，而自行实现压测环境，高昂的集群部署费用，也成了不必要的开支，因而我们推荐用户采用阿里云PTS作为压测平台，基于其他方案，具有部署简易，支持jmeter脚本，流量真实等优势，也可为用户提供更为详实的压测报告。
如图1-5所示，以上模型简单可以归纳为以下结构。
图1‑5 MGS压测模型
3.性能数据
MGS作为连接App和后端的网关服务，性能显得尤为重要。如图1-6所示，为单台资源规格为4C8G容器的在实验室环境下发送hello world报文测试的MGS性能指标参数，可以用做日常性能指标参考。但是由于实际的性能指标受报文大小，网络带宽，后端性能等全链路很多因素制约，所以如果需要真实现场环境性能指标数据，最好通过实际压测获取。
图1‑6 性能数据介绍
1.1.4 MGS更换秘钥
1.背景
因当前国家信息安全监管总局对金融类App监管要求，涉及到数据安全通信加密算法必须要使用国密的规定。众多使用mPaaS的金融客户，因早期大多数都是在网关配置的RSA加密或者ECC加密算法，当接到监管要求后，都要更改网关加密算法为国密。MGS目前已经具备了同时兼容多个加密方式的功能，解决了客户侧因更换加密算法造成的种种不便和问题。以下分别对控制台网关配置和客户端配置，整理更换加密算法方案。
2.服务端配置
打开移动开发平台->移动网关->网关管理。当前网关已经开启了数据加密。如图1-7所示，这里示例是RSA）。
图1‑7 秘钥配置介绍
这时更换国密，需要提前准备一对已生成的SM2公、私钥。在控制台-网关管理下，先关闭数据加密，再立刻开启数据加密，这是会出现重新选择加密算法和填写对应密钥的弹窗，如下图1-8所示。
图1‑8 秘钥配置
将SM2的私钥按正确格式填写到输入框内，点击提交。之后就能在这里看到已经配置好的两种加密方式，如图1-9所示。
图1‑9 秘钥配置
至此网关更换密钥操作已完成。
3.客户端配置
1）iOS端
iOS客户端的加密方式和公钥是配置在info.plist下的，详情如图1-10所示。
图1‑10 iOS配置
此时将已生成好的SM2公钥按正确格式替换上述info.plist里PubKey的value，加密算法更改为SM2，如图1-11所示。至此 iOS端加密方式和公钥也已更换完毕。
图1‑11 iOS国密配置
2）Android端
Android端的加密方式和公钥是配置在mpaas_netconfig.properties 文件下的。此时将已生成好的SM2公钥按正确格式替换上述mpaas_netconfig.properties 里的对应value，更换后如下图1-12所示。至此 Android 端加密方式和公钥已更换完毕。
图1‑12 Android国密配置
此时服务端和客户端均已更换加密方式完毕，旧版App依然可以正常访问网关，新版App也是可以正常访问网关的，后续需要等待旧版App用户完全升级到新版App后，修改掉网关旧的加密方式即可，当然一直保留也可以的。
