mPaaS

mPaaS 查看完整档案

杭州编辑  |  填写毕业院校阿里巴巴  |  移动开发平台 编辑 www.aliyun.com/product/mpaas 编辑
编辑

mPaaS 源于蚂蚁金服金融科技,致力于提供高效、灵活、稳定的移动研发、管理平台。

个人动态

mPaaS 发布了文章 · 3月5日

CodeHub#4 启动报名| 荷小鱼:K12 在线教育应用的开发实践

随着5G、大数据、人工智能技术的应用,各类传统行业纷纷大力推进数字化转型升级,在线教育市场更是不断在利用科技助力教育普惠。

受疫情的影响,教育行业大幅加速了线上化转型进程。

据咨询机构发布的报告显示:2020 年在线教育市场规模达 4858 亿元、学员规模达到 3766 万人,市场规模增速上升至 20.2%,2020 年学,K12 在线教育渗透率在 2020 年上升至23.2%,增长率远超历年数据。

本期 CodeHub 为大家邀请了来自「荷小鱼」的前端工程师雷文伟,与大家一同分享在线教育应用通过使用 mPaaS H5 开发框架,针对 App 如何实现网络环境弱影响、版本升级无感知展开相关的技术演示与探讨?

CodeHub#4:在线教育应用的开发实践

【主讲人】「荷小鱼」的前端工程师 雷文伟

时间】2021/3/18 晚上 7 点 - 8 点

【地址】CodeHub 线上直播间

codeHub #4主视觉备份 2.png

旨在解决的问题

面对市场快速发展进程中带来的用户下沉效应,网络环境的以及低端机型带来的影响已经逐渐成为应用开发过程中亟需解决的难题。

这一点在「荷小鱼」应用的开发过程中,具体体现在以下四个方面:1.网络问题导致的白屏2.浏览器兼容性问题3.无离线下发功能4.无法即时更新资源

因此,移动应用通过使用 mPaaS H5 开发框架,如何实现网络环境弱影响、版本升级无感知?从而达到提升用户体验、实现动态更新的效果。正是本期 CodeHub 想要跟大家共同探讨的话题。

>>>>等你发问

如您对本期 CodeHub 主题与内容还有更多疑问,欢迎提交表单向主讲人发问,主讲人将在直播过程中为您解答~

关于 CodeHub

CodeHub 是以线上直播的形式输出前沿的移动端开发实践。用分享、交流的形式触达更多开发者,从而让有趣、深度的思考能够双向互动起来。往期CodeHub回顾>>

点击立即参与本期 CodeHub

欢迎钉钉搜索“32930171”加入「mPaaS 技术交流群」参与更多讨论。

=

image

image

查看原文

赞 0 收藏 0 评论 0

mPaaS 发布了文章 · 2月26日

技术干货 | mPaaS 小程序高玩带你起飞:客户端预置小程序无视网络质量

传统的小程序技术容易受到网络环境影响,当网络质量不佳时可能导致拉取不到小程序包的情况。通过预置小程序,即可规避该问题。本文介绍了预置小程序的原理和预置小程序的实现过程。

什么是预置小程序

预置小程序是指将小程序的渲染、逻辑、配置等静态资源打包在一个压缩包内,客户端预先下载小程序包到本地、直接从本地加载资源的过程。预置小程序可以最大程度地摆脱网络环境对 mPaaS 小程序页面的影响。使用预置包能够为客户端带来以下优势:

  • 提升用户体验
    通过预置包的方式把页面内静态资源嵌入到应用中并随应用一起发布,可以使用户第一次开启应用时即无需依赖网络环境下载资源,可以直接开始使用。
  • 实现动态更新
    在推出新版本或紧急发布的时候,可以在小程序 IDE 中进行迭代开发,通过 mPaaS 控制台发布,客户端中集成的小程序 SDK 会自动将小程序更新到最新的版本。这种发布无需通过应用商店审核,可以让用户及早接收到更新。

预置小程序的实现原理

本文从以下方面介绍了预置小程序的实现原理:

  • 小程序预置包的结构
  • 小程序预置包的使用过程

小程序预置包的结构

小程序预置包是一个 .amr 格式的压缩文件,将后缀 amr 改成 zip 解压缩后,可以看到其中包含的 HTML 资源和 JavaScript 代码等。待小程序容器加载后,这些资源和代码能在 UC 内核渲染。

以 Android 系统为例,下图显示了一般资源包的目录结构:

  • 一级目录:一般为资源包的 ID,如 2020121620201216_1.0.1.0.zip。
  • 二级目录及往后即为业务自定义的资源文件。并设定当前预置包默认打开的主入口文件,如 /index.html

1.png

小程序预置包的使用过程

使用小程序预置包的过程可以分为以下三个步骤:

  1. 请求包信息
    从服务端请求小程序包,并将小程序包信息存储到本地数据库的过程。包信息包含了小程序包的下载地址、小程序包版本号等。
  2. 下载小程序包
    把小程序包从服务端下载到手机。
  3. 安装小程序包
    下载目录,拷贝到手机安装目录。

前提条件

操作步骤-Android

预置小程序包。

  1. 在 mPaaS 控制台发布小程序包并下载 AMR 文件和配置文件。image.png
  2. 将下载到的 AMR 文件和配置文件放置在 mPaaS 项目的 assets 目录下。
    image.png
  3. 在工程中添加预置代码,以在应用启动时调用预置代码安装应用。预置代码示例如下:

image

说明

  • 此方法为阻塞调用,请不要在主线程上调用内置预置包方法。
  • 此方法仅能调用一次。若多次调用,仅第一次调用有效。所以需要一次性传入所有需预置预置包信息。
  • 如果内置多个 AMR 包,需要要确保文件已存在;如不存在,会造成其他内置预置包失败。

启动小程序。启动小程序的示例代码如下。

image

更新小程序

默认情况下,每次打开应用,小程序 SDK 都会尝试检查是否有可更新的版本。出于服务端压力考虑,该检查有时间间隔限制,默认为 30 分钟。如果想立即检查最新可用版本,调用下方的代码来请求更新。一般情况下,可以在应用启动或者用户登录后调用。
image

校验安全签名

小程序具有签名校验机制,防止恶意程序篡改下载到设备的小程序包。通过调用 MPNebula 接口设置验签参数即可开启此机制。如果您使用的基线是 10.1.60 或以上版本,需要额外开启容器配置,详情参见 H5 容器配置

说明

  • 请在第一次打开离线包前调用 MPNebula 接口,否则将会导致公钥初始化失败。关于公钥与私钥,参见 配置离线包 > 密钥管理
  • 无论客户端是否开启签名校验,在被判断为 root 的手机上都会强制进行签名校验。

image

删除本地小程序

Nebula 提供了删除本地应用信息的接口。当本地应用信息被删除后,再次打开应用时会重新请求服务端下载、更新本地小程序的信息。
image

说明:此 API 在 10.1.68 系列和 10.1.60 系列支持的最低基线版本分别为 10.1.68.8 和 10.1.60.14 。

操作步骤-iOS

预置小程序包。

a. 在 mPaaS 控制台发布小程序包并下载 AMR 文件和配置文件。

image.png

b. 新建一个独立的 bundle,如 DemoCustomPresetApps.bundle,将从发布平台下载的 .amr 离线包和 h5_json.json 文件添加到此 bundle 中。

重要:目前发布平台仅支持下载单个离线包的 h5_json.json 配置文件。当预置多个小程序包时,需要将不同 h5_json.json中的 data 数据手动合并到一个配置文件中。

c. 在初始化小程序时,在initNebulaWithCustomPresetApplistPath 接口,设置预置小程序离线包路径为上一步中创建的 bundle。
image

启动小程序

与非预置小程序类似,进入对应的页面时,调用 Nebula 容器提供的接口方法加载小程序。

image

更新小程序。

默认情况下,每次打开应用,小程序 SDK 都会尝试检查是否有可更新的版本。出于减少服务端压力的考虑,该检查有时间间隔限制,默认为 30 分钟。如果想立即检查最新可用版本,可调用下方的代码来请求更新。一般情况下,可以在应用启动或者用户登录后调用。

image

校验安全签名。

小程序具有签名校验机制,防止恶意程序篡改下载到设备的小程序包。通过调用 小程序 接口设置验签参数即可开启此机制。

说明

  • 请在第一次打开小程序包前调用 MPNebulaAdapterInterface 接口,否则将会导致公钥初始化失败。关于公钥与私钥,请参见 配置小程序包 > 密钥管理
  • 开启验签

image

删除本地小程序。

Nebula 提供了删除本地应用信息的接口。当本地应用信息被删除后,再次打开应用时会重新请求服务端下载、更新本地小程序的信息。

image

结语

mPaaS 小程序源自于支付宝小程序框架,亿级线上业务体量的锤炼,安全性媲美支付宝原生能力。不仅面向自有 App 投放小程序,更可快速构建打包,覆盖支付宝、淘宝、钉钉等应用。

通过使用上述预置小程序的方案,预置小程序不仅可以最大程度地摆脱网络环境对 mPaaS 小程序页面的影响,还能深度体验用户体验、实现动态更新。

撰文:刘启洋、滕宏才

  • END -
    • *

动态-logo.gif

底部banner.png

查看原文

赞 0 收藏 0 评论 0

mPaaS 发布了文章 · 2月22日

技术干货 | 深度解构 Android 应用面临紧急发版时的救星方案:mPaaS 热修复——DexPatch

方案介绍

为了解决 Native 模块上线后的问题,mPaaS 提供了热修复功能,实现不发布客户端 apk 场景下的热修复。目前 Android 端热修复主要包括 andfix 和 dexpatch,考虑到 andfix 的版本兼容性,目前主要推荐使用 DexPatch

DexPatch 修复原理比较简单,就是在启动后通过 RPC 拉取当前需要下发的 jar 包地址,然后通过独立进程去下载 jar 包文件,下载完成后保存。在二次启动的时候 hook 系统的 classLoader,修改 DexPathList,在其数组的最前面加入一个有修改过的 class 的 dex 文件,使其拦截住数组后面的 dex 文件中同名的 class 的加载。

如下图所示,classloader 就会优先加载 Patch.dex 中的 Ding.class,而忽略 Classes.dex 中的 Ding.class,达到了替换的效果。  

1.png

基于这样的原理,DexPatch 具有以下特征:

  1. 支持范围上:是基于类级别的替换,所以只支持 Java 模块的 patch,不支持非 Java 模块的 patch,比如 so 模块;
  2. 兼容性上:由于是代理了系统的 ClassLoader,使用的黑科技较少,所以整体方案兼容性较好;
  3. 生效时效性上:只能在下载 patch 后重启后才能生效,不支持实时生效;
  4. 成功率上:由于下载是使用的独立进程,减少了启动阶段主进程闪退对 patch 下载的影响,提升了下载的成功比例。

操作说明

以下是关于在 mPaaS 下使用 DexPatch 模块的主要步骤以及问题排查思路,方便开发者日常开发。

1. 触发 patch 拉取

启动阶段调用 MPHotpatch.init(),主要触发 Patch 信息的 RPC 请求,如果命中发布 Patch 发布规则,RPC 会返回 Patch 的 jar 包下载地址,客户端去触发下载,下载后保存在客户端私有目录/data/user/0/包名/dexpatch/patch/下。

2.png

2. 代码操作演示

以组件化模式接入为例,介绍下 Patch 发布的主要流程。

(1)代码改动前

3.png

需要保存改动前的构建产物,方便后续做 Patch 生成,地址在:build/intermediates/bundle/xxxx-raw.jar

(2)代码改动后

4.png

重新编译,保存构建产物,产物地址:build/intermediates/bundle/xxxx-raw.jar

(3)生成白名单配置

主要用于热修复包时用于指定修复的类,配置文件为 .txt 格式,该配置文件应包含并按顺序包含以下信息:
需要 Patch 的类。以 L 开头,后跟以混淆后真实类名。如果多个类,每行只可写一个。示例:Lxxx.xxx.clazzX设置 Patch 类型为 dexpatch。示例:PatchType: dexpatch

设置是否是静态 Bundle。默认为 false,如果是静态链接的 Bundle,需要显式设置为 true。示例:HostDex: true(*目前 mPaaS 客户端的模块一般都在静态链接里,一般写 true)

5.png

(4)查看签名

生成 patch 需要用到项目的打包秘钥,需要提前准备好,可以在打包脚步下找到对应的配置

6.png

(5)生成 patch

① 通过 mPaaS 自带的 IDE 工具,点击热修复,进入修复页面。

7.png

② 按照页面提示,填入之前准备的修复前和修复后的 jar 包地址,还有白名单配置文件,勾选 dexPatch,进入到下一步

8.png

③ 下一步主要选择打包的配置文件,最近点击完成生成 patch 文件

9.png

(6)生成 patch 产物

生成 patch 产物如下:

10.png

查看产物,可以使用 dex2jar 工具反解 diff.dex 文件,用 jd-gui 文件查看反解产物是否符合预期

11.png

反解后可以看到修改的模块:

12.png

(7)上传发布

① 选择上一步的产物 jar 包进行上传

13.png

② 上传后可以通过白名单进行发布,验证 patch 的稳定性

14.png

(8)验证下载

白名单发布后,启动客户端,搜索关键字:DynamicRelease,可以看到在 tool 进程有触发下载的日志打出。
这里需要说明的是,这里触发 patch 的下载是在 tool 进程,不在主进程的主要原因是怕由于主进程由于启动导致重复闪退,导致 patch 不能下载成功,单独在 tool 进程实现下载,尽量提高 patch 的下载成功比例。

15.png

然后去下载目录查看,是否下载保存成功,下载目录在:/data/user/0/包名/dexpatch/patch/20201023110012@20201023110012.jar

16.png

(9)杀进程启动

确认下载保存成功后,杀掉 App,重启查看是否生效,重启可以搜索关键字:DexPatchManager,查看 patch 生效的日志,日志会打印当前是否存在 patch 以及 patch 是否加载的日志。

17.png

同时我们也可以就实际业务场景进行验证,查看是否生效。

常见问题

  1. aar 模式集成后 patch 没生效

aar 模式集成的时候,需要继承框架的 QuinoxlessApplication,指定 Application 为框架的实现类才能实现 dexpatch 的加载。QuinoxlessApplication 内主要封装了 dexpatch 模块的初始化和加载。

  1. 使用加固后不生效

需要使用加固前的 apk 生成 patch,不能用加固后的包生成 patch。然后还需要验证在不同加固厂商下的兼容表现。

  1. 使用热修复后,和 RPC 有关的调用发生 apache http 相关的 crash。

请使用 Android 官网上的方式引入 apache http client,禁止使用导入 jar 包或者 gradle implementation/compile 的方式导入 http client。否则会引起 classloader 加载类混乱。

建议方式:

<uses-library android:name="org.apache.http.legacy" android:required="false"/>
`_* 如有更多疑问,欢迎钉钉搜索“32930171”加入「mPaaS 技术交流群」_`


E · N · D

作者名片-荣阳.jpg


底部banner.png

查看原文

赞 0 收藏 0 评论 0

mPaaS 发布了文章 · 2月7日

排查指南 | 当 mPaaS 小程序真机扫码时提示 "应用更新错误(50002)"

问题描述

APP 扫码 mPaas 小程序弹出 toast 信息:"应用更新错误(50002)"。

未标题-1.png

原因分析

通过扫码进行真机调试的正常流程如下:

  1. 在小程序 IDE 生成二维码,以供手机客户端扫描,同时会将小程序包上传至 mPaaS 控制台的小程序发布中。
  2. 手机客户端扫描此二维码后,会主动通过 RPC 请求去拉取控制台中的 AMR 文件。

当调用 MDS 小程序更新接口后,若没有获取对应的小程序信息,就会提示“应用更新错误(50002)”。这类问题可能的原因包括:

  • 服务端尚未发布,包括:
    • 控制台未发布上传的小程序。
    • 小程序刚发布,但服务端尚未收到刚发布的小程序。
  • 客户端版本不在范围内。
  • 请求信息和服务端发布的规则不匹配。

排查思路

1. 过滤日志

在 Android Studio 控制台的日志信息中过滤关键字 DynamicRelease。查看 UnionResourceInfo 中是否有 Item 信息。

  • 正常情况下,会含有 item 信息,示例如下:

carbon.png

  • 若未包含 item 信息,则为异常,示例如下:

carbon (1).png

2. 检查接入真机预览和调试功能

按照Android 小程序接入真机预览与调试中的步骤检查检查接入真机预览和调试是否正确。

3. 检查客户端版本范围

版本号对应 Android 项目 versionName 值。只有当最低版本号 < 当前 App 版本号 < 最高版本号时,才能正常的拉取小程序。若不在这个范围,App 启动小程序时就会拉取失败,报 "应用更新错误"。

所以推荐在最低版本输入 0.0.0.0,最高版本不填写(表示无限大)。

image.png

注意事项

由于在小程序 IDE 上传、预览、真机调试会自动将小程序上传至控制台,无需用户在控制台修改配置信息,所以在创建小程序时,不推荐从小程序发布中添加小程序包,防止出现主路径不一致。如要修改小程序,可以在小程序 IDE 中修改。

4. 检查主入口路径

查看 mPaaS 控制台中填写的小程序主入口路径是否与小程序 IDE 中的主入口路径一致。

mPaaS控制台默认主路径格式为:/index.html#xxx/xxx/xxx/xxx,其中 # 后方的 xxx/xxx/xxx/xxx 是小程序的 app.json 中的 pages 中的第一个值。

工单协助

如果依然不能解决问题,请准备好相关问题的复现 Demo 工程,通过阿里云工单系统联系 mPaaS 售后技术支持。

撰文:刘启洋

-END-


底部banner.png

查看原文

赞 0 收藏 0 评论 0

mPaaS 发布了文章 · 2月1日

CodeDay#5 全程回顾——一场关于动态化开发实践的技术探讨

时隔一年,很高兴能在 2021 年的第一个月,重启 CodeDay。

在过去的一年中,经过跟支付宝移动端团队和广大开发者的交流和沟通,我们了解到大家在涉及到关于移动应用跨端开发的过程中遇到的一些问题,同时也在思考,我们可以对外输出那些行之有效的技术实践方案?开发团队在面临业务高并发需求时,如何对技术模型进行迭代升级?

带着这样的疑问,我们展开了 4 个方向的议题分享。

CodeDay#5 全程回顾

01 支付宝在动态发布方向上的探索和演进

1.png

*公众号「mPaaS」回复“动态发布”下载完整PPT_

经过近十年的版本迭代,支付宝已由初始的工具性 App,转型升级成为了开放的、生态化的超级 App。App 功能也由最初单一的转账、支付升级成了生活平台,不仅包含理财、金融等功能板块,也容纳了生活、出行等各种各样的服务板块。

那怎么样让这些业务模块平稳地运行在 App 里呢?动态化开发架构就是我们在升级探索上的一个很重要的支点,不仅能够保证业务模块可以即时发布和更新,也能保证整个 App 高质量平稳运行。

02 兼顾包大小/易用性的容器优化之路

2.png

*公众号「mPaaS」回复“小程序容器”下载完整PPT

小程序,是一种依赖 Web 技术,集成了原生能力的,新的移动应用程序格式。

但由于当前小程序容器依然存在接入麻烦、依赖冲突、接口不支持以及包体积大等问题,我们对小程序容器围绕接入优化、性能优化、体验升级等三个方向进行了改造。

公众号「mPaaS」回复“Alpha”申请试用

03 全新的跨端开发实践

3.png

*公众号「mPaaS」回复“跨端开发”下载

mPaaS 小程序 IDE 集成在支付宝小程序 IDE 中,继承了其中的能力,并且和 mPaaS 的账号体系深度绑定,可以实现一键真机预览,真机调试,上传发布等能力。并且通过 mPaaS 的插件,可以实现多端开发。

*点击跳转《使用 HBuilder 引入构建 mPaaS 小程序》视频教程

04 小程序体系下,探索更多可能性

4.png

*公众号「mPaaS」回复“U4内核”下载完整PPT

在各种新技术层出不穷的今天,Web 经过了 30 多年的发展,除了支撑传统互联网领域的网页搭建,在移动互联网领域也有着非常广泛的应用,比如小程序、信息流、会场这样的业务场景,我们都可以看到 Web 技术的身影。

为什么 Web 能有如此强大的生命力呢?

我们认为有一点非常重要,就是高度标准化。由于高度标准化,它有着很强的向下兼容性和跨平台兼容性,从而可以非常广泛地应用,而且经久不衰。但是高度标准化也会带来一个问题,就是新特性的落地非常缓慢,一个特性从提出到形成标准,到最终在浏览器中落地,需要经过多年的时间,对于开发者来说,了解浏览器内核的进展更有实际意义。


底部banner.png

查看原文

赞 0 收藏 0 评论 0

mPaaS 发布了文章 · 1月14日

技术干货 | mPaaS 客户端问题排查:漫长的 3s 等待之谜

面对日益复杂的技术世界,App 在开发、上线和运维阶段所遭遇的问题也越来越多。这些形形色色的问题可能来自整个链路的任意环节,而不仅仅是代码层面。

对于开发者来说,排查手段已经不再局限于构建代码过程中的调试,往往需要扩充排查方法,从多种途径对问题进行分析和定位。这篇文章会和大家分享 mPaaS 开发者的一例小程序网络性能问题排查之旅。

问题背景

“笑联科技”反馈基于 mPaaS 开发的 App 中,其集成的小程序访问客户自建的 Web API 存在连接慢的性能问题。问题复现视频如下:

播放问题复现视频

从问题复现的情况看,打开小程序后,页面数据的加载有一个“漫长”的等待过程。

和开发者沟通后了解到,页面初始化所必须的部分数据是通过自有的 Web API 获取到的,数据返回慢会导致页面加载的等待。另外开发者也提到,这个问题存在地域性和偶发性,既部分地区的部分用户在一段时间内会被这个问题严重困扰。

问题分析与排查

如前文所述,数据是通过 Web API 获取的,自然我们希望通过外部手段去确认这个 Web API 本身是否存在性能问题。

然而,通过浏览器或 Postman 等工具去访问该 Web API ,均无法复现问题,后端的响应都是毫秒级。但是因为开发者提到该问题存在地域性和偶发性,因此无法直接排除部分原因。

由于我们并不是 App 的直接开发者,对于这类问题,一种常规的手段是抓取 HTTP 报文来观察和理解 App 背后的行为特征。比较幸运的是,我们的测试用 iOS 手机可以复现问题,通过 Charles 抓取 App 报文,我们有如下发现:

Web API 的地址为:https://api.xiaolianhb.com/

当 Charles 开启 SSL Decryption 时(中间人解密 HTTPS Body 模式),问题无法复现。

当 Charles 关闭 SSL Decryption 时,问题可以复现,数据加载明显存在一个 3s 的等待情况。

上述现象 2 和 3 强烈暗示问题可能和 HTTPS/SSL 协议层面相关(开启 SSL Decryption 时,HTTPS 连接由 Mac 笔记本和服务器进行;关闭 SSL Decryption 时,HTTPS 连接由 iPhone 和服务器进行)。

对于 SSL 层面的问题,则需要抓取 TCP 报文做进一步的确认和分析。使用 Wireshark 进行网络层抓包(基本抓包步骤:iPhone 正常接入网络;iPhone 通过数据线连接到 Mac 上,并对手机网卡搭建一个虚拟映射;Wireshark 在该映射上进行抓包;详细步骤参考这里)。

问题复现并抓取到相关报文后,首先确认问题,如下图所示:

1.png

通过上图日志可以看到,在 TLS 握手阶段,客户端在流程上延迟了 3s 才把 Client Key Exchange 消息发给服务端,而正常情况下,不应该存在如此漫长的等待情况。于此同时,开发者在 Debug 包上的前端嵌入调试也确认了相关情况,如下图所示:

2.png

接下来需要搞清楚,客户端为何在握手阶段等待了如此之久以及这 3s 期间客户端在做什么?放开网络包过滤条件后,通过阅读网络包的上下文,我们有了进一步的发现,如下图所示:

3.png

在上图中,可以看到客户端一直尝试与一个 IP 为 243.185.187.39 的站点建立 TCP 连接,但均遭遇失败。这里会有两个疑问:1. 这个站点是干什么的?2. 为何客户端要在 TLS 握手过程中先去连该站点?

通过同一个网络包中的 DNS 查询记录,尝试反查该 IP 对应的域名地址,发现该站域名为:a771.dscq.akamai.net:

4.png

通过公网搜索该域名,得知这个域名是 Let's Encrypt (全球最大的免费证书机构)证书的 OCSP (Online Certificate Status Protocol,用于校验证书状态) 地址,但需要进一步确认该证据。在网络包中,查看服务端返回证书帧的详细信息,确认证书的 OCSP 地址为 http://ocsp.int-x3.letsencrypt.org

5.png

由于该 OCSP 地址和网络包中看到的不一致,本地通过 nslookup 再进一步确认:a771.dscq.akamai.net 是 ocsp.int-x3.letsencrypt.org 的一个 CNAME 地址(这种配置一般为了站点加速):

6.png

结合上述情况和公开资料,可以确认在 3s 的等待期内,客户端尝试去连接证书提供的 OCSP 站点地址,意图确认证书的吊销状态。仔细观察会发现,本地解析出的 IP 地址和手机端抓包看到的 IP 地址是不一样的,这里大概率是 Let's Encryped 证书的 OCSP 地址被“污染”导致的。

7.png

到这里,我们可以看到问题的小结为:客户端需要和 https://api.xiaolianhb.com/ 建立 HTTPS 连接,在 TLS 握手阶段,客户端无法连上该站点证书提供的 OCSP 地址,因此无法确认证书的吊销状态,3s 后触发超时放行机制,客户端和站点正常建立 HTTPS 连接,请求发送和数据返回流程得以进行。

既然 Let's Encrypt 证书的 OCSP 域名被“污染”已经成为事实,因此,要解决该问题,最快的解决方案是更换站点证书,保证 TLS 握手流程的顺畅。

小结

在这个案例中,我们可以看到有些时候,问题和代码、SDK 亦或是系统 Bug 并无直接关联,异常情况可能来自一个意想不到的地方。

回到问题症状上,更进一步的疑问是:为何桌面浏览器或网络工具受影响较小?为何 Android 手机不受影响?这些症状细节上的差异,均和不同系统或工具对协议的实现形式相关。

开发者很难在一开始的规划阶段就能把这些细枝末节的问题都预估到,因此,出现问题之后,深入的问题剖析配合日志解读往往是理解程序行为背后逻辑的重要手段。

CodeDay#5:深入探索支付宝终端

在过去的一年中,我们通过与众多终端开发者在能力对接、需求沟通中发现,愈来愈多的研发团队面临业务需求爆发时难以找到有效的方式进行高并发支撑。

大家的问题呈现出了共性特征:如何实现动态发布?如何进一步提升研发效率?支付宝是否有最佳实践?

因此,此次 CodeDay 我们把焦点放在“支付宝终端”,尝试通过 4 个议题分享,带领大家了解支付宝作为一款超级 App,如何借助容器化技术实现动态发布、更新能力,并沉淀出一套可复用的技术体系。

点我立即报名

作者名片-东雷.jpg

延伸阅读

动态-logo.gif

底部banner.png

查看原文

赞 1 收藏 0 评论 0

mPaaS 发布了文章 · 1月14日

技术干货 | mPaaS 客户端问题排查:漫长的 3s 等待之谜

面对日益复杂的技术世界,App 在开发、上线和运维阶段所遭遇的问题也越来越多。这些形形色色的问题可能来自整个链路的任意环节,而不仅仅是代码层面。

对于开发者来说,排查手段已经不再局限于构建代码过程中的调试,往往需要扩充排查方法,从多种途径对问题进行分析和定位。这篇文章会和大家分享 mPaaS 开发者的一例小程序网络性能问题排查之旅。

问题背景

“笑联科技”反馈基于 mPaaS 开发的 App 中,其集成的小程序访问客户自建的 Web API 存在连接慢的性能问题。问题复现视频如下:

播放问题复现视频

从问题复现的情况看,打开小程序后,页面数据的加载有一个“漫长”的等待过程。

和开发者沟通后了解到,页面初始化所必须的部分数据是通过自有的 Web API 获取到的,数据返回慢会导致页面加载的等待。另外开发者也提到,这个问题存在地域性和偶发性,既部分地区的部分用户在一段时间内会被这个问题严重困扰。

问题分析与排查

如前文所述,数据是通过 Web API 获取的,自然我们希望通过外部手段去确认这个 Web API 本身是否存在性能问题。

然而,通过浏览器或 Postman 等工具去访问该 Web API ,均无法复现问题,后端的响应都是毫秒级。但是因为开发者提到该问题存在地域性和偶发性,因此无法直接排除部分原因。

由于我们并不是 App 的直接开发者,对于这类问题,一种常规的手段是抓取 HTTP 报文来观察和理解 App 背后的行为特征。比较幸运的是,我们的测试用 iOS 手机可以复现问题,通过 Charles 抓取 App 报文,我们有如下发现:

Web API 的地址为:https://api.xiaolianhb.com/

当 Charles 开启 SSL Decryption 时(中间人解密 HTTPS Body 模式),问题无法复现。

当 Charles 关闭 SSL Decryption 时,问题可以复现,数据加载明显存在一个 3s 的等待情况。

上述现象 2 和 3 强烈暗示问题可能和 HTTPS/SSL 协议层面相关(开启 SSL Decryption 时,HTTPS 连接由 Mac 笔记本和服务器进行;关闭 SSL Decryption 时,HTTPS 连接由 iPhone 和服务器进行)。

对于 SSL 层面的问题,则需要抓取 TCP 报文做进一步的确认和分析。使用 Wireshark 进行网络层抓包(基本抓包步骤:iPhone 正常接入网络;iPhone 通过数据线连接到 Mac 上,并对手机网卡搭建一个虚拟映射;Wireshark 在该映射上进行抓包;详细步骤参考这里)。

问题复现并抓取到相关报文后,首先确认问题,如下图所示:

1.png

通过上图日志可以看到,在 TLS 握手阶段,客户端在流程上延迟了 3s 才把 Client Key Exchange 消息发给服务端,而正常情况下,不应该存在如此漫长的等待情况。于此同时,开发者在 Debug 包上的前端嵌入调试也确认了相关情况,如下图所示:

2.png

接下来需要搞清楚,客户端为何在握手阶段等待了如此之久以及这 3s 期间客户端在做什么?放开网络包过滤条件后,通过阅读网络包的上下文,我们有了进一步的发现,如下图所示:

3.png

在上图中,可以看到客户端一直尝试与一个 IP 为 243.185.187.39 的站点建立 TCP 连接,但均遭遇失败。这里会有两个疑问:1. 这个站点是干什么的?2. 为何客户端要在 TLS 握手过程中先去连该站点?

通过同一个网络包中的 DNS 查询记录,尝试反查该 IP 对应的域名地址,发现该站域名为:a771.dscq.akamai.net:

4.png

通过公网搜索该域名,得知这个域名是 Let's Encrypt (全球最大的免费证书机构)证书的 OCSP (Online Certificate Status Protocol,用于校验证书状态) 地址,但需要进一步确认该证据。在网络包中,查看服务端返回证书帧的详细信息,确认证书的 OCSP 地址为 http://ocsp.int-x3.letsencrypt.org

5.png

由于该 OCSP 地址和网络包中看到的不一致,本地通过 nslookup 再进一步确认:a771.dscq.akamai.net 是 ocsp.int-x3.letsencrypt.org 的一个 CNAME 地址(这种配置一般为了站点加速):

6.png

结合上述情况和公开资料,可以确认在 3s 的等待期内,客户端尝试去连接证书提供的 OCSP 站点地址,意图确认证书的吊销状态。仔细观察会发现,本地解析出的 IP 地址和手机端抓包看到的 IP 地址是不一样的,这里大概率是 Let's Encryped 证书的 OCSP 地址被“污染”导致的。

7.png

到这里,我们可以看到问题的小结为:客户端需要和 https://api.xiaolianhb.com/ 建立 HTTPS 连接,在 TLS 握手阶段,客户端无法连上该站点证书提供的 OCSP 地址,因此无法确认证书的吊销状态,3s 后触发超时放行机制,客户端和站点正常建立 HTTPS 连接,请求发送和数据返回流程得以进行。

既然 Let's Encrypt 证书的 OCSP 域名被“污染”已经成为事实,因此,要解决该问题,最快的解决方案是更换站点证书,保证 TLS 握手流程的顺畅。

小结

在这个案例中,我们可以看到有些时候,问题和代码、SDK 亦或是系统 Bug 并无直接关联,异常情况可能来自一个意想不到的地方。

回到问题症状上,更进一步的疑问是:为何桌面浏览器或网络工具受影响较小?为何 Android 手机不受影响?这些症状细节上的差异,均和不同系统或工具对协议的实现形式相关。

开发者很难在一开始的规划阶段就能把这些细枝末节的问题都预估到,因此,出现问题之后,深入的问题剖析配合日志解读往往是理解程序行为背后逻辑的重要手段。

CodeDay#5:深入探索支付宝终端

在过去的一年中,我们通过与众多终端开发者在能力对接、需求沟通中发现,愈来愈多的研发团队面临业务需求爆发时难以找到有效的方式进行高并发支撑。

大家的问题呈现出了共性特征:如何实现动态发布?如何进一步提升研发效率?支付宝是否有最佳实践?

因此,此次 CodeDay 我们把焦点放在“支付宝终端”,尝试通过 4 个议题分享,带领大家了解支付宝作为一款超级 App,如何借助容器化技术实现动态发布、更新能力,并沉淀出一套可复用的技术体系。

点我立即报名

1 月 23 日,我们广州见。

长图.png

作者名片-东雷.jpg

查看原文

赞 0 收藏 0 评论 0

mPaaS 发布了文章 · 1月12日

CodeDay#5 启动报名| 带你深入探索支付宝终端动态化实践

微信公众号.png

01

===

__ CodeDay 2021 年首站:广州见

时隔一年,mPaaS CodeDay 回来了。

在过去的一年中,我们通过与众多终端开发者在能力对接、需求沟通中发现,愈来愈多的研发团队面临业务需求爆发时难以找到有效的方式进行高并发支撑。

大家的问题呈现出了共性特征:如何实现动态发布?如何进一步提升研发效率?支付宝是否有最佳实践?

因此,此次 CodeDay 我们把焦点放在“支付宝终端”,尝试通过 4 个议题分享,带领大家了解支付宝作为一款超级 App,如何借助容器化技术实现动态发布、更新能力,并沉淀出一套可复用的技术体系。

1 月 23 日,我们广州见。

02

===

__ 议题及分享人介绍

  • 《Alipay 的动态发布演进:支付宝在动态发布方向上的探索和演进》

作为一款承载数百款业务模块的 App,要保持“动态发布、快速迭代”成为支付宝移动端开发团队持续攻坚的一大难题。

本专题聚焦支付宝作为一款超级 App,如何借助容器化技术实现动态发布、更新能力,并沉淀出一套可复用的技术体系展开分享。

分享人:重岳(蚂蚁集团客户端技术专家)

  • 《mPaaS 容器重磅升级:兼顾包大小 / 易用性的容器优化之路》

借助 mPaaS 容器,众多开发者逐步复用支付宝的端上研发模式,形成了一套面向自身业务场景的动态发布能力。

随着越来越多的外部 App 集成 mPaaS,我们在“包体积大小、易用性”等方向持续演进、优化,本专题将着重为大家介绍「mPaaS 新容器 Beta 版」的全新特性。

分享人:刺胃(蚂蚁集团客户端研发工程师)

  • 《更简易的端开发模式:全新的跨端开发实践》

mPaaS 小程序容器在近一年,帮助众多开发者从单纯的支付宝或微信小程序开发,过渡到多端开发模式,进一步提升自身研发效率。

借助 mPaaS IDE,我们逐步演进 AppX,集成三方跨端框架 UniApp,为开发者带来全新的小程序开发体验。

分享人:胜永(蚂蚁集团技术专家)

  • 《U4 内核优化之路:小程序体系下,探索更多可能性》

和支付宝、口碑一样,mPaaS 深度集成了 UC 自研U4内核。借助U4内核提供的能力,可以解决系统WebView碎片化,稳定性,安全性等问题,同时,在小程序技术愈发成熟,面向小程序的优化同样必不可少。

本专题将围绕U4内核在针对高性能,JS Worker,混合渲染,多进程等的探索和实践来展开分享。

分享人:齐誉(阿里集团技术专家)

03

===

____点击立即报名

🕑时间:2021/01/23(周六)下午 2 点 - 5 点
📍地点:广州 · 天河区广电平云广场B塔 · 15F

扫描图片中的二维码,即可报名免费参与,名额有限,先到先得。

海报.png

广州周六的下午
试试去看见终端技术的未来

04

===

__ 关于 mPaaS CodeDay

mPaaS CodeDay 由蚂蚁集团移动开发平台 mPaaS 发起系列线下沙龙,聚焦移动领域前沿的技术实践,通过专题分享的形式,面对面布道特定选题下的技术挑战与解决思路。

_往期活动回顾:
https://tech.antfin.com/community/activities?brandId=8_

欢迎使用钉钉扫码或搜索“33651760”加群,与分享人一起线上互动。若您无法到场,也可钉群云参与。

lADPD4PvLr2hOyTNBfrNBJI_1170_1530.jpg

动态-logo.gif

底部banner.png

查看原文

赞 0 收藏 0 评论 0

mPaaS 发布了文章 · 1月8日

技术干货 | “选图预览并上传”的场景如何解?全网最全方案汇总来了

选择本地相册图片或者拍照,然后预览并且上传是移动应用中一个典型的使用场景,比如常见的身份证信息上传等。

不少客户都反馈有类似的场景,并且在使用上都或多或少的遇到一些问题,最后找到 mPaaS,希望我们能够提供一些最佳实践。在这里分享下对应场景的一些优化解决方案。

选图方案

方案1:使用 Android 原生 Webview

前端通过 input 标签,指定 type=file,通过原生 webview 的支持实现选择文件。

Android 原生 webView 并不支持选择文件上传,需要外壳自己扩展 WebChromeClient 里的 openFileChooser 或者 onShowFileChooser,然后去唤起系统选择文件弹框,选择文件会使用系统提供的组件或者其他支持的 app,返回的 uri 有的直接是文件的 url,有的是 contentprovider 的 uri,需要统一处理一下返回 uri 格式。

这种方案存在以下问题:

  • 外壳定制实现的逻辑较多,还需要对系统不同文件选择器返回的地址做兼容,容易有兼容性问题;
  • 选择文件实现依赖系统的文件选择器,不同手机实现不一致,无法做到统一;

方案2:使用 mPaas 的 H5 容器

如果业务使用了 mPaas 的 H5 容器后,虽然容器内已经内置了唤起文件选择器的一系列操作,但是还是一样存在系统文件选择器不可控的风险。比如如果业务希望选择的是一张图片,但是唤起后的效果可能是下面这个样子,部分客户也是无法接受的。

1.png

方案3:实现 jsapi 唤起 Native 自定义的选图页面

这种方案就是利用 H5 容器提供的自定义 jsapi 的能力,自定义一个选图的 jsapi,然后前端去调用,去唤起 Native 自己实现的选图页面,最后结果通过 base64 的形式返回给前端做显示。这样就解决了前面提到系统选择文件不可控的问题。

但是当这个方案上线后,还是遇到了一些问题,主要因为通过 jsbridge 只能返回 json,所以图片数据是通过 base64 的形式返回的。但是因为有多选的场景,如果用户选择了多张图片后,返回的 base64 数据会特别大,导致在一些低端设备上有一些 OOM 的问题,同时大量 base64 转 JSON 的过程中,也会出现 ANR。所以也是不能上线的。

方案4:选图返回本地路径,WebView 拦截访问本地资源

为了解决前面提到的返回 base64 存在的稳定性问题,所以我们在选图的时候,是返回了一个本地的地址,然后 Native 模块拦截 WebView 的资源访问,去本地拿到对应的图片返回给 WebView 显示。

比如选图后返回给 WebView 的地址是:https://www.mPaas.com.cn/mpaa...www.mPaas.com.cn 是我们自定义的一个域名,我们拦截这个特定自定义域名,然后去本地相册去找 mpaas.jpg 对应的图片拦截返回。通过这样的一个转换逻辑,解决了 base64 传递的问题。

文件上传方案

通过以上的描述,我们对比了各种选图方案实现的优缺点,最后沉淀了最佳实践。选图实现了后,下一步就是上传。对于上传也经历了类似的方案演进。

方案1:使用 RPC 接口上传

对于使用了 mPaas 的用户,第一步想到的肯定是通过 RPC 接口实现文件的上传,但是在实际验证过程中,我们发现对于一些比较大的图片上传,RPC 接口直接返回了 403 的报错:Http Transport error[413] : Request Entity Too Large]. 很明显是因为文件过大导致服务端挂掉了。

主要因为 RPC 的定位是用做业务数据通道,一般建议的大小是 200K 以内,对于直接上传大文件的数据,会有稳定性风险,甚至因为这个把整个网关打挂。

2.png

方案2:使用 OSS 方案上传

对于类似的文件上传场景,建议是直接使用 OSS 的方案进行上传,比如常见的阿里云 OSS 方案:help.aliyun.com/product/31815.html。

OSS 是专门为解决文件存储整条链路设计的一套方案,解决了文件上传的各种场景,用户可以集成对应的 Android 和 iOS 的 SDK 实现对本地文件的上传。

结语

仅仅是一个选图上传预览这样一个场景,就可以有这么多不同的方案演进,没有最好的方案,只有最合适的方案。

作者名片-荣阳.jpg

- END -

动态-logo.gif

底部banner.png

查看原文

赞 0 收藏 0 评论 0

mPaaS 发布了文章 · 1月4日

江苏民丰 x mPaaS | 县域小银行,技术团队就12人,却找到了数字化转型的秘籍

图片

想参与未来竞争,中小银行积极参与数字化转型已经成为必选项。

金融数字化转型的大潮中,主角不只是国有大行,中小银行也积极活跃在舞台上。

总部位于江苏省宿迁市的民丰农村商业银行就是其中的一家。这家前身为当地农村信用社的农商行,总资产400多亿元,依靠一只规模仅有12 人的开发团队,通过使用云平台上的数字技术,单月投资仅仅1万元左右,就快速实现了业务数字化、线上化发展,为银行业绩的稳定快速增长做出了重要贡献。

图片

以往,类似民丰农商银行这样的很多地方中小银行运营作业模式分散、手工化程度较高,营销获客以实地拜访、网点地推等方式为主。但新冠疫情爆发以来,“非接触式”金融服务需求和数字化运营要求指数级增长,地方中小银行在提升数字化能力方面显得尤为迫切。

中小银行大都认识到要进行变革,要进行数字化转型,但在资本投入有限、人才缺乏、科技实力不足等刚性约束条件下,这条转型之路究竟该怎么走?绝大多数机构并没有清晰的答案。

作为一家扎根苏北的地方性法人金融机构,民丰农村商业银行也曾面临上述种种困难,但通过一场始于2016年的变革,逐渐探索出了一条有特色的普惠金融发展及数字化转型路径。这条路对于亟需变革的中小银行,尤其扎根县域经营的小银行而言,或许能够带来一点启示。

普惠金融的“民丰模式”

提到江苏,很多人脑海里都会浮现出很多美好精致的画面——小桥流水的乡村,波光帆影的太湖,蜿蜒流淌的古运河,粉墙黛瓦的古镇……但这些画面实际上绝大多数跟商贸发达的苏南地区相关。

由于江苏省区域经济发展不平衡,人们常说“苏南富,苏北穷”。宿迁市,就位于苏北,地处鲁南丘陵与苏北平原之间,古称“钟吾”,是西楚霸王项羽的故里。现在人们知道这座城市,更多是因为创业成功的刘强东。按照现在划分城市级别的方法,宿迁属于三线或者四线城市。

宿迁市是典型的农业大市,也是江苏省的产粮大区,这决定了扎根当地的民丰农村商业银行服务的对象是数量大、贷款金额小的农户,是支持‘三农’的真正主力军。

2016年7月,从沭阳农商行调任民丰农商行并担任董事长的许尔波,甫一上任就开始了一场对传统信贷服务管理模式的改革,实现信贷“三台六岗”全面分离,从机制建设上解决过去信贷业务中发展与风险的矛盾问题。

传统信贷开展模式之下,信贷人员实行“包放、包收、包管”的终身责任制。简单来说,就是对客户的贷款一竿子插到底。

乡村熟人模式之下,这种模式确实发挥效用,但是这一模式带来的弊端在于,银行信贷人员与大量分散客户之间数量上的不匹配以及随之形成的信息不对称,造成银行服务被动、效率低下,并且容易引发暗箱操作风险。

民丰农村商业银行的变革从改善岗位职能和流程下手,提出“三台六岗”模式。

具体的做法是,在传统信贷流程的“大三台”框架内打造“小三台”,即将营销与调查作为“小前台”、审批与签约作为“小中台”、管户与催收作为“小后台”,六大岗位各司其职、高效协作、相互制衡,实行专职化、流水化、标准化作业流程,确保“专业的人做专业的事”。

“三台六岗”模式的实施,激活了民丰农商行团队的活力,成效显著。推行四年来,全行累计受理授信申请13万笔,平均授信时长仅1.2天,审批效率较改革前提升了3倍多;当前信贷客户总数已突破8万户,贷款余额超230亿元,分别较改革初增加了2.5万户、87亿元,年增长率超过10%。

这种成功经验后来被业内成为“民丰模式”,全国数十家农商行前来学习交流经验。民丰农商行也没有藏着掖着,将成功经验全数分享。

在民丰农商行开创这一模式的许尔波看来,这一模式“完全可以”在其他地区和农信金融机构推广和复制。不过,他加了一个很重要的前提:“这家银行的高管尤其是董事长,需要在战略定位上有强大的定力,在执行和贯彻过程中有足够的魄力。”

率先启动业务线上化

复盘“三台六岗”模式能够顺利推行,民丰农商行针对覆盖宿迁农村地区的授信工程可以说非常重要。早在2009年,民丰农商行即启动农户贷款集中授信活动,并最终实现了对辖区内近26万个农户家庭总额超过150亿元的授信。

全区域覆盖的授信之后,客户经理不需要一家家挨门挨户去授信、放贷,不仅较好地控制了信用风险和操作风险,也把他们从繁杂的管护压力中解放出来,市场营销拓展力量得到了极大的释放,有效地解决了风险和效率之间的固有矛盾。

当然在这背后,科技力量的支撑作用也不得不提。2016年年底,在民丰农商行针对信贷业务进行流程再塑的同时,一场推动业务线上化的变革也在紧锣密鼓地筹划。

“全行启动三台六岗模式之后,我们科技部当时就想,能发挥什么作用?”作为民丰农商行研发经理的汪晓涛回忆当时的情况说,“当时民丰农商行的授信客户达到60多万,但是真正使用过信贷额度的客户约为40%左右,我们一直在思考如何撬动剩下的60%客户。”

2016年底,中国银行业的数字化转型还没有像今天这般深入,当时即使是江苏省内的一些大银行,在移动端上的发力也才刚刚开始。但民丰农商行科技部联合销售部将信贷业务线上化的想法汇报上去没多久,就得到了行里高层非常积极的回复——可行。

说干就干。通过紧急调研、立项、招投标等流程之后,民丰农商银行找来的科技外包公司在2017年6月开发出来了一款只有线上信贷功能的App——“宿速e”。汪晓涛说,由于宿迁本地区同业里面也没有类似的线上信贷产品,再加上有很大的利率优惠,当时用户增长以及信贷申请量都很大。

背后原因也很简单,业务线上化,给贷款客户以及行里的营销经理带来了极大便利。

宿迁是苏北劳动力输出大市,农村大量青壮年外出务工。在没有推动业务线上化之前,在外务工的人如果需要申请贷款,需要跑回来,到银行柜台提交材料,还要找一两位担保人,现在手机上下载App,依托数据智能分析技术,用户完成注册认证之后,可以线上申请、即时签约、实时放款,全流程仅需5分钟。而以前,客户经理准备这一套基础材料起码就需要30多分钟以上。

图片

不用说,民丰农商行“宿速e”App藉此在省内银行系统内一炮而红。

云上自主创新

周边兄弟银行反应也很快,也开积极上马手机银行App,推动业务线上化。“给我们提供服务的外包公司一下接到了6-7个开发App的需求,这家公司人力有限,看到我们的系统稳定之后,提出了撤场。”

外包公司撤场,但“宿速e”产品肯定还要继续优化和扩充功能,这给没有前端App开发经验的汪晓涛出了一个大难题。“我作为整个项目负责人,外包公司离场之后,最关心的是该如何保障产品的延续,但是我们人员又非常有限。”

突然之间,这个发展势头很好的App一下变成了有点烫手的山芋。当时,“宿速e”仅仅投放在Android端,按照规划还要开发iOS版.“我们在移动开发端比较弱,只靠一个人忙不过来,如果要在每端配置两个人,人手又不够。” 汪晓涛说。

技术力量薄弱、人手短缺,这是中小型银行广泛存在的窘境,民丰农商行也不例外。虽然该行通过科技外包公司推动业务创新,但多数情况下,外包公司其实很难准确理解银行的想法,导致后续开发出的产品不能满足银行需要。

简而言之,外包科技的模式虽然有利于控制成本,但是效率低,有时候还会贻误好的市场机遇。

正是在这样的压力下, 民丰农行商银行遇到了在阿里云上刚刚对外商业化的mPaaS移动应用开发套件。mPaaS套件是一套成熟的金融级移动端开发解决方案,支撑了国民级App应用12306,能够一次开发多端投放,帮助金融机构快速搭建稳定高质量的移动应用,将更多业务承载在移动端。

作为阿里云新金融的主打技术产品之一,mPaaS已服务中国农业银行、广发银行,华夏银行,西安银行、南京银行、广东农信、国寿保险等多家金融机构,大幅度提升了客户的活跃度和日均交易量。

“在阿里云上面看到这款产品之后,我对产品功能和介绍文档进行了深入了解,很符合我们的情况。”汪晓涛说,再加上mPaaS产品技术团队专门到宿迁进行培训,并在钉钉上随时帮我们解决问题,我们自己的工程师虽然此前没有移动端应用的开发经验,但是通过学习,很快就上手了,写很少代码甚至不写代码,通过拖拉拽相应的功能模块就能开发移动应用。

2018 年初,刚从 12306 项目抽出身来的阿里云mPaaS工程师唐天,高铁之后再打车,辗转来到宿迁。摆在他面前的问题,是需要帮助民丰农商行快速解决技术力量薄弱、人手短缺与架构重构统一之间找到平衡。

唐天必须一头扎进项目中,帮助民丰团队修改代码,定位问题,上手精简优化代码。现在回忆起来,唐天感慨道“客户的好学程度让人惊讶,mPaaS 在后续迭代推出的新能力,他们几乎都是第一时间做了试用。”

在 mPaaS 产品技术团队的加持下,民丰农商银行得以在 2018 年底彻底重构 App,由此而来的是更流畅的端上体验和极低的闪退率。第二年,还用时下流行的“小程序”构建了一系列生态,从付款码、扫码支付功能,到生活缴费、淘票票、天猫优选等新场景功能,通过自己独立运营就实现了移动端App的获客和活客。 

今年疫情期间,因为银行网点管控,民丰农商行的线下贷款比同期下降了非常多,而得益于业务很早就进行线上化部署,线上贷款业务反而逆势增长,达到4亿多元。

民丰农商行新发起成立的9家村镇银行由于没有及时推进业务线上化,“疫情期间贷款基本没有什么量。”得知这样的情况,汪晓涛带领科技团队仅用1个多月,就帮助他们开发出了线上贷款入口。

现在,移动端App开始承担更多业务。以“宿速e”手机App贷款服务平台为载体,民丰农商行先后推出了“农e贷”“融e贷”“商e贷”“快e贷”等多种线上信用贷款品种。按照民丰农商行的规划,今年银行会有约40%的贷款业务会承载在移动端,而在未来,这个比例会进一步增长。

而支撑这样的成绩,背后的开发和运维团队至今也不过12个人,而且一年投入在阿里云mPaaS公有云上的费用也只有十几万元,单月平均投入仅仅1万多元。

图片

作为银行业少见的mPaaS公有云客户,汪晓涛十分渴望把这个套件推荐给江苏省农村信用社联合社,构建一套全省统一的专有云。他好几次前去游说省联社分管手机银行业务的领导,游说风格上也非常直接:你看,我们只用这么些人,做成了这么多事!

数字化转型的样本意义

从金融服务广度和深度来看,民丰农商行这样的银行是县域金融服务的主力队伍,在服务县域经济发展、金融支农支小中作出了重大贡献。银保监会主席郭树清日前强调,县域金融是我国金融体系的重要组成部分,只能加强不能削弱。

但是要想参与未来竞争,中小银行积极参与数字化转型已经成为必选项。但是一个残酷的事实摆在面前,相比城商行、股份行、大行等同业,它们数字化上已经大大落后,形势非常严峻。

2020年10月,中国互联网金融协会进行的专项调研显示,在数字化转型方面,相较于大中型银行和新型互联网银行,地方中小银行总体处于初步探索阶段。被调研地方中小银行数字化能力自评估平均得分为2.75分(满分为5分),与大中型银行(3.41分)和新型互联网银行(3.87分)相比存在较大差距。

事实上,最近一年来有很多同类农商行到访民丰农商银行,进行学习。而民丰农商行也总是不厌其烦地分享在阿里云上创新的实践和经验。有两家心动的兄弟银行直接把App开发的任务甚至直接交给了他们。

汪晓涛还在极力游说江苏省级农信联社的领导,希望江苏省内地方农信社能够统一使用一个技术平台,省内50多家农信社只需要把自身业务以小程序的形式投放在这个大平台之上,即可实现数字化转型,共同抱团参与激烈的市场竞争。“省联社也想换技术架构,我们也一直想推动他们换。”汪晓涛笑称,“这是我短期内最大的目标。” 

去年年底,民丰农商行曾考虑联合阿里云一起搞一场中小银行数字化转型的论坛,向全国区域性的中小银行,介绍在云上做数字化转型经验,但因为疫情突然爆发,计划搁浅了。

“我们这种模式是完完全全可以复制的。” 汪晓涛说,复制成功的关键,顶层要看一把手的魄力,下面就要看团队是不是有意愿,想做事情。他还认为,中小银行在做数字化转型上要有长远规划,找到一个可以支撑业务发展的优秀技术平台。“从零开始造轮子,并不符合中小银行需求快速迭代的要求。”

今天,小银行所处的环境相较几年前已经有了彻底的改变,经济增长大幅放缓,息差在进一步缩小,另有大中型银行通过数字手段不断下沉,进一步争取区域内的客户……数字化能力“不及格”的县域小银行要怎样才能突围,继续延续所在区域的领先地位,民丰农行商银行的模式可能是一条不错的学习路径。

本文转自中国电子银行网

责任编辑:王超

END

图片

图片

图片

查看原文

赞 0 收藏 0 评论 0

认证与成就

  • SegmentFault 讲师
  • 获得 1 次点赞
  • 获得 1 枚徽章 获得 0 枚金徽章, 获得 0 枚银徽章, 获得 1 枚铜徽章

擅长技能
编辑

(゚∀゚ )
暂时没有

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

注册于 2020-06-09
个人主页被 899 人浏览