支付宝

在数字化和信息化的大潮中，大模型和 AIGC 正悄悄引领一场粗浅的改革，数字技术与各行各业深度交融，互联网企业遇到了业务高质量增长速度和老本过大的抵触，高质量倒退变成企业转型的外围命题。 云服务商通过智能托管，AI 大模型为企业构建以 AI 内核驱动能力的产业利用，帮忙企业数字化降级和业务高质量倒退。激发数字经济的生机与创造力。 本论坛拟邀请产业、学界、商业生态搭档独特探讨该命题，话谈将来和翻新。9 月 8 日，由支付宝小程序云主办的“云端 AI: 摸索新兴技术和倒退模式”论坛将在 INCLUSION·外滩大会召开。 INCLUSION·外滩大会是寰球备受期待和关注的金融科技大会，大会邀请寰球具备影响力的科技领军企业和专家学者，致力于推动金融科技和前沿科技摸索，以更前瞻的视线，探讨科技在经济、社会可继续倒退中的翻新与责任；以更具人文的视角，摸索科技与人、绿色倒退、将来的共生关系；以更凋谢的心态，搭建国际交流、产业倒退的平台。本次论坛将汇聚国内优良的科技企业家、出名专家学者以及行业首领，独特聚焦云端 AI 的后劲和翻新利用，摸索 AI 技术在新兴畛域的研究成果和利用案例，独特探讨云端 AI 对产业和社会的深远影响，并助力推动科技翻新的进一步倒退。 “云端 AI : 摸索新兴技术和倒退模式”论坛将邀请蚂蚁团体平台技术事业群总裁何征宇、中国信通院云大所云计算部主任马飞、复旦大学计算机学院副院长彭鑫、支付宝小程序云技术负责人李铮、NVIDIA 英伟达资深解决方案架构师张玮东、工商银行云计算实验室高级研究员腾达、DCloud CTO 崔红保进行分享。 新技术和新利用的倒退离不开产业、学界、商业生态搭档思维的碰撞和交换，作为一个凋谢的国际交流和共享平台，本次论坛将汇聚各方的智慧和教训，独特探讨相干的最新技术、趋势和利用，让行业的专家、学者、企业家和从业者独特分享和交流经验，取得最具创造力和启发性的解决方案，更好地应答新技术带来的的挑战，迎接新技术带来的时机，独特推动云端 AI 相干技术的倒退和利用。 咱们将抓住数字化、网络化和智能化的方向，减速数字技术利用的步调，深入经济数字化转型，助力打造可继续倒退的将来。 >>报名入口<<【填交胜利后关上手机钉钉查看审核后果】 工夫：2023 年 9 月 8 日 地点：上海黄浦世博园区 - 外滩大会 C5 场馆 议程亮点，先睹为快 让咱们携手参加“云端 AI : 摸索新兴技术和倒退模式”分论坛，独特探讨科技与 AI 的奇观，并独特发明一个更加智慧、凋敝和可继续倒退的将来！

支付宝签名验证支付宝服务器向商家服务器发送音讯签名验证官网文档在对接支付宝领取时无论何种领取，领取实现后支付宝都会有一个异步的回调告诉，此时咱们就须要解决其中的音讯来更新订单状态。因为接口是对外开放的谁都能申请，所以须要留神接口平安，支付宝给咱们发送的音讯会带有签名，避免音讯被篡改 1. 当咱们收到音讯是首先就须要对内容进行签名验证支付宝官网并没有提供Go的sdk// CheckSign 校验签名// @Description: 校验异步告诉签名// @param req_body 申请body a=1&b=2// @param public_key 支付宝公钥// @return bool 后果// @return errorfunc CheckSign(req_body string, public_key string) (bool, error) { var sign string input := map[string]string{} //解析查问字符串 val, _ := url.ParseQuery(req_body) for k, v := range val { if k == "sign" || k == "sign_type" { if k == "sign" { sign = v[0] } continue } //URL解码 value, _ := url.QueryUnescape(v[0]) input[k] = value } return checkSign(input, sign, utils.GetPublicKey(public_key))}// 自定义排序type kv struct { Key string Value string}type SortKv []kvfunc (s SortKv) Len() int { return len(s)}func (s SortKv) Less(i, j int) bool { return s[i].Key < s[j].Key}func (s SortKv) Swap(i, j int) { s[i], s[j] = s[j], s[i]}// 解决数据验证签名func checkSign(input map[string]string, sign string, public_key string) (bool, error) { var ListKv SortKv for key, val := range input { ListKv = append(ListKv, kv{ key, val, }) } sort.Sort(ListKv) var sign_str string for _, v := range ListKv { sign_str += v.Key + "=" + v.Value + "&" } sign_str = strings.TrimRight(sign_str, "&") fmt.Println("---------------------------------") fmt.Println(fmt.Sprintf("签名字符串：%s", sign_str)) fmt.Println(fmt.Sprintf("sign：%s", sign)) fmt.Println(fmt.Sprintf("public_key：%s", public_key)) return utils.Rsa2PubCheckSign(sign_str, sign, public_key, crypto.SHA256)}// rsa2公钥签名验证func Rsa2PubCheckSign(signContent, sign, publicKey string, hash crypto.Hash) (res bool, err error) { hashed := sha256.Sum256([]byte(signContent)) pubKey, err := ParsePublicKey(publicKey) if err != nil { return false, err } sig, _ := base64.StdEncoding.DecodeString(sign) err = rsa.VerifyPKCS1v15(pubKey, hash, hashed[:], sig) if err != nil { return false, err } return true, nil}// 组装公钥func GetPublicKey(pubkey string) string { PREFIX := "-----BEGIN PUBLIC KEY-----" SUFFIX := "-----END PUBLIC KEY-----" return PREFIX + "\n" + pubkey + "\n" + SUFFIX}// ParsePublicKey 解析公钥func ParsePublicKey(publicKey string) (*rsa.PublicKey, error) { block, _ := pem.Decode([]byte(publicKey)) if block == nil { return nil, errors.New("公钥信息谬误！") } pubKey, err := x509.ParsePKIXPublicKey(block.Bytes) if err != nil { return nil, err } return pubKey.(*rsa.PublicKey), nil}2. 签名能够避免音讯被篡改然而不是阻止重放攻打，所以咱们还须要验证内容的合法性以下是官网文档原文1. 商家须要验证该告诉数据中的 out_trade_no 是否为商家零碎中创立的订单号。2. 判断 total_amount 是否的确为该订单的理论金额（即商家订单创立时的金额）。3. 校验告诉中的 seller_id（或者 seller_email ) 是否为 out_trade_no 这笔单据的对应的操作方（有的时候，一个商家可能有多个seller_id/seller_email）。4. 验证 app_id 是否为该商家自身。

大家好，我是小悟 曾经有小伙伴开始应用主动解决【支付宝交易领取投诉管理系统】，所以具体介绍一下如何配置。 浏览这篇文章之前，联合这篇【连夜干进去一个主动解决【支付宝交易领取投诉管理系统】，反对多商户】干货食用更佳。 1、商户信息 商户名称：利用id所属的利用名称。 利用id：支付宝开放平台-控制台-利用详情页-左上角。 利用私钥证书门路：支付宝开放平台-控制台-开发设置-接口加签形式（密钥/证书)。设置好当前把下载到的【利用私钥_RSA2_PKCS8.txt】后缀改一下，重命名成【appCertPrivateKey.crt】，而后上传服务器，复制证书所在位置门路即可。 利用公钥证书门路：支付宝开放平台-控制台-开发设置-接口加签形式（密钥/证书)。设置好当前把利用公钥证书下载下来上传服务器，复制证书所在位置门路即可。 支付宝公钥证书门路：支付宝开放平台-控制台-开发设置-接口加签形式（密钥/证书)。设置好当前把支付宝公钥证书下载下来上传服务器，复制证书所在位置门路即可。 支付宝根证书门路：支付宝开放平台-控制台-开发设置-接口加签形式（密钥/证书)。设置好当前把支付宝根证书下载下来上传服务器，复制证书所在位置门路即可。 利用需签约交易领取投诉解决性能。创立利用后，在产品绑定绑定产品找到 根底性能产品，点击 批改。 在权限集中勾选交易领取投诉解决，点击 确定。 在抉择产品页面，点击确定，实现产品绑定。 新增商户信息后，要选中该商户，而后点击复制地址，提醒复制胜利。 到支付宝开放平台-控制台-开发设置-利用网关，粘贴刚刚复制的地址。这是很重要的一个步骤，只有这个操作胜利了，零碎才会收到支付宝的回调。 2、告诉参数 邮箱告诉参数配置 发送人邮箱：注册一个163邮箱用来当发送方。 发送人邮箱受权码：登录发送人163邮箱账号-设置-POP3/SMTP/IMAP-开启IMAP/SMTP服务和新增受权明码。 接管人邮箱：这个就是用来接管投诉单告诉的接管人邮箱，能够不肯定是163邮箱。 公众号告诉参数配置 公众号appId：公众号后盾-设置与开发-根本配置-公众号开发信息-开发者ID(AppID)。 公众号secret：公众号后盾-设置与开发-根本配置-公众号开发信息-开发者明码(AppSecret)。 公众号模板音讯id：公众号后盾-广告与服务-模板音讯-从历史模板库增加，所在行业要有【IT科技/互联网|电子商务】，而后搜寻增加如下这个模板音讯。 接管人公众号openId：这个就是用来接管投诉单告诉的接管人公众号openId。公众号后盾-内容与互动-用户治理，找到要设置为接管人的用户，而后右击头像地位，点击“查看”，就能够进去开发者模式，data-fakeid后边的值就是用户的openId。 短信告诉参数配置 腾讯云短信secretId：腾讯云后盾-拜访治理-拜访密钥-API密钥治理。 腾讯云短信secretKey：腾讯云后盾-拜访治理-拜访密钥-API密钥治理。 腾讯云短信模板id：腾讯云后盾-短信-国内短信-注释模板治理。 腾讯云短信appId：腾讯云后盾-短信-利用治理-利用列表。 腾讯云短信签名：腾讯云后盾-短信-国内短信-签名治理。 接管人手机号：这个就是用来接管投诉单告诉的接管人手机号。 您的一键三连，是我更新的最大能源，谢谢 山水有相逢，来日皆可期，谢谢浏览，咱们再会 我手中的金箍棒，上能通天，下能探海

大家好，我是小悟 1、问题背景 对于支付宝交易领取投诉，目前有两个入口，一个是从账单详情页中点击【对此订单有疑难】 > 【交易投诉】进行反馈，从这个入口的投诉数据是在支付宝商家平台-账号核心-小程序与代扣等投诉列表显示。 另一个入口是从账单详情页中点击【投诉】 > 【举报中心】进行反馈，从【投诉】 入口的投诉数据是在支付宝商家平台-账号核心-领取交易投诉列表显示。 值得注意的是，【对此订单有疑难】 这个入口须要提供商家PID给支付宝进行开明，入口才会显示进去。 目前支付宝开放平台凋谢的投诉接口也就是从这个入口进行投诉才会走接口，反对包含商户代扣，预受权，小程序领取、app领取、手机网站领取在内的订单投诉。 一旦解决不及时，超时什么的，就会受到相应的处罚。为了更高效地解决用户投诉，为用户提供更好的售后服务体验。所以还是搞个零碎来解决，起码会比拟及时的解决投诉单。废话不多说，来看一下这个零碎。 2、商户信息 这里录入的是商家利用相干信息，能够新增多个商家利用，治理起来也不麻烦，挺不便。 要筹备商户名称、利用id、利用私钥证书门路、利用公钥证书门路、支付宝公钥证书门路、支付宝根证书门路，这些参数信息到支付宝开放平台后盾获取。 当零碎在收到用户投诉时会主动回复，回复的内容就是获取的【商户回复用户内容】字段的值，所以，这个字段填写的内容要敌对、客气、礼貌一点，毕竟，客户可是上帝哦。 如果开启了主动退款，零碎收到投诉单后，也会主动退款，而后将投诉单状态改为投诉完结。 如果将状态改为禁用，则零碎不会收到投诉单告诉。 3、告诉参数 这个配置的是音讯告诉参数，如果商家订单被投诉了，零碎收到投诉单时，会告诉接管人。有三种告诉渠道，邮箱告诉、公众号告诉、短信告诉，任选其一。 邮箱告诉须要设置发送人邮箱(必须是网易云163邮箱)、发送人邮箱受权码、接管人邮箱。这些须要到网易云163邮箱后盾获取。 公众号告诉须要设置公众号appId、公众号secret、公众号模板音讯id、接管人公众号openId。这些须要到公众号后盾获取。 短信告诉须要设置腾讯云短信secretId、腾讯云短信secretKey、腾讯云短信模板id、腾讯云短信appId。这些须要到腾讯云后盾获取。 您的一键三连，是我更新的最大能源，谢谢 山水有相逢，来日皆可期，谢谢浏览，咱们再会 我手中的金箍棒，上能通天，下能探海

大家好，我是小悟 在对接支付宝开放平台的一些罕用性能时，经常须要收到支付宝的回调告诉后果，能力解决业务逻辑。此文介绍通过WebSocket长连贯接入支付宝音讯服务，实现音讯告诉。 包含五局部内容：问题、劣势、配置、代码接入、总结。 问题比方接入互联网平台直付通二级商户进件时，须要晓得这个进件审核的后果，是审核通过还是审核回绝，就要用到直付通商户进件审核通过音讯接口和直付通二级商户进件回绝音讯接口。 再比方接入支付宝小程序模板开发时，须要晓得第三利用受权勾销后果、小程序审核后果、服务商代创立小程序后果等等，就要用到第三方利用受权勾销音讯接口、小程序审核通过告诉接口、小程序审核驳回告诉接口、商户确认服务商代创立小程序后果告诉接口等等。 尽管能够通过对应的查问接口被动发动查问后果，但多个业务后果还需开发多个查问接口，体验终归不如由支付宝服务端侧间接告诉开发者来的好。所以千万别干“脱裤子放pi，多此一举”的事件来，哈哈哈。 为了解决告诉的问题，支付宝开放平台音讯服务提供两种通信协定来接管音讯，一种是基于 HTTPS/HTTP，一种是基于 WebSocket 长连贯。 劣势抉择WebSocket 长连贯有诸多劣势： 官网提供封装好的SDK，开发者无需思考通信、验签、组装报文协定，只有分心依据收到的音讯解决本身的业务逻辑即可。 无需申请https证书，缩小繁琐的证书申请工作，音讯也能触达。 开发者无需额定开发一个服务来接管开放平台的音讯。 相比之下，WebSocket 长连贯有更多的劣势，所以个别抉择应用WebSocket 长连贯来接管支付宝服务端发来的音讯。 配置创立好利用后，在产品绑定-绑定产品，增加对应的产品。 而后在开发设置-音讯服务-FROM平台订阅所需监听的音讯接口，接入形式抉择WebSocket。 接入以上操作是接入的前提条件，务必查看分明再进行代码的开发。 可应用一般公钥形式和公钥证书形式接入，形式不同，SDK的应用也不同，这个取决于设置接口加签是何种形式，这边抉择的是公钥证书形式。 在代码中引入依赖，这边有个留神点就是，如果抉择的是公钥证书模式的话，SDK版本须要应用4.11.54.ALL 及以上版本。 <!-- https://mvnrepository.com/artifact/com.alipay.sdk/alipay-sdk-java --><dependency> <groupId>com.alipay.sdk</groupId> <artifactId>alipay-sdk-java</artifactId> <version>4.11.54.ALL</version></dependency>这个是重点，开发一个支付宝音讯配置类，支付宝服务端有音讯告诉时会主动触发。 @Component@Configuration@EnableConfigurationProperties({AliPayProperties.class})public class AliPayMsgConfig { private static Logger logger = LoggerFactory.getLogger(AliPayMsgConfig.class); private AliPayProperties aliPay; public AliPayMsgConfig(AliPayProperties aliPay) { this.aliPay = aliPay; } @Bean public AlipayMsgClient alipayMsgClient() throws Exception { AlipayMsgClient alipayMsgClient = AlipayMsgClient.getInstance(aliPay.getAppId()); alipayMsgClient.setConnector("openchannel.alipay.com"); alipayMsgClient.setSecurityCertConfig(aliPay.getSignType(), FileUtil.readUtf8String(aliPay.getAppCertPrivateKeyPath()), aliPay.getAppCertPublicKeyPath(), aliPay.getAliPayCertPublicKeyPath(), aliPay.getAliPayRootCertPath()); alipayMsgClient.setCharset(aliPay.getChartSet()); alipayMsgClient.setMessageHandler(new MsgHandler() { /** * 客户端接管到音讯后回调此办法 * @param msgApi 接管到的音讯的音讯api名 * @param msgId 接管到的音讯的音讯id * @param bizContent 接管到的音讯的内容，json格局 */ @Override public void onMessage (String msgApi, String msgId, String bizContent) { logger.info("receive message. msgApi：{}，msgId：{}，bizContent：{}", msgApi, msgId, bizContent); if (StringUtils.equals("alipay.open.app.api.field.changed", msgApi)) { logger.info("用户信息申请记录审核告诉，接管到的音讯内容：{}", bizContent); } else if (StringUtils.equals("alipay.open.auth.appauth.cancelled", msgApi)) { logger.info("第三方利用受权勾销音讯，接管到的音讯内容：{}", bizContent); } else if (StringUtils.equals("alipay.open.auth.userauth.cancelled", msgApi)) { logger.info("用户受权勾销音讯，接管到的音讯内容：{}", bizContent); } else if (StringUtils.equals("alipay.open.mini.version.audit.passed", msgApi)) { logger.info("小程序审核通过告诉，接管到的音讯内容：{}", bizContent); } else if (StringUtils.equals("alipay.open.mini.version.audit.rejected", msgApi)) { logger.info("小程序审核驳回告诉，接管到的音讯内容：{}", bizContent); } else if (StringUtils.equals("alipay.trade.refund.depositback.completed", msgApi)) { logger.info("收单退款冲退实现告诉，接管到的音讯内容：{}", bizContent); } else if (StringUtils.equals("alipay.open.mini.merchant.confirmed", msgApi)) { logger.info("商户确认服务商代创立小程序后果告诉，接管到的音讯内容：{}", bizContent); } } }); alipayMsgClient.connect(); return alipayMsgClient; }}下面代码的AliPayProperties类是配置了利用的一些参数信息，包含利用id、加签类型、利用私钥证书门路、利用公钥证书门路、支付宝公钥证书门路、支付宝根证书门路、编码格局。 ...

大家好，我是小悟 那天中午要午休的时候，看到微信通讯录新敌人有个红色1，像俺这种有强迫症的，那不得去把它点掉。关上一看，加好友的备注是“我是熊二，支付宝开发者社区经营”。 收到支付宝社区的经营增加微信，还说要给俺寄礼品，这太忽然了，心里牵强附会演出了一出心田戏，“这不会是骗子吧？怎么会有人在技术社区上行骗？闻所未闻啊。难道是什么新套路？是要骗俺那菜鸡个别的技术吗？”。 如果真的是骗子，那俺高下得逗一下他啊，俺最喜爱撩拨这些利用互联网行骗的卡拉米了。总之记住只有保持住不贪小便宜的底线，就不会落入他们的网。惋惜没有机会啊，起初细聊之下，原来是之前在支付宝社区写的一篇文章，获了新星奖。 俺都忘了本人在支付宝社区公布过的这个文章，哈哈。所以，嗯嗯，他不是骗子，的确是官网的经营小二，熊二小孩儿，巴拉巴拉。可是我纳闷了，他是怎么找到我微信的？ 还有就是这个文章顶到了社区热文榜单Top3，有点小惊喜，尽管没什么技术含量，菜的一逼，见笑了见笑了，人在家中坐，奖从天上来。 俺感觉这个小礼物还不错，是个解压Enter抱枕，超大回车键，配合插电脑USB应用更佳，嗯，还有点理论作用。 你想啊，当你被leader屌的时候，当产品经理不顾你的想法给你加需要的时候，当测试经理给你测出一堆bug的时候，无处发泄，一拳砸上来，真的很过瘾。此时无声胜有声，俺也是有脾气的。（发此文时已屏蔽这些人，不用为我放心，甚安，甚安） 最初，感激支付宝官网，感激经营熊二。不过大家在陌生人增加好友时，尤其是被动给你送货色要信息什么的，还是须要审慎，留个心眼更好。好了，我写bug去了，哦不，是改bug。 您的一键三连，是我更新的最大能源，谢谢 山水有相逢，来日皆可期，谢谢浏览，咱们再会 我手中的金箍棒，上能通天，下能探海 上一篇：天下苦“集体公众号认证”久矣，吾闻今可

对于支付宝小程序模板开发，之前写过相干的介绍，详情请看 【支付宝小程序模板开发，一整套流程】这篇文章。 和微信一样，支付宝也有通过接口创立小程序的服务。不过在对接模板开发那时候，还没凋谢这个接口，是一个邀请制的，没有被官网被动邀请到就没有权限调用。 当初是曾经全量凋谢，只有你是服务商就能够调用。抽空更新了通过接口创立小程序的性能，集成到本人的零碎，能够更不便帮助商家创立小程序。 服务商在开发之前，须要进入第三方利用详情 > 产品绑定，确保产品列表中已增加小程序。若没有，则点击绑定产品增加产品。 给商家创立小程序后，支付宝会向调用接口时传入的支付宝账号发送告诉来确认。须要进入第三方利用详情 > 音讯服务 > FROM平台，订阅 alipay.open.mini.merchant.confirmed 告诉，用于接管商家确认的后果告诉。 小程序创立前须要筹备以下材料： 商家登录支付宝的邮箱账号或手机号；商家法人名称；营业执照企业名称；营业执照编码；小程序名称；商家联系人手机电话；商家联系人名称；若商家的营业执照名称为空，应依照规定补充对应内容，填写规定为 个体户+法人名称 ，例如 个体户张三。 申请通过后，零碎会发送确认音讯到商家的支付宝账号。商家在支付宝 APP 中登录创立时传入的支付宝账号，点击音讯进入小程序受权确认页面，点击确认创立并受权，并输出领取明码进行确认，即可实现小程序的创立。 商家回绝或者24小时内未确认，则该次工单生效；商家24小时内回绝2次，则服务商在24小时内无奈再为该商家创立小程序；如果商家未收到确认音讯，商家可关上支付宝客户端搜寻【支付宝开发者助手】小程序，点击音讯查收确认音讯。 或者搜寻【商家平台音讯核心】小程序，点击待办工作查收确认音讯。 服务商代商家创立小程序，待商家确认后服务商代创立的小程序才会失效，若商家超过确认工夫则服务商创立的小程序会主动作废开释占用的小程序名称。 实现创立小程序后，在商户列表选中商户，点击商户受权会弹出受权码。 关上支付宝扫码受权。 因为是刚创立的小程序，所以有些信息是空的，能够到类目治理设置类目。 而后到根本信息设置应该图标、利用简介、应该名称、英文名称、利用形容、客服电话、客服邮箱。 山水有相逢，来日皆可期，谢谢浏览，咱们再会 我手中的金箍棒，上能通天，下能探海 上一篇：微信领取服务商，消费者投诉解决零碎

立刻返回直播间预约观看 从icon到card，一场内容前置化的改革从 Windows 时代开始，应用程序图标就成为了用户（流量）的主入口，始终继续到挪动端时代。 图标即入口的形式，尽管足够不便但却不够直观，用户起码须要一次点击后能力接触到想要的信息。 而在近期 iOS 和局部 Android 零碎的更迭，也逐步实现了把局部内容和服务前置的卡片。而越来越多的 App 也实现了通过卡片作为内容展现以及服务入口的场景。 魔方卡片（Cube）是「支付宝」外部自研的一套跨平台、动态化卡片解决方案，是服务于利用页面内的区域动态化技术。 本期 CodeHub 将围绕 Cube 技术的架构逻辑，论述其渲染和生产过程，并领导开发者实现初阶的技术调试。立刻返回直播间<u>预约观看</u> CodeHub#7 「支付宝」全新卡片技术栈 直播福利，超百份 mPaaS 周边等你拿互动一：11/8 19:00观看本期 CoedHub，参加互动问答，即可取得 mPaaS、掘金限定周边好礼。（以下礼品随机发放） 互动二：关注公众号「mPaaS」回复“Cube”，参加互动问答，即可取得蚂蚁周边小礼物一份。延长浏览：Cube 技术解读 | 支付宝新一代动态化技术架构与选型综述

简介： mPaaS 小程序市场正式上线，海量小程序一站式集成，用场景拉高终端沉闷水位。 01 小程序破壁打算从 2018 年「支付宝」将支付宝小程序全量凋谢给用户应用开始，整个小程序生态市场产生了新一波的震荡。 小程序商家通过「支付宝」获取到更多流量曝光以及更晦涩的领取体验，而「支付宝」也通过小程序生态，从原来简略的领取工具一跃成为了国民级生存服务平台。 就像网上已经流传的一个段子所说： “说进去你可能不信，这个APP最后是用来领取的。” “爷爷，你们为什么用一个打车软件付钱呢？” 各行各业的壁垒，正在被“小程序”一点一点地抠破。 02 小程序市场上线：复刻下一个支付宝汇聚出行、医疗、快消等若干生态场景的行业头部服务，mPaaS 小程序市场为各类 App 提供丰盛的小程序场景供应。 诸如高德、盒马等上百款小程序，能够通过 mPaaS 小程序市场一站式集成。 03 支付宝同源框架，实现轻松适配mPaaS 小程序框架能力源于支付宝，基于同一套技术标准，小程序方无需二次开发，即可上架 mPaaS 小程序市场。 企业 App 通过集成 mPaaS SDK，并从小程序市场引入所需小程序，上架自有 App，体验成果与原生支付宝小程序完全一致。 04 平台与商户跨端联结经营，让1+1＞2除了获取小程序本身服务能力以外，企业 App 还能够与小程序商家单干，定制联结经营流动优惠，发放专属优惠红包等，拉新促活，实现单方互惠共赢。 05 海量小程序等你来点亮mPaaS 小程序市场现已入驻近百款三方小程序利用，你可依照接入需要点亮所需 费用阐明1：mPaaS 私有云用户，可登录阿里云控制台，收费抉择任意非阿里系小程序，集成到本人的 App 中。 费用阐明2：mPaaS 专有云用户以及动向接入阿里系小程序（盒马鲜生、淘票票、高德打车等）的私有云用户，可关注「mPaaS」公众号并回复“小程序市场”，获取相干集成规定。 原文链接 本文为阿里云原创内容，未经容许不得转载。

前言在国内环境，宽广的集体站点及利用，因为业务倒退需要，往往须要以集体资质申请对接微信和支付宝的领取渠道。然而当初无论是微信还是支付宝，仅反对具备企业资质的主体申请接口对接，对集体开发者而言，路曾经齐全卡死了。然而道高一尺，魔高一丈，聪慧勤奋的国人想出了很多办法绕过这些限度。本文次要分析以后具备可操作性的两种办法，供有缘人参考决策。 1.通过金额原理安卓端的支付宝，在收到收款音讯时，会弹出收到 XX 元的利用栏告诉音讯。这个告诉栏音讯，是能够通过编程伎俩获取到的。只须要监听用户的告诉栏音讯，判断是否是支付宝的告诉，而后解析外面的金额，就具备了自定义回调接口的根底。 想像这样一种场景：用户A在网站发动100元的领取，而后网站后盾出现100元的收款二维码（这个二维码能够当时生成放在后盾）进去，用户付款胜利后，在商家的挪动端，通过程序监控到支付宝收到了100元的订单，而后给网站回调。ok，后续的流程和回调逻辑，能够持续做了。 场景再简单一点，那如果同一时间，有另外一个用户B也发动了100元的领取，可能还没有付款。同时商家挪动端检测到了一个100元的订单，进行回调。因为只有金额信息，网站后盾无奈辨别这个100元的订单，到底属于用户A，还是属于用户B，一下子就乱套了。波及到钱的事都是小事，预计用户得炸了。 这种并发场景，能够通过一个很简略的技巧解决，即当多个用户发动同一金额的领取时，给不同的用户，出现不同的金额二维码。比方下面的场景，用户A，出现100元的二维码，同一时间用户B发动100元的订单领取申请，那就出现99.99元的领取二维码，用户C再来，就出现99.98元的领取二维码，顺次类推。这样，挪动端监测到的是不同的金额，因而也就具备了通过金额，辨别订单和用户的能力。 长处原理简略，实现简略。账号比拟平安，没有被支付宝风控的危险。毛病下面这种通过不同的金额实现回调的形式，毛病是非常明显的，轻易列几点： 仅反对支付宝。微信的挪动端告诉音讯外面，并不蕴含金额信息，因而这种办法就熄火了。因为是通过金额进行订单和用户辨别，因而须要提前上传收款二维码，包含用于应酬并发场景的大量高低浮动的二维码。对于有大量定价的站点和利用，这个工作量是十分可观的。不利于定价调整。每次定价调整，都须要上传大量收款二维码。不反对任意金额。还是因为要当时上传收款二维码。代表通过金额辨别订单和用户的形式实现领取接口回调，因为原理简略，实现老本并不高，因而当初市面上有大量基于该原理实现的领取接口平台。列举如下： 1.paysapi 点评：paysapi 官网提到反对微信。其实是通过上传一张任意金额的微信二维码实现的。也就是用户发动领取后，须要人肉的输出领取金额，这在体验上是比拟差的。2.goddpay 点评：和 paysapi 的网站还是一毛一样。3.领取吧 点评：无2.挪动端 hook原理挪动端安卓平台，是一个比拟凋谢的平台。咱们运行的简直所有软件，都是能够通过肯定的伎俩，进行底层编程 hook，自定义其行为的。比方微信音讯防撤回，摇骰子划拳舞弊，主动抢红包，还有支付宝的余额 & 等级自定义装逼等性能，都是通过诸如 xposed, virtualxposed 等 hook 框架技术编程实现的。 同样，微信和支付宝的收款二维码主动生成，包含领取胜利的音讯检测，也是能够通过 hook 的伎俩，进行编程作业的。大抵流程如下： 用户发动订单领取申请，而后挪动端 hook 软件，监测到这个领取申请，获取到金额和平台（微信还是支付宝）信息。调用相干的软件，注入相干的二维码生成行为，ok，相干金额的二维码生成胜利，再显示给用户。 用户领取胜利后，同样的，不论是微信，还是支付宝，都会检测到相干的领取胜利信息。挪动端 hook 软件，同样也能够检测到。而后进行回调。再后续，就是业务零碎解决流程逻辑了。 毛病须要装置挪动端 hook 框架，比方 xposed, virtualxposed 等。其中，xposed 软件，还要求零碎必须 root。存在肯定的平安危险。因为 hook 软件，能够监测到微信和支付宝的软件行为，包含你的明码信息，因而存在肯定的平安危险。账号存在被风控的可能。不论是微信还是支付宝，对自家软件被自定义的行为，都是零容忍的。长处与上述通过金额实现回调的形式比起来，这种形式有显著的长处，就是不须要提前上传大量二维码，反对任意金额的领取解决。同时反对微信和支付宝。并发能力，能够绝对做到比拟高。代表基于 hook 形式实现领取接口回调，对软件开发者的要求较高。因而相干的解决方案并不多见，现简略列举如下： 微米富点评：基于 virtualxposed。尽管网站简直和 paysapi 一毛一样，但接口回调实现的原理，却天壤之别。另外，微米富还有一个非凡的中央，就是其在挪动端 hook 软件外面，内置了一个微型的 web 服务器，间接接管并解决用户的领取申请。这也导致了几个问题，一是限于挪动端 web 服务器的性能，并发的解决，有肯定的限度。二是领取页面的调整和定义，须要批改挪动端代码。三是软件配置流程简单（web 服务器代理相干的配置）。greenyep点评：基于 virtualxposed。greenyep 和 微米富裕一些轻微的区别。它并未在挪动端 hook 软件外面内置 web 服务器，而是采纳定时检测的形式，去后盾服务检测订单信息。这样做的益处是能够有一个中心化的平台做订单的调度和统计，同时性能也较内置 web 服务器的形式，有肯定的进步。毛病也是显著的，并不不便软件的散发，做一些私有化的部署。倡议如果站点和利用的领取场景比较简单，同时对微信领取没有强需要，能够思考诸如 paysapi 等通过金额进行辨别实现接口回调的平台。如果对平安及危险敏感度较高，同样倡议思考 paysapi 等平台。如果领取场景比较复杂，须要反对任意金额，同时对微信和支付宝渠道均有需要，能够思考诸如微米富，greenyep 等平台。接上，如果对系统稳定性，并发能力要求较高，能够思考 greenyep 平台。接上，如果冀望公有部署的便捷性，能够思考微米富平台。正规渠道类 ...

About Scan随着支付宝的线下场景不断扩大，收钱码、口碑、共享单车、充电宝、停车缴费等产品让咱们的生存越来越便当。 二维码因为成本低、兼容性好成为了线上线上最次要的连贯工具，也因而面临更多新的挑战。 因为二维码是一种点阵式信息编码方式，任何视觉上的缺损、蜿蜒以及光线作用都会极大的影响辨认成功率，如果辨认艰难也就意味着用户可能抉择放弃，影响领取体验也影响用户心智。 源自支付宝的扫码组件，全网收费凋谢！欢送下载接入~ 下载地址关注「mPaaS」CSDN 账号即可收费下载 https://download.csdn.net/download/m0_47737908/15684443 插件介绍本插件是支付宝 mPaaS 的扫码组件，让您的 app 能够领有像支付宝一样的扫码体验，辨认速度、识别率远超开源扫码。扫码组件完全免费提供应用，接入时须要您在阿里云上进行注册开明并将 mPaaS 扫码增加到您的工程即可。 接入过程中，您遇到任何问题，都能够在钉钉上搜寻「32843812」进群进行解答。 欢送大家应用不同带有扫码性能的 App，对以下三种二位码进行扫码辨认，体验 mPaaS 扫码弱小的辨认能力和辨认速度 弱光二维码 反光二维码 含糊二维码 插件应用筹备1.购买插件，抉择该插件绑定的我的项目。 2.在 HBuilderX 里找到我的项目，在 manifest 的 app 原生插件配置中勾选模块，如须要填写参数则参考本文增加。 3.依据本文的提供的文档开发代码，在代码中援用插件，调用插件性能。 4.打包自定义基座，抉择插件，失去自定义基座，而后运行时抉择自定义基座，进行 log 输入测试。 5.开发结束后正式云打包 付费原生插件目前不反对离线打包。 Android 离线打包原生插件另见文档 https://nativesupport.dcloud.net.cn/NativePlugin/offline_package/android iOS 离线打包原生插件另见文档 https://nativesupport.dcloud.net.cn/NativePlugin/offline_package/ios 注意事项：应用 HBuilderX2.7.14 以下版本，如果同一插件且同一appid下购买并绑定了多个包名，提交云打包界面提醒包名绑定不统一时，须要在HBuilderX我的项目中manifest.json->“App原生插件配置”->”云端插件“列表中删除该插件从新抉择 插件应用流程1. 开明阿里云 mPaaS登陆阿里云账号拜访mPaaS 产品页，点击「立刻开明」，即可开沟通 mPaaS 产品。 2. 创立 mPaaS 利用开明后您须要创立一个 mPaaS 利用 3. 配置 Config 并下载3.1 Android3.1.1 填写配置信息，并上传签名 APK。点击 代码治理 > 代码配置 > Android，输出 Package Name（利用包名）（此处以 com.mpaas.demo 为例），上传编译并增加签名后的 APK 安装包。对于疾速生成签名后的 APK 相干信息，请参见 生成控制台用签名 APK。 ...

去年春节期间支付宝推出的集五福的活动可谓风靡一时，每张福卡背面都有刮刮卡，里面有来自蚂蚁金服、阿里巴巴以及合作伙伴的上百种权益。集五福的活动集中在春节前的几天，具有很强的时效性。所以如何实现权益和投放人群的自动匹配，解决系统的冷启动问题，优化转化率和提升用户体验，就成了一个在线学习的优化问题。 之前我们搭建一个这样的系统需要的模块非常繁杂。我们需要日志收集、数据聚合、样本的拼接和采样等流处理任务，需要对接模型训练、模型验证等机器学习模块，需要有把模型实时加载的模型服务，还需要其他的配套设施等等。众多模块的衔接极大地增加了系统的复杂性。 由于涉及的系统比较多，我们之前的系统遇到了比较多的问题。比如大促时为了保证高优链路的稳定性，上游某些数据处理的链路就会被降级了，但下游同学并不知情。另外一个很常见问题的是流批逻辑不一致，需要离线特征来训练基准模型，同时在线计算的特征来对模型进行实时更新。这两个模块一个在离线一个在线，曾经出现过处理逻辑的细微差别对业务效果造成了很大的影响。 总结下来，我们曾经遇到的坑可以归结为三类： SLA：整个链路的SLA会受到每个模块的SLA的影响，并随着模块的增多而放大，稳定性成为制约业务发展的重要因素。系统效率：模块之间的衔接多数是通过数据的落盘来进行，模块间的调度通过系统调度来实现，造成不必要的I/O、计算和网络开销。开发和运维的成本：各个模块风格迥异，开发模式、计算框架、甚至代码风格都不一致，开发和运维对接时需要花很多时间去熟悉系统，降低业务开放的效率。 一个理想的系统应该提供什么样的能力呢？可以从“稳快简”三个方面来讲：首先从数据来讲它需要保证数据和计算一致性，实现整个链路端到端的SLA，数据一致性和链路的稳定是保障业务稳定的基础。第二是我们需要去优化系统效率，我们希望把这十几个系统的衔接转换成系统内部的衔接，希望把这些作业调度转换成任务的调度，通过这样转化我们希望把计算与计算之间协同调度，从而提高系统效率和降低网络带宽使用的目的。一个融合的系统也可以对开发和运维提供非常大的便利，以前需要对接十几个系统，现在只要对接一个系统就可以了。以前我们在应急的时候需要回溯好几个业务来发现问题，现在融合在一起的系统调试也会更加容易。 在线机器学习最外层需要透出数据处理、模型训练、模型服务三个能力。这三个能力反映到对计算引擎框架上的需求是敏捷的调用机制、比较灵活的资源管控，以及比较完善的容错机制。上层的系统往往是通过不同编程语言来实现的，因此还需要有多语言接口。通过对底层需求的考量以及现在各框架的特点，最后我们选择了Ray为融合计算的底座。 Ray是由伯克利大学RiseLab实验室发起，蚂蚁金服共同参与的一个开源分布式计算框架，它提出的初衷在于让分布式系统的开发和应用能够更加简单。Ray作为计算框架可以帮我们实现上面“稳快简”三个目标。Ray作为计算框架具有敏捷的调度机制，用它可以一秒钟进行上百万次任务调度，它也可以根据计算对资源使用的需求实现异构调度。 在目前比较流行的分布式框架，都有三个比较基础的分布式原语，分布式任务、对象和服务。而我们常用的面向过程的编程语言中，也刚好有三个基本概念，函数、变量和类。这三个编程语基本概念刚好可以和分布式框架的原语对应起来。在Ray系统中，可以通过简单的改动，实现他们之间的转换。 左边是一个简单的例子，在这个函数前面需要加入一个“@remote”修饰符，就可以把一个函数转换成为分布式任务。任务通过“.remote”调用执行，返回值是一个变量，又可以参与到其他计算中。 右边是另一个例子，通过加“@remote”修饰符的方式可以把一个类转变成服务。类中的方法可以通过“.remote”调用变成一个分布式任务，和函数的使用非常相似。通过这种方式可以实现从单机程序到分布式任务的转变，把本地的任务调度到远程的机器上进行执行。 Ray上应该做怎么样的调度，衡量指标就是系统的效率问题，系统的效率很多时候取决于计算和数据的组织方式，比如说我们要计算Add(a,b)，首先这个函数在本地会被自动注册并且提供给本地调度器。之后通过全剧调度器和第二个节点的本地调度器一起协同工作，把A备份到第二个节点执行Add这个操作。它还可以根据A和B的数据大小来进行进一步的调度和控制优化，A和B可以是简单数据类型，也可以是比较复杂的变量或者矩阵。 Ray上面提供多语言API接口。由于历史原因，在蚂蚁金服内部流式计算使用最多的语言是Java，而机器学习建模比较普遍使用的语言是Python。我先希望重用Java语言实现的流处理算子，同时保留Python进行机器学习建模的便捷性。Ray上面提供这样的多元化支持就非常方便我们做这个事情，用户在上层开发的时候可以可以方便地使用Java和Python分别进行流处理和机器学习模型的开发。 对于在线机器学习来说，它最核心需要解决的问题是要打通流计算和模型训练，那我们需要使用一个介质，这个介质能够比较方便的将两者衔接在一起。之前我们介绍Ray的几个特点，如提供多语言的接口、灵活的调动机制，这是因为这两个特点在Ray上可以比较方便做这个事情，Ray可以起到衔接的作用。数据处理的最后一个节点是流计算的输出，worker节点消费数据，是模型训练的输入。Ray就可以通过调度机制把这两个计算调度在一个节点上，实现数据共享从而实现两个模式的打通。通过这种方式不仅可以兼容流计算和机器学习，也可以将其他模式进行衔接。 计算中DAG概念最开始是为了解决多阶段分布式计算的效率而提出的，主要思想是通过调度减少计算时的IO。但是以前的计算DAG，在任务执行的时候它就已经确定了，但我们在机器学习的任务里面，很多时候我们会需要设计新的模型，或者对模型的超参进行调试，我们希望看到这些模型能被加载到链路上，看到业务效果的同时又不想线上已经有的模型的训练和服务被中断。在Ray系统内部，计算的过程中可以动态的生成另外一个节点，我们可以利用这个特性来增点和变，从而动态的对DAG进行局部修正。 在线系统和离线系统之间比较大的区别，在于如果一个离线系统里的任务挂了，一般来说可以通过重启机器的方式来解决，但对在线系统来说，出于时效性的考虑，我们不能简单的通过重启机群回溯数据的方式来解决。因此就需要有比较完善的容错机制。我们在模型训练的时候可以利用Ray的Actor来拉起模型训练的worker和server节点。如果worker或者server节点处于不健康状态，我们就可以利用Actor的容错特性通过血缘关系来对数据和计算进行恢复，从而实现容错的训练。 我们比较追求链路的时效性，模型能够尽快的拟合实时数据里。但是追求时效性的同时也要保证整个链路的稳定性，在敏捷和敏感之间达到平衡。我们从三个方面，系统稳定性、模型稳定性、机制稳定性来保障整个链路的稳定性。 系统稳定性，里面包括数据实时性和强一致性保障。模型稳定性，我们希望设计的模型能够拟合实时数据流，但同时要防止在线学习链路在各种不确定性因素下，如数据噪音，造成的效果退化。因此我们需要考虑在线特征和离线特征的组合，在模型设计上需要考虑到深层模型和浅层模型对数据的敏感性和噪音的容忍度。机制稳定性，赛马机制、快速回滚策略。除了之前用Ray来实现融合以及它带来的好处，我们也做了非常多的模块建设，TF融合、稳定性保障、样本回流、延迟样本修正、数据共享、流批一体、端到端强一致、模型增量导出。我们把这个平台上线了支付宝的几个场景，从下面的几个数字可以一探效果： 99.9%的全链路SLA业务指标有2%到40%的提升几十分钟模型延迟到4、5分钟，并且可以根据业务的需求进一步降低机器使用降低了60%我们从去年8月份开始建设，今年2月份开始上线第一个场景，在支付线财富线也都取得了不错的效果，接下来我们会推广到蚂蚁金服的其他业务线上。 基于融合计算机器学习，它是融合计算和机器学习这两种模式的有机组合，实现优化资源共享。我们通过这两方面的探索初步验证了融合计算的框架，融合计算是旨在数据共享来进行计算模式的兼容，融合的本质是开放，开放的基础是实现数据的互通，只要我们能够方便的实现各模式之间的数据互通，并且能够保障它们数字的实时性和端到端的一致性，就可以实现复杂场景里面需要多种模式进行组合的计算。模块的衔接就像搭乐高积木一样，基本的模块可能只有几种，但是搭建出复杂且多变的系统。 阿里云双11领亿元补贴，拼手气抽iPhone 11 Pro、卫衣等好礼，点此参与：http://t.cn/Ai1hLLJT 本文作者：缪克卢汉 阅读原文 本文为云栖社区原创内容，未经允许不得转载。

对于蚂蚁金服研究员王益而言，2019年是个颇有纪念意义的年份。今年他整40岁。从10岁开始，写代码整30年。这30年来，他当过“不务正业”的学生，创纪录地在大一就考下系统分析员，“单枪匹⻢”闯荡过从国内到硅谷的多家知名互联网科技公司，和AI领域许多传奇人物都有所交集。不惑之年对于许多工程师来说，或许已是需要焦虑的年龄，但40岁的王益在蚂蚁金服每天都过得很充实：起床，自由泳一千米，然后去做他最喜欢的事——写代码和组织大家一起写代码。2019年9月11日，在上海举办的Google开发者大会上，蚂蚁金服研究员王益分享了新开发的分布式深度学习系统ElasticDL。这是他来到蚂蚁金服的一年之中所做的第二个开源项目，主要用于大幅提升集群总体利用率以及深度学习团队的工作效能。之前开源的 SQLFlow系统在短短的几个月之间，已经在GitHub上获得了三千多颗星星。 2019对于王益而言是个颇有纪念意义的年份，今年他整40岁，写代码整30年。 这听上去是一件不可思议的事——30年前，上世纪的80年代末，他在⻓沙上小学，全城都很难找出一位能教编程的老师，个人电脑更是一个陌生名词，一台以苹果2为原型、可以用BASIC语言编程的 “中华学习机”售价7000人⺠币，在当时几乎可以买下一套房子。幸运的是，王益在10岁那年得到了这样一件贵重的礼物，从这台学习机和一本BASIC语言教材开始，他开启了与代码结缘的人生。 “我那时不是个好学生，经常受‘别人家的孩子’打击，老师和同学都觉得写代码是不务正业。”回想起30年来的经历，这位清华博士、足迹从国内到硅谷历经多家知名互联网科技公司的学霸笑谈自己“活得比较任性”，“但我就是想做与众不同的事。别人越说这样不行，我就越想用这种方式证明自己。” 初中毕业那年的暑假，他用“中华学习机”和自己焊接的电路板，把自家的老式“威力牌”双筒洗衣机改造成了自动洗衣机。同时，他用Apple BASIC语言和6502汇编混合编程，写了人生中第一个游戏。高中三年，其他同学努力备考，他却加班加点自学了大学计算机系所有课程，随后参加计算机水平考试，先后获得了程序员、高级程序员、以及最高级别系统分析员资格。2018年，他获得Google APAC Innovation Award。从不断摸索代码世界的少年时代，到专注于AI基础架构和系统开发的求学工作生涯，这份“任性”一直伴随他走到今天。 “我经常从零开始。选择去做什么的一大标准是‘有意思’。” 相比于规划一条稳妥的职业发展道路，王益更愿意顺应自己强烈的好奇心，去选择最困难但最有意思的探索方向。他在中国和美国互联网公司都工作过，也分别在美国公司的中国分部和中国公司的美国分部工作过。他的足迹遍及国内BAT三家。任性的是，每次跳槽， 他都从一个人coding一个创新项目开始，吸引同事们加入，从而组建团队。虽然2011年就在腾讯作为广告系统技术总监，但是他从不在跳槽时要求带何等规模的团队。 2014年，王益带着妻子和两个月大的女儿离开腾讯移居硅谷。“一切都归零了。工资减半。”他笑笑说。不过凭着多位学界和业界领袖的推荐，他很快就安顿下来，不到一年就开始在硅谷创业，作为Head of Research Scienets 参与创建了AI创业公司 ScaledInference。这是一家人才济济的创业公司。人工智能行业的领袖人物、加州大学伯克利分校的Michael Jordan教授是这家公司顾问。陆奇曾代表微软到访，讨论技术合作。“可惜我们不够关注业务落地，做的不够好。技术研发一定要有落地的能力。”事后，王益不无遗憾的说。 在加入蚂蚁之前，王益在百度硅谷研究院工作，负责开源深度学习系统PaddlePaddle。在历经两年的艰苦开发，新一代技术Fluid开始系统地落地百度各个业务之后，他发起了他在 PaddlePaddle的最后一个子项目——一条太阳能驱动的无人驾驶船。这是一条双体船，由他和五岁女儿的两条划艇构成。船上的笔记本电脑运行基于immitation learning的人工智能系统，自动学习驾驶者的技巧。为了船体稳定，他在自家⻋库里焊接了连接两条划艇的金属框架。便于拆装的结构，可以装上他的皮卡，方便下水测试。 做出加入蚂蚁金服的决定，也是出于同样的理由——“有意思”。“这里的业务很新颖，对AI 有着更加多样化的需求。”如何用AI解决金融行业的问题，是和他以往所面对的完全不同的全新挑战。 SQLFlow：分析师与AI模型间的翻译加入蚂蚁金服不久，王益就意识到自己之前的朦胧猜想越来越清晰地被验证：和主要依靠流量与广告赚钱的传统互联网公司不同，蚂蚁金服不是纯互联网公司，它有独特的商业模式和对于工具的独到需求。 此前的十多年中，他的大部分经历是在传统互联网行业做搜索推荐技术，这一类业务所需的模型总数比较有限，只需要算相关性的模型、排序的模型等，一个成熟的模型通常会有几十上百人维护，每年修改调整去提升性能。但在蚂蚁金服，这种模式被颠覆了。因为金融行业的数据远比社交、电商和搜索引擎的数据要稀疏，很难完全靠机器来挖掘出规律，必须依赖金融专业分析师的智慧。分析师大量使用SQL语言来验证想法，或者进一步做探索，这些结论对金融业务非常关键。 每一位分析师平均每天要提交很多个AI任务，这些任务对AI模型的需求各不相同，差异性特别显著。但是，模型是建模团队用Python语言描述的，分析师们如果要调用模型，要么需要学习Python语言，要么需要专配一位工程师，效率难以显著提高。 语言不通，所以需要翻译，那么能否在SQL和Python之间也设立一个翻译？ 基于这样的想法，王益和团队一起开发了SQLFlow，这个系统好比一个“翻译机”，能将分析师们输入的SQL命令翻译成Python语言，这样一来，分析师无需学习Python，使用SQL语言就能够处理数据、训练AI模型，并使用训练好的模型来回答业务问题。这套系统更重要的作用，是重新界定了分析师、建模团队和工具开发团队的责任，让同一个机构里的这三个工种有了清晰的分工，有效形成合力。 ElasticDL：一个“聪明”的智能学习系统通过SQLFlow被调用的模型，会基于基础架构来进行分布式执行，这套分布式的智能学习系统，就是刚刚开源的ElasticDL。ElasticDL基于TensorFlow2.0构建，是面向未来的下一代技术，其很重要的独特之处，就在于它很“聪明”。 首先，它能和SQLFlow一起，补足简短的SQL程序翻译成复杂的Python程序的过程中所需的信息。根据深度学习模型的数学特性，它能够决定用什么样的方式来进行计算，还能在计算过程中智能地决定一些参数。 其次，它的容错和弹性调度机制，能让集群的利用效率更高。用户提交需求之后，不再需要“排队”等待资源释放才开始计算，计算会“插空”进行，这样闲置和等待时间更短，大幅度减少了浪费在等待上的系统资源和人力资源。 在数据收集能力极大提升的今天，拥有能算“大”数据的能力，比算得快更为重要。这是王益一直未变的观点。ElasticDL的开发，着眼之处不仅是计算本身的提速，更是针对云计算时代中，数据量大且多人共用集群的特点而进行的调度优化。“等待的时间有时会占到60%-80%，如果不能有效减少这部分的浪费，只是提升计算速度的话，对整体效率的提升就是杯水⻋薪。”王益说，但是ElasticDL的弹性调度能在资源不足的情况下，有多少就先调用多少，让计算尽快启动。 ⻓远看来，ElasticDL还将支持各种学习模式，以顺应金融行业对AI的多种需求。很多在传统互联网行业可有可无的训练模式，在金融行业都很有广阔的应用场景，比如保障数据安全的同时还能共享数据背后规律的共享智能，或者建立可以进行各种大胆试验的虚拟环境，这些面向未来的需求，在ElasticDL的设计之中也有所考虑。 对于一直在做AI基础架构的王益来说，对AI有着各种不同需求的金融行业，是一片全新的驰骋疆场。无数新的问题等待他去尝试，去寻找新的解法，让他乐此不疲。 实践出真知，无需等待理论完美证明“数学模型和分布式架构是互相影响的，只了解其中任何一面，在这个领域都做不好。要为深度学习的架构去改数学模型，也要因为数学模型的数学特点去做架构调整。” 站在今天回顾过去做AI基础架构的十多年，王益觉得这是自己所学到的最重要一课。 这一想法的首次验证，是在他2009年离开Google进入腾讯之后写出的Peacock系统。和在Google所做的语义理解项目不同，这次他将算法和分布式架构一起考虑调整，让语义理解的规模扩大了上千倍，后来集结成了论文发表在ACM Transactions on Intelligent Systems and Technology杂志上，广为业界知晓。 2015年，他进入百度硅谷参与语音识别项目Deep Speech 2，这一项目不仅被MIT科技评论评为 2016年全球十大科技突破之一，也成为他了解深度学习的一个契机。他一度坚持要有完美的理论论证才能进入实践验证，因为深度学习的理论未经严格推敲，他一直认为只有统计学习才是“正道”。 在百度，王益获得深度学习科学家徐伟的推荐，去负责深度学习平台PaddlePaddle。在不断探索解决实际问题的过程之中，他的想法改变了。 “并不一定先要有完整论证的理论才去进行实践，也可以先实践，实践出真知。实践之后再总结提升为理论。”王益说，“这就像是在牛顿发现力学原理之前的几千年前，人类就已经利用杠杆原理修起了金字塔。” Code Review：从最初的震撼到⻓年的习惯今年5月，SQLFlow宣布开源，之后仅四个月，ElasticDL也宣布开源，这在蚂蚁金服的历史上并不多⻅，却是王益的坚持。他认为唯有开源才能保证信息透明，唯有让代码直接面对全社会，才能全方位的接受审视和检验，对写代码的人自身来说，也是一种自我约束。 “开源和codereview不仅是个技术问题，更是管理学问题、社会学问题，关系到如何把大家组织起来变成更高效的团队。”王益说。 Code Review对他自己而言，也是人生中一段难以磨灭的经历。他用“最初的震撼”来描述12年前初出校⻔加入Google中国时的体验。当时他已经写了18年程序，手握系统分析师资格，还特别研究过了Google的Code style，所以初次遭遇Code Review时并没有太当回事:“以为自己写了这么多年程序，怎么都还行吧。” 但现实是⻣感的：他在Google写出的第一个程序，总共不过100行代码，却被来自美国的同事和好友Jerad提出了120行意⻅。“当时深受打击，简直觉得屈辱。” 他压制了情绪，仔细去看那些意⻅，这才发现每一条都真诚且很有帮助。“从那一刻起， Code Review 成为了我们的工作方式。”每天和这些同事们一起coding，互相review，让中国工程师们很快知道了应当关注哪些地方，应当如何沟通合作。因此，不管是腾讯的 Peacock，百度的PaddlePaddle新版本Fluid，还是蚂蚁的SQLFlow 和 ElasticDL 都是王益先开发出原型，再吸引感兴趣的同事一起来完善。 ...

蚂蚁金服在过去十五年重塑支付改变生活，为全球超过十二亿人提供服务，这些背后离不开技术的支撑。在 2019 杭州云栖大会上，蚂蚁金服将十五年来的技术沉淀，以及面向未来的金融技术创新和参会者分享。 在人工智能时代，数据是AI领域的石油，如果没有数据很难将AI更好的落地。但是数据孤岛阻碍了数据的获取和利用，蚂蚁金服在三年前开始布局隐私保护机器学习，致力于在保护数据安全和隐私保护的前提下进行机器学习，我们称之为共享智能。我们之前分享了共享智能的理念和原理，今天，我们想聊聊共享智能的发展与应用趋势。 人工智能目前存在的难题是鱼与熊掌不可兼得，也就是隐私性跟可用性难以兼顾。如果你想要你的AI系统能发挥作用，就可能需要牺牲隐私。但是，在大量真实场景中，如果做不到同时兼顾隐私和可用性，会导致很多AI落地的困境。 举几个例子。 首先是贷款风控，用户想要买房去银行贷款，在银行A可能被判定为“坏人”，没有办法给他进行贷款，因为这个机构持有这个人部分数据，同样的用户到了机构B，这个机构B基于它拥有的部分数据，有可能会给予他贷款，这样矛盾的情况比比皆是，皆是因数据不通导致。 在智慧医疗领域，有些罕见病在每个医院的案例都不多，如果我们能把各个医院的案例共享起来，就能获得更多的样本数据，从而可以利用AI进行更准确的诊断，但是这个案例里面技术不是最优先的，对医院来说，它有责任保护患者的隐私，如何确保在共享案例的同时，不泄漏用户的隐私才是首先要解决的。 数据孤岛的问题会给AI落地和应用带来很多类似的难题。 现实环境中，数据在这个图中是不通的，有的地方可能有一些短暂的链接，绝大部分数据在这个图中处于断开状态。我们的目标是想打通数据孤岛，用技术的方法解决技术的问题。通过技术保护数据安全的情况下，实现数据的共享和价值的传递。 共享智能：可用不可见对于共享智能，我们希望达到的目标是数据可用不可见，在多方参与且各数据提供方与平台方互不信任的场景下，能够聚合多方信息进行机器学习，并确保各参与方的隐私不被泄漏，数据不被滥用。 为了达到这一目标，我们使用了很多业界已有的技术，比如学术圈一直在研究的差分隐私、很多大数据厂商在探索的可信执行环境、随着计算力和硬件技术的提升+密码学突破而广受重视的多方安全计算等。还有一些情况，目标数据比较少，但源领域数据较多，我们采用迁移学习的方法去做数据共享，这个也属于我们大的技术范畴。 具体来看的话，第一种方案是可信执行环境的方案，主要依赖中间的硬件级的保险箱Enclave，双方通过一些密码学的机制，把数据进行加密，加密之后只有在密码箱里面才能解密，解密以后做各式各样的计算，因为密码箱是第三方可信的密码箱，大家不信任彼此的情况下，信任密码箱即可，这样在数据隐私不会泄露的情况下，去做各式各样AI的算法。 这种方案依赖可信硬件，通过数据加密的方式，集中传送到可信的平台。对于一些机构，本身就已经上云，把所有的东西都存放在云上面，所有的技术在云上面部署，那么采用这种方式非常快速便捷，同时又能达到很好的隐私保护的效果。 第二种方案是偏软件级别的方案，我们在中间把数据做相应的处理后再进行计算。比如说像秘密分享的技术，通过把数据拆分完以后，几方通过发送随机数来完成运算，然后可以完成各式各样AI的计算和模型；还有像同态加密这样的方法，在加密后的空间里面做相应的运算来完成AI的计算，中间有一个控制模块来共同完成学习的目标。这个方式本身不涉及到硬件，是偏软件+密码学的方案，中间出去的是随机数/加密中间结果，目前业界隐私+AI结合的方向上，用这个方案相对来说比较多。 星云 Nebula：共享智能网络 共享智能需要多方参与，我们设计了星云Nebula共享智能网络架构，对于蚂蚁金服而言，希望跟合作方共同打造这样的共享智能网络。 网络中存在各式各样的计算节点，能够在某个管理平台中进行触发实现AI计算。这个共享智能网络，可以用不同的技术完成共享智能的目标，比如，构建联合营销网络，节点之间可任意组网，采用多方安全计算技术来实现联合营销，同时管理节点可以部署在任何的地方；对于某些机构而言，可能没有很强的AI能力和多方计算能力，那他们可以依赖于云这样的技术，将数据放在可信执行环境中，去参与建设这样的网络，通过这样的共享智能技术来解决AI落地最后一公里的难题。 我们整个计算节点的架构如上图，最底层跟正常环境比较相似，左边是各式各样的可信执行环境，右边是正常的CPU、GPU环境。上面会有统一的API层来屏蔽这些不同的细节。 再往上面，会有本地的计算，这个计算本身会跟通用的开源框架稍有差异，我们会把现在流行的版本改成安全的版本，比如安全的XGBoost。中间做MPC的时候，我们会提供各式各样的技术，混淆电路、OT等等这样的技术，最顶层提供一些可视化跟交互式的接口，普通的用户通过这样的调用就可以完成复杂的多方计算的操作。同时支持各种保护隐私的安全模型推断。 我们希望通过这样的架构完成共享智能技术，并且打造了可视化的界面，采用拖拽式的方式就可以快速高效完成整个AI计算的构建。 上述共享智能架构现在已经达到了较好的完备性、易用性和稳定性的目标，在很多的地方已经进行了落地。在完备性方面，我们实现了功能完备和场景完备，目前主要是支持风控和其它AI典型场景，里面的算法比较全面，涵盖了线性模型、树模型、深度学习、图神经网络等各个方向；在易用性方面，我们希望能够更好的推广这种建模技术，同时又能“屏蔽”一些底层技术（可信执行环境、多方安全计算等），降低大家学习使用的成本；在稳定性方面，我们实现了共享智能计算的集群化，并且支持远程运维。 我们已经将共享智能上线到大数据智能平台上，下面这个demo，是一个多方安全计算的AI建模展示。 http://mpvideo.qpic.cn/0a78owv2z46vcbacambaeciiaucvrvvfkof4jwlibqeqgdakb4hq.f10002.mp4?dis_k=360fe7e0bf7304571a370082c38142c9&dis_t=1571137251 前面预处理部分跟正常的AI建模看起来一样，通过拖拽式操作，把数据进行了预处理以后，送到共享智能建模中，会产生AI运算的结果。通过这种方式能够大幅度降低新技术的使用门槛，方便业务方使用。 蚂蚁金服在共享智能领域里建设了三年多，发布论文超过10篇，获得专利超过80余项，在标准立项上我们在IEEE共享智能和ITU-T MPC国际标准、CCSA共享智能行业标准以及AIOSS / AIIA共享智能联盟标准方面都在同步推进，也获得了一些创新奖项。 共享智能落地案例接下来分享三个典型落地案例。 一个是在安全风控领域，联合生态伙伴来建立安全风控网络。生态伙伴使用前面介绍的可信执行环境技术，把数据加密传输到网络中共建这个模型，打击虚假交易、团伙作案等，大幅度提升风控准确率，实现风控网络的净化。通过这样的风控网络平台，使得商家每天新增很多的交易，同时降低资损。 第二个是中和农信，我们通过数据融合大幅度提高风控性能，把原来传统的线下模式，变成线上自动过审模式，完成授信只需5分钟，8个月累计放款31.9亿，授信成功人数44万人，业务覆盖20+省区，300+县城，10000+个乡村，助力实现农村普惠金融。 第三个是与江苏银行进行的信贷联合风控，还记得我们前面的例子吗？因为数据不完整，导致风控决策错误，现在通过共享智能技术，双方可以完成共同的模型构建，通过这样的机制实现联合风控，使得效果有大幅度提升。同时在这个过程中，用户的数据和隐私得到了有效保护。 总的来说，我们想构建开放的共享智能网络，希望有更多的伙伴、机构参与进来，一起完成建设，打破数据孤岛，助力AI技术更好的落地和应用。 本文作者：缪克卢汉 阅读原文 本文为云栖社区原创内容，未经允许不得转载。

这里是蚂蚁金服体验科技精选 第 4 期，本期内容包括原创精选、蚂蚁前端动态和行业动态，希望你喜欢！ 蚂蚁前端动态Ant Design https://github.com/ant-design... 九月上旬，Ant Design 又招募到三位优秀的社区协作者@yoyo837 @shaodahong @orzyyyy ，相信其社区生态将会更加繁荣！ TechUI https://www.yuque.com/yuque/h... TechUI 9 月上旬新增高级成员搜索组件以及标签设置模板。Kitchen 发布 2.16.0 新增设计资产功能模块，TechUI 设计资产即拖即用 原创精选从链式调用到管道组合 https://zhuanlan.zhihu.com/p/... 如果让你在不用 this 和原型链，不用 ES6 Generator/Iterator，不用箭头函数的前提下，实现「惰性求值」，你是不是想到使用链式调用实现？但初具规模之后，链式调用带来的问题该如何解决？ 未来属于声明式编程 http://djyde.github.io/blog/d... 提升开发效率，我们应该去想如何尽量让开发者声明式地编写代码，而不是只去想我们在 Serverless 上能做什么。 行业动态JSConf 2019 归来记 https://www.yuque.com/zhenzis... 作者参加了 JSConf 2019, 归来后写下此文。本文将着重分享：TDCD、Make it boring、Web norms of the world、Tour de bikeshare 这四个 Talk，希望给大家带来一些信息和启发。 尤雨溪：在框架设计中寻求平衡 https://zhuanlan.zhihu.com/p/... 当你试图去设计一个框架时，最佳平衡点在哪？或许说是否存在一个完美的平衡点？它又是否是一个单一、完美的平衡点，甚至是以 JS 开发人员作为一个整体的最佳平衡点？ MVVM框架的数据状态管理的发展与探索 https://github.com/farzer/blo... 前端应用日渐复杂，页面状态的可控制及可跟踪已成为开发和调试的重要手段，显然我们有必要了解状态管理方案可以解决什么问题，解决问题的核心方式是什么。 抖音研发实践 https://mp.weixin.qq.com/s/Dr... 基于二进制文件重排的解决方案，APP 启动速度提升超 15%。启动是 App 给用户的第一印象，对用户体验至关重要。为了保证抖音在业务迅速迭代情况下的高效启动，抖音 iOS 客户端团队做了大量优化工作及开拓性探索，将应用启动速度提高了约 15%。 ...

个人支付接口现状分析--如何选择一个靠谱的支付接口本篇文章的目的，是向正在寻求个人支付方案的开发者朋友们提供一些信息，希望能给他们一定的帮助，结合自己的使用环境、业务领域和应用场景自行选择。对提到的所有第三方支付工具、第四方聚合支付工具绝无恶意贬低。如何选择一个靠谱的个人支付服务方？选择标准1.var 标准 = 安全性 && 稳定性 && 结算周期 && 费率2.var EFS = 使用环境 + 业务领域 + 应用场景服务方分类互联网支付方式有很多种，基本上将网上支付服务分为几种：1.原生网银支付2.国内主流第三方支付3.其他第三方支付4.第四方聚合支付网银支付想要接入银行，需要一家家的去谈，资质不足的话一般是不可以申请网银的，涉及到企业资格，承诺、合同、不菲的保证金，就个人来说还是不要考虑了，不现实第三方支付1.原生支付宝支持电脑网站支付，手机网站支付，APP支付和当面付，但是接入需要网站备案，需要有营业执照，不管怎么说还是要企业资质。2.微信支持公众号支付，APP支付，扫码支付，刷卡支付和微信买单，使用扫码支付，需要先注册公众号，然后提交企业资质认证，验证通过后，才能接入，还是需要企业资质才能直接接入。以上两种想一下都不是一个简单的工程，对大多数人而言，以上两大主流方式行不通。其他第三方支付PayPal有些人可能不熟悉，这是一个全球支付的工具，主打境外收付款，那么对于做外贸的朋友来说是一个不错的选择。有网站，无网站，B2B商家，个人收款都适用。用户注册后，可以在网站商获取一个PayPal账户，当客户付款后，款项会打到用户的PayPal的账户中，但是，提现到国内的银行，需要手续费的，算下来差不多近5%的手续费，而且PayPal比较偏向买家，如果买家有任何不满意而产生的争议，卖家将拿不到钱。有赞通过有赞微商城支付接口收款。需手动提现，不免费，费用6800/年起，一旦风控资金很难取出。云付通Passpay支持个人和企业接入。个人接入需要实名认证，企业认证需要企业资质，收款存入银行或者微信、支付宝平台上，平台不留存资金，支持的付款方式丰富，但是手续费颇高，提现有门槛。第四方聚合支付Ping++所谓聚合支付 ，实际上是简化了平台接入的流程而已，适合对多个系统对接的需求，个人开发者仍然需要去申请所需接口的使用权限，所以，企业资质也是需要的。美团 & 支付宝口碑通过美团商家码收款，通过支付宝口碑掌柜收款。支付转化率并不高，可能随时被风控通过金额通过技术手段监听通知栏，判定支付宝通知，获取金额信息，本质上依然是采用挂机监听的策略，成本高，配置麻烦，需24小时挂台安卓手机，不免费，PaysApi、虎皮椒，支付吧等移动端hook基于virtual xposed hook相关技术，可自动生成任意备注金额收款码 成本高，配置麻烦，需24小时挂台安卓手机，潜在风险系数高，被风控的概率会非常之高。微米富，greenyep等paybob专业为个人支付而生的支付接口，支持微信、支付宝。为个人开发者/个体户/小微企业，提供安全稳定，正规快捷的收款服务。支持NATIVE/JSAPI/收银台/小程序等支付方式。稳定原生回调（毫秒级），成功率100%，资金直接到个人。个人资质就可开通，一次开通永久使用。可免费开通针对特定行业0%的手续费。市场上面的方案，看起来好像很多，但总结一下主要是下面两类代收结算主要缺点：资金安全难以保障，代收结算天然的额外成本带来的高费率。App挂机监听类主要缺点：首先也是安全性， 能监听支付信息就可以监听其他信息， 稳定性差 ， 比如通知延时，漏单等等。对于个人支付来说，到底有没有正儿八经的个人支付接口呢？大家可以看一下最后提到的 paybob支付，这里有一张详细的个人支付对比表，看过之后可能会有一个更清晰的认识.个其实每个产品都有自己的特性，并不是说哪个好，哪个不好，看自身的实际情况去选择以上只是个人见解，不足之处欢迎拍砖。

近期，CCTV9播放了自制的系列纪录片《大数据时代》，该片是国内首部大数据产业题材纪录片，节目细致而生动地讲述了大数据技术在政府治理、民生服务、数据安全、工业转型、未来生活等方面给我们带来的改变和影响。在第四集中，讲述了芝麻信用如何助力共享经济，推动商业信用体系建设的故事。我们将其摘录分享出来，并简要介绍芝麻信用背后的技术。 曹雪莹是一名平面模特，工作性质让她经常穿着不同的服装，在不同的场合，需要穿不同的衣服，并且风格还不能重样，服装开销占了曹雪莹日常开支的很大一部分。很多女人，总会感觉自己的衣橱里少一件衣服，曹雪莹更是如此。 一个偶然的机会，曹雪莹发现了一种共享衣橱的消费模式，每月花销不到500元，便可换穿30件衣服，其中有不少，是高于曹雪莹消费水平的轻奢品牌，并且大部分衣服都是免押金。一年下来，曹雪莹可以节省很多买衣服的钱，这一切得益于信用体系。 芝麻信用技术总监毛仁歆，便是这个信用评价体系的搭建者之一。他一直在用算法和模型创新商业模式，信用评估，便是毛仁歆团队利用算法创造的一个非金融的商业信用评价体系。 “我们其实在技术领域有非常非常多的创新，通过这样的一个信用评价体系，我们将用户各个维度的数据计算，最终输出一个用户的守约画像。”毛仁歆说道。 商业信用评价体系，从一个人的身份特征、信用历史、履约能力等方面进行综合评分，通过机器学习、时序建模、深度学习、网络分析等技术，精确评估出用户在不同商业场景的守约行为，信用评估作为共享经济中买卖双方建立信任的纽带，它的评分规则必须保证客观和公平，这促使毛仁歆和他的团队，要不断提高守约行为预估的精准度，这样可以让商家扩大自身业务的同时，有效控制经营风险。 随着信用平台体系的不断完善，越来越多的网民加入到中国人自创的购物狂欢节中，一个新的产业链也随之诞生。这里便是新经济体系下的另一个环节，工作人员正在把回收的衣服运到清洗车间，衣服经过分拣，被放进大型洗衣机中清洗，然后经过高温熨烫，臭氧消毒，塑封包装等环节，进入巨大的服装仓库。 当共享衣橱系统，接收到消费者的订单后，工作人员会从服装仓库的几十万件衣服中拣选出对应的款式，然后衣服在流水线上被电脑系统细化分拣，打包后快递发出。 借助于这个信用评估体系，共享衣橱这种共享经济消费模式越来越受年轻人青睐，随着共享经济模式的普及，更多用户有机会展示自己的守约行为，积累自身信用，信用评价体系也得到持续优化，进而刺激了中国消费市场的活力。 信用评估中涉及的机器学习方法由浅到深均有涉及，其从线性、时序和结构数据上进行统一建模的框架即芝麻分背后的DeepCredit技术。传统评分卡技术，虽然能给每一个用户提供一个可解释的芝麻分组成，但模型的评估准确度非常依赖底层的特征工程。近几年来深度学习技术极大的推动了时序挖掘、图网络分析、自然语言处理、图像识别等领域的发展，也为更准确的用户信用画像评估提供了可能。 通过对时序挖掘方法的研究，芝麻信用对深度学习在信用评估中的应用做了探索，其通过对用户的守约历史进行时序建模，完整刻画了一个用户在时间维度上的守约表现。传统在金融领域的守约历史数据挖掘主要依赖开发人员的业务经验，受到工作量大、特征维度少等影响，最终无法达到商业应用的性能要求。在建模过程中，深度学习中的循环神经网络（RNN）及其变种时序算法能较好的对序列数据建模，当前在语音识别、机器翻译、序列预测上都有非常棒的应用。芝麻分团队首次将多层循环神经网络应用在数亿用户规模的守约时序行为上，模型示意图如下图所示。通过在模型结构中引入了Stacking、Embedding、Wide&Deep等优化技术，通过算法学习到了用户的守约习惯，如按时守约、多用多守约等。最终的性能效果相比传统方法有显著提升40%+，给商业场景带来更多的准入用户、更低的资金成本。 当前芝麻信用已经深入渗透到支付宝的各个产品当中，同时对外开放向合作伙伴提供服务。芝麻信用也将投入更多精力优化技术，推动商业信用体系的加速到来。 本文作者：缪克卢汉阅读原文 本文为云栖社区原创内容，未经允许不得转载。

本文内容主要分为以下三个部分： 移动互联网背景下的高可用性能挑战主要给大家介绍支付宝 APP 在这几年移动互联网快速发展的阶段，其自身的一个变化与遇到的性能挑战。 支付宝 Hybrid 方案建设与演进 （H5 容器 & 小程序）为了应对前面提到的这些挑战，支付宝逐步沉淀出 2 套 Hybri 方案，分别是 H5 容器与小程序。 Hybrid 方案借助移动开发平台 mPaaS 对外输出通过 mPaaS 平台，让大家也可以去接触使用到支付宝的 Hybrid 技术。 移动互联网背景下的高可用性能挑战根据公开的 2018 年移动互联网行业分析报告，目前支付宝的月活跃用户已经超过 QQ ，成为国内第二大 App。 支付宝一开始仅仅只是一个单体应用的工具型 App，让用户可以在手机完成支付宝相关的业务查询和操作。2013 年后，支付宝逐步转型为平台型 App， 平台型 App 具有服务化、模块化、工具组件化的特点，这个时候支付宝的业务不仅仅是支付，还需要给客户提供了很多生活相关的服务，例如余额宝、缴电费等。2015 年后支付宝成长为超级 App，超级 App 会面临开放、动态化、高可用的挑战，此时支付宝里面需要支持大量复杂的业务，同时开放自己的商业能力，用自己流量助力合作伙伴。从单体应用到超级 App 的转变，其实体现了一个用户对 App 需求的变化，移动互联网用户需求的本质是服务，而不是 App，用户高频使用的 App 是少数。在 超级 App 时代，支付宝主要面临的挑战是： 1、支持复杂业务 App 的业务越来越复杂，不仅仅是内部业务，还包含了大量外部的合作伙伴。如果采用传统的 App 开发方式很难应对日趋复杂的业务场景。 2、满足业务快速迭代的需求 当前业务的另外一个特点就是需要快速迭代，变化的政策、突发事件都需要我们可以快速把新的业务需求触达给用户。但是 App 开发一个不容忽视的问题，就是应用商店审核。由于审核的存在，App 上开发的业务会有一个统一排期，比如说月底会有新版本，那么所有的业务进度都得考虑 App 的排期计划。 3、开放平台 ...

如果有A、B、C三位同学，他们各自手上有10、15、20块钱，这时需要在相互不知道对方有多少钱的情况下，不借助力第三方来计算三个人一共有多少钱。请问这时候，我们如何实现呢？——这，就是最经典的秘密共享场景。在看完这篇文章后，答案就出来了~背景互联网时代，一切基于数据。 随着人工智能的兴起，数据的质量和数量，已经成为影响机器学习模型效果最重要的因素之一，因此通过数据共享的模式来“扩展”数据量、从而提升模型效果的诉求也变得越发强烈。 但在数据共享过程中，不可避免会涉及到两个问题：隐私泄露和数据滥用。 提到这两个关键词，大家一定都对其背后的缘由有所耳闻： 第一则：2018年3月，剑桥咨询公司通过FaceBook的数据共享漏洞，收集了5000万用户信息，据说有可能利用这些信息操控美国总统竞选，造成恶劣社会影响；事件曝光后，FB公司股票大跌7%，引发一系列后续问题。第二则：2018年5月，欧盟通过General Data Protection Regulation（GDPR）法案，法案指出：所有与个人相关的信息都是个人数据，对数据的使用行为必须要有用户的明确授权。把对隐私保护的要求提到了一个新的高度。 随着对数据安全的重视和隐私保护法案的出台，以前粗放式的数据共享受到挑战，各个数据拥有者重新回到数据孤岛的状态，同时，互联网公司也更难以收集和利用用户的隐私数据。 数据孤岛现象不仅不会消失，反而会成为新的常态，甚至它不仅存在于不同公司和组织之间，在大型集团内部也存在。未来，我们必须面对这样的现状：如果我们想更好的利用数据，用大数据和AI做更多有意义的事情，就必须在不同组织之间、公司与用户之间进行数据共享，但这个共享需要满足隐私保护和数据安全的前提。 隐私泄漏和数据滥用如同达摩克利斯之剑悬在各个公司和组织头上，因此解决数据孤岛，成为AI行业需要解决的首要问题之一。 如何解决数据孤岛问题？当前，业界解决隐私泄露和数据滥用的数据共享技术路线主要有两条。一条是基于硬件可信执行环境（TEE： Trusted Execution Environment）技术的可信计算，另一条是基于密码学的多方安全计算（MPC：Multi-party Computation）。 TEE字面意思是可信执行环境，核心概念为以第三方硬件为载体，数据在由硬件创建的可信执行环境中进行共享。这方面以Intel的SGX技术，AMD的SEV技术，ARM的Trust Zone技术等为代表。TEE方案的大致原理如下图所示： 目前在生产环境可用的TEE技术，比较成熟的基本只有Intel的SGX技术，基于SGX技术的各种应用也是目前业界的热门方向，微软、谷歌等公司在这个方向上都有所投入。 SGX（Software Guard Extensions ）是Intel提供的一套软件保护方案。SGX通过提供一系列CPU指令码，允许用户代码创建具有高访问权限的私有内存区域（Enclave - 飞地），包括OS，VMM，BIOS，SMM均无法私自访问Enclave，Enclave中的数据只有在CPU计算时，通过CPU上的硬件进行解密。同时，Intel还提供了一套远程认证机制（Remote Attestation），通过这套机制，用户可以在远程确认跑在Enclave中的代码是否符合预期。 MPC（Multi-party Computation，多方安全计算）一直是学术界比较火的话题，但在工业界的存在感较弱，之前都是一些创业小公司在这个方向上有一些探索，例如Sharemind，Privitar，直到谷歌提出了基于MPC的在个人终端设备的“联邦学习” (Federated Learning）的概念，使得MPC技术一夜之间在工业界火了起来。MPC方案的大致原理如下图所示： 目前，在MPC领域，主要用到的是技术是混淆电路（Garbled Circuit）、秘密分享（Secret Sharing）和同态加密（Homomorphic Encryption）。 混淆电路是图灵奖得主姚期智教授在80年代提出的一个方法。其原理是，任意函数最后在计算机语言内部都是由加法器、乘法器、移位器、选择器等电路表示，而这些电路最后都可以仅由AND和XOR两种逻辑门组成。一个门电路其实就是一个真值表，假设我们把门电路的输入输出都使用不同的密钥加密，设计一个加密后的真值表，这个门从控制流的角度来看还是一样的，但是输入输出信息都获得了保护。 秘密分享的基本原理是将每个数字随机拆散成多个数并分发到多个参与方那里。然后每个参与方拿到的都是原始数据的一部分，一个或少数几个参与方无法还原出原始数据，只有大家把各自的数据凑在一起时才能还原真实数据。 同态加密是一种特殊的加密方法，允许对密文进行处理得到仍然是加密的结果，即对密文直接进行处理，跟对明文进行处理后再对处理结果加密，得到的结果相同。同态性来自抽象代数领域的概念，同态加密则是它的一个应用。 当前，业界针对数据共享场景，利用上面的技术路线推出了一些解决方案，包括隐私保护机器学习PPML、联邦学习、竞合学习、可信机器学习等，但这些方案只利用了其中的一部分技术，从而只适合部分场景，同时基本处于学术研究阶段，没有在生产环境落地。 共享机器学习：蚂蚁金服数据孤岛解决方案为了更好的应对形势变化，解决数据共享需求与隐私泄露和数据滥用之间的矛盾，蚂蚁金服提出了希望通过技术手段，确保多方在使用数据共享学习的同时，能做到：用户隐私不会被泄露，数据使用行为可控，我们称之为共享机器学习（Shared Machine Learning）。 共享机器学习的定义：在多方参与且各数据提供方与平台方互不信任的场景下，能够聚合多方信息并保护参与方数据隐私的学习范式。 从17年开始，蚂蚁金服就一直在共享机器学习方向进行探索和研究，在结合了TEE与MPC两条路线的同时，结合蚂蚁的自身业务场景特性，聚焦于在金融行业的应用。 蚂蚁金服共享机器学习方案拥有如下特性： • 多种安全计算引擎整合，可基于不同业务场景来选择合适的安全技术。既有基于TEE的集中式解决方案，也有基于MPC的分布式解决方案；既可满足数据水平切分的场景，也能解决数据垂直切分的诉求；既可以做模型训练，也可以做模型预测。• 支持多种机器学习算法以及各种数据预处理算子。支持的算法包括但不限于LR，GBDT，Xgboost，DNN，CNN，RNN，GNN等。• 大规模集群化。支持大规模集群化，提供金融级的高效、稳定、系统化的支撑。 基于数年沉淀与积累，目前共享机器学习技术已在银行、保险、商户等行业成功落地诸多场景业务。通过在业务中打磨出的金融级共享机器学习能力，沉淀下来一套数据共享场景的通用解决方案，未来会逐步对外开放。 在几年的艰苦研发中，共享学习累积专利50余项。在2019中国人工智能峰会上，共享机器学习获得“紫金产品创新奖”，在8月16日的全球人工智能创业者大会上，获得“应用案例示范奖”。 下面，我们将分享基于上面两种路线的共享机器学习实践细节。 基于TEE的共享学习蚂蚁共享学习底层使用Intel的SGX技术，并可兼容其它TEE实现。目前，基于SGX的共享学习已支持集群化的模型在线预测和离线训练。 1.模型在线预测 预测通常是在线服务。相对于离线训练，在线预测在算法复杂度上面会相对简单，但是对稳定性的要求会更高。提升在线服务稳定性的关健技术之一就是集群化的实现——通过集群化解决负载均衡，故障转移，动态扩容等稳定性问题。 但由于SGX技术本身的特殊性，传统的集群化方案在SGX上无法工作。 为此，我们设计了如下分布式在线服务基本框架： 该框架与传统分布式框架不同的地方在于，每个服务启动时会到集群管理中心（ClusterManager，简称CM）进行注册，并维持心跳，CM发现有多个代码相同的Enclave进行了注册后，会通知这些Enclave进行密钥同步，Enclave收到通知后，会通过远程认证相互确认身份。当确认彼此的Enclave签名完全相同时，会通过安全通道协商并同步密钥。 该框架具备如下特性： • 通过集群化方案解决了在线服务的负载均衡，故障转移，动态扩缩容，机房灾备等问题；• 通过多集群管理和SDK心跳机制，解决代码升级，灰度发布，发布回滚等问题；• 通过ServiceProvider内置技术配合SDK，降低了用户的接入成本；• 通过提供易用性的开发框架，使得用户在开发业务逻辑时，完全不需要关心分布式化的逻辑；• 通过提供Provision代理机制，确保SGX机器不需要连接外网，提升了系统安全性。 ...

近期，CCTV9播放了自制的系列纪录片《大数据时代》，该片是国内首部大数据产业题材纪录片，节目细致而生动地讲述了大数据技术在政府治理、民生服务、数据安全、工业转型、未来生活等方面给我们带来的改变和影响。在第四集中，讲述了芝麻信用如何助力共享经济，推动商业信用体系建设的故事。我们将其摘录分享出来，并简要介绍芝麻信用背后的技术。 曹雪莹是一名平面模特，工作性质让她经常穿着不同的服装，在不同的场合，需要穿不同的衣服，并且风格还不能重样，服装开销占了曹雪莹日常开支的很大一部分。很多女人，总会感觉自己的衣橱里少一件衣服，曹雪莹更是如此。 一个偶然的机会，曹雪莹发现了一种共享衣橱的消费模式，每月花销不到500元，便可换穿30件衣服，其中有不少，是高于曹雪莹消费水平的轻奢品牌，并且大部分衣服都是免押金。一年下来，曹雪莹可以节省很多买衣服的钱，这一切得益于信用体系。 芝麻信用技术总监毛仁歆，便是这个信用评价体系的搭建者之一。他一直在用算法和模型创新商业模式，信用评估，便是毛仁歆团队利用算法创造的一个非金融的商业信用评价体系。 “我们其实在技术领域有非常非常多的创新，通过这样的一个信用评价体系，我们将用户各个维度的数据计算，最终输出一个用户的守约画像。”毛仁歆说道。 商业信用评价体系，从一个人的身份特征、信用历史、履约能力等方面进行综合评分，通过机器学习、时序建模、深度学习、网络分析等技术，精确评估出用户在不同商业场景的守约行为，信用评估作为共享经济中买卖双方建立信任的纽带，它的评分规则必须保证客观和公平，这促使毛仁歆和他的团队，要不断提高守约行为预估的精准度，这样可以让商家扩大自身业务的同时，有效控制经营风险。 随着信用平台体系的不断完善，越来越多的网民加入到中国人自创的购物狂欢节中，一个新的产业链也随之诞生。这里便是新经济体系下的另一个环节，工作人员正在把回收的衣服运到清洗车间，衣服经过分拣，被放进大型洗衣机中清洗，然后经过高温熨烫，臭氧消毒，塑封包装等环节，进入巨大的服装仓库。 当共享衣橱系统，接收到消费者的订单后，工作人员会从服装仓库的几十万件衣服中拣选出对应的款式，然后衣服在流水线上被电脑系统细化分拣，打包后快递发出。 借助于这个信用评估体系，共享衣橱这种共享经济消费模式越来越受年轻人青睐，随着共享经济模式的普及，更多用户有机会展示自己的守约行为，积累自身信用，信用评价体系也得到持续优化，进而刺激了中国消费市场的活力。 信用评估中涉及的机器学习方法由浅到深均有涉及，其从线性、时序和结构数据上进行统一建模的框架即芝麻分背后的DeepCredit技术。传统评分卡技术，虽然能给每一个用户提供一个可解释的芝麻分组成，但模型的评估准确度非常依赖底层的特征工程。近几年来深度学习技术极大的推动了时序挖掘、图网络分析、自然语言处理、图像识别等领域的发展，也为更准确的用户信用画像评估提供了可能。 通过对时序挖掘方法的研究，芝麻信用对深度学习在信用评估中的应用做了探索，其通过对用户的守约历史进行时序建模，完整刻画了一个用户在时间维度上的守约表现。传统在金融领域的守约历史数据挖掘主要依赖开发人员的业务经验，受到工作量大、特征维度少等影响，最终无法达到商业应用的性能要求。在建模过程中，深度学习中的循环神经网络（RNN）及其变种时序算法能较好的对序列数据建模，当前在语音识别、机器翻译、序列预测上都有非常棒的应用。芝麻分团队首次将多层循环神经网络应用在数亿用户规模的守约时序行为上，模型示意图如下图所示。通过在模型结构中引入了Stacking、Embedding、Wide&Deep等优化技术，通过算法学习到了用户的守约习惯，如按时守约、多用多守约等。最终的性能效果相比传统方法有显著提升40%+，给商业场景带来更多的准入用户、更低的资金成本。 当前芝麻信用已经深入渗透到支付宝的各个产品当中，同时对外开放向合作伙伴提供服务。芝麻信用也将投入更多精力优化技术，推动商业信用体系的加速到来。

1.前言近年来，随着移动互联网的蓬勃发展，移动测试技术也取得了长足的进步，从早期基于测试脚本的单机自动化，到录制回放、图像识别、云测平台等测试技术贴合实际业务需求深度应用和创新，测试效率从而一次又一次被提升。 本文主要介绍支付宝在移动端上实现的一套无线化、非侵入、免 Root 的 Android 专项测试方案 Solo。直接操控手机，即可实现自动化的功能、性能、兼容性、以及稳定性测试等工作。 1.1 移动测试 1.0 时代 移动测试 1.0 时代，也可以称之为探索期。由于厌倦了日复一日的手工操作，如何提升测试效率成为了移动测试领域最重要的课题，在此期间，除了 Monkey、UiAutomator、Instruments 等官方提供的工具，业界还涌现了一批优秀的开源自动化测试工具/框架，在自动化驱动能力的基础之上，不仅可以实现基本功能的验证，还可以结合性能采集方案、遍历算法等实现各类专项测试的自动化。在这个阶段，自动化测试的常见形态是在单机或本地少数几台 PC 上部署测试环境，再利用 Jenkins 等工具实现持续集成。 1.2 移动测试 2.0 时代 伴随着测试技术的持续发展、又得益于 STF 的开源，业界开始出现了云测平台的概念，将真机设备、任务管理、自动化框架以及专项测试方案打包在平台中作为服务提供出去，给用户带来了一站式的测试体验。另一方面，远程调试、设备调度等技术的引入极大的提升了设备的利用率，测试人员不再需要为缺少测试设备或测试任务排队耗时而担心。对于云测平台用户而言，在此阶段常见的测试形态是：在本地 PC 上开发测试脚本，再上传至云测平台执行，最后可在平台中查看测试报告，测试流程简单且清晰。 1.3 移动测试 2.0+ 在保留了上述“云测”的玩法之外，移动测试 2.0+ 时代下的测试技术提供的往往不再是某一个独立的小工具，更多的是带来一套完整的解决方案，例如为用户提供一套定制化的 IDE 环境，结合录制回放、图像识别等技术，用户可能只需要做一些简单的框选、拖拽就能完成测试脚本的开发。另一方面，由于办公环境、硬件条件等因素的限制，越来越多的测试人员希望可以在移动端上直接发起测试，做到移动测试“移动测”。当然，无论是云端、IDE 端、还是移动端，都应该做到能力互通，即“多端多通”，这样才能让测试方案更加灵活、适用于更多场景。 2.无线驱动的Android专项测试方案:Solo“多端多通”的概念比较广，仅凭一篇文章可能无法阐述清楚，所以下面将会重点介绍为了迎接“移动 2.0+”时代，我们在移动端上实现的一套无线化、非侵入、免 Root 的 Android 专项测试方案 Solo。直接操控手机，即可实现自动化的功能、性能、兼容性、以及稳定性测试等工作。 2.1 整体架构 这套方案中，底层依赖主要是“无线 ADB、系统辅助功能、Chrome 调试以及图像识别技术”，后文将会介绍它们具体的应用场景。同时，在底层依赖的基础上，我们封装了一套核心能力，由“控件定位、事件驱动、性能采集以及依赖注入”组成，并在服务层实现了录制、回放、数据处理等公共服务能力。在架构的最顶端，结合界面交互逻辑包装出了各个功能的入口。 2.2 无线 ADB 大家都知道，对于 Android 自动化，ADB shell 的执行能力是一切的基础。 在 PC 上，通过 Android SDK 提供的ADB client 与同样运行于 PC 中的 ADB server 通信，再由 ADB server 通过 USB 与位于设备中的 Adbd 通信。要实现一套无线化的方案，必须要摆脱对 USB 线的依赖。好在 Android 系统还提供了一种基于 Socket 的 ADB 连接模式，既然是这样，那么只需要按照 ADB 通信协议在端上与本机的 5555 端口进行通信即可获得 ADB shell 的执行能力。 ...

“支付宝生态红利是不可错过的时代产物，你很难再遇到这样一个能够让中小微创业者真正融入并扎根生长的生态平台。”拥有近 10 年互联网运营经验的老兵、嘉图软件副总经理兼共享事业部经理张韵攀说道。 嘉图软件是国内从事图书共享流转业务的平台企业，为全国读者提供书籍共享、图书借阅、二手书买卖等服务。张韵攀负责该公司线上图书共享业务。 二手共享市场被预测具有巨大的市场潜力，然而在共享经济心智日益成熟的今天，就二手图书业而言，据统计，全国每年新增闲置图书量约为 20-30 亿册，2014 年至今闲置图书量已经达到100 亿册，但是，国内二手书回收率不足 5%，流转率更加受到制约。 在这样的背景下，嘉图软件运营的支付宝小程序书袋熊 BOOKSTORE 平台，上线 1 个月时间即实现从零开始累计获得超过 100 万用户，并且不到三个月销售二手书 20 万册，营收上每个月增长率达 50%。这样的创新自运营成绩，让书袋熊 BOOKSTORE 小程序一举夺得第一届支付宝小程序创新大赛总季军。 支付宝小程序创新大赛是以支付宝端为依托，面向广大开发者、商户及企业的大型创新创业孵化计划，旨在通过开放阿里巴巴与蚂蚁金服的技术、能力和生态，助力优秀商户探索解决实际生活问题，推动各行业生态商业创新和服务升级。以日前刚结束的第一届大赛为例，通过创新挑战赛，支付宝小程序助力了多项商业价值创新成果，书袋熊便是其中之一。 那么，在高速业务增长的背后，书袋熊是如何不断向前自我驱动的？ 为什么选择支付宝？虽然 2018 年才开始探索支付宝小程序，而嘉图软件与支付宝的结缘可以追溯到 2016 年 12 月。 据介绍，那时嘉图软件通过与芝麻信用合作，帮助全国多个城市公共图书馆简化线上借阅流程，优化读者体验，提升图书借阅率。 而随着自身对图书线上线下的管理能力逐渐形成，嘉图软件希望图书管理服务能够向外延伸，因此开展了二手图书回收共享业务，向更广大读者提供图书借阅、交易、公益捐赠等服务。 关于互联网线上运营，嘉图软件也经历尝试了许多路径，而该公司最终选择支付宝小程序的考虑在于，首先，无论是图书借阅或销售交易，都需要信用担保和完善的流程服务，支付宝则天生具有信任和服务的属性，通过接入支付宝展开业务是自然而然的选择。其次，由于自身场景的锻造，支付宝具有丰富的商业基础资源和能力支持，能够适应各类业务场景。 更重要的是，张韵攀表示，支付宝具有非常成熟的生态，强大的生态连接力和平台工具让中小微业务能够植根其中成为一方领域、一个频道，打造自己的阵地和增长模型，实现服务升级和商业创新。“这些原因促使我们决定全力投入支付宝生态，探索支付宝小程序的创新运营。” 也因为这些不同的考虑，书袋熊小程序上线时并没有直接做太多关于小程序本身的推广活动，而是通过“创新图书循环服务+支付宝开放平台”的融合创新模式，打造新的图书共享平台服务体系。 “我们的目标是从图书全生命周期出发，从各个领域贡献自身的能力，而不是利用支付宝小程序简单获取流量。”强调服务的生态特点，既是支付宝的优势，也是前提基础。 张韵攀认为，图书共享与循环流转是链条很长的过程，图书管理服务能力也具有相应的壁垒，而且阅读是一项深度沉淀的服务和社交活动，如果不能很好地消化转换平台上的流量，并提供优质的服务体验，后续的自运营就是空中楼阁。 因此，书袋熊小程序在开发、上线过程中，在支付宝小程序创新大赛平台的助力下，选择了通过服务生态、融合场景的方式来影响用户，创新商业运营模式。 1个月100万用户背后的秘诀经过多年实践积累，支付宝上有丰富的应用和服务场景对外开放，包括蚂蚁森林、小目标、社区生活等，以及地图、芝麻信用、区块链、智慧营销等技术和能力都全面开放给支付宝生态创新创业者。 图书共享流程包括从回收、处理，到借阅、捐赠或售卖。张韵攀介绍，书袋熊的图书回收能力包括完善的物流服务体系，后期对图书进行质检、消毒、翻新、塑封的仓储处理能力，以及高达数百万册的图书管理能力。数百万册的图书相当于一个市级图书馆藏书管理规模。 基于小程序进行生态创新运营时，书袋熊首先根据支付宝各类场景和能力特点，对自身业务和能力进行分解，形成不同的服务和能力融入支付宝生态场景中，最终实现全链条自运营创新。在此过程中，大赛也持续为参赛团队组织由投资人、创新创业者等组成的专家集训营交流。张韵攀笑称，“过去这大半年我几乎一周来一次支付宝大楼。” 服务输出，融合生态场景首先是回收循环的创新。 基于回收能力形成的壁垒，现在，在芝麻信用的信用回收频道，以及在城市服务领域，书袋熊都成为图书快速回收场景的服务者，输出图书回收处理能力。同时，书袋熊也作为绿色能量生产的策略和支付宝生态紧密结合，读者参与书籍回收可以获得相应的“蚂蚁森林能量”奖励。 而在提供能力和服务的同时，书袋熊也获得了生态的支持。除了一方面获得庞大的流量资源，化公为私，另一方面，基于芝麻信用能力，书袋熊实现预付款结算的回收模式创新，提升回收效率和用户体验；而基于城市共享和蚂蚁森林等应用，成功打造了良好的绿色阅读的心智，吸引用户。据统计，书袋熊上线收书 2 个月，收书总量超过 100 万册；截至 6 月 10 日，收书总量超过 300 万册。 过去，图书回收存在几个痛点：一是流程问题，需要读者先寄回书籍，再被评估价值，最后打款，过程长、无保证；或者是，线上线下回收点不发达，送书不够便捷，再一次提高书籍回收门槛。今天，这些问题都得到了解决。“支付宝生态的服务属性很强，相应地用户的便民诉求也比较突出。”张韵攀说道。“痛点的解决对市场潜力的释放作用也尤其明显。” 然而，“不只是收书，送书也是书袋熊的能力，”张韵攀笑道，并且，送书作为优质权益，它在书袋熊连接更丰富的场景中发挥着更加重要的作用。 打造场景矩阵，高增长高转化“免费领好书”是书袋熊为生态打造的一项“送书”权益，通过它而连接的生态场景涵盖支付宝的业务、应用、服务等各种类型，实现多场景融合，并将用户沉淀在小程序和生活号上。比如： 通过该权益，书袋熊与支付宝生态包括饿了么会员、支付宝会员、花呗等场景保持高频互动，最高曾实现单日会员增长 180%。对接“步数”应用，通过“行万里路，读万卷书”活动，读者可用步数免费兑换好书。针对大学生活、社区生活等人群和服务场景，推出“打卡读书小目标”等活动，覆盖更多人群。……有了更多好书，实现生态连接、用户留存后，基于支付宝人群画像、精准营销推荐等技术能力，通过“书单推荐”、“名人荐读”等服务，实现购买转化。据透露，书袋熊小程序上线 1 月累计用户突破 100 万，“免费领”销售转化率达到 11%；截至 6 月 10 日，出现单日订单最高超过 23000 单。 ...

近日，全球知名开源组织云原生计算基金会 CNCF 宣布，蚂蚁金服正式成为 CNCF 黄金会员。为什么蚂蚁金服会拥抱开源，科技公司和开源社区如何实现双赢且可持续发展？蚂蚁金服副CTO胡喜在TechCrunch上发表专栏阐述了自己的见解。 自诞生以来，开源软件在许多行业有效地推动了技术普及、开放与公平竞争。然而，金融服务业一直是个罕见的例外：金融机构依然倾向于使用私有技术进行开发和运营。 传统上，金融服务业只为少数人提供服务。全球有 20 亿人和 2 亿小微企业无法获得银行和信贷等基本服务。在这样的情况下，开源技术可能会是推动普惠金融的关键。 Gartner 报告称，在汇率不变情况下，银行和证券业的 IT 支出 2018 年增长了 4.6%。银行和证券公司仍坚定不移地将数字化转型放在未来发展的首要位置。不过在很大程度上，有能力与资源投入技术开发的主要是全球性的大银行，规模较小的地区性银行则没有这样的机会。 小银行，例如来自发展中国家和农村地区的银行往往缺乏专业技术知识，也难以承担当代信息技术系统，例如下一代数据库、先进的分布式计算架构和金融级人工智能的建设成本。但是，如果这些机构愿意利用集众人之力、低成本的开源创新，那么就可以更好地服务它们的市场。 金融科技开源基金会（FINOS）的成立是朝着这个方向迈出的重要一步。该基金会的成员包括美国资产管理规模最大 30 家银行中的 10 家，例如高盛和摩根大通。 出于同样的原因，蚂蚁金服加入了云原生计算基金会（CNCF），成为黄金会员。位于硅谷的 CNCF 管理着云原生软件体系的关键部分，包括 Kubernetes 和 Prometheus，也是 Linux 基金会旗下领先的开源组织。通过与 CNCF 及其旗下成员分享我们的技术知识，支付宝致力于向全球金融机构和合作伙伴开放我们的技术，同时与中国的地区性和农村地区银行合作，基于成熟的开源技术提供产品，助力它们的数字化转型。 成立于 2004 年的支付宝在中国开创了安全可靠的支付系统。自那时以来，支付宝不断发展，为数百万小微企业提供各类服务，包括支付，小额信贷和保险等等。 我们正在给行业提供技术帮助，为 200 多家金融机构提高效率、降低成本。这些机构包括中国全国范围内的 100 多家银行、60 多家保险公司，以及 40 多家基金公司和证券公司。 借助过去多年服务支付宝这种任务关键型金融应用的经验，蚂蚁金服启动了多个开源项目，例如热门 UI 设计语言 Ant Design，以及 SOFAStack。后者在帮助用户顺利参加“双 11”活动的过程中发挥了关键作用。按交易量来看，“双 11”是全球最大的购物节。 利用 SOFAStack，各种规模的企业都可以轻松实现类似支付宝的规模和可靠性，在购物高峰期将关注重点转向如何更好地给顾客提供服务。 通过 SOFAStack 的开源，我们已经帮助南京银行等合作伙伴建设强大的技术系统。在 SOFAStack 和支付宝其他开源技术的帮助下，南京银行最近为自己和第三方合作伙伴开发了下一代核心银行系统“鑫云+”。 鑫云+带来了强大的性能，灵活的可扩展性，强数据一致性和重要的容灾机制。截止 2018 年底，鑫云+签约了近 1000 万新客户，日贷款申请处理能力上升了 10 倍，从 10 万笔提升至 100 万笔。贷款审核流程也因此加快，一些客户不到 1 秒就能获得贷款审批。同时，单账户的管理成本下降了 80% 至 90%。 ...

2019年6月28日，在中国国际软件博览会上，蚂蚁金服金融科技产品技术总监杨冰发表主题演讲，分享了蚂蚁金服在过去的十多年里，是如何通过商业创新与技术创新的双轮驱动，创造出数字时代的普惠金融“奇迹”。 十多年以前，大概很难有人能想象到如今我们习以为常的生活场景：只要带上手机就可以放心出门，从购物到餐饮，从打车到住宿，甚至理财和贷款，都只需轻点几下屏幕。 十多年以前，大概也很难有人能想象到金融业会发生如此深刻的变革：人满为患的实体网点、冗长的申请表单和繁复的审批流程都逐渐成为过去时；传统金融行业因成本和风控问题而难以触达的用户，比如小微企业和个人，也日渐成为银行的目标用户群体。 越便捷的服务，需要越强大的技术蚂蚁金服为金融业的变革做了些什么？ 在过去的十五年中，它通过技术重塑了支付服务小微贷款服务，让普惠金融服务对于每一个普通的中国人来说，都变得触手可及。 基于互联网和移动互联网，蚂蚁金服的产品为用户带来了前所未有的轻松和便捷：转账无需再去银行排队，在只需在手机上轻点几下；消费无需现金，二维码支付已经遍布中国的大街小巷；即使没有信用卡，只要开通花呗即可先付后还；余额宝可以让用户通过手机就能实现理财，而如果一名小微企业主想要贷款，只需要花3分钟在网上填写申报材料，1秒钟就能实现贷款到账，整个过程中零人工干预。 但是，用户对于快捷和便利的要求不断增长，也给金融机构带来的全新的挑战。在挑战面前，唯有技术的创新和发展才是最有力的武器。 通过智能手机，用户可以随时随地发起交易，线上交易流量远非传统银行柜台业务可比。在类似“双十一”的大促活动中，每秒的交易峰值可达数十万笔，在这样巨大的流量面前，如何保持交易系统的稳定、安全、高可用，保证数据没有任何丢失和偏差，这是互联网时代的“新型银行”必须面对的难题。 金融交易技术中，最关键的是分布式数据库能力。随着蚂蚁金服的业务量突飞猛进，依靠开源的分布式系统已经不足以解决问题。2009 年，蚂蚁金服自主研发金融级分布式关系数据库 OceanBase，这是一个专长于高可用、一致性的分布式数据库，结合蚂蚁自研的金融级分布式中间件，整个系统具备百万级每秒的伸缩支付能力，成功经受住了“双十一”交易量每年翻三倍的考验。 金融交易的另一个关键点是风控，这关系到金融业务的生命线。传统金融机构用严格的审核来控制风险，但在互联网时代，为了用户体验及时流畅，消费、信贷、保险等交易的审核都必须在尽可能短的时间内完成。 对于金融机构而言，这可谓压力山大：交易是否违规？是否虚假交易？是否合谋套现？如何在不借助担保材料的情况下来判断借款者是否可靠？如何甄别诈骗和洗钱？如何避免坏账和资金损失？这一系列复杂的问题，都要在毫秒级的时间中里找到正确答案。 传统金融机构依靠人力来审核的做法显然是行不通的，不但成本高企，时间也不允许，因此必须要有一套数据和算法构筑的庞大、复杂而精密的平台，依靠海量的计算来做出精准的决策。 这不是一件简单的事，因为每一笔交易都关系到真金白银，出错就会带来资损，金融级对于精确和稳定的要求非常高，尤其在延时性要求也非常苛刻的情况下，对技术是很大的考验。举例而言，如果要甄别一个花呗账号是否有套现嫌疑，既要做实时的特征计算，还要用图计算去查看与这个账号关联的资金情况。如果在多种计算模式之间来回切换，不仅会增加成本，还会带来延时，影响用户体验。 蚂蚁金服：不是取代者，而是支持者强大的技术支持，让蚂蚁金服实现了快、稳、准，许多本来难以享受金融服务的企业和个人，如今也可以享受到普惠金融带来的便利。在传统金融机构看来，像这样的新型科技金融机构是强有力的竞争者，发达国家的许多银行家担心，新兴科技公司的崛起将挤压他们的份额。 但在蚂蚁金服看来，这种担心是多余的：蚂蚁金服不会取代传统机构，而是扮演支持者的角色，通过技术开放帮助机构提升服务效率和质量。 自研技术的基础上，蚂蚁金服还一直在扮演着推动技术开放，为传统金融业赋能的角色。因为蚂蚁金服定义中的普惠金融，不仅是自身要服务大量的用户，让原本难以享受到便捷金融服务的用户受益；还要通过技术的开放，让更多的金融机构具备更好地服务大量用户的能力。 在金融业变革的大势之中，许多传统金融机构都走上了数字化转型的道路。转型之中，他们不约而同地遇到了相似的门槛：如何快速搭建线上业务？如何利用互联网获客、扩大业务规模和覆盖范围？如何基于互联网用户群体的特性开发新的产品？ 蚂蚁将自己沉淀下来的技术和经验开放出来，让传统金融机构在面对这类问题时，手握更具效率的工具，也少走了很多弯路。 三大PaaS产品都是蚂蚁金服技术开放的结晶：mPaaS（mobile PaaS）能够快速帮助这些机构开发移动APP；bPaaS（business PaaS）是凝结了蚂蚁金服多年来积累的分布式金融核心能力的套件，能帮助这些机构在最短三个月内快速“复制支付宝的能力”；dPaaS作为一个数据智能平台，借助强大的底层数据引擎，通过海量的计算，能帮助这些机构获得基于大数据的业务分析洞察能力和实时智能决策能力。 mPaaS自2017年下半年开始推广以来，已经帮助多家股份制银行和城市商业银行完成互联网金融升级，如广发银行，华夏银行，苏州银行等。mPaaS团队仅用了不到三个月的时间，就帮助铁路售票系统12306 App完成重构，极大提升了性能和效率。此外，mPaaS还和上海地铁深入合作，推出了“Metro大都会 App”，实现扫码进站，为日均客流量超过1100万人次的上海地铁解决了排队买票的问题。 bPaaS的面世，为传统金融机构的转型提供的现成的平台，让他们不必再从零开始摸索和开发自己的分布式业务系统，节约大量时间的同时，也极大减少了分布式技术在核心业务中的落地难度。bPaaS中整合的是蚂蚁金服十几年来在金融业务实践中经过无数次验证的技术和解决方案，在保持银行传统核心稳定的前提下，bPaaS可以根据不同银行差异化的业务场景，快速定制新业务场景。随着bPaaS的开放，金融机构在最短三个月内“复制蚂蚁金服的核心技术能力”，完全可能成为现实。 dPaaS则针对传统金融机构转型中使用数据门槛过高的痛点，主要提供“三合一”的数据智能能力：处理海量数据的工具，收集和存储数据的标准，使用数据的方法论。在风控和营销场景之中，dPaaS都有突出的表现，在dPaaS的帮助之下，传统金融机构能够更为顺畅地使用数据来提升业务，将手中的数据资产切实有效地转化为业务能力，实现数据的价值。 《经济学人》特别指出，技术对金融业的意义深远。科技创新可以孕育更灵活、便利、开放的金融系统，而智能手机和数字技术在金融业的广泛应用将成为推动社会经济发展和普惠的最佳途径之一。在运用数据和数据技术规避风险、降低成本、促进业务成长、推动普惠金融等方面，以蚂蚁金服为代表的中国金融科技公司已经走出了一条自己的道路，同时，也在不断将技术进步的趋势推广到全世界。 本文作者：华蒙阅读原文 本文为云栖社区原创内容，未经允许不得转载。

国内的前端行业，是一个群星璀璨，同时又有些纷纷扰扰的圈子。很多初出茅庐的年轻人怀着改变世界的梦想，谁也不服谁。不过，有一些为前端领域做出贡献的拓荒者几乎受到所有人的尊敬，玉伯就是这些拓荒者中的一员。 如今，他已经是蚂蚁金服研究员，带领着体验技术部，打造出 Ant Design、AntV、Eggjs 等广受欢迎的开源项目，他所在的团队也成为国内前端开发者向往的地方。 在同事眼中，玉伯是一个严谨的人，同时保持着对生活的热爱，他曾以 lifesinger 为笔名写名为“岁月如歌”的博客、参与 GitHub 上的开源社区，到现在也经常在知乎上分享自己的知识和见解。 从中科院到支付宝时间转回到 2006 年，当时在中科院物理所进行硕博连读的玉伯对前途产生了迷茫，是就这样继续深造，将来投身学术界，还是出来干一番事业？ 当时，腾讯的 QQ 已经开始有所起色，在年轻人之间开始风靡，淘宝网已经成为中国最受欢迎的线上购物网站，互联网正风起云涌。这时，玉伯得知中科院软件所正在找人，一番思考之后，玉伯毅然放弃学业投身到软件行业。由于他当时年龄小，在软件所工作期间，经常闹出被误认为是学生的笑话。 中科院的生活单纯但缺乏激情，2008 年，玉伯终于离开了象牙塔，南下杭州，加入了当时正在招兵买马的淘宝 UED。虽然并非科班出身，但玉伯从 2002 年起就已经开始接触前端开发，从此与前端结下了不解之缘。 加入淘宝 UED 后，他与承玉等人一起研发了 Kissy，当时淘宝前台业务的标准前端技术栈，并将之开源，在 GitHub 上，Kissy 一度是阿里系开源项目 Star 数最多的项目。 在淘宝期间，玉伯还发起了 Sea.js，一个开源的 JavaScript 模块加载框架，它契合了前端工程化的演进趋势，也是现代大中型前端项目的基础。 2012 年，玉伯加入支付宝前端开发部，负责基础技术组。第二年，他遇到了职业生涯的另一个重大选择：阿里宣布“ALL IN 无线”，支付宝前端解体，所有人都面临选择，要么转岗去做移动端开发，要么留下来做中后台的前端开发。玉伯选择留了下来。 虽然从事后来看，无论是走的还是留的，结果都挺好的，但当时对于玉伯是一个痛苦的时刻，甚至对前端的价值产生了怀疑，他在《阿里前端的困局与突围》中写道： 一个事实：把国内大部分公司的 UX 部门解散掉，也不会太影响产品的体验。在国内，UX 主要还是起到美工的作用，虽然我不想承认。前端依旧是美工，而且仅仅是实现工。 在阿里，我们不得不承认一个事实：前端的确有价值，但放在全局来看，前端产生的价值并非核心价值。 在阿里，虽然前端的工作已经不可或缺，但对大公司而言，不可或缺的岗位多了去呢，不可或缺不代表有核心价值，我就不说了。不过好在，他很快振作起来，从中后台业务中找到了前端的价值。 “后来我们发现中后台业务也是有很多事情可以去做的，无论是业务还是技术都值得深挖，只是以前前端只关注 C 端业务，但其实 To B 的业务对前端来说是一片蓝海。”玉伯说。 玉伯发现中后台的业务量其实非常大，如果没有一套系统的规范来应对，研发效率和产品体验都将面临挑战。 在这样的背景下，前端技术部改名为体验技术部，玉伯和他的小伙伴们踏上了新的征程。 冰山之下的体验意识到中后台方面前端体验的缺失，玉伯开始带领团队做这方面的工作，他还专门招募了设计师团队，和前端工程师一起工作，开始在体验方面深挖。 设计师的加入让前端团队发生了巨大变化，也让玉伯开始思考体验的更深层含义，他在《我们是如何从前端技术进化到体验科技的》一文中表示： 前端技术再牛，都很难直接解决产品层的用户体验。对中后台产品来说，设计的价值也远远不止于让产品的颜值提升，设计的更多价值，在于深入到产品的业务逻辑里去，去帮助业务梳理产品信息架构与任务流程。用户体验是一个非常综合的事，需要各种专业人士在同一个产品上聚焦发力，一起共同努力才能真正提升产品体验。他还引用乔布斯的话说：设计不止于好看，更关乎好用。 为了让前端工程师和设计师更好的协作，玉伯说，团队曾经开展过一个活动：任何设计师的要求都是合理的，只要设计师提出的要求都尽可能的去实现，除非技术上的确实现不了。这个活动让设计师感觉到前端工程师的尊重，增进了双方的互相了解。而且前端工程师和设计师都是视觉型动物，都关注人机交互的细节，所以相处下来很融洽。 2015 年，体验技术部推出了 Ant Design，它有别于 UI 组件库，是一种全新的设计系统，随着 Ant Design 不断的证明自己，它受到了阿里内外的广泛赞誉，也在一定程度上引领了国内业界关注中后台体验的风潮。 ...

“很多事情，说出来很多人都在做，但是只有真正做到极致，技术的差异性才会体现出来”，蚂蚁金服技术风险部研究员陈亮（花名：俊义）在接受 InfoQ 采访时如是说道。在此前的支付宝技术嘉年华，InfoQ 对支付宝数次技术架构升级的见证者及主导架构师陈亮进行了独家采访，首次系统了解稳定支撑“双十一”等多次实战背后的支付宝技术风险体系。 支付宝技术风险体系2007 年，陈亮加入支付宝，负责支付宝搜索及通信中间件架构。在之后的十年时间里，陈亮先后负责过支付宝交易拆分整体架构，这成为支付宝数据库拆分架构标准；支付宝三代架构单元化及容灾整体架构，实现异地多活，这成为支付宝单元化架构标准。如果简单总结在支付宝工作的前十年，陈亮表示： 前十年，我一直在做可扩展性相关的工作。在这期间，问题和需求驱动占据上风。陈亮回忆道：“最初的支付宝是单体架构，一个小型机加两个 Java 写的 APP，那年 DBA 就找过来说如果不进行数据库拆分，很难扛住业务发展”。 经过系列改造，这一工作终于完成。当时，陈亮以为这个架构起码可以支撑支付宝未来五到十年的发展。然而，双十一很快就来了，超大规模瞬时流量的冲击对架构提出了全新挑战，整个团队又开始马不停蹄地进行异地多活相关项目研发。 彼时，支付宝有两个主要应对技术风险的团队，一个叫技术质量团队，另一个则是运维团队。技术质量主要是各种功能测试，并解决程序 Bug、故障等问题；运维团队主要是生产偏基础设施以及应用、DB 运维管理保障，同时也会自发性地做一些技术风险相关的事情，但并未形成体系化的技术风险组织阵型及打法。 2013 年，支付宝技术团队提出质量 2.0 战略，其目的是希望在技术风险领域有一些延展，体系化沉淀 Bug 检测等方面的能力。自此，支付宝的技术风险体系建设逐渐步入正轨。 组织架构演进 2014 年，质量技术部成立希望从全域视角解决技术风险问题。但是，质量技术部并没有运维团队，主要就是通用质量检测和高可用保障相关的技术解决方案，并驱动各业务部门的技术团队落地。当时，质量技术部人员并不多，是一个小而精悍的中台部门。 经过一年多的发展，质量技术部发现仅仅依靠质量技术并不能解决生产上的各种故障风险。虽然，质量技术部会关注生产研发过程，但主要精力在于对各业务技术团队输出技术风险，比如高可用及通用质量检测的解决方案，高可用及资金保障方面尚未出现成型的平台体系。虽然当时的全链路压测和持续集成平台已有所成型，但关于高可用等并没有成型的平台。 当时，技术团队判断，不能只从质量角度看风险，而需要从更高的维度和更全面的视角看待风险。2015 年，质量技术部升级为技术风险部，专注研发及架构技术风险问题，做相应的解决方案和落地平台。 2016 年，陈亮一手打造了支付宝的 SRE（Site Risk Engineer，参考谷歌的 Site Reliability Engineer）体系。技术风险部增加 PE 和 DBA 团队，PE 团队直接对生产环节中的运营、操作等做技术风险防控，整个大团队的职能属于 SRE。据了解，这也是国内第一个 SRE 团队。 陈亮发现，传统的运维思路和文化已经无法彻底解决支付宝的稳定性问题，因此需要成立 SRE 团队。事实上，传统的运维方式侧重于靠人肉解决风险，不管是调参还是更改配置，都无法从本质上解决支付宝的稳定性问题，相反会让运维人员的工作成就感很低。说到底，运维领域的问题终究还是软件问题，需要建立软件平台更好地管理风险。 在组建 SRE 团队的过程中，陈亮认为最难的反而不是技术层面的推进，而是让团队工程师，包括整个公司认同 SRE 的价值，这需要让所有人理解 SRE 可以解决哪些新的问题以及传统的思维方式为何不可取。 据了解，支付宝的 SRE 团队主要由研发、运维和测试人员组成，八成运维人员都需要写稳定性相关的代码。团队组建完成即全面开展故障自动定位、自适应容灾、防抖、精细化高可用等工作。其中，防抖要保证任何网络或基础设施抖动，用户都无感知；精细化高可用，又叫单笔高可用，其颗粒度可以精准到用户的每一笔交易，远远优于行业内的机房级高可用。 2016 年，SRE 团队建设了很多平台和能力。同时，技术团队发现了两个极为重要的现象，一是生产故障不是必然的，通常都是偶然性的；二是生产故障是低频的。这带来的问题就是故障样本很少，没有办法证明在真实故障到来时平台是否具备能力应对。也就是说，SRE 团队建设的防御系统的可靠性，无法充分验证。 2017 年，SRE 团队成立了专门的、独立职能的技术蓝军，其主要的工作就是发掘防御系统的弱点并发起真实的攻击。技术蓝军并不对各业务方负责，只对这套防御系统的稳定性和可靠性负责。 在技术蓝军看来，发生故障是必然的，只是时间早晚而已，技术蓝军会想尽办法触发这些故障，以保障在故障真实发生时，团队有足够的应付能力。目前，全栈级的技术攻防演练每周都在进行，而故障防御系统及不断优化的高可用架构则是由 SRE 团队的红军与各业务深度合作，沉淀、构建出来的。 ...

对话亲历者：他是支付宝技术平台的奠基人之一，但是他总说“这还不是我心中最完美的架构”；他行事低调但却有着“此时此地，非我莫属”的豪气；他曾无数次充当救火大队长，但自评只是“没有掉队的那个人”。在2009-2019 互联网技术十年发展的波澜壮阔中，他是亲历者之一。 查看视频，点击此处：▵7分52秒，听支付宝技术人鲁肃讲故事 他叫程立，花名鲁肃，蚂蚁金服首席技术官。2005 年加入支付宝，是支付宝技术平台的奠基人之一，在支付宝与蚂蚁金服期间，主持支付宝各代技术架构的规划与基础技术平台的建设。2018 年，程立开始担任蚂蚁金服国际事业群首席运营官。 今天我们的主题是“十年”：希望能站在互联网技术发展的时间线上梳理出来几个重要的时间节点，如果用“2009 年到 2019 年是互联网技术 __ 的十年”来造句，希望听听您的讲述！ 鲁肃：过去十年，面向整个数字时代的关键技术一个接一个的出现，从被人们接受，到开始步入应用。2009-2010 年是云计算，2011-2012 年是移动，2013-2014 年是大数据，2015-2016 年是人工智能，2017-2018 年是区块链。在蚂蚁金服，我们把区块链、AI、安全、IoT、计算这几大关键技术称为”BASIC“。这五个关键词在过去的十年里面接踵而至，而且得到了所有人的理解。所以我觉得回首来看的话，过去十年是技术革命非常关键的十年：一次技术革命去改变一个真正的行业，完成所有技术的准备。 您提到“革命”这个词，是不是可以这么说：过去十年是互联网技术革命的十年，是互联网技术改变所有人生活的十年？ 鲁肃：我们认为过去十年技术正在改变，但是你说它已经完成这个改变了吗？它才刚开始。 听说您小时候一直想做一个数学家，然后某一天忽然发现自己应该做一个程序员？ 鲁肃：我读书读到硕士都是以做数学家作为梦想。读博士之后，我的导师他是一个做实践、做工程的老师，所以在他的熏陶下，他让我解决很多工程的问题。那个时候我做了一个选择：不是完全根据自己的兴趣去做一件事情，而是结合自己的兴趣和擅长。那时候我基本上就把注意力转到工程上了。 说到做工程的精神，其实小时候我印象比较深的就是我的父亲每个周末到实验室加班，就把我带到实验室。他会让我看非常大的激光器，一个激光器像一个房子一样大，要把它上面一个盖子盖上，要把螺丝拧上，拧上之后要严丝合缝，确保没有任何漏气。我就是负责拧螺丝的。一圈有几十个螺丝，要一个一个去拧，而且你不能够一次把一个螺丝拧死，要一圈一圈拧。那时候我爸说我拧螺丝拧的特别好。 我的父亲是个物理学家，他做了很多拧螺丝的事情。我读硕士期间做数学研究，数学必须非常缜密，从提出一个定理，到证明它对不对，可能过程很长。我们现在做一个大的系统，写一个没有 bug 的程序，也是很相似的。所以说，我做了很多”拧螺丝“的事情。 您之前介绍过支付宝开发初期的一次重要转折，您经历过非常重要的一夜。可以再跟我们分享一下吗？ 鲁肃：2004 年，当时淘宝要改造。这个项目是当时整个阿里巴巴最重要的一个项目，要用新的架构做面向未来的淘宝网。2005 年我加入支付宝以后，很自然的想要向团队证明自己。当时我的主管特别信任我，任命我做当时非常重要项目的主架构师。 这是我第一个做的项目，所以一开始做项目架构师的时候，我把我能想到的最好的架构、当时我懂的和我不懂的技术全部用上去。我想既然是这么重要的一个项目，它应该用最好的技术、最好的架构来做。 当项目进行到一个半月的时候，功能差不多开发到一半，有一天晚上加班以后一起吃饭。当时一个同事坐在我的边上，对着我主管说：你们设计的那个架构可能有问题，项目开发到现在，我们在里面加很多功能越来越难了，越来越容易出错。当时我的主管跟他说，鲁肃是这个项目的架构师，这个项目的技术他说了算，不要再有任何的怀疑，这个事就过去了。 那天晚上回去之后，我仔细想了想，认为他说的这个问题确实存在。而且，在这么重要的一个项目里面用了这么多新的技术，这是一件真正可靠的事情吗？差不多在凌晨一两点的时候，我开始正视这个问题：我认为这个架构确实是有问题。不但有同事说的问题，而且我们不应该用从未经过验证的技术去支持这么重要的一个系统。 所以接下来我也需要做决定：现在怎么办？ 在凌晨三四点的时候，我决定要用新的架构。我快速搭了一个原型，用我最擅长的、最有把握的技术，做了一个演示系统。 早上八点到公司，我第一时间和主管说：马上叫齐项目组，我们开个重要的会议。会上我就说，之前这个架构有问题，我建议我们项目要改架构，改成一个更朴实的架构，用更可信赖的技术支撑，我根据这个架构做了一个 demo。会议开的非常高效，最后的结果是：第一，所有人支持用新的架构。第二，所有人会把他们自己之前的工作移到这个新的架构。这个会开完之后我特别感动。大家快速用新的架构完成了这个项目，在五月份把支付宝推到线上。 这个事情影响了我做架构的风格：我会偏实用主义，能够确保每个系统上线一定是最成功的方式。现在回想 2005 年如果当时做错一个决策的话，我的职业生涯也许可能是完全不同的道路，这个项目极大的可能会失败，对支付宝会有什么样的影响也不好说。这个事情也改变了我做决策的风格：做任何决策之前，先把“我”抛开。 感觉您和支付宝是互相成就的关系。至少，您是一个做好准备的人？ 鲁肃：应该说是支付宝成就了我。整个支付宝发展的过程中发生过非常多重要的事情，我只在个别事件中起到关键作用。 我只是支付宝发展的过程中没有掉队的人。我觉得支付宝的发展永远比我想象的快，必须全力以赴才能够不掉队，你永远保持你的胜任和担当，其实这就是你的成长。 我觉得是一种担当。从加入支付宝第一天起，我就感觉支付宝这个系统扛在我的肩膀上了。那时候系统非常的原始，特别在早期一两年，基本上三天两头出问题，而且很多时候出现在夜里，任何的问题都是你的问题。这个责任感早期建立起来，一直到后来都没有改变。 您有座右铭吗？ 鲁肃：我自己本人其实并没有什么座右铭，但是阿里巴巴有很多土话，这些土话对我的影响非常大。有一句话土话叫“此时此刻，非我莫属”，这个我觉得体现出整个阿里担当的精神，这种精神我个人觉得在我身上是有的，第一时间我会站出来。 在支付宝的发展当中还有没有其他印象深刻的事情？ 鲁肃：2010 年，我印象是 1 月份开年会。当时支付宝的总裁讲完话之后，整个晚会的会场就黑了，突然一个声音响起，是我们一个客户的声音，客户在电话里面报怨我们的服务怎么不好，有什么问题。 那个时候我觉得特别震撼：那是我第一次听到一个真正的客户的声音！而且提出我们产品的问题。这些问题过去我们都知道，但我们不觉得它对客户有那么大的影响，但是那个时候听了这个，触动非常大。 然后灯亮了，马云先生走到台上说了一句话：“支付宝你做的太烂了，非常烂！” 这是阿里的风格，非常直接。说完，然后彭蕾上台说：“我会成为支付宝新的总裁。” 我印象她做了一篇演讲，她说：“我是一个女人，我有三个特点：第一个特点是爱做梦，第二个特点是小心眼，第三个特点是不讲理。”然后跟我们提了目标。当时用户在线支付要从支付宝网站跳到银行的网站上，这个成功率只有不到 70%。她说我要求大家把今年支付的成功率从 70% 做到 90% 以上。你们技术人员不要跟我讲做不到，我是不讲理的，你们一定要做到这个事。 年会开完，那年我们全公司就一个目标，就是怎么把这个数据从 70% 做到 90%，而不是非常宏大的做一个业务战略架构。在这个目标的驱动下，我们做了一个非常重要的创新：现在每天支付用的快捷支付，就是那时候创新出来的。由于快捷支付的出现，把它从 70% 不到变成 95% 以上，让移动支付成为可能。 ...

“我的花名是改之，不是‘有则改之无则加勉’的改之，而是‘杨过，字改之’的那个改之。”一见面，他对自己花名的介绍，就让人耳目一新。至于为什么要用杨过的字给自己起名，他也毫不扭捏地坦诚相告：“因为帅。” 这个颠覆了对传统程序员刻板印象的改之，是蚂蚁金服的技术小二，但同时也是蚂蚁金服BasicCollege的技术讲师，在这所内部大学，他带出的“师弟”达7个之多。 不仅发多“话多” 而且早脱单身作为蚂蚁金服的一名中间件的程序员，改之这样形容自己的工作：好比是在为“搞装修”的业务同学“打地基”，双11等大促节点的保障能力，都和他们“脱不了干系”。可就是这样一个勤勤恳恳、默默无闻的岗位，偏偏来了一个改之这样的“话唠”程序员。 就连他“老板”，都怕了他的热情。“我是湖南长沙人，后来老板面试到长沙的应聘者，连忙摆手‘我团队里只要一个长沙来的就够了。’” 但爱说话的男孩运气总归不会太差。 之所以这么说，是因为89年的改之，四舍五入也算是个伪90后。但凭借在蚂蚁金服1年的实习，和5年的工作经历，他不但拥有了自己的小团队，还拥有了爱情。 如今，他和同在阿里巴巴工作的女朋友，每年都保证4-5次出国旅行。潜水也一直是他的爱好之一。“如果说景色的话，我最喜欢瑞士。但是吃喝玩乐的话，还是喜欢泰国。” 不过去旅行，我也处处带电脑。“程序员嘛，随时都要应对各种需求，有时候还要随地应对红蓝攻防战里面的攻击。” 关于红蓝攻防战可参考《拜关公，期末考，支付宝有群人“疯起来连自己都打》。 新时代程序员傲娇且闷骚不仅顺利找到了女朋友，他在同事圈中，也常常是负责“带节奏”的那个人。 “平时大家聚在一起，经常是一人一个switch游戏机。有时也玩玩王者荣耀，但一般都是吃饭的时候玩，或者是星巴克局。”所谓星巴克局，就是大家玩游戏时哪一方输了，或者谁的评分最低，负责请大家喝星巴克。” “一般五个人玩，我都是第三第四。”说到王者荣耀，改之脸上的微笑里透着些骄傲，“只要少死一点，哪怕杀得不够多，一般都不至于评分垫底。” 对于大众对程序员的刻板印象，改之不以为然：“在蚂蚁不会这样，但其实程序员很傲娇的，甚至非常闷骚。身边的同事包括他自己，都还保有着浓密的头发，更过分是大多还英年早婚。” “蚂蚁的程序员很少穿格子衫，虽然我们不比吃穿，但是碰到代码问题，就会立刻傲娇起来，甚至想争个高下。” 程序员傲娇的点，确实有点让人难以琢磨。“就好像有时候看到谁写代码，如果他用的是上、下、左、右的键盘按键，就会忍不住告诉他整套操作快捷键。快捷键用得溜，也能处于鄙视链前端。” 所谓“闷骚”，则是程序员对代码的完美主义追求，每次都想憋个大招，但往往会在show time翻车。 “曾经有个同学，写了一段自己很满意的代码，大概性能能提升个10倍，得意之余加了很长的注释，巴拉巴拉夸了自己的代码一堆。提交到我这边，却发现他如果能再改一下，性能能提升个一千倍。所以闷骚并不是好事情呀！” 但这些小攀比，在改之眼中都是好事。程序员的傲娇，其实也是阿里文化中不以对错论成败的表现，“为过程鼓掌，为结果买单嘛。” 当好“师兄”很重要“阿里有师兄弟文化，尤其是蚂蚁金服这边，新入职的同学都要敬茶认师兄。”改之已经带出了7个“师弟”。 “曾经是认‘师傅’，后来觉得把人叫老了，就叫‘师兄’了。公司里的前辈们，甚至盛名在外的大佬们，其实也都挺年轻的，还是“师兄”更加亲切。 而且师兄，往往除了“师”，还要担起“兄”的职责。除了传道授业解惑，还要陪伴和保护新人，共同成长进步。“我说你听，我做你看；你说我听，你做我看”就是蚂蚁师兄文化的十六字箴言。 作为一个资深“师兄”，改之表示，当师兄除了要喝师兄茶，还要会给师弟“背锅”。“代码是由0和1组成的，跟画画一样，也是门艺术。”但当艺术“反了过来”，意味就完全不一样了。 画画时画反了，是个美丽的错误。但代码跑反了，bug和问题就都来了。“蚂蚁内部有一个列着花名的名单，每个bug或者问题，复盘后都会有个归属。”而师弟在为期一年的上手熟悉过程中，“制造”出来的麻烦，往往都会记在师兄账上。 “我属于比较严格的那种师兄，代码不过关就打回去重写，重写个7、8次都是正常的。” 但每位“师兄”又都各自有自己的风格。改之的师兄，是现任蚂蚁金服技术总监杨冰。“他就属于比较nice的师兄，评估过任务难度后，会放心地将任务交给师弟，不会过多干涉。”虽然会完整交代任务的来龙去脉，但杨冰对改之大多时候都采取“放养”，“我在师兄手下基本没有返过工。” 蚂蚁的内部大学BASIC College在程序员的世界里，一直通行着一个道理：技术这一行，保鲜期短，不进则退。于是乔布斯亲自拍板建立了苹果大学；谷歌CEO拉里·佩奇一力主导GoogleEDU；通用电气每年豪掷10亿美元给员工培训发展。 支付宝的程序员也不例外，专门有一所蚂蚁金服的内部大学，叫做BASIC College。据蚂蚁金服副CTO胡喜说，这所“大学”是为了能够让技术同学们，在离开校园后继续保持学习。 除了像改之这种，蚂蚁金服自己的“师兄天团”定期授课以外，公司还会定期邀请世界级的大咖到园区，在BASIC College面对面开讲。 “BASIC College最初的培养项目是‘蚂蚁青年近卫军’，专门针对校招的技术新人，帮助他们快速适应和融入工作环境”。这所大学之所以如此命名，一方面对应着 Blockchain (区块链)、Artificial intelligence（人工智能）、Security（安全）、 IoT（物联网）和 Cloud computing（云计算）五大领域，另一方面代表蚂蚁的技术人员始终专注于金融科技的本质——计算机基础技术能力的提升。 改之说：“作为讲师，一方面能有一方讲台对外输出，一方面也能通过课堂交互，给自己带来反馈和提升。” 除了针对校招组建的“蚂蚁青年近卫军”，蚂蚁金服对社招入职的同学，还组建了“精武门”。“目前已经带过6-7期近卫军的课程，精武门那边上过我课程的人数，也已经超过了100人。” “蚂蚁自身也有很多技术名人，平时大家在论坛上发邮件讨教还要等个来回，内部大学机制最大的好处，就是能够让邮件那端的人，真真实实坐在你的身边。”尽管作为讲师，改之也对自己技术上的精进丝毫不敢松懈。 除了新技术、新解决方案的探讨，十余年来蚂蚁金服历代师兄们走过的路、踩过的坑、收获的成就，都浓缩成了精华保存在这里。 “五月下旬马上就要迎来技术大考了，这也是内部大学对同学们的期中检验。”目前全球只有少数几家顶级互联网公司拥有真正意义上的SRE团队，蚂蚁金服作为其中之一，能否借BASIC College提升工程师的风险意识和应对能力，还靠真正的演练见分晓。 本文作者：华蒙阅读原文 本文为云栖社区原创内容，未经允许不得转载。

公司内各部门工作文档难以共享？缺乏高效便捷的团队协作工具？文档放到在线云平台担心安全？…… 2019年4月22日，蚂蚁金服旗下知识创作与分享工具语雀发布“空间功能”。语雀在支持在线文档编写、多人协作、灵活的团队管理和金融级安全存储的基础上，新增“空间”功能，助力企业知识管理，帮助企业快速提升团队内容协作与知识管理效率，同时搭建企业知识门户，系统沉淀企业数据资产。 语雀是蚂蚁金服体验科技研发的创新产品，目前已是阿里员工进行文档编写、知识沉淀、搭建组织知识库的标配。 便捷的在线文档编辑基于蚂蚁金服体验技术的实践积累，语雀采用了自主研发的文档编辑器，不仅便捷易用，响应迅速，还支持文档分享及多样化的编辑功能。同时，语雀还具备实时云储存功能，编辑过程中可进行自动保存。 当文档编辑完成后，你可以通过在线的形式，或将文档导出为Word、PDF等本地文件来分享给朋友或者同事。如果希望非团队成员参与文档的编辑，可以使用文档的分享功能来解决。 而历史版本管理功能，可以查阅历史编辑的每一个版本。工作中一个文档的最终完成常常需要多人参与，到最后容易混淆，而通过文档分享功能和历史版本管理可以轻松解决文档版本管理问题。 金融级安全实时存储依托于蚂蚁金服支付宝底层技术，语雀信息存储具备金融级安全属性，对数据采用了双重密钥加密存储确保数据安全，同时文档发布可历史永久保存确保永不丢失、完整的操作日志方便团队危险操作有迹可循。 除此之外，语雀还获得了ISO安全认证和公安部三级等级保护认证。 “空间”：灵活的企业团队和知识体系管理语雀空间是面向企业或组织推出的全新知识管理方式，在这里你可以实现知识在线化管理，与成员一起交流分享知识。 语雀“空间”功能支持灵活的团队管理，除了自己手动建立团队，还支持钉钉等平台的团队导入。 知识文档管理方面，语雀支持结构化知识归档管理，通过文档大纲，自动生成文档要点，使用知识库目录编排，让多篇文档结构化，形成一本本像书一样清晰易读的知识库。 于企业机构而言，语雀提供了全新的体系化知识管理，帮助企业让协作更高效，让知识成为企业财富。 以云谷学校为例，在语雀中，云谷学校创建了许多团队，「智库」是其中之一。“智库”是云谷学校教育科学研究院搭建的一个内部分享平台，是云谷“科研扁平化”的尝试：每一个老师都是智库的主人，可以在这里建立自己的小平台，展示自己正在研究和探索的领域及进展；它也是开放和互动的，希望通过把自己向其他人打开：“把自己的研究暴露在大家的监督下，把自己的探索暴露在大家的帮助下，让自己的能力暴露在那些可以发起协作的人的面前。” 在“智库”有研究院搜集整理的一些教育理论与方法，也有老师们自发分享的自己的推荐和研究内容，也有技术部门、HR部门建立的工具平台，让云谷的所有人更好地熟悉云谷已经走过的路。 学校的老师们表示，语雀知识库不仅有利于学校的知识沉淀，也有利于教师团队工作的展开。 目前，语雀“空间功能”已正式上线，点击官网即可开通体验。体验地址：https://yuque.com。 本文作者：华蒙阅读原文 本文为云栖社区原创内容，未经允许不得转载。

摘要： 0.2.0新增fundebug.test()方法，同时报错增加了Page数据。 Fundebug提供专业支付宝小程序BUG监控服务，可以第一时间为您捕获生存环境中小程序的异常、错误或者BUG，及时给开发者发送报警，帮助您快速修复BUG。欢迎大家免费试用，也欢迎各位用户反馈建议或者问题。 test(name, message)fundebug.test()用于测试，可以将测试数据发送到Fundebug，并收到报警邮件。 name: 错误名称，参数类型为字符串，默认值为"Test"message: 错误信息，参数类型为字符串，默认值为"Hello, Fundebug!"示例： fundebug.test()fundebug.test("Test", "Hello, Fundebug!")fundebug.test() 主要用于测试，它发送的错误每次都会报警邮件（每天的限额是 20 封），这样可能会给您造成困扰。为了避免重复报警，请使用其他 API 记录错误，这样同一个错误将只会在错误数达到阈值(10, 100, 100...)的时候报警。 notifynotifyErrorPageFundebug插件会调用getCurrentPages方法获取报错页面的Page数据，与错误数据一起上报： { "route": "pages/index/index", "_viewId": "1556021552987", "data": { "title": "Alipay" }}如果不需要收集Page数据的话，可以将silentPage属性设为true: fundebug.init({ silentPage : true})最后，感谢 Fundebug 用户闵胖胖的反馈。 参考Fundebug文档 - fundebug.test()Fundebug文档 - silentPage关于FundebugFundebug专注于JavaScript、微信小程序、微信小游戏、支付宝小程序、React Native、Node.js和Java线上应用实时BUG监控。 自从2016年双十一正式上线，Fundebug累计处理了10亿+错误事件，付费客户有Google、360、金山软件、百姓网等众多品牌企业。欢迎大家免费试用！ 版权声明转载时请注明作者Fundebug以及本文地址：https://blog.fundebug.com/2019/04/25/fundebug-alipay-miniprogram-upgrade-0-2-0/

我们知道要想使用支付宝，要具备以下条件具备个体工商户营业执照或者企业营业执照。 这样才能申请到支付宝接口的，对于个人开发者，根本就是一个大门槛，为了支付而去注册一家公司，有点成本高了，那么个人可以用支付宝吗？在这之前不可以，现在可以了！因为支付宝有服务商，有能力的企业可以申请成为支付宝官方签约的服务商，服务商签约后，就可以获得开发权限。 所以有一家公司：北京顶风科技有限公司，他成为了服务商，然后开发了PAYJS，用于开放接口给个人开发者接入官方支付宝！所以我们可以利用PAYJS的接口进行开发即可。 而且申请这个接口只需要个人支付宝扫码授权，填写一些基本资料即可。 PAYJS官网 PAYJS的优点1、即时到账2、支付宝官方接口3、安全稳定4、提供清晰易懂的开发文档和DEMO 我开发的支付宝扫码支付DEMOhttp://liketube.cn/payjs/alip... 扫码后，就是这样的 即时到账不存在二次清算，不存在提现操作，对方付款后，直接到达您个人支付宝账户。 目前PAYJS只开放了支付宝扫码支付的能力可以通过PAYJS的扫码支付接口发起支付，具备以下能力：1、发起订单2、查询订单3、异步订单4、订单退款5、关闭订单 请求参数 大家可以体验：https://payjs.cn/ref/DNXBJD 对了，PAYJS早就有微信官方支付接口，也是个人申请，无需执照：点击了解 开通PAYJS只需300元，永久，只是一个解决方案，不喜勿喷，我用了一年多，体验非常好。 TANKING2019-4-24

目前项目中比较常用的第三方支付无非就是支付宝支付和微信支付。下面介绍一下Vue中H5页面如何使用支付宝支付。其实很简单的，只不过是调自己后台的一个接口而已（后台根据支付宝文档，写好支付接口）。触发支付宝支付调用后台接口，后台会返回支付宝提供的form表单，我们只要在vue里面创建新节点，将返回的form表单append进去，并提交就可以唤起支付宝支付。另在此说一下这个returnUrl, 它是支付后支付宝回调的页面。具体可以根据自身业务，后台写死或者由前端控制。methods () { /** * 支付宝支付 / goAlipay () { this.$loading.show() const data = { / 自身接口所需的一些参数 / … amount: this.price, / 支付后支付宝return的url / // returnUrl: ‘www.baidu.com’ returnUrl: window.location.origin + window.location.pathname + ‘?userParams=’ + this.userParams } this.$http( this.$apiSetting.alipay, data ).then(res => { this.$loading.hide() if (res.data.statusCode === ‘000000’) { const div = document.createElement(‘div’) / 此处form就是后台返回接收到的数据 */ div.innerHTML = res.data.data.alipayInfo document.body.appendChild(div) document.forms[0].submit() } }, error => { this.$loading.hide() console.log(error) }) }} ...

小程序的平台越来越多了，开发者的精力也越来越分散。事实上，这些平台有怎样的特色？他们有怎样的代表作品？他们有几个入口？开发成本高吗？他们有给开发者怎样的扶持政策？一文为你解析小程序六大平台。01 微信关于微信小程序2017 年 1 月 9 日，微信小程序正式上线。经过三年的发展，它俨然成为了开发者最关注的小程序开发平台。在 2018 年 8 月，马化腾就透露已有 150 万开发者加入了小程序的开发队伍，小程序应用数量超过 100 万，覆盖 200 多个细分行业，日活用户达到 2 亿。而在 2018 的全年财报也表明，微信小程序日活跃账户数增长迅速，用户人均日访问量同比增长 54%，而中长尾小程序也占到了小程序日均总访问量的 43%。在小游戏中，微信已有单月流水过亿的杰出小游戏作品。10 款内购道具月流水过千万小游戏变为了 10 款，11 款广告月流水过千万小游戏。头部小游戏的成功已经无需证明，但从整个行业来看，三十天留存率 43% 亦足够优秀。微信里的社交关系让小程序拥有了更多的吸引力，小程序则让微信的「操作系统梦」成为现实。在微信中，小程序拥有着超越公众号之外的连接和服务能力，也能将公众号、群聊、对话、朋友圈串联起来，为用户提供更延展也更丰富的服务。代表作品小程序：拼多多、跳一跳、享物说、小打卡、轻芒、小年糕、乘车码、粤省事等小游戏：跳一跳、物理弹球正版、头脑王者、欢乐斗地主、星途 WeGoing、羽毛球高高手等主要入口微信聊天下拉的小程序界面是小程序最重要的入口之一。聊天的小程序卡片、公众号推文中的、分享小程序、四散的小程序都是小程序的重要入口。据不完全统计，微信小程序已有 60 余个入口。开发成本小程序的主要开发语言是 JavaScript ，小程序的开发同普通的网页开发相比有很大的相似性。对于前端开发者而言，从网页开发迁移到小程序的开发成本并不高，但是二者还是有些许区别的，毕竟小程序还处于一个封闭的程序运行环境。开发文档：https://developers.weixin.qq….扶持政策在小程序和小游戏上，微信都推出了不同的扶持计划。????小程序腾讯云在微信公开课上宣布推出的「小程序 · 云开发」资源扶持计划价值 10 亿。该计划分为长期普惠、进阶扶持和高阶扶持三种机制。腾讯云提供的基础版套餐、专业版资源、旗舰版资源都是扶持奖励。????小游戏创意小游戏鼓励计划：创意标识、初始用户、分成激励、创意保护。种子用户计划：针对新游，微信将无差别分配等额的种子用户。在第一批无差别等额用户发布后，微信会持续观察所有小游戏的数据，根据平台的数据模型，给新游戏第二批的种子用户。在这两个计划之外，微信提供的应收转投放和应收预提将帮助开发者快周转。同时对普通开发者的抽成比例进一步降低。月流水 50 万以下的小游戏免抽成。月流水在 50 万以上的部分，游戏内购抽成 40%；日流水在 100 万以下的部分，广告抽成 50%。02 支付宝关于支付宝小程序2018 年 9 月 12 日，支付宝小程序正式上线，主要活跃在商业和生活生活领域，暂不支持小游戏（严格来说目前仅支持支付宝官方开发游戏类小程序，如「叠叠乐」）。据悉，截至 2019 年 1 月，支付宝小程序的数量已增至 13 万，日活跃用户数突破 2.3 亿，平均 7 日留存率为 43.26%。目前，支付宝小程序对企业账号及个人账号（已开启个人开发者限量公测）开放。支付宝的实名认证并与「钱」挂钩让用户和商家都更具信任感；而有独特优势的信用体系则让支付宝在与押金、租赁相关的场景大放异彩，比如共享单车、共享充电宝等支付宝小程序，在接入芝麻信用后为用户提供了免押金等便捷服务。代表作品免押金类：来电、内啥、人人租机、哈啰出行等其他：好食期、青团社兼职、航旅纵横、淘票票电影等主要入口主要为支付宝 app 首页顶部搜索栏，以及首页下拉呼出「小程序收藏」。更多支付宝小程序入口，可以查看 ???? 《细数支付宝小程序的 35 个入口，我们终于找全了》。开发成本与微信小程序的整体架构基本一致。如果你想将微信小程序迁移至支付宝，只需重命名小程序文件后缀、一些事件函数和部分 API 即可。开发文档：https://docs.alipay.com/mini/…扶持政策3 月 21 日，在 2019 阿里云峰会 · 北京上，阿里巴巴旗下的阿里云、支付宝、淘宝、钉钉、高德等联合发布「阿里巴巴小程序繁星计划」：提供 20 亿元补贴，扶持 200W+ 小程序开发者、100W+ 商家。凡入选「超星」的小程序，入驻支付宝、淘宝、钉钉、高德后还能得到流量重点支持。03 百度关于百度智能小程序2018 年 7 月 4 日，百度智能小程序正式上线，主要运行在百度 app 上，主打「体验、流量、智能、开放」四大特点。据了解，12 月时百度 app 已为小程序开放了 40 多个流量入口，并为小程序开发者提供了超过 60 个 AI 接口和超过 20 个 NA 化组件。百度智能小程序支持小游戏开发，不过目前支持的主体主要为媒体、企业、政府及其他组织，个人主体类型开发者暂时无法入驻。代表作品AI 相关：爱说唱、长隆 AR 动物园、AI 分诊助手等其他：小红书、爱奇艺视频、几何大逃亡、贴吧等主要入口可以从百度 app 的搜索栏联想、搜索结果、底部菜单「我的」中进入百度智能小程序。更多百度智能小程序入口，可以查看 ????《百度的搜索流量终于全面开放！新入口就在王牌产品主场景》。开发成本与微信小程序的整体架构基本一致。如果你想将微信小程序迁移至百度，只需使用百度的「搬家工具」转换已有的微信小程序即可。开发文档：https://smartprogram.baidu.co…扶持政策在 2018 年的百度世界大会上，百度宣布了智能小程序「开发者共筑计划」——「千百十一」，分别对应着百度将为智能小程序开放全域千亿用户流量、提供百亿的广告分成、成立一个提供投资与推广的创新基金以及像公开课一样的一对一专人服务。04 淘宝关于「轻店铺」2018 年 9 月，手机淘宝上的小程序「轻店铺」开始内测。淘宝「轻店铺」是一个支持个人或者企业进行开店的工具，具有群聊、发文章、门店导航等功能。据了解，「轻店铺」将把淘宝品牌主的直播、微淘内容以及门店信息进行汇集，最后形成了一个信息块，当用户在线上搜索该品牌时会打包弹出。代表作品严格来说，目前手淘上只有「星巴克中国」是真正的「轻店铺」，底层与支付宝小程序相通。其他的淘宝店铺虽然同样有小程序标志性「胶囊键」，但并不是小程序，且胶囊键与「轻店铺」按键不同。主要入口在淘宝搜索「星巴克中国」，即可从顶部的横幅进入。开发成本因仍处于内测阶段，开发者可将姓名、联系方式、公司名称、职务发送邮件至 taolite@service.taobao.com 申请成为内测用户。未获取内测资格的用户将无法进行入驻。05 字节跳动关于字节跳动小程序2018 年 11 月 8 日，字节跳动小程序正式上线，小程序旨在利用优质内容所关联和产生的使用场景进行小程序导流，解决开发者流量与转化困扰。开发一套小程序就可以服务多个产品是头条小程序的优势所在。在字节跳动开发者平台开发的小程序有机会出现在抖音、西瓜视频等不同平台。目前字节跳动被人所熟知的小程序，多为其他平台的已有内容。但在游戏、电商、娱乐等领域，字节跳动反倒有了更多拿得出手的作品。不过由于平台尚在发展阶段，很多内容构架都尚未完善。代表作品小游戏：光与森、行星毁灭、音悦球球、一笔画完等主要入口今日头条文章详情页、微头条、小视频、搜索等入口均为今日头条小程序入口，新版今日头条「常用」底部导航栏还在内测一个类似小程序桌面的新界面。而在其他平台，抖音短视频左下角也有对应的小程序入口。开发成本字节跳动小程序暂不支持一键转换工具。暂不支持 wepy，mpvue 等框架，需开发者主动把利用 wepy 框架开发的代码，编译为小程序的语法，才能在头条上正常的渲染。开发文档：https://microapp.bytedance.com/扶持政策目前字节跳动公布的扶持政策仅面向小游戏。针对普通游戏，开发者可以拿到广告日流水不超过 100 万部分的 60%，超过 100 万的部分开发者可保留 50%。而在字节跳动首发的游戏将获得更多资源倾斜，开发者可以拿到广告日流水不超过 100 万部分的 70%，而超过 100 万的部分开发者可保留 60%。06 快应用关于快应用vivo、华为、OPPO、小米、联想、金立、魅族、中兴、努比亚、一加、海信、中国移动终端想要一起做一个基于手机硬件平台的新型应用形态。十二家手机厂商和服务商组成的快应用联盟来势汹汹。覆盖 10 亿设备、月活 2 亿、打开快应用 20 亿次、留存 1 亿个桌面图标，35% 的流量来自桌面留存图标。快应用与其他小程序平台应用同质化严重，联盟 12 个合作伙伴对开发者的资源分配亦有较大不同。代表作品工具类：菜鸟裹裹、西窗烛、吐司工具箱等主要入口快应用有四类入口：应用分发、智能场景、二次入口、开发者自身入口开发成本快应用使用前端技术栈开发，原生渲染，同时具备 HTML 5 页面和原生应用的双重优点。快应用使用 MVVM 的设计模式进行开发，开发者也无需直接操作 DOM 节点的增删，利用数据驱动的方式完成节点更新。相比微信、支付宝小程序，快应用的开发语法标准，其语法也更接近传统网页。开发文档：https://doc.quickapp.cn/除了以上几大平台推出的小程序，其实优酷、钉钉、网易云音乐也出现过小程序的身影：优酷的小程序、钉钉的 E 应用，还有网易云音乐的「私藏推荐」。▲ 左为优酷小程序，右为网易云音乐小程序 在已有几大平台的努力下，小程序存在的方式和其代表的服务形态已经被越来越多的平台所认可。这些平台或许不会 all in 小程序，却也会在自己的生态内对小程序进行更多的尝试。和一个成熟、有包容性的平台相比，这几个平台或有严格的类目限制；或者只是将原有的 H5 内容转为了小程序；有的则只是模仿了小程序相似的界面。对于开发者而言，他们似乎不能算一个开放的开发平台，但也与小程序有着不小的联系。知晓云福利参与 iOS、Android SDK 内测领福利「知晓云」cloud.minapp.com，诞生于 2017 年 8 月 8 日，是以小程序开发为起点的后端云服务，它免去了小程序开发中服务器搭建、域名备案、数据接口开发、线上运维等繁琐流程，让开发者更快、更地做出优质的小程序。你的主要业务不在小程序，而是在移动端？没关系，iOS、Android 的应用开发也可以使用知晓云来完成了哦～知晓云移动端（iOS、Android）支持的内测活动已经开启：即日起至 4 月 17 日，填写表单报名参与内测活动的用户，在成功接入移动端（iOS、Android）应用后将获得 100 元无门槛优惠券???? 报名点这里 ???? ...

与传统意义上的红包相比，近两年火起来的“红包”，似乎才是如今春节的一大重头戏。历经上千年时代传承与变迁，春节发红包早已成为历史沉淀的文化习俗，融入了民族的血脉。按照各家公布的数据，除夕全天微信用户红包总发送量达到80.8亿个，红包峰值收发量为40.9万个/秒。春晚直播期间讨论春晚的微博达到5191万条，网友互动量达到1.15亿，网友抢微博红包的总次数超过8亿次。为此，本文策划了“春节红包”系列文章，以期为读者剖析各大平台的红包活动背后的技术细节。本文为支付宝篇。蚂蚁金服旗下的支付宝经过十几年的发展，从简单的支付工具逐步发展成互联网金融平台。2013年余额宝的崛起就是互联网金融平台升级的标志型事件，这一年支付宝顺利进行了PC向无线的布局，可以说架构成功升级到移动互联网金融平台。经过两年的发展，2015年口碑和社交业务的崛起让支付宝架构进一步在原有架构基础上拓展出支持线下市场和社交的生活互动型架构。2015年钱包9.0的发布，这个里程碑式的项目初步奠定了支付+移动互联网金融+生活互动型混合架构。演进示意图如图1所示。图1 架构演进示意图项目保障体系2015年12月份，我们在第一时间得知支付宝中标央视消息后，既兴奋又担心！兴奋的是，这是一次千载难逢的机会，我们终于可以一展身手。担心的是，支付宝和央视联合搞活动，是我们有史以来最大规模的活动，到底规模多大，我们没有任何概念。唯一能得到的信息是，历年观看春晚的人数大约在7亿多，支付宝的年度活跃用户4亿多，至于用户的行为习惯，没有任何参考模型。虽然心里不是很有谱，但也没那么担心，信心来自于两方面。经历过这么多年的双11和去年的除夕，多年经验的沉淀，我们对超大规模的活动沉淀总结出一整套预测模型，而且这个预测模型经过了多次实战检验，相对比较准确。从钱包9.0开始，我们已经开始布局生活服务平台，这个版本搭建起社交和口碑两个平台的雏形，架构上从移动互联网金融架构扩展出能支撑生活互动型的架构，形成了支付+互联网金融+生活互动的混合架构，这种架构体系既能支持移动互联网金融的高可用、资金安全、高弹性伸缩，又能支持生活互动型架构的轻巧、灵便、弹性十足的特点。架构示意图如图2所示。图2 总体架构示意图团队在拿到中标信息后，我们迅速决策，达成了以下指导原则：优先确保核心链路，保证核心链路上用户体验顺畅。万一出现系统容量不足，系统必须能扛住洪峰，不被压垮，即使这种情况下也要给用户尽量友好的提示文案。在确保主链路基础上，还需要照顾到支付宝App内几百个非关键链路，对于非关键链路按照业务重要程度分为4个等级，根据等级分配不同的资源配置。经过2个月的精心准备，在激动人心的4小时结束后，整个春晚支付宝系统稳稳地扛住了4波洪峰，表现平稳，无论是核心链路还是非核心链路，没有出现任何问题。4个小时内几乎没有用户因为系统、功能上的问题而产生投诉，客服同学没有任何咨询压力。用户“咻一咻”在第二场活动达到高潮，累计互动次数达到1808亿次，是去年的16倍。20点38分，“咻一咻”峰值达到177亿次/分钟。可以想象一下，几亿用户同时拿着手机，以想戳透手机屏幕的速度点击咻咻按钮，几亿的请求瞬间从客户端洪水般涌入服务端，对后台将是多大的压力！这么高并发情况下，如果系统设计不合理或者预测模型不准确，将立即被冲垮，应用系统一旦被冲垮，高压下根本没有恢复的机会。五项准备为了保证整个春晚顺利进行，我们在以下5个方面做足了功课：1）相对合理的超大规模压力预测模型。前提约束条件要说明下，服务器资源是有限的。总共这么多服务器，要充分利用起来需要两个条件。应用架构必须可以大规模扩容。如果架构不合理，即使有服务器也没法扩容，刚好在架构演进的过程中，支付宝App服务端进行了LDC单元化改造，扩容对我们来说so easy。模型要尽量准确。模型不准确的后果是用户的行为习惯和预期不同，导致部分业务压力特别大，无法正常提供服务，而另外部分服务器十分空闲，占着机器资源不干活。2）核心链路和非核心链路彻底梳理。核心链路梳理和非核心链路梳理相对比较容易，注意以下5点。接入层必须具备足够富裕的容量支撑，即使因为评估不准浪费部分机器也是可以容忍的。接入层一旦出问题，所有业务将全军覆没。如果接入层足够健壮，当某个业务抗不住时，完全可以通过限流来隔离这个业务，而其他业务不受任何影响。用户必须能进得来。也就是要保证用户能顺利登陆进来，如果用户连登陆都受限制，体验肯定好不到哪儿去。用户要能玩起来。这是核心业务逻辑，如果咻都没法咻，或者咻了半天红包或者福卡发不出去，那也是致命的。要能保证用户能传播和互动起来，包括分享、加好友、聊天。非核心业务需要进行合理分级。我们大致分了4档。第一档4个tab，非核心链路中的最高优先级，必须力保。第二档1级入口，容量必须是平时的几十倍。第三档2级入口，容量是平时的十几倍。第四档，一、二、三档外的其他业务，要保证系统具备自我保护能力，底线是不能被压跨。3）大规模生产系统全链路压测。核心链路和非核心链路梳理清楚了，进行了性能优化和系统扩容后，能否达到我们预测的目标值，要靠线上全链路压测来验证。全链路压测相应的原则：核心链路必须全部覆盖，包括单独压测和混合压测，非核心链路要尽最大可能覆盖。经过项目组的努力，全链路压测基本覆盖了所有的核心链路和非核心链路，覆盖率接近100%。单系统或接口压测问题不大，但混合压测就比较头痛，主要还是用户行为预测的问题，为了确保万无一失，在混合压测时组合出多个模型进行压测，尽最大可能暴露出系统的性能和容量问题。4） 高频次灰度内测和线上小规模活动预热（2月1日和2月4日两次小规模活动）。高频次的内部灰度测试更主要是能暴露出一些比较隐蔽的功能问题，能进行充分的业务配置演练。而两次小规模预热则起到了更大的作用，虽然规模没有春晚大，但用户行为习惯具备一定的参考性，并能相对真实地模拟春晚活动。我们在这两次预热活动中确实也发现了一些问题，并且根据相对真实的用户行为习惯对系统容量进行了调整和优化，有效地防止了春晚出现资源分配不均的问题。5） 上千个业务、技术预案和完备的应急响应体系支持。业务上主要参数化、配置化，通过服务端来控制客户端的行为，以满足业务多样性需求，降低客户端版本升级困难带来的冲击。技术上预案分为提前预案和应急预案。提前预案主要作用是让服务器轻装上阵，将计算能力节省下来供核心功能使用，比如降级日志、关掉定时任务等。而应急预案更主要是用来保命的，万一系统在某些点出现了意外状况，会通过所谓的大招以牺牲部分非核心业务来保核心业务，也就是丢卒保车。当然春晚因为前期工作做得比较到位，这些大招都深藏闺阁，没机会施展。八大技术难点这么超大规模的活动，肯定存在很多技术难点，平时看不起眼的一个问题，在超大规模情况下，就可能被放大。接下来简短总结这些技术难点。1） 登陆：去年除夕，我们登陆上容量做的不足，导致用户在登陆时就被挡在门外。本次春晚，我们做了硬性规定，必须能顺利登陆进来，坚决不允许出现因为登陆系统处理能力不足而导致出现限流这种很不好的体验。去年的登陆峰值大约在十几万每秒，今年我们提出实现百万登陆能力，这个量是平时量的200倍左右，也是去年除夕峰值的6、7倍，而我们用户数量也仅仅增长了2，3倍，百万级别应该没有问题，而实际上登陆量确实也在这个数量级。目标确定好了，接下来比较难的就是如何做到这个系统容量目标。性能优化和扩容两手抓，而且更多的是要靠性能优化，作为有追求的工程师扩容不应该是首选。经过1个月左右极致的性能优化，最终机器仅仅扩容到原来的4倍，大约在几千台，其他的提升全部通过性能优化实现。2） 如何应对洪峰（图3是简单的架构示意图）：可以想象，几亿用户同时在线，在几乎同一时刻进行咻咻操作，瞬间洪水般流量直接冲进来，当时秒级峰值达到了2.95亿次。对于这么大的流量，我们使用了漏斗形的分流、导流方案。客户端请求到我们的网络设备后，从应用视角我们大体分为三层LVS、spanner、gateway。这儿你可以看作一个漏斗，越往里层，可以处理的请求越小。之所以这么设计，还是基于业务和用户体验，对于咻一咻，虽然有2.95亿次请求，但我们的奖品个数是有限的，每场只有6000万个现金红包和上亿张福卡。如果发奖能力达到了6000万每秒，那6000万个现金红包瞬间被秒光，这也不是业务和用户想看到的。我们平衡下来，将奖品（现金红包+福卡）发放能力设定在100万每秒，大约可以在几分钟内顺利发完这6000万个现金红包。这里有几个关键点，gateway的处理能力是千万级别，集中咻咻大约用掉了100万，剩下900万是给其他业务的。当大量咻咻请求没到gateway时，lvs和spanner要能正确处理，给用户比较好的体验，不能出现任何限流问题，这也符合用户没有中奖预期。我们的处理方案是，如果咻咻请求没到后端，给用户随机显示彩蛋（包括文案、图片、视频等）。对于spanner虽然处在网络更外层，但也需要理解部分业务逻辑。比如要能识别出不同的rpc请求，尤其是要能区分出咻咻接口。如果spanner不做任何识别，只管向网关转发1000万请求，那肯定将导致转发的咻咻请求超过100万，而挤占了其他业务的配额，导致其他业务被spanner限流无法正常处理。图3 网络漏斗模型示意图3）活动奖品控制系统：春晚一共搞了4场活动，大约发了2.3亿个现金红包和十几亿张福卡。在这么大规模的活动下，我们做到了0差错0资损，没有多发或者少发一个红包，严格控制了福卡的发放比例，也合理控制了发奖速度。4场活动基本控制在3-5分钟内完成，严格按照我们设定的预期模型执行。所有这些都得益于我们的奖品控制系统，对于这个系统设计上有3个基本原则：资金0资损、百万级的奖品处理能力、灵活的奖品发放控制。4）动态技术：客户端的一个最大的问题就是版本发布，有个成语叫做“覆水难收”，刚好比较形象地说明了这个问题。版本一旦发布，如果有问题需要让用户再次升级，时间已经来不急了。为了更好地控制客户端的行为，参数化、配置化就成了必不可少的利器。但参数化、配置化带来了两个问题：客户端预埋了很多逻辑，极大的增加了代码复杂度，客户端的代码测试难度加大，质量很难保证。因为参数化、配置化，需要有机制能够保证配置数据能尽可能实时下发给几亿客户端，并且在最短的时间内生效。对于客户端复杂度增大的问题，主要通过多套机制保障。传统的质量保障，加强测试力度。进行不同范围内的人群进行灰度。安排多轮演练，模拟各种配置场景。为了保证春晚的万无一失，年前增加了几场小规模预热，通过预热发现尽可能多的问题，并进行规避。客户端版本发布后，产生的部分bug，必须修复，通过热补丁的方式，在不发布版本的情况下修复这些bug。对于配置的实时下发，我们单独做了一套机制，使用推拉结合的方式，在最短的时间内下发配置信息。以服务端推送为主，通过sync机制，只要用户在线，尽最大可能将配置数据推送到客户端，万一有极少量配置推送失败，还可以通过拉的方式进行补偿，这样确保了配置数据一定能下发到客户端。5） 资源管理：在这次春晚活动中，涉及到大量的资源，包括图片、拜年视频等。图片和视频都比较大，十几b到几百kb不等。当在高峰期时，如果瞬间有海量的请求到CDN上，这么大的请求带宽根本扛不住。我们当时预估了大约有几T的带宽需求。为了能有效地扛住瞬间峰值对CDN的压力，我们对资源进行了有效的管理和控制。首先在客户端预埋了几个缺省资源，万一真不行了，这几个资源可以用。其次尽量提前打开入口，当用户浏览过后，就将资源下载到本地。再次浏览时不再需要远程访问CDN。最后，做了应急预案，高峰期一旦发现流量告警，紧急从视频切换到图片，降低带宽压力，确保不出现带宽不够而发生限流导致的黑屏等体验不好的问题。最后的结果可以用完美来形容，由于预热充分，带宽虽然很高，但没达到我们的告警值，应急预案也没有使用。6） 实时数据计算能力：红包剩余个数尽可能实时准确显示。这里有一个细节，当咻咻的时候，红包剩余个数随着你咻咻在不停的递减，而且递减的个数比较平滑，不像某些App，出现长时间不动，动一次就是断崖式变化。虽然这是一个不起眼的细节，但我们为了给用户更好的体验，让没抢到红包的用户能在最短的时间内知道尽量准确的红包剩余个数，我们解决了这个技术难题。我们充分利用了两个方面的能力。一是实时的流式计算处理能力，可以在秒级收集各个服务器处理的红包个数，并且进行汇总计算，并把这个计算结果写在缓存中。另一方面我们充分利用每个请求头的控制信息，在用户每次请求的同时带回剩余个数。客户端收到应答后，如果发现本次请求没有中奖，从头部控制信息中解析出红包剩余个数并正确显示。7） 全链路压测：支付宝有一套非常强大的线上环境压测的利器，能够模拟出你所想要的任何请求场景。对于参与用户量非常大的活动，前期再完备的准备，也不能确保一定不出问题，需要对线上环境进行性能压测。在全链路压测机制下你不仅仅可以知道各个应用系统的容量水位和目标之间的差距，还能够知道整个基础设施层，比如数据库、网络、存储等的瓶颈，让你能够根据压测数据进行快速决策。8） 超大规模活动弹性计算能力：这么大规模的活动，初步计算下来，大约需要几万台机器，包括应用服务器、存储、网络设备等。对于这么大量的资源调配，如果没有金融云高弹性能力，短时间内部署完成，这是不可想象的。得益于金融云的高弹性能力，我们基本做到在1周内完成了相关资源的调配部署。小结2016年春晚在轰轰烈烈中过去了，我们收获了很多，其中最重要的一点是我们对春晚的用户行为有个初步的了解，如果再搞这种超大规模的活动，预测模型将更加精确。如果2017年央视春晚我们继续中标，我们将做得更加从容，更加顺滑，真正做到喝着咖啡过春晚！原文来自：InfoQ；原文链接：http://www.infoq.com/cn/artic…点击阅读更多，查看更多详情

摘要：本文重点分享了在双11背景下，OceanBase云平台所遇到的挑战，介绍了针对实时监控和规模运维两个方面云平台所提供的应对策略，并详细解释了需要做哪些设计才可以解决这些挑战？本文从开发者视角，带大家了解构建大规模分布式系统要关注的事情。 演讲嘉宾简介：张松树（花名：笑言）：现任蚂蚁金服 OceanBase 团队技术专家，2014 年加入阿里巴巴，曾是阿里云 GTS 产品 Founder，从事领域涉及分布式事务、中间件高可用，致力于分布式系统稳定性的建设工作，目前主要负责 OceanBase 云平台的建设。 本次直播视频精彩回顾，戳这里！https://tech.antfin.com/activ…以下内容根据演讲嘉宾视频分享以及PPT整理而成。https://tech.antfin.com/activ… 本次的分享主要围绕以下四个方面： 一、双11带来的挑战二、实时监控技术点剖析三、极致运维技术点剖析四、OceanBase云平台一、双11带来的挑战刚刚过去的2018年双11是阿里双11的第十个年头。从2009年开始，当时一天的营业额还不到1个亿，但是到了2012年，营业额就已经增长到了191亿。在这三年当中，除了逐年成倍增长的销售数字，另外比较重要的事情就是OceanBase诞生了。2014年，OceanBase开始应用于支付宝的核心交易系统，当时OceanBase的版本是0.5版本，一个开源版本，大家最开始了解OceanBase就是从0.5版本开始的。到了2015年，将近1000亿的日营收，蚂蚁交易支付链路百分之百的流量都已经切到OceanBase上了。2016年双11，支付宝的每秒支付峰值创造了12万笔/秒的世界记录。全世界比较大的交易系统有Visa和Master。Visa的支付峰值大概是5万笔/秒，Master比Visa略少一些，所以12万笔/秒是非常有纪念意义的。2017年双11，诞生了数据库处理峰值4200万/秒世界纪录，2018年，OceanBase在存储成本以及性能方面有了重大突破。下面的漫画生动地描绘了双11前阿里技术人员的工作状态。在双11将要开始的一段时间，对于技术人员心脏的挑战是非常大的。普遍来说，每年双11从零点时刻开始，交易曲线会在很短的时间内冲到峰值，在峰值处很平稳的运行10分钟左右，然后再掉下来。大家可以思考一下，为什么会存在那段10分钟左右的平稳期？这是因为系统容量不足以承载瞬时流入的海量请求，这时系统会采取一些自我保护手段来保证系统不被压垮，这也是分布式高可用的一些特征，做互联网应用的人会比较熟悉这一点。这些策略包括限流、预付、当天无法退货等，这是都是为了保证系统的高可用而采取的措施。但是没有用户请求被限流，才是最理想的购物体验，这要求我们的技术人员需要通过技术手段来不断提升用户的购物体验。双11具体会给OceanBase带来什么挑战呢？首先看系统高可用，简单来说，高可用就是能够时时刻刻提供一个持续稳定的服务。如果只有几百几千人使用系统，高可用是很容易实现的。但是对于数十亿用户同时并发请求的情况，如何维持如此大规模分布式系统的高可用是一个非常挑战技术深度的事情。来看OceanBase，目前OceanBase有数万个的服务节点，这些服务节点分布在阿里巴巴不同的数据中心。服务器部署在不同的地域会衍生出一系列问题，比如不同地域之间存在网络延迟，北京到上海，大概有30-50毫秒的延迟。那么我们的数据库需要尽可能的保证事务操作不跨地域，以保证数据库服务稳定。还有实时计算和监控能力的问题，前面所提到的，4200万条SQL在同一秒产生，每条SQL背后有大量、多维度的监控数据，监控信息散落到分布式系统中，要给不同业务视角的同学提供满足业务需求的数据，需要把这些散落在数万个服务节点上数据快速发现、聚合、实时计算并且展示出来。这也是极具挑战的。另外，怎么能做到全方位的安全？数据安全是系统的底线，无论是数据库服务，还是数据库平台都会将数据安全作为系统建设的基本原则。还有，如何做到极低的资源占用？在做分布式系统时，需要考虑资源问题。由于几万台服务器本身的成本是非常庞大的数字，我们的用户在进行技术选型的时候，成本是很重要的考虑因素，所以将系统资源发挥到它的极限对于工程师来说是极具挑战的。最后一个挑战是系统要做到可定制可扩展。做业务系统时所能提供的功能非常有限，无法预设到百分之百，也不可能匹配到所有用户的需求，只能尽可能的把系统做到用户可自定义，站在用户的视角来，把他们的问题解决掉。对于OceanBase来说，可定制可扩展是非常重要的问题，它需要给每一个用户提供专属的数据库操作体验，用户可以通过接口或者服务，通过数据库云平台做一些定制化的操作。二、实时监控技术点剖析一条SQL的一生一个数据库能够正确的执行SQL是最基本的功能。而对于OCP来说，这只是开始。分布式系统与单机系统最大的区别是分布式系统由多个服务器组成，那么数据究竟在哪个服务器节点上？一条SQL由哪台服务器承担执行任务？如果发生了问题，应该到哪一台机器说查找数据，并解决问题？这些都是OCP关注的问题。OCP对租户级和会话级的监控数据进行采集，包括监控项，等待事件和锁事件。采集完之后对采集的数据从不同的视角进行聚合，给不同的业务人员提供满足他们视角的视图。之后对数据进行分析，包括分析SQL性能，执行路径等等，给用户提供实际的建议。根据预设规则或者自定义规则，实时告警。这些流程是整个分布式系统能够提供更好更稳定服务的必备环节。实时监控-海量数据处理下图左边是蜂窝状的数据库服务器，它会分布在全国各地多个机房内。那么该如何集中化处理这些数据？最简单的方法是把他们采集到集中式的数据库里面，但随之而来的问题就是不同地方的数据所经历的延时不一样。数据采集到数据库里面后，对于这些不是同一个时间段的数据如何提供统一的视图？数据进行集中处理后，要做相应的加工，如果加工的链路足够的长，足够的耗时，那么数据实时性就会遇到问题。而且对于数据所给出的建议功效也会大打折扣。所以需要采用高质量的算法和并行计算的策略解决这个问题。同样，通过聚合的链路把数据进行分类，如建议事件，警告事件，普通事件等。采用不同事件处理流程解决不同的数据。实时监控-监控信息每一条SQL都会产生N个监控项，比如，4200万条SQL背后的数据量是N*4200万监控信息。在这种量级下，分布式系统的开发人员重点关注哪些问题？如下图，在系统级别下包括集群，实例，主机，事务，IO，锁和临界区等指标。在SQL级别下由延时，返回行，CPU时间占用，逻辑读行数，物理读的行数，内部等待和外部等待花费的时间等。如此多的数据就仅仅只是一条SQL下来所产生的数据。作为分布式系统的构建者，面对如此多的数据，该采用什么存储方式？通常来说，主要有两种存储模型，一种是窄表模型，另一种是宽表模型。对于窄表来说，一行信息里面有两个或三个字段，一条信息所包含的属性比较少。宽表则相反，一行里有比较多的属性，少则几十个，多则上百个。窄表典型的代表是HBase，宽表就是MySQL。他们的问题和优缺点也是显而易见的。比如说要统计一台机器在某一个时间点的所有的信息，要在程序里实现，在窄表模型下想要对这些信息做扩展，开发者说需要改代码，而这种操作对于分布式系统构建者是非常不友好的事情。最理想的是通过一条SQL或修者改一个列就可以做到信息扩展，所以宽表模型对于维护成本相对较低。但是在另外的问题上，宽表模型的扩展性并没有那么好，比如想要加一个属性，可能还需要考虑加到哪张表，字段需要什么描述方式。这时窄表就具备扩展性的优势。在表结构变更时，比如1个TB数据的表，加一个字段是很难想像的。OceanBase是一款准内存数据库，中间数据保存在内存中，周期性和基线数据做合并，因此DDL不会产生锁表问题；OceanBase采用了高效的压缩算法，尽可能的很好的解决了经济性的问题。同时，使用OceanBase不需要额外部署资源，对于提升构建系统的效率无疑是重大利好。三、极致运维技术点剖析近几年分布式系统发展特别快，包括阿里、AWS都已经有了成熟的全链路监控跟踪系统，OCP也一样。每一条SQL或者事务都会有个全局唯一的Transaction ID，可以帮助DBA和运维人员根据Transaction ID到数据库的服务器中抓日志、查问题；DBA和运维人员还利用OCP上提供的一系列服务做运维相关的工作，包括集群管理、计算逻辑编排、流程控制等。OCP对每一次的操作都会有一个全局的Request ID来全链路跟踪该操作所经过的每一个环节；Transaction ID表现在数据库层面，Request ID表现在平台服务层面，作为开发者，能够结合业务，做完整业务的全链路是我们下一步要关心的事情。数据库的使用者比较关心的是数据库的增删改查，而对于OCP实现者来说，还需要对数据库进行监控、运维、调度，提供数据服务、数据管理、数据库诊断等。OCP提供了Open-SDK的方式，让每个人都可以根据自己的需求以及喜好来定制自己的数据库。四、OceanBase云平台下面看看Oracle云是怎么做的。最底层，Oracle数据库服务跑在云主机上，有可能是公有云（如阿里云，AWS、腾讯云）；可能是专有云，大型的企业用户可能会自建机房，将数据库服务部署在自建机房里；也可能是混合云，将自建机房和公有云做打通，数据在专有云里面，然后管控和服务在公有云上。中间层，Oracle会把数据管理，应用集成等基础的能力包装成服务发布给开发者。最上层，将会有不同的业务视角提供给不同角色。下图是阿里内部的OCP的构建模式。底层是由物理机，ECS，Docker等组成的基础设施层;上面是OceanBase数据库；OceanBase之上构建了OCP平台以及各类平台服务。OCP从功能上来说包括监控、运维、诊断、资源调度等基础应用，另外还有数据迁移、备份恢复、历史库等数据管理类应用。服务之上，构建了Open-SDK，将服务能力通过SDK的方式发布出去，SDK能够帮助大家跟自己的业务系统做结合。最上面提供了不同的业务视角，比如开发人员会关心一个数据库实例的状态，用户DBA会关注自己的集群运行状态，系统的DBA要从更宏观的层面关心所有系统之间负载是否均衡，稳定性是否好。现状下图是目前OceanBase云平台所应用的场景，客户包括蚂蚁金服，网商银行，南京银行，浙商银行等等。右边是阿里巴巴内部应用的场景，OceanBase在集团内得到了广泛的应用。OceanBase是经过了8年的验证磨练出来的成熟的产品。然而云平台成长的时间并不长，还处于初级的阶段。我们的初级目标是系统变得更稳定，功能更友好。对比Oracle，内核研发人员是几千人，但是Oracle公司其实有几万人。他们有大量的人都投入到了工具，平台，致力于怎能让数据库从使用的感知更友好，这是我们OceanBase云平台所关注的事情。 点击阅读更多，查看更多详情

小蚂蚁导读：在刚过去不久的春节，你是否也参与了支付宝春节集五福的活动呢？不少小伙伴发现，今年的支付宝扫福更严格、更快也更准确了，这背后的技术是怎么做到的呢？本期稿件小蚂蚁邀请到了支付宝多媒体技术部创新组的算法专家嘉睿与大家分享支付宝春节集五福背后的技术，如果你也对此感兴趣，欢迎投简历加入我们！该团队目前正在招聘目标检测识别、文字检测识别方向的专业人才，有兴趣可以发邮件至：qiang.heq@antfin.com 扫福回顾集五福这个新年俗在2018年又与大家见面了，还是那个熟悉的味道-扫福集福，背后却是全新的技术架构，技术变革的背后隐藏着哪些故事呢？心历路程请听我慢慢道来。2017年扫福任务，由最初定位为获得福卡的一个小功能点，上升到主流玩法，技术上也是猝不及防。手写行不行？窗花福行不行？任意的福字包罗万象，初次应对这么大型且复杂的识别任务，做到什么程度心里也没底，期间和产品讨论了很久。这块简单描述一下我们采用的什么措施来识别的。回顾2017年扫福，一个很重要的举措就是我们引入了客户端福字检测的兜底预案，当服务端扛不住了就全走客户端，识别效果差点也总比限流都出不来强吧。事实证明我们这个预案派上了大用场，原计划在大年30高峰期开启的降级预案，由于用户的热情，在活动第一天中午就被迫启动了。由于客户端识别的简单方案，扫福被小部分网民恶搞了：开启2018扫福新篇章2018年扫福除了要保证绝大部分用户能够快速顺畅的扫福字外，还面临着AR同一入口存在更多业务并发的压力，以及去年负面舆情问题。汇总下来新的一年要解决的问题主要如下：（1）兼顾福字多样性的同时避免非福字尤其是相似字误识。（2）高并发：去年虽然也考虑了有着亿级用户的支付宝扫一扫入口会有非常大的并发量，但是由于是第一年扫福还是低估了用户的参与热情，最终作出部分降级。依据去年的调用量看对于图像识别算法，如此高的并发是相当有挑战的，因此今年在整体方案设计中首要考虑的就是客户端与服务端如何联动，提供高并发识别服务，尽量在不降级的情况下保证用户顺畅的扫出福字抽福卡。（3）AR入口承担更多识别任务：支撑扫福、扫人脸手势、AR平台运营活动；其中AR平台运营活动线上运营活动图片也有几百张，需要避免不同业务误识。带着众多问题，2018年扫福，不能重走老路，我们给自己定了一个小目标：更高：识别精度更高，提升识别率，同时降低误识率。更快：速度快、应急响应快。更强：并发能力强。1.架构方案基于上述分析，在方案设计时，从精度角度出发，有两种选择，一种是相对复杂的深度学习目标检测方法，另一种是轻量的检测方法+一个小型的校验网络，由于复杂一些的深度学习目标检测网络虽然误检低，但是不能覆盖低端机型（速度和内存等原因），因此最终选择传统的检测算法，这一步只需要保证快速的检测出福字候选区域，尽量不漏检，下一步则通过一个相对小的网络去校验。最终福字识别的客户端与服务端流程如下图：客户端：a. 检测部分快速检出福字候选区域，全机型覆盖，侧重点在于尽量多的检出福字（90%以上）误检可以存在。b. xFuNet校验，去掉上一步检测出来的误检，判断检测结果是否为福字，少量不确定部分先流转到其他业务，超过一定时间没有命中任何业务，则上传到服务端进行服务端检测校验。服务端：a. 检测部分主要是与客户端的检测算法互补，侧重点在客户端无法检测的少量福字的检测上，这部分使用基于小网络的深度学习目标检测算法，同样会有部分误检存在，因此也需要进行二次校验。b. 服务端校验负责：对于少量客户端不支持xFuNet校验的机型，将客户端检测结果送至服务端进行xFuNet校验。服务端检测结果的二次校验。2.核心技术xFuNet如上文所述我们目前需要一个轻量级的校验网络，为了确保客户端快速高精度的分类效果，我们对业界主流的深度学习网络进行了评估，最符合项目需求的要算是MobileNet0.25了。但是其训练速度较慢，同时由于多个业务轮询，我们希望速度能低于10ms。基于这些现状，我们自研了一套轻量级的深度学习网络xFuNet，它是基于resnet18改造而来。xFuNet的主要设计思路是：a. 尽早缩小feature map大小b. 控制参数数量（kernel size 和num output）c. 控制卷积层数目xFuNet性能特点如下：-速度快(10ms)，模型小(120k，可进一步压缩)，识别率高，迭代快(低于2h)。-服务业务场景：福字、手势、AR平台其它场景。在福字识别的场景中，我们同MobileNet0.25进行了比较：可以看出xFuNet虽然非常小，但是在特定场景校验部分表现的非常好，不逊色于一些开源的网络，更适合我们客户端需求大的场景。3.福字的校验训练在此前的活动中，我们积累了大量实拍的福字图片。为了实现识别率高、误识率低的目标，针对福字分类的训练投入了大量精力。校验网络的目标是区分出形态各异的福字（敬业福、窗花、手写、门贴）、诸如“逼”、“祸”这类的负面相似字、其他负样本图，下图列出部分示例图：不得不感慨汉字的博大精深，同一个字真的可以写出花来，但这同时加大了校验的难度，到底应该分为几类更合适？后续出现舆情如何能快速的增加特定图片同时尽量减少对福字识别率的影响。分两类？所有的福字一类，非福字一类，显而易见这个方案不靠谱，类内差别过于大。那么福字与非福字具体怎么分合适呢？福字：手写福（相对正规的打印福）和非手写福比划粗细结构各方面会有较大的不同，每个用户的手写福都有差别，连体多的手写福同逼字本身很难区分，因此福字至少分为两类，而敬业福属于特定设计福字，与其他福字分为一类也不合适，因此单独作为一类，这样福字分为三类。非福字：对于非福字最简单的是分为一类，但是考虑到大部分用户不会完全随意的拍摄，我们的重点是逼、祸或者其他相似的字，同时舆情也大部分集中在这些字上面，因此将字类负样本同非字类分开。字类负样本和手写福字单独成类的另一个主要原因是增加了动态控制能力，这两类本身是容易分错出现舆情的类别，万一出现问题可以通过阈值的调整快速的解决一部分；同时后续优化模型的时候可以通过少量针对性样本进行finetune，训练快同时最有效；如果混为一类，当临时增加负样本时finetune样本比例不好控制，很可能引起保证福字检出率负样本的拦截率就不够，反之则会出现大幅度降低福字检出率的情况。4.2018扫福效果通过一系列的努力，2018年的扫福获得了不错的效果，相比2017年来说，相关指标——包括识别率和识别速度均有了大幅提升，实现了低于1%的误识率。回到开头，围绕扫福的负面声音今年也得到了有效控制，通过微博舆情监控我们可以明显感受到我们的努力没有白费。后记有了去年的经验，经过一年的技术沉淀，2018年春节扫福字活动圆满结束，虽然过程中还是会碰到许多预期之外的问题，但是在团队共同努力下也都一一得到解决。在此，感谢红包项目各兄弟团队的鼎力支持和帮助，尤其是得益于多媒体部的另一项利器，XNN引擎对我们训练好的xFuNet网络模型进行有效的压缩，支撑其在客户端高效运行。接下来，我们将继续丰富支付宝AR平台能力，比如红包期间沉淀的手势识别能力即将登陆AR平台，敬请期待。原文来自：云栖社区；原文链接：https://yq.aliyun.com/article…点击阅读更多，查看更多详情

017年支付宝五福红包红包开奖人数是167966715人（约1.68亿）；除夕当天的参与人数是2.2亿；在业务峰值上，活页主页面峰值达到81W/s；扫福的峰值为22W/s；除夕当天的登录峰值为29W/s；除夕开奖峰值是90W/s。在本文中，蚂蚁金服技术专家天镜飞深入技术背后，为大家讲解了整体活动的稳定性保障、资损防控、运维部署、投产保障、监控管理、安全防护等方面的实战经验。业务模式今年支付宝新春红包主要采用了AR红包和五福红包两种模式。AR红包是创新业务的体现，主要分为藏、找、开三个步骤。其中藏是在当前位置扫描指定的物体，输入金额、人数，支付完成之后，该红包就出现在地图上；用户可以在地图上发现该红包或者是通过扫描指定的物体找到该红包，找到红包之后用户可以使用线索图打开红包。AR红包另一个玩法是商户红包，主要用于商户的推广，商户可以把自己的Logo藏在所有门店的地理位置上，通过引导用户去指定的门店扫Logo、开红包，进而起到商户宣传的作用。五福红包也就是所谓的敬业福，今年的玩法和去年的类似：搜集福卡、交换福卡，集齐五福之后等待开奖；二者区别在于在收集福卡上，今年的形式更加多样化：扫福字，蚂蚁森林浇水以及钻石会员可以得到万能福；同时金额分配采用随机的方式，做到人人有份。业务核心指标上图显示的是今年支付宝红包业务核心指标：五福红包开奖人数是1.68亿；除夕当天的参与人数是2.2亿；在业务峰值上，活动主页面峰值达到81w/s；扫福的峰值为22w/s；除夕当天的登录峰值为29w/s；除夕开奖峰值是90w/s。那么支付宝是如何支持如此高并发的业务和如此庞大的人群呢？背后的支撑的技术体系是怎么样的呢？下面来一探究竟。支付宝支撑技术体系支撑支付宝红包产品实现的技术架构可以总结为六个要素：其中稳定性保障、资损防控是核心；运维部署、投产保障是基石；监控管理、安全防护是重要组成部分。这六大要素支撑产品实现技术架构整体的运行以及最后完美地结束。支付宝红包产品实现的技术架构如上图所示。基于业务可变性和用户体验的要求，在终端上主要采用H5和Native的实现方式：其中H5主要用于蚂蚁森林、福卡任务、福卡排行榜等易变的业务；福卡主页、AR地图、AR扫一扫、AR引擎、AR开红包等业务是采用本地Native的方式，因为其用户体验非常好。当然，整体客户端架构都是基于支付宝客户端&H5容器的通用能力，如框架、通讯、网络、登录、安全等。在服务器端，福卡业务平台和AR业务平台都是基于支付宝现有的资金能力，其中福卡业务平台是基于现有的营销发奖资金处理能力，在处理过程中，使用了推荐、凭证中心、蚂蚁森林中的产品能力，福卡业务中最为关键的是配置后台（这是因为它是配置型的产品），所以我们搭建了新春配置后台和营销配置后台；AR业务平台是基于个人红包和商户红包现有的资金能力，其中图像识别服务和地理位置服务是该业务中最为重要的两点。总结来看，服务器端依赖于支付宝新金融引擎的共享能力，如监控、社交、会员、账务、支付、安全、SYNC、中间件等。在存储方面，除了采用通用的MySQL存储，还大量引入了关系型数据库Geabase，对于分布式缓存采用了tair，图片存储使用的是OSS。下面来逐一讲解支撑产品实现的六个要素。运维部署运维部署要解决的问题是资源缺口。正常情况下，华东1和华南机房的机器数量是无法满足新春活动资源的需求，因此需要周转腾挪。在解决资源缺口的过程中，利用了弹性资源来节省成本，将关键链路“弹”到云上；活动结束之后再将这些流量从云上迁回线下机房中。正常情况下，华东1机房和华南机房分别承担40%和60%的流量，并且它们都是非云的机器；在新春红包业务上，支付宝将60%的流量切到华东2机房中，并且将其上云，借助了阿里云强大的服务器能力，此外，在华南机房会部署15%的云机器，也就是说，新春红包业务中，75%的机器是在云上运行的，在活动结束后，流量会切出，将机器空闲出来极大的节省了成本。投产保障投产保障是技术架构的另外一块基石。今年业务上线过程中，代码开发、产品上线只占了全部精力的20%；其中75%的精力用于演练和压测。针对演练和压测，支付宝设计了三套环境，分别是压测环境、演练环境和正式环境。终端、服务器端和存储都支持这三套环境来回切换，三套环境是基于白名单的隔离控制机制，以防止三套环境相互串扰带来线上稳定性的风险。在演练中优化产品流程，在压测中打磨代码性能。今年产品上线时的业务流程和最终正式环境下的产品业务流程变化非常大，并且代码的层次也发生了很大的变化，利用这三套环境，通过压测来调优代码，通过线上的演练，不断地完善代码、产品，最终达到基本稳定线上产品状态。这里值得一提的是灰度拉练，在开奖环节，今年设计了灰度开奖的功能，也就是提前一天，某些用户可以提前开奖，在提前开奖过程中修复了一个严重的配置问题，避免了正式上线时产生故障，因此灰度拉练可以说是投产保障中最关键的一环。监控管理监控管理和安全防护是两个重要的组成部分。监控是产品的“眼睛”，它为技术和产品人员提供了发现线上问题、做出业务决策的依据。今年，依照不同的监控场景和需求，支付宝共部署了四套监控模式：第一套监控模式是利用Xflush分析系统的稳定性日志，最终产出系统监控、业务链路大盘、SLA限流大盘，这部分主要是为各技术负责人提供线上运行状态的监控；第二套监控模式是利用Kepler实时计算平台，对业务日志进行分析，产生一些业务指标，最后产出电视大屏、移动直播间、营销大盘，对外输出有绚丽效果的展示；第三套监控模式是利用海纳实时计算平台，对客户端日志进行分析，产生资源下载大盘、性能稳定性大盘、基础网络大盘，可以对客户端的运行状态进行有效的监控和预警；最后一套监控模式是针对客服的安保日志分析，产生安保大屏，对用户投诉情况进行监控。安全防护只有在产品设计之初就考虑安全防护，才能做到产品运营时的防患于未然。今年，支付宝在AR红包和五福红包上采用了三道安全防护策略。前两道防护主要是针对AR红包的线索图和LBS，其中第一道防护是针对AR红包的线索图，通过线索图遮挡算法，在线索可识别和线索不泄露之间寻求平衡；第二道安全防护是针对LBS篡改的监测，采用的策略是终端采集用户LBS、位移等数据，然后报送给服务器端，服务器端在用户领取AR红包时分析LBS、位移等数据是否出现漂移等现象，对异常的情况进行领取拦截；第三道防护是基于大数据的安全策略防护，支付宝安全团队对用户的数据进行大数据分析，基于大数据分析会产生相应的安全策略，这些安全策略会在产品的关键流程上进行防护，主要是得福卡、交换福卡、福卡开奖、领AR红包和发AR红包，针对不同的环节，采用不同的安全防护手段，保障用户操作的有效性。稳定性保障在稳定性保障中，第一个较为突出的点是将图片识别散于终端，这是由于图片识别算法是非常耗性能的。图片识别时面临着两个选择：一是在各终端上完成图片识别，直接和用户交流，具有较好的体验，此外还缓解了服务器端的压力，并且由于图片不用上传到服务器端，可节省了流量的开销，但是它面临的最大问题是不安全，因为在终端进行图片识别，用户可以篡改图片识别结果，从而欺骗服务器端，具有较高的风险；另一个选择是在服务器端进行图片识别，也就是图片上传到服务器端，通过服务器端的算法进行识别，保证了识别结果的安全性，它的缺点是用户体验差、服务器资源损耗高、消耗用户大量的流量。因此，需要在这两种方式中寻求平衡，支付宝采用的策略是针对不同的图片识别场景采用不同的图片识别方式，如地图上领取红包，采用的是客户端严格匹配，服务端按策略再次校验的方式，以安全为上；扫一扫领取红包场景，采用服务端Top n匹配，领取时服务端验签的方式，也是为了安全考虑。这两种场景的实际峰值并不高，将其放在服务器端是在可接受范围内；另外三个场景，包括可口可乐红包（出红包福卡）、口碑活动（出红包）、任意福活动（出福卡）主要是识别福字和商户Logo，其中不牵扯隐私问题，因此对于商户Logo采用的是纯客户端匹配，服务器端不再识别，避免了服务器的资源损耗；对于任意福活动，是采用客户端严格匹配福字，当客户端识别不出福字时，再由服务器端进行识别，这种方式可以节省服务器端70%以上的资源损耗。在稳定性保障中，针对扫一扫环节实现了关键链路多档位切换。扫一扫环节的关键点主要包括终端福字识别、附近可领取红包线索匹配、服务端福字识别和福卡领取。支付宝针对扫一扫环节设计了三个档位：档位一，完全模式，即识别福字又识别红包，该模式可承受峰值为12W/s，在该模式下可以通过调整附近匹配红包个数调整系统性能；档位二是将红包Top n匹配环节去掉，服务器端只保留福字识别和福卡领取这两项功能，该档位可承受峰值为50W/s，该模式下可以通过调整服务端福字识别算法复杂度对系统性能进行调整；档位三是在服务器端仅保留福卡领取功能，该档位预计可承受峰值为60W/s，节省图片下载等资源损耗。在实际使用过程中，档位二已满足要求，但多档的思想为稳定性保障提供了很好的支撑。稳定性保障方面细节特别多，每个细节又非常重要。除了上述两点外，支付宝还在全局上考虑了一些风险点的梳理、规避以及制定了活动前、活动中、活动后的操作手册，制定了相应的应急处理机制，并对关键业务流程进行多次模拟演练。在终端上采用了限流无感知、资源预下载、用户操作数据缓存、开奖时间离散、数据项与开关动态配置等稳定性操作；在服务端，进行了全链路梳理、全链路压测、限流保护、应急熔断机制等。资损防控资损防控是今年红包活动中的另一个核心点，这是因为AR红包和五福红包涉及的金额巨大；另外由于今年的奖池分配策略采用随机分配的方式，进一步增加了困难：计算困难，开奖只有18分钟，如何在18分钟内将2亿随机分配并发放出去？核对困难，资损风险高，并非简单地将金额计算出即可，而是要保障每个人金额总和和总金额相同。奖池发完难度大，将2亿现金全部发放干净，其中涉及预测、保底等问题。针对计算困难，引入多档位类随机机制，设计多个开奖档位，使得看起来像随机的结果，而不是纯随机的方式；另外采用提前算奖的方式，在用户五福合一时提前计算出部分用户的奖金，实际开奖时只是查看原来计算好的金额。基于这两种策略，支付宝设计了今年资损防控的新模型，该模型包括算奖、抽奖、发奖三个环节，通过监控、预警、核对机制来保证这三个环节的正确性；其中算奖环节设计了可重复算奖，当发现异常时，可重新计算奖金，抽奖环节支持快速订正，发奖环节支持快速调账。核对机制是资损防控中最为关键的环节，今年采用的是基于实时计算平台的核对机制。该核对机制主要包括两种核对策略：一是实时核对，对关键的资金流变动、资金链的切换采用实时核对；另一种是异步核对，也就是所谓的15分钟核对、小时核对和T+1核对，对于所有和资金相关的环节都采用异步核对以保证最终的一致性。实时核对采用了三种基本策略：第一种策略采用了乾坤镜技术，对接口的入参出参实时地检查；第二种策略采用定时调度任务，尽量保证准实时性，将数据库中的相关数据捞出来进行核对；第三种策略是将核对的代码片段糅杂在业务代码中，通过这种方式保证实时核对的一致性。异步核对，包括15分钟核对、小时核对、T+1核对，采用的技术架构主要是DRC（异地多活数据同步）与TT结合的方式，将DB的数据和日志的数据按15分钟、小时、日汇总存储到ODPS上，再通过相应的核对机制来保证整体的一致性。在算奖—抽奖、抽奖—发奖的过程中，下一个环节开始前，必须通过核对的策略保证上一个环节的准确性，包括总金额和明细；这样一来，可以平稳地过渡到下一个阶段而不必担心上一阶段出现问题。总结支付宝新春红包产品以运维部署和投产保障为基石，以稳定性保障和资损防控为核心，辅以监控管理和安全防护这两个重要组成部分，完美地解决了五福红包和AR红包的高并发业务和庞大的人员参与两大难题，实现了81w/s的活动主页面峰值、22w/s的扫福的峰值、29w/s的除夕当天的登录峰值以及90w/s的除夕开奖峰值等一系列指标。原文来自：云栖社区；原文链接：https://yq.aliyun.com/article…点击阅读更多，查看更多详情

承智关于支付宝AR框架体系和实践的分享主要分为以下三个部分：支付宝AR框架体系AR实践案例分享总结和展望在本次分享中，来自蚂蚁金服支付宝多媒体技术部猎鹰团队的技术专家承智为大家解密了支付宝AR红包背后的技术。在他的演讲中首先分享了支付宝对于AR技术需求的一些特点，之后分享了在对支付宝AR框架体系进行设计时遇到的一些问题和挑战，以及支付宝多媒体猎鹰团队是如何满足产品运营需求的，并结合四个具体的案例分享了在支付宝AR实践中遇到的一些问题和收获的经验，最后对于支付宝AR技术的发展进行了总结和展望。一、支付宝AR框架体系支付宝AR需求特点现在AR技术已经成为了一个比较热门的话题，很多公司都在AR方面投入了大量的人力和物力进行产品研发。而支付宝对于AR技术的需求存在着自身的特点，正如下图中所展示的，支付宝AR的运营活动其实特别多，这些活动有基于人脸的、人手的还有基于图片和logo的，活动形式比较多样而且所需识别的对象也非常丰富。而一般对于活动运营而言，时效性的要求也比较强，往往只能留给开发一到两周的时间，所以支付宝对于AR框架体系设计的要求是比较高的。总结一下，支付宝AR框架的设计大致有以下几点需求：运营方面对于时效性的需求，因为需要让活动可以随时上线，所以实时性要求比较高，一般需要在几天或者几周的时间内完成开发，并且需要不依赖客户端的发布。针对不同的场景识别需要具有动态的能力，识别logo、物体或者图像采用的技术是不一样的，所以必须通过动态配置的方式选择配置的参数实现对于对象的高效识别，进而达到运营的要求。SDK轻巧，目前支付宝的体量已经非常大了，所以在实现SDK时需要尽量做到轻巧。目前的经验是识别引擎200+K；渲染引擎400K，总体而言对于支付宝的增量不会很大。AR框架体系结构针对于支付宝AR框架的总体设计要求，支付宝多媒体猎鹰团队设计出了如下图所示的AR框架客户端体系结构。AR框架结构主要分为三层，从下向上依次为：核心层、接口层和应用层。在AR框架客户端体系结构的最下面是核心层，这一层大致包括5个模块：ARConfig，也就是配置文件，配置文件的目的就是当运营活动出现的时候，通过对于配置文件的解析就可以对应地选择不同的识别引擎以及渲染方式。ARBrain，就是整体的识别工厂，这里面包括了目前比较主流的一些识别方法。ARRender，这是主要的渲染模块，包括了对于2D图像序列、3D图像模块素材的渲染以及对视频、纯图像和语音进行播放的功能。ARDevice，这部分包括两个主要的功能：因为在渲染的过程中往往会遇到机型适配的问题，所以这里将会使用黑白名单机制对于机型进行管控；而对于一些特定的场景可能还需要管理手机的硬件设备，比如像陀螺仪和手机的传感器等，这些也都是在ARDevice中进行管理的。ARResource，这部分就是资源管理模块，它主要用于管理识别的素材、动画渲染的素材以及在整个AR活动中会用到的资源素材。支付宝AR框架客户端体系结构的中间是接口层，接口层桥接了各种业务和底层的算法，会根据不同的业务形态总结抽象出几种对外呈现的接口方式供外面调用。AR框架的最上层就是对接的各个业务方的应用层，比如“扫月亮”、“扫logo”等应用以及对外开放数据之后的一些ISV的应用。AR引擎动态配置具体而言，怎样才能够获得动态化的能力呢？其实在下图中可以看到，想要获得动态化的能力最主要的就是在识别引擎中涵盖了一些识别的方法，包括了针对于颜色的、形状的、目前比较主流的海报的互动、基于特征点的以及对于形状比较单一或者比较特殊的对象等等识别的方法。而对于一些客户端做不了的事情，比如春节期间的一些福字识别或者圣诞节期间圣诞树的识别这些也会由客户端将图片上传到服务端，在云端进行识别。结合客户端和服务端两种模式的识别达到一种比较通用的识别手段，然后在进行具体配置的时候，可以通过配置文件选择某一种具体的识别方法，比如上图中最左边的配置文件，可以选定使用feature point的方式来达成识别的目的。在识别完成之后，可以跳转到一个动画，或者进行动画跟踪、具体渲染等，最后再跳转到H5页面。与此同时，配置文件也会指定识别过程中用到的一些素材包和识别包的路径，然后引擎就会在相应的目录加载相应的资源。每一种识别的方法都会有单独的配置文件，该文件会表明识别对象的名称、大小，以及在多大的尺度和旋转角度下进行识别，所以这是和识别方法紧密相关的，可以将一些识别方法的参数单独列出来，尽量做到不用修改代码而只需要修改配置文件实现动态推送的能力。AR研发流程这部分介绍的主要是AR底层的设计相关的内容。从整体来看，一个AR的项目从开发到上线可以抽象成为以下的四步：线下素材制作过程，如果一个AR活动需要上线，那么就需要准备两部分的素材，一部分是动画呈现的素材，比如像图像序列以及3D模型；同时还需要有互动的素材，比如需要识别的对象是什么，如果需要用到识别模型，那么就会需要有一个离线的训练模型。当所有素材准备好之后会将它们推送到云端的素材中心和配置中心，素材中心存储了识别的素材包和呈现的素材包，而配置中心则配置了相应活动的信息以及AR引擎里面所需要用到的配置文件信息。在活动开启的时候，支付宝APP的客户端会主动地从服务端拉取相关的资源，在将资源拉取到本地之后进行实时的渲染。最终将AR效果呈现给支付宝客户端的用户。整体来看，AR研发最主要的工作就集中在第一部分，也就是怎样制作素材以及如何将识别和跟踪这部分功能在线下验证完成之后实时地推送上线。如果整个流程进行的比较顺利的话，可能只需要几天的时间就能将一个AR运营活动做上线，达到快速上线的目的。二、AR实践案例分享接下来承智分享了2016年支付宝所做的与AR相关的四个案例，并且重点分享了春节期间支付宝推出的扫福字集福卡活动案例。AR实践1：扫月亮支付宝AR运营活动的首次的尝试就是在2016年中秋节的时候做的扫月亮的活动，当时需要识别月亮以及一些圆形的物体。而扫月亮这个识别流程大致分为以下三部分内容：因为在进行实景拍摄时，月亮的成像一般都比较小，所以用到了亮点检测模块，然后简单地做了场景分析，把明显拍摄的不是月亮的图片进行过滤。第二部分就是支付宝官方也会推出一些海报，而海报的呈现一般都比较大，所以这里用到了白圆检测的算法。因为中秋节那段时间的天气不是很好，所以有可能出现看不到月亮的情况，而为了增加互动的话题，市场和运营提出要求，希望允许识别除了月亮以外的圆形的物体，于是还需要使用到圆形物体检测算法。总之，将上述三个部分整合到了一起，从而实现了对于图片快速地进行识别。当时大概处理一帧的时间也就在100毫秒以内，往往在用户抬手机的过程中对象已经被识别出来了，但是人的视觉可能都还没有识别出来，因为识别太灵敏可能给用户造成一种假象的感觉，所以做了延迟3秒的处理，并且设定了不会在抬手机的过程中进行图像识别。除此之外，对于圆形检测而言也有很多方法，比如随机选择多个点拟合成一个圆形来进行匹配。而其实在客户端的开发过程中，速度和计算量要求会非常高，所以这里使用了简化后的方法：首先使用颜色分割将物体区分出来，提取边缘后使用近似圆检测。扫月亮活动整体的效果还是不错的，在微博上引起了比较大的热议，同时一些图像的网站也借此进行了宣传。AR实践2：扫1212集四宝扫月亮活动之后，也有很多的业务方开始积极主动地去开拓相关的应用场景。所以在双12的时候，支付宝也进行了线下引流，通过在线下商圈张贴海报引出“扫1212集四宝”的活动。因为是主要针对线下商圈的场景，所以这次活动的宣传量并不是特别大，但是活动现场的热度还是不错的。当时的需求是识别“1212”这四个字，但是在实际线上测试的时候发现，海报样式是非常丰富的，总共大约有20多种样式，因为角度、远近和光线等因素，导致摄像头采集的像素可能比较低，所以实拍图片的识别难度比较大。所以最后采取的策略是近景识别“1212”四个字，远景则对于整个海报进行识别。整个客户端大概支持了对于20多种图片的识别，在杭州银泰百货进行实测的时候也进行了动态改进，不断调整线上配置的模型包，实时地提升整体用户的体验和算法功能。如果不具备这样动态调整的能力，而是将代码静态地放在客户端，那么这样一旦上线以后，就很难做到修改和更正，所以引擎的动态化在一些运营的场景里面是十分重要的。对于这次活动总体效果而言，客户端对于20张海报图的整体识别率接近90%。没有能够达到特别高的识别率是因为在线下的场景里面可能存在距离比较远等因素的影响，一些情况下，可能人眼能够识别到，但是机器却因为像素比较低而无法准确地识别。识别的速度大约在每帧130毫秒左右，所以整体用户体验还是比较流畅的，当时还有很多地方电视台对这次活动进行了采访报道。AR实践3：AR实景红包接下来重点分享一下支付宝去年做的与AR实景红包相关的一些实践。支付宝去年推出的AR实景红包也算是一次比较大胆的尝试，其实在业务讨论的阶段，初期的方案与一些像Pokemon GO 一样的已有产品比较类似，想通过LBS和手机传感器来实现互动。但是在开发过程中却遇到了一个问题，就是如果想在某一个楼层发放红包或者只针对拍摄这个楼的时候才能发放和领取红包的话，通过现有的技术是无法解决的，因为LBS的定位不能满足这样的需求，在一栋楼里面，LSB无法区分出某一层。面对这样的问题，支付宝多媒体猎鹰团队提出了这样的一个方式就是基于拍摄图片的比对来实现目的，比如用户在藏红包的时候对着这个物体拍摄的，领取的人也必须来到这个地方，找到这个物体才能拍摄并领取红包。基于这样的逻辑，支付宝技术团队一起将AR实景红包实现并完成上线。AR实景红包的一个优点就是可以帮助商家进行品牌宣传，因为需要藏和找红包都需要拍摄图片，商家可以将自己的logo或者产品作为线索图进行推广。AR红包框架AR红包框架背后的逻辑主要是两个部分：一部分就是藏红包的过程，另一部分就是找红包的过程。在藏红包的过程中为了避免很多存在歧义的场景，比如随处可见的白墙以及比较暗的区域等，支付宝多媒体技术团队在这里面加上了一个评估过程。如果用户想要发AR红包，首先就需要判断这个场景适不适合发红包，是不是需要让光线更加明亮一点，因为特别暗的场景不适合藏红包；另外一方面就是评估纹理是不是足够丰富，因为如果纹理特征比较少的话，无论是后续的识别还是做区分度，都是不利的，所以在藏红包的时候对这一部分特征进行了限定。如果满足以上条件的限定的话，就会将图片上传到服务端，在服务端进行特征提取，然后合成一张线索图。而在找红包的时候，当用户选完一个红包之后，线索图以及红包的特征码会被客户端拉取到本地，后续的图片比对都是在本地完成的。这样做的好处就是用户在找红包的过程中，可以进行实时的计算，如果将这个图片传到服务端可能数据传输来回的时间达不到产品的需求，另外也达不到对于用户体验以及准确性上的需求了，所以在客户端对于图像进行实时匹配的优势还是很大的。在本地匹配成功之后会将对应的图片传到服务端进行二次校验，进行二次校验的主要目的是为了保证安全性，因为可能出现恶意用户绕开支付宝入口，直接调用后台服务的情况，所以这里面的二次校验主要是针对一些作弊行为进行了特殊处理。AR红包的挑战其实在AR实景红包的背后也遇到了很多的挑战：图片比对准确性，在实景红包推出来之后，很多研究人员也在研究图片的比对是基于什么样的算法。其实在最开始支付宝多媒体技术团队也考虑了很多种算法，比如基于颜色、形状的算法，但是测试后发现旋转、远近、角度等因素对于这些算法的影响都比较大，并且造成误检非常多。所有后来就采用了比较传统的基于特征点匹配的方式进行实现。算法性能和CPU占用率问题，图像识别对于客户端的算法性能要求是比较高的，如果对于图像的每一帧都进行计算的话，手机CPU占用率会很高，导致产生发热问题。可能出现在找红包的过程中，持续地找了几分钟，由于计算量会很大，导致手机发热的问题非常严重。针对于这个问题，支付宝采用了抽帧的方式，大概一秒钟处理3到4帧的计算量，虽然对于整体计算流程的影响不会非常大，但是将整体的计算量降下来了，使得CPU维持在占用率30%左右的水平。图片流量的问题，在藏红包和找红包的过程中都需要传输图片，而在传图的时候就涉及流量大小问题。为了帮助用户节约流量，并将传输速度提升上去，支付宝在传图过程中用到了智能压缩的方式，将传图过程消耗的整体流量降低下来。渲染兼容性问题，因为目前安卓机型特别多，从统计数据来看，支付宝用户大概会使用到2000多种机型，因为不同的手机能够支持的渲染的版本和能力是不一样的，所以在做3D渲染的时候就会遇到兼容性的问题。因此AR红包对渲染兼容性的处理使用了手机黑白名单的机制，将一些性能比较好的、比较主流的机型列在白名单里面，这样的机型会使用正常的3D渲染方式；而对于一些性能比较差的、支持能力也不是特别好的机型，则可能采用降级的方式，可能会采用2D渲染方式跑动整体的流程，只不过在呈现的效果上面则会差一点。PS冒领问题，在AR实景红包上线之后，遇到了一个比较大的问题就是PS冒领问题。最开始推出AR实景红包的时候，支付宝做的提示图会比较简单一些，就是使用简单的横条纹做了提示图，但是也有一些PS爱好者通过PS软件把横条纹P掉，然后恢复出原图大概的模样，并拍摄这个图冒领其他人发的红包。针对于PS冒领问题，解决方式就是使用自动化生成网格提示图的方式，使得每个红包的提示图都是不一样的，提示图的难度增加了，所以很难从提示图恢复出原有图片的模样，但是目前而言在网上寻找相似图片的作弊手段还是比较难避免的。AR红包效果最终AR实景红包上线的时候，影响还是比较大的。可以从最初的界面上看出，图上定位点周围的区域都布满了红包，当然这是个人的玩法，而影响比较大的就是随着商家对活动的关注，很多商家也愿意尝试加入进来，所以后来就有二三十家主流商家加入进来，也创造了新的营销方式，就是通过拍摄自己的logo进行宣传。AR实践4：扫福集福2017年春节，支付宝推出的红包活动是扫福集福，关于这个活动大家了解比较多的就是扫描网页上或者门贴上的福字，但是其实在这背后还涉及到很多复杂的需求。在支付宝技术团队实现AR扫福时面临着一些主要的挑战：多识别任务并发，在扫一扫的入口不仅仅需要识别福字还要识别不同的海报，而且一些商家的红包也是通过扫一扫的入口传一张图到后台进行识别的，所以这是一个多任务并发的过程。扫福字请求高并发，因为春节扫福集福活动的关注量比较大，所以扫福字的请求数也比较高，每秒需要处理的计算量也是非常大的。福字识别的挑战，当时提出的需求是福字识别不仅仅需要能识别网页上的福字，而且对于一些手写的福字或者墙上贴的福字也都要进行识别，因为需要识别的福字样式非常丰富，所以从福字本身的识别难度上来看也存在一定的挑战。春节期间的扫福活动还和可口可乐进行了深入的合作，所以也需要支持对于可口可乐7种福娃的扫描。上图中最上面的一行图片就是可口可乐福娃的海报样式，顾客通过扫描线下购买的可口可乐产品上的福娃，就能领取相应的红包或者福卡。与此同时，支付宝在海外以及港澳台等地区也进行了大规模的海报宣传攻势，所以也需要对于这些特殊定制的海报进行支持，当用户在海外机场或者在海外消费的时候，看到这些宣传海报使用支付宝扫一扫也能够获取福卡。所以对于识别而言，除了需要识别开放性的福字，也需要对于大约14种海报的样式进行识别。AR扫福框架设计为了满足上述的需求，支付宝扫红包客户端的识别策略也采用了分帧处理的模式。首先在第一帧的时候进行对于海报的识别，大概就是对于之前提到的14种海报进行识别，而且每帧处理的时间大概控制在100毫秒以内，所以能够非常迅速地判断当前拍摄的是不是海报。在下一帧的时候就需要判断手机是不是静止的，因为有时候在客户端识别不成功，需要将图片传到服务端去，就需要判断当前手机是否处于静止状态。而静止判断也有很多种方式，比如通过手机的陀螺仪以及传感器等进行判断，而支付宝技术团队则使用的是通过图像判断，使用图像前后帧的差异大小判断，如果在两到三秒连续的时间内图像的差异不是很大，那么就认为当前用户的意图是想要拍摄一张图片并发送到服务器端进行识别，所以在第二帧进行的是图像静止判断处理。如果静止判断成功，就会将图片传到服务器端进行识别。第三个步骤，就是本地福字检测。为了应对可能出现的服务端压力扛不住的情况，需要做一个基于本地客户端的紧急预案，于是支付宝多媒体猎鹰团队在客户端做了基于LBP的福字检测的本地备案算法。本地福字检测的目的就是为服务端分流，而且这一功能会在需要的时候打开。其实在活动初期的时候这个开关是处于关闭状态的，所以扫红包的过程只有前面的海报识别和传图到服务端这两个步骤，当活动进行到第二天的时候因为服务端压力比较大，才将三个步骤全部开启。这种策略的好处就是为用户提供的整体体验不会存在卡顿情况，因为每个模块处理完成也就是在100毫秒以内，所以每秒也能进行大约10次的尝试，平均下来每个模块大约也有三次机会。支付宝AR扫福框架的反应速度和流畅性都得到了很好的保证，而客户端福字识别的模块的加入也能够进行分流，帮助服务端减轻了负担。活动效果最终达到的效果就是在同时开启客户端和服务端的福字识别之后，识别的峰值达到了14WTPS。活动开启的第一天预估的峰值大概在1万左右，但是由于用户参与的热情很高，所以在活动开启一天之后就达到了服务端识别能力的上限，于是就立刻开启了客户端的本地识别。但是这也同时带来了一些问题，因为客户端的识别能力有限，所以一些不是福字的图像会被误识别成福字，而这些都是在后续开发的时候在技术包装和储备上面需要进一步完善的地方。但是总体活动效果上看还是不错的，能够把大多数用户拍的福字识别出来，少量的误识在产品上是可以被接受的。整体上70%的识别任务都是在客户端完成的，而且识别过程还是比较流畅的，只有少量本地无法识别的情况才会上传到服务端，这样的做法节省了服务器的资源。通过这样的活动也引起了很大的关注，网上也很多出现了很多趣闻，所以整体上效果还是不错的。三、总结和展望以上就是目前支付宝AR技术的一些分享，那么未来支付宝的AR技术将会朝着什么样的方向发展呢？承智谈到支付宝多媒体猎鹰团队首先会在现有的基础之上完善已有的AR技术，并和其他技术团队一起努力打造一个AR的开放平台，希望能通过这样的平台使更多的开发者和AR技术爱好者能够参与进来，创造出更多的创新性场景，并通过这样的平台为用户和商家建立相互连接的关系，使大家都能够从AR开放平台上受益，创造出更多的价值。原文来自：云栖社区；原文链接：https://yq.aliyun.com/article…点击阅读更多，查看更多详情

摘要：最近几年来，农历春节期间，大家增加了一项新的“年俗”，那就是在支付宝上集五福，咻红包，从抢不到的“敬业福”到“咻咻咻咻，咻红包”，支付宝不仅成为大家过年的必备武器，还使得春节因为它变得更有“年味”。本文为大家整理了支付宝春节红包背后的那些事，在新春佳节即将来临之际，让我们先温故一下那些支撑数亿人每秒N次点击的技术！1808亿次，16倍的超越！谈支付宝红包的高并发挑战2015年12月份，蚂蚁金服技术团队在第一时间得知支付宝中标央视消息后，既兴奋又担心！兴奋的是，这是一次千载难逢的机会，终于可以一展身手。担心的是，支付宝和央视联合搞活动，是蚂蚁金服有史以来最大规模的活动，到底规模多大，他们没有任何概念。唯一能得到的信息是，历年观看春晚的人数大约在7亿多，支付宝的年度活跃用户4亿多，至于用户的行为习惯，没有任何参考模型。面对这样的挑战，他们做了五项准备，并且攻克了8项技术难点。点击查看原文首次揭秘！扫福得福：支付宝春节集五福背后的技术分享集五福这个新年俗在2018年又与大家见面了，还是那个熟悉的味道-扫福集福，背后却是全新的技术架构，面对更快、更高、更强的技术压力，支付宝扫五福技术变革的背后隐藏着哪些故事呢？心历路程请听本文慢慢道来。点击查看原文扫福得福背后，支付宝 AR 红包的技术创新与故事春节期间，支付宝的「扫福得福」活动火爆异常。AR 是一种新的交互方式，与传统营销方式相比，可以使用户更深入地参与互动，给用户带来新体验。而支付宝红包，寄托着用户对未来的期盼，因此其团队就考虑将 AR 与红包相结合，探索一种新的玩法。在 AR 领域走在前面的支付宝，其 AR 红包的技术选型、技术架构及其背后的技术故事都有哪些？点击查看原文支付宝17年新春红包技术体系剖析今年支付宝五福红包红包开奖人数约1.68亿；除夕当天的参与人数是2.2亿；在业务峰值上，活页主页面峰值达到81W/s；扫福的峰值为22W/s；除夕当天的登录峰值为29W/s；除夕开奖峰值是90W/s。在本文中，蚂蚁金服技术专家天镜飞深入技术背后，为大家讲解了整体活动的稳定性保障、资损防控、运维部署、投产保障、监控管理、安全防护等方面的实战经验。点击查看原文从“扫月亮”到“扫福字”，扒一扒背后的支付宝AR框架体系从攒五福到抢红包，全国人民的春节活动越来越多样，其背后技术挑战也更复杂：业务层挑战与实现方案、AR红包支付架构变化、技术难点和攻克手段、优化细节和保障方法、安全风险和*实战等，每一年的红包背后，如果能拍摄出来，都将是一部技术大片。在云栖社区2017红包技术峰会上，蚂蚁金服技术专家承智为大家分享了“扫福字”的背后的支付宝AR框架体系实践，精彩不容错过。点击查看原文

Hello，我是犯迷糊的小 K。目前是 ifanr 的一只前端攻城狮，同时也是知晓云团队的一员。3 月伊始，ifanr 旗下品牌——知晓云 3.0 版本正式上线。此次更新得到业内许多开发者的密切关注和积极支持，在此，我代表知晓云团队表示万分感谢哈。(￣▽￣)~*知晓云是业界第一个支持多平台小程序开发的后端云服务，它免去了小程序开发中服务器搭建、域名备案、数据接口开发、线上运维等繁琐流程，让开发者更快、更低成本地做出优质的小程序。言归正传。和许多童鞋一样，小 K 使用知晓云时，也是第一次开发小程序，开发过程也是百转曲折。因此，小 K 希望通过这篇文章，和各位童鞋进行交流。毕竟，大家的学习历程是相似的，遇到的困惑也应该差不多。本文结构大致如下：谈谈如何成为支付宝小程序开发者。聊聊如何创建我的第一个支付宝小程序。以一个 Demo 为例，详细讲讲如何在支付宝小程序中接入和使用知晓云 SDK。如何成为一名支付宝小程序开发者？申请成为支付宝小程序开发者，是一件再简单不过的事儿，仅需 2 步，比把大象放进冰箱还简单。第一步，登录蚂蚁金服开放平台，注册成为小程序开发用户。此过程需要你依次完成账号信息、邮箱激活和信息登记等流程。第二步，完成上述操作后，就能进入小程序管理后台，点击创建应用并填写信息，创建成功后即可获取开发小程序的 AppID。嗯，现在小 K 已经是一枚准小程序开发者啦。（后续请进入小程序配置-设置-开发设置，根据平台的设置方式教程，配置接口加签方式，获得支付宝公钥和密钥文件）如何创建我的第一个小程序？获得了「准入资格」后，小 K 开始参照小程序官方文档，下载官方的开发者工具并创建了一个初始化的小程序。Well done！小 K 的第一个初始化小程序诞生了～ 接下来，可以看看支付宝小程序官方的体验小程序 Demo 教程文档，熟悉一下小程序代码组织方式和开发特性。现在，有了开发工具和基础知识积累，可以试试 freestyle 咯。唯一的问题是：小 K 应该选择什么类型的小程序作为 Demo 呢？对于 Demo 选择，唯一的原则就是精简「简」是像小 K 这样的小白开发者一看就懂。「精」是尽可能在有限的代码中，体现知晓云功能的强大性。于是，我选择了个经典的 TodoMVC 的小程序——「我的书架」作为示例。由于「我的书架」 Demo 将知晓云的核心模块之一——数据管理的 CRUD 操作很好地展示了出来，所以，我们希望通过这个 Demo 让各位童鞋学会利用知晓云，完成常见的数据增删改查功能。如何在小程序中调用知晓云 SDK？准备工作在正式使用知晓云的 SDK 前，首先确保走完以下 2 个流程：第一，完成小程序的授权。目前，知晓云在注册模块和设置模块都有提供小程序授权操作，二者的授权流程大体一致。在这里，我们演示设置模块的小程序操作。点击应用标签，进入应用的管理面板；进入管理面板后，切换到设置模块并进入应用设置 tab 页，点击平台设置-支付宝小程序-立即开通，点击编辑并填写相关配置信息后即可完成授权。第二，在「小程序后台」配置安全域名。装载 SDK接下来，看看知晓云的 SDK 的使用说明文档。老夫掐指一算，将 SDK 的接入小程序的方法和数据表操作看了一遍，约莫花费 10 分钟。毕竟 Demo 只涉及数据操作嘛，所以要做到有的放矢，要啥看啥。下载知晓云提供的 SDK 后，将其引入小程序的 app.js 中，并通过在前面的设置模块的小程序设置 tab 页中获取当前应用的 ClientID。设计数据结构和创建数据表完成上述操作后，小 K 就可以使用 SDK 提供的各种接口，接下来思考一下「我的书架」将用到什么数据及其结构。由于是第一个 Demo ，本着精简的原则，小 K 在此就只设计了一个 bookName 的字段Tips：知晓云的数据管理模块会为每张数据表自动创建 id，create_by，create_at，update_at 和 acl 等字段。根据文档提示，在使用知晓云的数据管理模块时，需要首先提供存放数据的 tableName。因此，首先要在知晓云开发者平台创建数据表从而获取 tableName。获取 tableName 后，小 K 将其放在了 app.js 文件的 globalData 对象上，以供后面各种数据操作接口的参数调用。开始使用知晓云的 SDK小 K 在这里不会细谈「我的书架」是如何编写的，因为不同的童鞋的对这个功能的实现方式可能不一样。小 K 只会谈在哪些控件中使用知晓云提供的接口，来实现小 K 的需求——添加一本书。创建书目记录翻查了文档，发现创建一条记录很简单，只需要调用 create 创建一条空记录，然后调用 set 为上面创建的空记录赋值，最后调用 save 将创建的记录保存到服务器即可。更新一条记录有时，小 K 手抖，在输入书目的时候填写了错别字，那么理应提供一个更新记录的功能吧；知晓云提供了 update 接口，让更新数据 so easy。删除一条记录最后，当小K的书架不再存在某本书时，必然需要一个删除操作。通过调用 delete 接口就可以实现一条记录的删除操作。最后的话以上就是小 K 用知晓云烹调出的第一个支付宝小程序——「我的书架」，最主要就是用到了知晓云的数据管理功能模块。当然，知晓云还提供作为 BaaS 产品的基础文件上传和数据统计功能等，同时具备贴切小程序的特性功能，譬如支付宝支付和富文本编辑功能。*除了「我的书架」 Demo 外，知晓云官方还提供了知晓云 SDK 官方示例小程序，用于演示 SDK 更丰富的接口使用方法。代码已开源在 ifanrX 的 GitHub 上，链接：https://github.com/ifanrx/hyd… 有兴趣的童鞋可以 star 或是 fork 一下。本文首发于「知晓云」公众号：https://mp.weixin.qq.com/s/Vk…知晓云是国内首家专注于小程序开发的后端云服务。使用知晓云，小程序开发快人一步。 ...

首先呢，我不会开发安卓App，这款APP是我在酷安网看到的，非常简单的一款APP，安装后填写我们的后端接口（用于接收收款通知的）就可以接收收款通知了。所以就算我们没有这款APP的源码，我们也可以做一个支付系统了。APP界面：界面就这点东西了！只需要设置后端接口就可以接收这个APP监听的支付宝收款数据了APP会以POST方式向您的接口POST一段JSON数据数据格式如下：{“title”:0.01,“time”:“2019-02-26”,“title”:“支付宝支付”,“content”:“成功收款1.00元。享免费提现等更多专属服务，点击查看”}下面是我写的PHP后端简易版：<?php// 定义接收JOSN数据header(“Content-Type:application/json”);// 接收从APP端POST过来的数据$json = $GLOBALS[‘HTTP_RAW_POST_DATA’];// 将JSON数据转换为PHP对象$obj = json_decode($json);// 解析对象返回字符串$money = $obj->money; // 返回支付金额$title = $obj->title; //返回支付标题$time = $obj->time; // 返回支付时间$content = $obj->content; // 返回支付内容// 连接数据库$con = mysql_connect(“数据库地址”,“数据库账号”,“数据库密码”);if (!$con){die(‘Could not connect: ’ . mysql_error());}//选择数据mysql_select_db(“数据库名”, $con);//设置字符集mysql_query(“SET NAMES UTF8”);//插入数据库mysql_query(“INSERT INTO 表名 (paymoney, paytime, title, content) VALUES (’$money’, ‘$time’, ‘$title’, ‘$content’)”);//关闭数据库连接mysql_close($con);?>数据库接收到的通知：App下载：https://www.coolapk.com/apk/c…作者：TANKING时间：2019-2-26网站：http://likeyunba.com

微信支付结合微信支付的api文档进行配置。参考JSAPI支付开发者文档——微信内H5调起支付微信文档中的例子如下。function onBridgeReady(){ WeixinJSBridge.invoke( ‘getBrandWCPayRequest’, { “appId”:“wx2421b1c4370ec43b”, //公众号名称，由商户传入 “timeStamp”:“1395712654”, //时间戳，自1970年以来的秒数 “nonceStr”:“e61463f8efa94090b1f366cccfbbb444”, //随机串 “package”:“prepay_id=u802345jgfjsdfgsdg888”, “signType”:“MD5”, //微信签名方式： “paySign”:“70EA570631E4BB79628FBCA90534C63FF7FADD89” //微信签名 }, function(res){ if(res.err_msg == “get_brand_wcpay_request:ok” ){ // 使用以上方式判断前端返回,微信团队郑重提示： //res.err_msg将在用户支付成功后返回ok，但并不保证它绝对可靠。 } }); }// 下面是兼容不同浏览器绑定事件的方法if (typeof WeixinJSBridge == “undefined”){ if( document.addEventListener ){ document.addEventListener(‘WeixinJSBridgeReady’, onBridgeReady, false); }else if (document.attachEvent){ document.attachEvent(‘WeixinJSBridgeReady’, onBridgeReady); document.attachEvent(‘onWeixinJSBridgeReady’, onBridgeReady); }}else{ onBridgeReady();}我们主要是从后台中获取数据传入onBridgeReady这个方法中。所以第一步是获取数据，第二步是把获取到的数据传入到onBridgeReady方法第一步：发送请求获取后台数据1.在对应的api文件下封装请求（get）export function wechatPay(type, vid, token, point, discount) { let discount_type = discount || null return axios.get(${Host}/api/save_mobile,{ params: { pay_type: type, video_id: vid, token, point, discount_type } })}2.在对应的组件调用请求<p @click="_wechatPay(paytype, $route.query.video_id, info.token, info.points)" class=“submit”>发送支付请求</p>import { wechatPay } from ‘../../../api/pay.js’export default { name: ‘payfooter’, computed: { info() { return this.$store.state.user.info }, // 获取选择支付的方式 paytype() { return this.$store.state.pay.paytype } }, methods: { _wechatPay(type, vid, token, point) { wechatPay(type, vid, token, point).then(res => { console.log(res) // 这个res就是后台返回的数据 }) } }} 3.后台返回的json格式数据如下（这不是console出来，方便显示我就直接把json数据复制过来）{ “code”: 0, “data”: { “appId”: “wx5beac7c40c”, “nonceStr”: “8491k3Rs5”, “package”: “prepay_id=wx07**************2653”, “paySign”: “CDE21B40C1A”, “signType”: “MD5”, “timeStamp”: “151” }, “msg”: null}第二步：把数据传给onBridgeReady函数所以真正需要获取的内容是 res.data.data，然后再把res.data.data的值传给onBridgeReady函数4.重新整理一下代码就是 methods: { _wechatPay(type, vid, token, point) { wechatPay(type, vid, token, point).then(res => { res = res.data if(res.code === 0) { this.onBridgeReady(res.data) // 这样就把res.data传给onBridgeReady函数 } }) }, // 微信支付api相关配置文档 onBridgeReady(data) { if (typeof WeixinJSBridge === ‘undefined’) { this.$toast({ message: ‘请使用微信内置浏览器进行支付’ }) } else { WeixinJSBridge.invoke( ‘getBrandWCPayRequest’, { appId: data.appId, // 公众号名称，由商户传入 timeStamp: data.timeStamp, // 时间戳，自1970年以来的秒数 nonceStr: data.nonceStr, // 随机串 package: data.package, signType: data.signType, // 微信签名方式： paySign: data.paySign // 微信签名 }, res => { if (res.err_msg === ‘get_brand_wcpay_request:ok’) { this.$toast({ message: ‘支付成功’ }) this.$router.push({path: ‘/videoplayer’, query: { video_id: this.$route.query.video_id }}) // 支付成功之后跳转的路由 } else { this.$toast({ message: ‘支付失败’ }) } } ) } }, }支付宝支付与微信支付不同的是，支付宝支付后台是返回form格式的数据，如下<form name=“punchout_form” method=“post” action=“https://openapi.alipay.com/gateway.do?charset=UTF-8&method=alipay.trade.wap.pay&sign=DEpMkIeWUs6EW3QKlt9OHYv%2FqkporO8Sr5%2Bay5VA9dpx3pAbIiPPajQ2gEcWHvz5bmkxH8ZvHUXahQL9S69p9wKNXpXOxYadlsxE8QKGUc4cO5rrgGq08%2BpiOq%2FOz4fLogEBWANXILUMWXNzJn8YryNifZ416Pd%2BxkKgXs%2Fo%2FQDcqEUgVXXPRq7IGRGQg%2FpZkOhxCH%2Fq%2B9hnWEncAfQLlAXfPqjdcQTNJ0TJdVr1X1ENOdAr5LQkydWw2EQ8g%3D%3D&return_url=+https%3A%2F%2**********&notify_url=+https%3A%2F%Fpub%2Fapi%2Fv1%2Fallback1&version=1.0&app_id=2057&sign_type=R&timestamp=2019-055&alipay_sdk=al*****.49.ALL&format=json”> <input type=“hidden” name=“biz_content” value="{&quot;body&quot;:&quot;&quot;,&quot;enable_pay_channels&quot;:&quot;balance,moneyFund,bankPay,debitCardExpress,creditCardExpress,creditCard,pcredit,pcreditpayInstallment,coupon,point,voucher,mdiscount,honeyPay&quot;,&quot;out_trade_no&quot;:&quot;132ecf937ad84487aa6cbaeb2ec157fe&quot;,&quot;product_code&quot;:&quot;13&quot;,&quot;subject&quot;:&quot;SpringBoot 2.x微信支付在线教育网站项目实战&quot;,&quot;timeout_express&quot;:&quot;20m&quot;,&quot;total_amount&quot;:&quot;98&quot;}"> <input type=“submit” value=“立即支付” style=“display:none” ></form><script>document.forms[0].submit();</script>那么在处理后台数据的时候用下面的方法（参考网络大神）_wechatPay(type, vid, token, point) { wechatPay(type, vid, token, point).then(res => { const form = res.data const div = document.createElement(‘div’) div.id = ‘alipay’ div.innerHTML = form document.body.appendChild(div) document.querySelector(’#alipay’).children[0].submit() // 执行后会唤起支付宝 })} ...

摘要： 支付宝与欲望、想象力的博弈乃至搏斗，10年来不曾停歇。小蚂蚁说：双11十年间，交易规模的指数级增长不断挑战人们的想象力，而对蚂蚁技术团队来说，这不仅是一场消费盛宴，而是无数次濒临压力和焦虑极限的体验，更是技术的练兵场。如今双11对蚂蚁金服而言，已经绝不仅限于一个技术项目，而更像是一个社会化工程，可以叫做「连贯的，社会化的技术大协作」。支付宝团队不正像那尊红漆雕塑一样？一面对技术保持着敬畏、谦逊，一面又不得不玩命狂奔。「双11」就在眼下了，但蚂蚁金服的新园区里气氛明朗，人群也没往年那么匆忙。进园区时，出租车司机左手扶稳方向盘，右手比划着说，秋天是杭州最好的季节，当然啦，春天也不赖。阳光猛烈，洒在园区的楼群上，映得金栗色玻璃深邃又清亮。这座新园区里尚有很多事不为人所熟知。每3分钟会有1人在2号楼门口左手边垃圾桶上捻灭烟头，吱呀作响；访客大厅的姑娘每天用胖大海跟人参片泡4壶茶，12个玻璃杯倒扣，杯子把统一偏右30度；园区身着橙色外套的保洁员不间歇地扫落叶，她们每天工作8小时，3班倒，总在推车上预备3个喷壶，以及1个保温杯；每个花坛里，通常能用竹质夹子够出三个烟头或纸片。这里的秋天昼夜温差只有6摄氏度，但早晚都有人衣着单薄；穿冲锋衣的外卖员打手机时，话筒离开嘴边20公分，嗓门平均70分贝；下午时分，很多餐馆的员工们蹲在门口抽烟，只有星巴克客流不断，这里的大蛋糕与迷你蛋糕预定时间都是3天，收银员也偶尔会用墨色水笔给姓董的先生标注Mr Wang；员工餐厅每天分四次供餐，楼群间额外排列着18家餐饮门店。楼内有超过1000平米的免费健身房，私教价格仅为外边的一半，穿耐克跑鞋的姑娘每天会带着她的柯基犬来同时使用两台跑步机，尽管她的身型已没什么可挑剔。当你在下沉广场跟第四个人搭话后，套着夹克衫的保安会盯着看，在你发毛之前问及身份，噢，是记者，别介意，履行职责嘛。这是造价超过11亿元，面积18万平方米的蚂蚁金服新总部，设施功能齐全，堪堪媲美小型城镇，是 NBBJ 建筑事务所的手笔，也被叫做「蚂蚁Z空间」。功能强大的综合体建筑容纳了这里的杭州人与新杭州人，注视着他们的每一单生意，每一次创新，这里承载上万人的财富与梦想，也记录着每个个体的骄傲与焦虑。双11十年间，交易规模的指数级增长不断挑战人们的想象力，而急速扩张背后，对技术团队来说，是无数次濒临压力和焦虑极限的体验。想象力和焦虑最初给蚂蚁金服技术团队结出了一张网，又织就成细密厚实的茧壳。从2010年开始的三四年里，人们总会在双11的消费前端感受到一些使用体验的卡顿、不舒适，而内里则是这批工程师与欲望、想象力的博弈乃至搏斗，并在很多个逼近焦虑极限的瞬间，不断打破桎梏。「为了几十秒，值吗？」杭州入秋的早晨，凉得很，黄勇（花名展一）起个大早，跟几位同事结伴跑了趟灵隐寺。这千年古刹在深山，向来香火旺盛。这几年，寺庙时兴环保，免费发清香，他请了三炷，点上，拜拜。采访时，我问拜的哪位菩萨，黄勇皱皱眉头，乐了，「还真不认识」。烧香的心可是诚的，况且，来许愿的人，没几个比他的愿望还大，作为今年双11支付保障PM（项目经理），他得事无巨细地操办这个事关几亿人的项目。每逢双11，蚂蚁金服的项目组成员们总要供上关二爷，穿上红内裤，换上红战袍，存几瓶红酒，烧几炉香。按支付宝双11保障团团长陈亮（花名俊义，技术风险部研究员）的话来说，这是对技术的敬畏。可事实上，要敬畏的绝不仅仅是技术这一件事，双11作为枝节空前庞杂的项目，每个事物的细节上都有无数个随机的可能性，早已超出了人能控制的边界。黄勇能做的就是制定「容灾」机制，尽力去逼近那个不可能到达的「确定性」。举个例子来说，在采访当天，黄勇刚刚给所有11月10号晚上要进光明顶（支付宝双11作战室）的成员发了邮件，仔细交代了「如果当晚茶杯在电脑上打翻了怎么办」这个主题。2012年，负责支付宝双11项目的PM同事从西安请回一尊皮影关公像，大伙觉得新鲜，纷纷敬上香烟、酸奶跟水果。自打那会开始，每逢重要的项目启动，总有人提前往公司请关二爷。创业邦这次拜访蚂蚁金服时，作战室里就供着一尊二爷铜像，该上的供也早都摆上了。请二爷似乎也开始带来好运，那位请铜像的同学，前年双11还在公司里抽到一次大奖。某年双11，马云带几位合作伙伴在西溪园区参观，登上光明顶（支付宝双11作战室）的时候，一位女性投资人吃惊地问，你们工程师居然时兴拜关公？俊义就笑，还是那个说辞，敬畏。信仰也好，敬畏也罢，双11显然都值得。十年里，从最初几乎不太被人感知的促销活动，由欲望、情绪、责任感和创造力混合驱动着增长，长成一个不断突破想象力极限的庞然大物。2009年，首届双11购物节的单日成交额是5000多万元，一个对比是，当年支付宝的日交易额最高突破了12亿元。「记得有几十个品牌参与，当时对它的感觉就是，淘宝做了个活动」，支付宝事业群总裁倪行军（花名苗人凤）回忆称。但他没有预料到，所有人都没预料到，从第二年，双11就开始刷新所有人的想象力上限，如今回头端详增长曲线，它在某些年份里维持着数字量级的增速，那线条着实显得陡峭，但想想吧，处在那个当下，未知和增长给人们心理带来的是更加强烈的冲击感。在蚂蚁金服CTO程立（花名鲁肃）的记忆里，2010年之后的几年双11，对支付宝技术团队来说，是像电影《2012》一般的巨大考验，「你把一个船放在那里，上面有个大浪，没人知道能不能扛住，扛住就扛住了，扛不住就没了。」这艘大船只能提前按既有的想象力建造，但在应对巨浪时，必须临时补救随机出现的漏洞，随机意味着不确定性，巨大的随机和不确定性就进一步施加给团队更庞大的压力。程立记得，现任阿里云副总裁李津当时在阿里巴巴集团负责双11项目，「受不了的时候，李津要开车到龙井山上，打开窗户睡一宿，他说压力太大了，要吸氧。」2010年，第二次迎接双11的支付宝经历了一次后来广为人知的「4秒惊魂」。11日的23时59分30秒，双11结束前半分钟，支付宝核心账务系统突然报警，资源行将耗尽。当时整个支付宝的账务数据库没有进行过任何拆分，一旦系统崩溃，所有业务都会挂掉，对淘宝和支付宝都会造成灾难性损失。在工程师将一个会计系统的应用关掉，释放出来资源时，离数据库崩溃只剩4秒。单就技术本身，在当时就已经是一笔永远测算不清楚的账。2012年双11之前，支付宝技术组已经把能想象到的压力测试做了个遍，但当晚高峰期还是出了岔子，运维工程师巩杰（花名袁越）记得，当时后台一条数据通道设置的阈值太低，导致短暂宕机，但系统认定为无法响应，于是自动将其剔除了，随后服务器一台接一台地挂掉，「跟雪崩似的，导致几十分钟里交易一直在抖动」，直到做了降级，切掉一部分流量之后，系统才恢复正常交易——按程立的说法是，那根保险钨丝被高频交易熔断了，临时搭上一根铜线才应付过去。此时，过于庞大复杂的系统，人力已经无法完成全面有效的测试了。巩杰说，因为有前两年数据库无法承压的情况，2012年已经在应用和DBA层面做了大量的压力测试，但最终出问题的，恰恰是前面还没压到的「路口」。采访中，俊义苦笑道，当时每年双11都信心满满，每年又都过得提心吊胆。在双11压力最大的那几年，整个支付宝技术团队每年要花费几个月乃至半年时间来「练兵」，做各种技术结构调整，系统测试。俊义最初产生过疑问，整个团队花费出的绝大部分时间精力，只是为了贡献给双11最高峰的那几秒。「非得这样吗？」「值吗？」但时间会赋予所有原本未知事物以终极的意义，双11正是这样一个把意义逐渐延展开的时代产物。「在当时，淘宝是我们最大的客户，我们必须服务好」，俊义说。按照马云早年的讲法，在客户关系之外，淘宝天猫和支付宝更像是夫妻关系，也正是在淘宝天猫的业务倒逼下，支付宝团队的技术能力被空前地激发，一位今年入职的工程师毫不讳言，他入职蚂蚁金服的核心吸引力就是双11，「对工程师来说，再没有比双11更值得挑战的项目了。」巩杰也是后来才意识到，某信用卡团队早先在实验室环境里实现的数万笔每秒的交易峰值，早就被支付宝在实战里远远抛在身后。2017年双11，支付宝的交易峰值就达到了25.6万笔/秒。按照资深技术专家李铮（花名祢衡）的说法，技术团队最近几年已经把双11两天48小时的工作量做了很细致的拆分，“我们做了非常详尽的作战手册，它有很多的步骤，按不同的时间点，你要去执行。”技术之外，双11是个在更广泛的范围内牵扯着不同部门，不同团队，不同企业的庞大协作系统。蚂蚁金服集团副总裁陈亮（花名关胜，品牌与公众沟通部门负责人）记得，某一年的双11当晚十点钟前后，一家国有大行银行的交易系统内的一百万个单号发光了，后续单子无法生成，于是当晚最后两个小时，所有源自该银行的支付订单都无法执行。「总会有你无法预想的问题出现，我们做好所有准备，剩下只能兵来将挡水来土囤了。」想想啊，就好比火箭升空一样，倪行军敲敲桌子说。多少软硬件技术环节，多少个零件组装拆卸，在设计制造的过程中，只能穷尽所有人脑可以企及的可能性去做测试，但在点火那一刹那，等待它的是圆满功成还是原地爆炸，你只能束手以待了。倪行军觉得，无论是技术人员拜关公、烧香还是公关团队的预案，都证明了蚂蚁金服团队对双11的敬畏心。2013年5月，支付宝下线了最后一台IBM小型机，随后逐渐以自主研发的OceanBase数据库替代了Oracle，完成了去IOE工程。如今双11对蚂蚁金服来说，已经绝不仅限于一个技术项目，而更像是一个社会化工程。程立说，如果为它定义一个清晰的组织概念，可以叫做「连贯的，社会化的技术大协作」。一面敬畏，一面狂奔蚂蚁Z空间的楼群维持着古怪的几何形状，像个「撅着屁股」的Z字，又像个扭动起舞的水泥巨人。但与外部怪异的建筑设计、杂乱的人流相反，在楼宇内部密布着闸机与证件机器，构建起坚固的秩序和准入流程。室外，巨大的红色人形雕塑朝着人流入口鞠躬，姿态谦逊，气势却浑然不可当。支付宝团队不正像那尊雕塑一样？一面对技术保持着敬畏、谦逊，一面又不得不玩命狂奔。这十年间，在双11之外，他们也有很多焦虑要去消解。被问及在支付宝工作十几年间最难忘的瞬间，倪行军和陈亮的首选都是那次年会。2010年1月21日，支付宝公司年会，此前内部并没有太多源自自觉的危机感。遥遥领先的市场份额与灼灼亮眼的业务数据，一切看起来十分顺利。但年会一开场，人们就发现气氛就有些怪异。会场高音喇叭里首先传来指责、抱怨、无奈与批评，这些声音是来自客服电话录音里的客户投诉。但现场事态发展，完全不只是「反思」而已。陈亮到了会场，才收到马云等阿里集团组织部的高管们将要到场的消息。随后，客户满意中心的代表上台，表达了「我们的体验如何糟糕，用户如何承受着折磨」；BD团队则指出「合作伙伴是如何对支付宝的高期望，同时又是如何的失望和无奈」。马云现场发火了。「烂，太烂，烂到极点」。陈亮记得，这是他多年来唯一一次在公开场合看到马云发脾气。马云毫不客气地指出，支付宝在很多问题上太过保守，如果不重视用户体验，「将慢慢死去」。这显然跟支付宝团队自我评价的结论相去甚远，事实上，在那个时点上，如果横向对比来看，支付宝的产品设计和市场占有率表现绝不算差，团队甚至把2009年定义为「用户体验年」。但回头看，当时在PC端的产品体验确实很不理想，每次支付都需要解决控件、插件、外接U盾一堆问题。 时任阿里巴巴CTO的王坚也给了一句非常严厉的评价，「自娱自乐」。这甚至使倪行军当下有点懵，他记得在年会之后一段时间里，一度陷入严重的自我怀疑，「搞了这么多年技术，怎么变成自娱自乐了？是不是我们对技术的认知出了问题？」后来他反应过来，差池是出现在从技术到产品、到业务、再到客户之间的对话环节。做客户体验，单由使命与愿景来驱动不够。他原本认为的应该如何运作，与用户的现实期待之间，鸿沟已现。整个中国的支付行业按照支付方式演变可以分成三个阶段：2009年-2013年，从网银支付到快捷支付；2014年-2016年，移动支付崛起；2017年-2018年，则是指纹和刷脸支付渐成主流。如今回头看，那次年会对整个蚂蚁金服公司来说都是个至关重要的节点，在此次转型的推动下，支付宝从网银支付迈进了快捷支付时代。「生生被逼出来的」，俊义回忆道，「如果那时候没有快捷支付，整个中国移动互联网的进程至少会落后两三年」。微信支付加入之前，支付宝曾有十年时间只能自我调试，寻找发展坐标。而当前者入局，支付宝团队的反应是：哇！我们有竞争对手了。「我们从没有遇过像这样的竞争对手，竞争是很正常的事情，但结局取决于竞争对手的能量，微信支付是非常值得尊敬的一个竞争对手。」陈亮如是说。微信支付出现，促使蚂蚁金服又一次推进意识形态的提升。如今说来云淡风轻，当时可是风起云涌，情绪百般垂丧。时间回到2014年1月26日，腾讯推出微信红包，后者立刻以病毒式传播的方式活跃在微信群内，并在除夕夜全面爆发。数据显示，除夕当天到初八，超800万用户参与了红包活动，超4000万个红包被领取。与微信红包这面的热火朝天形成明显反差的是，支付宝的「讨彩头」反响平平。后者推出于23日，还早了3天。「微信一个红包就超过支付宝8年干的事。」这句话很快流传起来，马云后来则用「珍珠港偷袭」评价腾讯推出微信红包一举。陈亮对这件事情对记忆尤其深刻，他参与了支付宝红包的产品讨论。因为也在广东工作过，知道当地有讨红包的习俗，于是他给出了做「讨红包」的建议。但微信做的是「发红包」，陈亮回想，当时讨论过程中，似乎也有人提出这一点，但产品设计最终并未将其采纳。 其实，即便支付宝当时采用了发红包的设计，在那一阵上也未必有胜算——没有关系链，没有社群，没有从交易体系到账户体系的整体准备。但陈亮仍然感到懊悔，控制不住的懊悔，甚至责怪自己技不如人。眼看着媒体群里纷纷扬扬的红包雨和赞扬声，陈亮都不想上微信了，「不想说话了，不敢说话了」。 他想去友人处寻得开解，想驳斥那句一个红包顶八年的说法，但他刚开口就沉默下去，市场反应已然说明一切。可他还是在心里翻来覆去地想，怎么我们没有想到人家那个点子，怎么就没有呢？ 但事情过去也就过去了。尽管公司层面的焦虑一直延续到2016年，但陈亮已经学会将焦虑情绪摒除在自己的生活之外。焦虑毫无用处这件事已被证明——前两年的焦虑除了让他自己难受紧张、动作变形外没有产生任何意义。其实，接受这种量级的竞争，或许某种意义上也是在接受命运馈赠。陈亮后来总是被年轻同事认为对困难事物的感受很迟钝，他自己觉得原因在于再没有过境况更加艰难的时刻了。再碰到困难时，总有一种消解的情绪在，「最难的时候都过来了，这些算什么？」而支付产业则更加受益于两家顶级公司的竞争推动，中国支付技术在国际上一骑绝尘。2017年年末，西班牙《世界报》刊文表达了对中国支付产业的看法，给出的结论叫做：「中国的支付革命堪称中国史上最大的技术革新之一。」技术的价值观其实从2010年双11的「4秒惊魂」之前，支付宝技术人员就意识到，使用IOE商用设备（IBM-服务器提供商，Oracle-数据库软件提供商，EMC-存储设备提供商，三者构成了从软件到硬件的企业数据库系统）与开源软件，已经不能适用于双11交易量指数级增长对技术支持的要求，尤其是在谁也不能完全预设到当晚状况的时候。即使能支撑，成本也将是天文数字。支付宝决定去IOE，自主研发分布式数据库，转云计算，OceanBase项目随即启动。俊义记得，他在支付宝做的第一个技术改造项目是拆分数据库。当时还不是因为双11，单纯是因为支付宝网站交易量涨得很快，数据库扛不住了，不拆，业务就无法增加。这是在2008年。2010年，俊义又拆了一次数据库。这次，他将上次拆出的两个数据库中的交易数据库，拆成10个小型机。这时已差不多算是为去IOE铺下基础。但很快，10个小型机也不够用了。 2011年的双11结束后，应用服务器与数据库的连接已到瓶颈，容量没办法再增加，换句话说，IOE集中式强大单点无法满足阿里特别是当时淘宝爆炸式业务增长应用的模式，同时也限制了技术潜力的发挥，另外，由于IOE是专用设备，对机架、电力、网络存在单独设计的要求，成本压力也已经非常大。 从2010年1月启动，到2011年7月完成商品库的去IOE（经历读写分离、去小型机、去Oracle和EMC），再到交易等其他核心系统的去IOE，2013年，支付宝最后一台小型机下线，IOE中的I和E都已经被中国自主研发的技术取代，上云完成阶段性进展，这就像造发动机，意味着双11的交易量不会再受到技术制约。不过在第一阶段，每年双11能否顺利通过，还是有点碰运气。从2014年开始，支付宝开始研发和施行全链路压测技术，这就有点像造飞机时候的风洞，造一个实验室，完全模拟当天峰值所有的真实环境，对系统进行压力测试。据2018年大促保障副队长巩杰说，全链路压测对真实用户请求的模拟可以达到与双11当天请求90%以上的一致度。这样一来，到了双11当天，平稳度过的概率就极高了，团队因不确定而产生的焦虑大幅降低。全链路压测作为消除不确定性的“大杀器”，已经成为目前测试系统的常规手段，随着系统的升级，使用频率也在降低，李铮记得，全链路压测技术刚刚研发使用的时候，“恨不得每天都做一遍测试”，而今年的双11准备工作里，每周定期做1-2次压力测试已经足够了。支付宝的双11已经是一个巨大的系统工程，已经无法再完全依赖人脑思考解决所有条线上的问题。所以，李铮觉得，“智能化”是另一个关键词。对系统工程的把控，也正是要辅以智能化全链路压测这类技术手段，才能更加精准高效地解决问题。 11月2日，大促保障团组织了最后一次模拟的全链路压测，万事俱备，只欠东风，就等10日24点一过。对支付技术来说，稳定压倒一切，稳定也意味着一切。一如往年，第10年双11，稳定的重要性依然处于第一位置。稳定之外，支付宝技术团队还有更多追求。在2018年的双11技术保障上，人工干预已经越来越少，因为整个保障系统的智能化程度越来越高。比如，往年筹备双11时，该配置多少计算资源，如何达到最优化的配置，都需要非常有经验的工程师进行严密计算，并进行反复的压力测试，不断调优。但现在，机器可以自动地进行计算和调优。程立打了个比方，双11的支付保障会越来越朝着「自动驾驶」的目标迈进，该往哪开，在哪停，如何躲避风险，保障安全，都是智能的。新的变化还体现在生物识别支付和区块链技术的应用。 在倪行军的谈论中，支付宝对支付的理解，倾向于支付脱媒，到最后，支付时不需要任何载体，人体本身即为最大媒介，当然，脱媒不可完全脱离，但生物识别技术是IoT时代用户参与到数字化场景的敲门砖，任何的场景系统都要首先确定一个所谓的数字身份的问题，而人本身就是最棒的载体，不需要其它的媒介做二次切换。由此，生物识别是可以重塑体验的技术。据倪行军透露，平日应用场景中的生物识别（包括指纹输入、面部扫描等）支付比例已经超过一半，这反映出整体人群对生物识别技术所对应的新支付体验的接受程度，这信号让他觉得，手机应用之外其他生活场景中，扩展生物识别技术用户的时机，已经到来。今年上半年，生物识别技术真正走向规模化商业化，倪行军的预期是先实现规模化，在终端设备达到百万级规模的基础上，根据用户行为与各商业场景连接的磨合情况，再考虑后续的商业诉求。未来，新技术的应用势必重新定义整个商业流程，新的百万级的商业机会将在此诞生。今年天猫双11用区块链技术为1.5亿跨境商品提供原产地溯源，包括比利时钻石交易所的钻石这类大额商品。 变化背后是蚂蚁金服的BASIC技术战略演进及开放，Blockchain (区块链)、Aritificial intelligence（人工智能）、Security（安全）、IoT（物联网）和Computing（计算）这五条线索构成对未来更加清晰的想象力。十年间，蚂蚁金服整个公司都在从中心化向分布式持续变化。人员能力变得更加均衡。俊义记得，早年在双11和很多技术攻关的关键时刻，总会有几位技术大牛同事站出来，在当下拿出过人的洞察与能力，最终顺利过关。但如今，蚂蚁金服公司的整个技术结构益发庞杂，必须形成全局、众人的工程化作战。IT架构从IOE变成分布式，再演化出「离在线混部」。去年有25%是自有服务器处理，55%在云上，20%是离线资源；今年这个比例则会更新到60%在云上，在线与离线分别20%，其间，性能较差的离线机房也能执行在线处理，核心在于资源的进一步合理分配。分布式趋势渐成大势：机房越来越多，从杭州拓展到全国各地；应用系统与数据库越扩越多；团队从支付宝技术团队扩至各个产品线，集团运作从前尚可靠寥寥能力拔尖者把握，如今则需层层分解，整体组织协同作战。「从中心化到分布式」是互联网发展过程中，近年形成的社会关系形态和内容的一大特征。如果将其视作一种价值观的话，作为一家工程师员工占比超过51%的互联网金融企业，它正在被深深影响、驱动并改变着，企业里大量人、事、物，都在明确地呈现这这种趋势导向，这家价值上千亿美金的企业，也正在成为一个由技术价值观驱动业务、团队革新与发展的经典范本。本文作者：平生栗子阅读原文本文为云栖社区原创内容，未经允许不得转载。

小蚂蚁说：双11十年间，交易规模的指数级增长不断挑战人们的想象力，而对蚂蚁技术团队来说，这不仅是一场消费盛宴，而是无数次濒临压力和焦虑极限的体验，更是技术的练兵场。如今双11对蚂蚁金服而言，已经绝不仅限于一个技术项目，而更像是一个社会化工程，可以叫做「连贯的，社会化的技术大协作」。图 | 东方IC CYZONE特写，大时代惘闻录图 | 东方IC CYZONE特写，大时代惘闻录支付宝团队不正像那尊红漆雕塑一样？一面对技术保持着敬畏、谦逊，一面又不得不玩命狂奔。「双11」就在眼下了，但蚂蚁金服的新园区里气氛明朗，人群也没往年那么匆忙。进园区时，出租车司机左手扶稳方向盘，右手比划着说，秋天是杭州最好的季节，当然啦，春天也不赖。阳光猛烈，洒在园区的楼群上，映得金栗色玻璃深邃又清亮。这座新园区里尚有很多事不为人所熟知。每3分钟会有1人在2号楼门口左手边垃圾桶上捻灭烟头，吱呀作响；访客大厅的姑娘每天用胖大海跟人参片泡4壶茶，12个玻璃杯倒扣，杯子把统一偏右30度；园区身着橙色外套的保洁员不间歇地扫落叶，她们每天工作8小时，3班倒，总在推车上预备3个喷壶，以及1个保温杯；每个花坛里，通常能用竹质夹子够出三个烟头或纸片。这里的秋天昼夜温差只有6摄氏度，但早晚都有人衣着单薄；穿冲锋衣的外卖员打手机时，话筒离开嘴边20公分，嗓门平均70分贝；下午时分，很多餐馆的员工们蹲在门口抽烟，只有星巴克客流不断，这里的大蛋糕与迷你蛋糕预定时间都是3天，收银员也偶尔会用墨色水笔给姓董的先生标注Mr Wang；员工餐厅每天分四次供餐，楼群间额外排列着18家餐饮门店。楼内有超过1000平米的免费健身房，私教价格仅为外边的一半，穿耐克跑鞋的姑娘每天会带着她的柯基犬来同时使用两台跑步机，尽管她的身型已没什么可挑剔。当你在下沉广场跟第四个人搭话后，套着夹克衫的保安会盯着看，在你发毛之前问及身份，噢，是记者，别介意，履行职责嘛。这是造价超过11亿元，面积18万平方米的蚂蚁金服新总部，设施功能齐全，堪堪媲美小型城镇，是 NBBJ 建筑事务所的手笔，也被叫做「蚂蚁Z空间」。功能强大的综合体建筑容纳了这里的杭州人与新杭州人，注视着他们的每一单生意，每一次创新，这里承载上万人的财富与梦想，也记录着每个个体的骄傲与焦虑。双11十年间，交易规模的指数级增长不断挑战人们的想象力，而急速扩张背后，对技术团队来说，是无数次濒临压力和焦虑极限的体验。想象力和焦虑最初给蚂蚁金服技术团队结出了一张网，又织就成细密厚实的茧壳。从2010年开始的三四年里，人们总会在双11的消费前端感受到一些使用体验的卡顿、不舒适，而内里则是这批工程师与欲望、想象力的博弈乃至搏斗，并在很多个逼近焦虑极限的瞬间，不断打破桎梏。2017年8月份，蚂蚁金服正式启用了这座名为「Z空间」的新园区 | 图虫创意「为了几十秒，值吗？」杭州入秋的早晨，凉得很，黄勇（花名展一）起个大早，跟几位同事结伴跑了趟灵隐寺。这千年古刹在深山，向来香火旺盛。这几年，寺庙时兴环保，免费发清香，他请了三炷，点上，拜拜。采访时，我问拜的哪位菩萨，黄勇皱皱眉头，乐了，「还真不认识」。烧香的心可是诚的，况且，来许愿的人，没几个比他的愿望还大，作为今年双11支付保障PM（项目经理），他得事无巨细地操办这个事关几亿人的项目。每逢双11，蚂蚁金服的项目组成员们总要供上关二爷，穿上红内裤，换上红战袍，存几瓶红酒，烧几炉香。按支付宝双11保障团团长陈亮（花名俊义，技术风险部研究员）的话来说，这是对技术的敬畏。可事实上，要敬畏的绝不仅仅是技术这一件事，双11作为枝节空前庞杂的项目，每个事物的细节上都有无数个随机的可能性，早已超出了人能控制的边界。黄勇能做的就是制定「容灾」机制，尽力去逼近那个不可能到达的「确定性」。举个例子来说，在采访当天，黄勇刚刚给所有11月10号晚上要进光明顶（支付宝双11作战室）的成员发了邮件，仔细交代了「如果当晚茶杯在电脑上打翻了怎么办」这个主题。2012年，负责支付宝双11项目的PM同事从西安请回一尊皮影关公像，大伙觉得新鲜，纷纷敬上香烟、酸奶跟水果。自打那会开始，每逢重要的项目启动，总有人提前往公司请关二爷。创业邦这次拜访蚂蚁金服时，作战室里就供着一尊二爷铜像，该上的供也早都摆上了。请二爷似乎也开始带来好运，那位请铜像的同学，前年双11还在公司里抽到一次大奖。某年双11，马云带几位合作伙伴在西溪园区参观，登上光明顶（支付宝双11作战室）的时候，一位女性投资人吃惊地问，你们工程师居然时兴拜关公？俊义就笑，还是那个说辞，敬畏。信仰也好，敬畏也罢，双11显然都值得。十年里，从最初几乎不太被人感知的促销活动，由欲望、情绪、责任感和创造力混合驱动着增长，长成一个不断突破想象力极限的庞然大物。2009年，首届双11购物节的单日成交额是5000多万元，一个对比是，当年支付宝的日交易额最高突破了12亿元。「记得有几十个品牌参与，当时对它的感觉就是，淘宝做了个活动」，支付宝事业群总裁倪行军（花名苗人凤）回忆称。但他没有预料到，所有人都没预料到，从第二年，双11就开始刷新所有人的想象力上限，如今回头端详增长曲线，它在某些年份里维持着数字量级的增速，那线条着实显得陡峭，但想想吧，处在那个当下，未知和增长给人们心理带来的是更加强烈的冲击感。在蚂蚁金服CTO程立（花名鲁肃）的记忆里，2010年之后的几年双11，对支付宝技术团队来说，是像电影《2012》一般的巨大考验，「你把一个船放在那里，上面有个大浪，没人知道能不能扛住，扛住就扛住了，扛不住就没了。」这艘大船只能提前按既有的想象力建造，但在应对巨浪时，必须临时补救随机出现的漏洞，随机意味着不确定性，巨大的随机和不确定性就进一步施加给团队更庞大的压力。程立记得，现任阿里云副总裁李津当时在阿里巴巴集团负责双11项目，「受不了的时候，李津要开车到龙井山上，打开窗户睡一宿，他说压力太大了，要吸氧。」2010年，第二次迎接双11的支付宝经历了一次后来广为人知的「4秒惊魂」。11日的23时59分30秒，双11结束前半分钟，支付宝核心账务系统突然报警，资源行将耗尽。当时整个支付宝的账务数据库没有进行过任何拆分，一旦系统崩溃，所有业务都会挂掉，对淘宝和支付宝都会造成灾难性损失。在工程师将一个会计系统的应用关掉，释放出来资源时，离数据库崩溃只剩4秒。单就技术本身，在当时就已经是一笔永远测算不清楚的账。2012年双11之前，支付宝技术组已经把能想象到的压力测试做了个遍，但当晚高峰期还是出了岔子，运维工程师巩杰（花名袁越）记得，当时后台一条数据通道设置的阈值太低，导致短暂宕机，但系统认定为无法响应，于是自动将其剔除了，随后服务器一台接一台地挂掉，「跟雪崩似的，导致几十分钟里交易一直在抖动」，直到做了降级，切掉一部分流量之后，系统才恢复正常交易——按程立的说法是，那根保险钨丝被高频交易熔断了，临时搭上一根铜线才应付过去。此时，过于庞大复杂的系统，人力已经无法完成全面有效的测试了。巩杰说，因为有前两年数据库无法承压的情况，2012年已经在应用和DBA层面做了大量的压力测试，但最终出问题的，恰恰是前面还没压到的「路口」。采访中，俊义苦笑道，当时每年双11都信心满满，每年又都过得提心吊胆。在双11压力最大的那几年，整个支付宝技术团队每年要花费几个月乃至半年时间来「练兵」，做各种技术结构调整，系统测试。俊义最初产生过疑问，整个团队花费出的绝大部分时间精力，只是为了贡献给双11最高峰的那几秒。「非得这样吗？」「值吗？」但时间会赋予所有原本未知事物以终极的意义，双11正是这样一个把意义逐渐延展开的时代产物。「在当时，淘宝是我们最大的客户，我们必须服务好」，俊义说。按照马云早年的讲法，在客户关系之外，淘宝天猫和支付宝更像是夫妻关系，也正是在淘宝天猫的业务倒逼下，支付宝团队的技术能力被空前地激发，一位今年入职的工程师毫不讳言，他入职蚂蚁金服的核心吸引力就是双11，「对工程师来说，再没有比双11更值得挑战的项目了。」巩杰也是后来才意识到，某信用卡团队早先在实验室环境里实现的数万笔每秒的交易峰值，早就被支付宝在实战里远远抛在身后。2017年双11，支付宝的交易峰值就达到了25.6万笔/秒。按照资深技术专家李铮（花名祢衡）的说法，技术团队最近几年已经把双11两天48小时的工作量做了很细致的拆分，“我们做了非常详尽的作战手册，它有很多的步骤，按不同的时间点，你要去执行。”技术之外，双11是个在更广泛的范围内牵扯着不同部门，不同团队，不同企业的庞大协作系统。蚂蚁金服集团副总裁陈亮（花名关胜，品牌与公众沟通部门负责人）记得，某一年的双11当晚十点钟前后，一家国有大行银行的交易系统内的一百万个单号发光了，后续单子无法生成，于是当晚最后两个小时，所有源自该银行的支付订单都无法执行。「总会有你无法预想的问题出现，我们做好所有准备，剩下只能兵来将挡水来土囤了。」想想啊，就好比火箭升空一样，倪行军敲敲桌子说。多少软硬件技术环节，多少个零件组装拆卸，在设计制造的过程中，只能穷尽所有人脑可以企及的可能性去做测试，但在点火那一刹那，等待它的是圆满功成还是原地爆炸，你只能束手以待了。倪行军觉得，无论是技术人员拜关公、烧香还是公关团队的预案，都证明了蚂蚁金服团队对双11的敬畏心。2013年5月，支付宝下线了最后一台IBM小型机，随后逐渐以自主研发的OceanBase数据库替代了Oracle，完成了去IOE工程。如今双11对蚂蚁金服来说，已经绝不仅限于一个技术项目，而更像是一个社会化工程。程立说，如果为它定义一个清晰的组织概念，可以叫做「连贯的，社会化的技术大协作」。双11作战室里的鲁肃（程立）| 受访者供图一面敬畏，一面狂奔蚂蚁Z空间的楼群维持着古怪的几何形状，像个「撅着屁股」的Z字，又像个扭动起舞的水泥巨人。但与外部怪异的建筑设计、杂乱的人流相反，在楼宇内部密布着闸机与证件机器，构建起坚固的秩序和准入流程。室外，巨大的红色人形雕塑朝着人流入口鞠躬，姿态谦逊，气势却浑然不可当。支付宝团队不正像那尊雕塑一样？一面对技术保持着敬畏、谦逊，一面又不得不玩命狂奔。这十年间，在双11之外，他们也有很多焦虑要去消解。被问及在支付宝工作十几年间最难忘的瞬间，倪行军和陈亮的首选都是那次年会。2010年1月21日，支付宝公司年会，此前内部并没有太多源自自觉的危机感。遥遥领先的市场份额与灼灼亮眼的业务数据，一切看起来十分顺利。但年会一开场，人们就发现气氛就有些怪异。会场高音喇叭里首先传来指责、抱怨、无奈与批评，这些声音是来自客服电话录音里的客户投诉。但现场事态发展，完全不只是「反思」而已。陈亮到了会场，才收到马云等阿里集团组织部的高管们将要到场的消息。随后，客户满意中心的代表上台，表达了「我们的体验如何糟糕，用户如何承受着折磨」；BD团队则指出「合作伙伴是如何对支付宝的高期望，同时又是如何的失望和无奈」。马云现场发火了。「烂，太烂，烂到极点」。陈亮记得，这是他多年来唯一一次在公开场合看到马云发脾气。马云毫不客气地指出，支付宝在很多问题上太过保守，如果不重视用户体验，「将慢慢死去」。这显然跟支付宝团队自我评价的结论相去甚远，事实上，在那个时点上，如果横向对比来看，支付宝的产品设计和市场占有率表现绝不算差，团队甚至把2009年定义为「用户体验年」。但回头看，当时在PC端的产品体验确实很不理想，每次支付都需要解决控件、插件、外接U盾一堆问题。 时任阿里巴巴CTO的王坚也给了一句非常严厉的评价，「自娱自乐」。这甚至使倪行军当下有点懵，他记得在年会之后一段时间里，一度陷入严重的自我怀疑，「搞了这么多年技术，怎么变成自娱自乐了？是不是我们对技术的认知出了问题？」后来他反应过来，差池是出现在从技术到产品、到业务、再到客户之间的对话环节。做客户体验，单由使命与愿景来驱动不够。他原本认为的应该如何运作，与用户的现实期待之间，鸿沟已现。整个中国的支付行业按照支付方式演变可以分成三个阶段：2009年-2013年，从网银支付到快捷支付；2014年-2016年，移动支付崛起；2017年-2018年，则是指纹和刷脸支付渐成主流。如今回头看，那次年会对整个蚂蚁金服公司来说都是个至关重要的节点，在此次转型的推动下，支付宝从网银支付迈进了快捷支付时代。「生生被逼出来的」，俊义回忆道，「如果那时候没有快捷支付，整个中国移动互联网的进程至少会落后两三年」。微信支付加入之前，支付宝曾有十年时间只能自我调试，寻找发展坐标。而当前者入局，支付宝团队的反应是：哇！我们有竞争对手了。「我们从没有遇过像这样的竞争对手，竞争是很正常的事情，但结局取决于竞争对手的能量，微信支付是非常值得尊敬的一个竞争对手。」陈亮如是说。微信支付出现，促使蚂蚁金服又一次推进意识形态的提升。如今说来云淡风轻，当时可是风起云涌，情绪百般垂丧。时间回到2014年1月26日，腾讯推出微信红包，后者立刻以病毒式传播的方式活跃在微信群内，并在除夕夜全面爆发。数据显示，除夕当天到初八，超800万用户参与了红包活动，超4000万个红包被领取。与微信红包这面的热火朝天形成明显反差的是，支付宝的「讨彩头」反响平平。后者推出于23日，还早了3天。「微信一个红包就超过支付宝8年干的事。」这句话很快流传起来，马云后来则用「珍珠港偷袭」评价腾讯推出微信红包一举。陈亮对这件事情对记忆尤其深刻，他参与了支付宝红包的产品讨论。因为也在广东工作过，知道当地有讨红包的习俗，于是他给出了做「讨红包」的建议。但微信做的是「发红包」，陈亮回想，当时讨论过程中，似乎也有人提出这一点，但产品设计最终并未将其采纳。 其实，即便支付宝当时采用了发红包的设计，在那一阵上也未必有胜算——没有关系链，没有社群，没有从交易体系到账户体系的整体准备。但陈亮仍然感到懊悔，控制不住的懊悔，甚至责怪自己技不如人。眼看着媒体群里纷纷扬扬的红包雨和赞扬声，陈亮都不想上微信了，「不想说话了，不敢说话了」。 他想去友人处寻得开解，想驳斥那句一个红包顶八年的说法，但他刚开口就沉默下去，市场反应已然说明一切。可他还是在心里翻来覆去地想，怎么我们没有想到人家那个点子，怎么就没有呢？ 但事情过去也就过去了。尽管公司层面的焦虑一直延续到2016年，但陈亮已经学会将焦虑情绪摒除在自己的生活之外。焦虑毫无用处这件事已被证明——前两年的焦虑除了让他自己难受紧张、动作变形外没有产生任何意义。其实，接受这种量级的竞争，或许某种意义上也是在接受命运馈赠。陈亮后来总是被年轻同事认为对困难事物的感受很迟钝，他自己觉得原因在于再没有过境况更加艰难的时刻了。再碰到困难时，总有一种消解的情绪在，「最难的时候都过来了，这些算什么？」而支付产业则更加受益于两家顶级公司的竞争推动，中国支付技术在国际上一骑绝尘。2017年年末，西班牙《世界报》刊文表达了对中国支付产业的看法，给出的结论叫做：「中国的支付革命堪称中国史上最大的技术革新之一。」2018年10月19日晚，蚂蚁金服在Z空间举办HighMa音乐节 | 东方IC技术的价值观其实从2010年双11的「4秒惊魂」之前，支付宝技术人员就意识到，使用IOE商用设备（IBM-服务器提供商，Oracle-数据库软件提供商，EMC-存储设备提供商，三者构成了从软件到硬件的企业数据库系统）与开源软件，已经不能适用于双11交易量指数级增长对技术支持的要求，尤其是在谁也不能完全预设到当晚状况的时候。即使能支撑，成本也将是天文数字。支付宝决定去IOE，自主研发分布式数据库，转云计算，OceanBase项目随即启动。俊义记得，他在支付宝做的第一个技术改造项目是拆分数据库。当时还不是因为双11，单纯是因为支付宝网站交易量涨得很快，数据库扛不住了，不拆，业务就无法增加。这是在2008年。2010年，俊义又拆了一次数据库。这次，他将上次拆出的两个数据库中的交易数据库，拆成10个小型机。这时已差不多算是为去IOE铺下基础。但很快，10个小型机也不够用了。 2011年的双11结束后，应用服务器与数据库的连接已到瓶颈，容量没办法再增加，换句话说，IOE集中式强大单点无法满足阿里特别是当时淘宝爆炸式业务增长应用的模式，同时也限制了技术潜力的发挥，另外，由于IOE是专用设备，对机架、电力、网络存在单独设计的要求，成本压力也已经非常大。 从2010年1月启动，到2011年7月完成商品库的去IOE（经历读写分离、去小型机、去Oracle和EMC），再到交易等其他核心系统的去IOE，2013年，支付宝最后一台小型机下线，IOE中的I和E都已经被中国自主研发的技术取代，上云完成阶段性进展，这就像造发动机，意味着双11的交易量不会再受到技术制约。不过在第一阶段，每年双11能否顺利通过，还是有点碰运气。从2014年开始，支付宝开始研发和施行全链路压测技术，这就有点像造飞机时候的风洞，造一个实验室，完全模拟当天峰值所有的真实环境，对系统进行压力测试。据2018年大促保障副队长巩杰说，全链路压测对真实用户请求的模拟可以达到与双11当天请求90%以上的一致度。这样一来，到了双11当天，平稳度过的概率就极高了，团队因不确定而产生的焦虑大幅降低。全链路压测作为消除不确定性的“大杀器”，已经成为目前测试系统的常规手段，随着系统的升级，使用频率也在降低，李铮记得，全链路压测技术刚刚研发使用的时候，“恨不得每天都做一遍测试”，而今年的双11准备工作里，每周定期做1-2次压力测试已经足够了。支付宝的双11已经是一个巨大的系统工程，已经无法再完全依赖人脑思考解决所有条线上的问题。所以，李铮觉得，“智能化”是另一个关键词。对系统工程的把控，也正是要辅以智能化全链路压测这类技术手段，才能更加精准高效地解决问题。 11月2日，大促保障团组织了最后一次模拟的全链路压测，万事俱备，只欠东风，就等10日24点一过。苗人凤（左4）与蚂蚁金服同事在双11办公室现场 | 受访者供图对支付技术来说，稳定压倒一切，稳定也意味着一切。一如往年，第10年双11，稳定的重要性依然处于第一位置。稳定之外，支付宝技术团队还有更多追求。在2018年的双11技术保障上，人工干预已经越来越少，因为整个保障系统的智能化程度越来越高。比如，往年筹备双11时，该配置多少计算资源，如何达到最优化的配置，都需要非常有经验的工程师进行严密计算，并进行反复的压力测试，不断调优。但现在，机器可以自动地进行计算和调优。程立打了个比方，双11的支付保障会越来越朝着「自动驾驶」的目标迈进，该往哪开，在哪停，如何躲避风险，保障安全，都是智能的。新的变化还体现在生物识别支付和区块链技术的应用。 在倪行军的谈论中，支付宝对支付的理解，倾向于支付脱媒，到最后，支付时不需要任何载体，人体本身即为最大媒介，当然，脱媒不可完全脱离，但生物识别技术是IoT时代用户参与到数字化场景的敲门砖，任何的场景系统都要首先确定一个所谓的数字身份的问题，而人本身就是最棒的载体，不需要其它的媒介做二次切换。由此，生物识别是可以重塑体验的技术。据倪行军透露，平日应用场景中的生物识别（包括指纹输入、面部扫描等）支付比例已经超过一半，这反映出整体人群对生物识别技术所对应的新支付体验的接受程度，这信号让他觉得，手机应用之外其他生活场景中，扩展生物识别技术用户的时机，已经到来。今年上半年，生物识别技术真正走向规模化商业化，倪行军的预期是先实现规模化，在终端设备达到百万级规模的基础上，根据用户行为与各商业场景连接的磨合情况，再考虑后续的商业诉求。未来，新技术的应用势必重新定义整个商业流程，新的百万级的商业机会将在此诞生。今年天猫双11用区块链技术为1.5亿跨境商品提供原产地溯源，包括比利时钻石交易所的钻石这类大额商品。 变化背后是蚂蚁金服的BASIC技术战略演进及开放，Blockchain (区块链)、Aritificial intelligence（人工智能）、Security（安全）、IoT（物联网）和Computing（计算）这五条线索构成对未来更加清晰的想象力。十年间，蚂蚁金服整个公司都在从中心化向分布式持续变化。人员能力变得更加均衡。俊义记得，早年在双11和很多技术攻关的关键时刻，总会有几位技术大牛同事站出来，在当下拿出过人的洞察与能力，最终顺利过关。但如今，蚂蚁金服公司的整个技术结构益发庞杂，必须形成全局、众人的工程化作战。IT架构从IOE变成分布式，再演化出「离在线混部」。去年有25%是自有服务器处理，55%在云上，20%是离线资源；今年这个比例则会更新到60%在云上，在线与离线分别20%，其间，性能较差的离线机房也能执行在线处理，核心在于资源的进一步合理分配。分布式趋势渐成大势：机房越来越多，从杭州拓展到全国各地；应用系统与数据库越扩越多；团队从支付宝技术团队扩至各个产品线，集团运作从前尚可靠寥寥能力拔尖者把握，如今则需层层分解，整体组织协同作战。「从中心化到分布式」是互联网发展过程中，近年形成的社会关系形态和内容的一大特征。如果将其视作一种价值观的话，作为一家工程师员工占比超过51%的互联网金融企业，它正在被深深影响、驱动并改变着，企业里大量人、事、物，都在明确地呈现这这种趋势导向，这家价值上千亿美金的企业，也正在成为一个由技术价值观驱动业务、团队革新与发展的经典范本。

摘要： 红军 VS 蓝军，谁是更强者？小蚂蚁说：自古红蓝出CP，在蚂蚁金服就有这样两支“相爱相杀”的队伍——红军和蓝军。蓝军是进攻方，主要职责是挖掘系统的弱点并发起“真实”的攻击，俗称“找茬”；红军则是防守方，其防控体系建设中的实时核对平台能够做到稳定的分钟级核对异常发现能力，并提供业务快速接入的能力。支付宝“疯起来连自己都打”的项目就是红蓝军技术攻防演练，他们不仅每周进行全栈级别的演练，每年还会举行规模极大的“期中考试”和“期末考试”。接下来就跟着小蚂蚁一起去看看这对红蓝cp的日常“互怼”生活吧！如果一个技术团队不干别的，专门“搞破坏”，这是一种怎样的存在？这真的不是“天方夜谭”，在支付宝确实有这么一支队伍——技术蓝军。蓝军的任务就是不断地攻击和进攻，而防守方则是技术红军。在支付宝，蓝军从属于蚂蚁金服技术风险部（SRE），而红军则包括SRE及各业务部门的技术团队。说到SRE，就需要科普一下了。SRE全拼为Site Reliability Engineer，是软件工程师和系统管理员的结合，是一种要求极高的技术工种。据说，目前全球只有少数几家顶级互联网公司拥有真正意义上的SRE团队，蚂蚁金服是其中之一。由蓝军主导的技术攻防演练就是那个传说中的“疯起来连自己都打”的项目，今天，就来起底一下这个神秘的项目。从“青铜”到强者红蓝军技术攻防演练与蚂蚁金服技术风险部的发展息息相关，而蚂蚁技术风险的演进轨迹和游戏中的不断打怪升级非常相像。早期是质量+运维+架构师三角协同，各司其职并自发性的开展一些技术风险相关的工作。2013年，蚂蚁金服技术团队提出了质量2.0战略，以统一的规章、统一的流程和统一的阵型，开始体系化地沉淀故障检测等方面的平台化能力。大概一年后，也就是2014年，专门成立了技术质量部，从全域视角解决技术风险的问题。2015年，技术质量部正式升级成为技术风险部，专注研发及架构的技术风险问题，并完成相应解决方案和落地的平台。2016年，技术风险部再次升级为SRE团队。SRE团队组建后，就开始全面开展故障自动定位、自适应容灾、防抖、精细化高可用等工作。其中防抖这块，要保证任何的网络或基础设施抖动，用户都无感知；而精细化高可用，又叫单笔高可用，其颗粒度可以精准到用户的每一笔交易，远远优于行业内的机房级高可用。同时，那个热衷“找茬”的组织——技术蓝军也正式成立。这个专门的、拥有独立职能的团队不干别的，主要职责是挖掘系统的弱点并发起“真实”的攻击，红蓝军技术攻防演练也自此诞生。牛X的是，技术蓝军并不对各业务方负责，只对应用架构及防御系统的稳定性和可靠性负责。在蓝军眼中，故障的发生是必然的，只是时间早晚而已。蓝军只有想尽办法去触发这些故障，这样，在故障真实发生的时候，才有足够的应付能力。所以，蓝军发掘各类脆弱点，并通过红蓝军技术攻防演练，不断验证防御系统的可靠性。而故障防御系统及不断优化的高可用架构则是由SRE团队的红军与各业务深度合作，沉淀、构建出来的。现在，全栈级别的技术攻防演练每周都在进行，蓝军似乎对“疯起来连自己都打”很上瘾。利矛与坚盾不断升级持续不断的攻防演练，让蓝军和红军的技术能力得到了极大地提升，同时双方“武器库”也在不断升级。2017年秋天，蓝军团队在成立后的两个月内，自主研发了字节码级别的故障注入系统Awatch，这个武器的厉害之处在于可以实时地对运行中的业务系统进行任意链路的编织侵入。这对于对于技术蓝军以及整个红蓝攻防体系，具有里程碑式的意义。蓝军研发出了厉害的武器，红军也没闲着。与此同时，技术红军的防控体系建设也在如火如荼地进行着，实时核对平台横空而出。该平台能够做到稳定的分钟级核对异常发现能力，在某些场景下可以做到秒级发现，并且平台提供了业务快速接入的能力；红军还在实时核对平台的基础之上，升级演化出一套智能核对平台(内部代号四道防线)，引入AI技术自动识别业务问题，目前这套防线已经覆盖蚂蚁80%以上的业务。另外，各个业务域针对自身业务的一些特殊性，也研发了相应的核对系统。尽管蓝军制造故障的能力有很大的提高，但大部分的故障场景主要是各个业务方提供的，只有极少数是蓝军人工梳理业务或者分析代码产出。此时，蓝军团队认为，日常演练常态化，在故障场景发现方面不能再依赖业务，必须建立自主发现故障场景的能力。2018年3月，蓝军推出故障场景挖掘平台，基于Awatch探针探测应用内数据流，以此进行“弱点挖掘”。这套弱点挖掘体系，能够自动发现故障场景，最高能够在5分钟内产生500+的故障场景，红蓝攻防的日常演练的最为重要一块拼图终于完成！然而新的问题来了。蓝军的故障挖掘平台能力毋庸置疑，但有攻击就需要应急，高频攻防实施亦会给红军带来大量的人力消耗。持续应急压力驱动，红军开展““故障自愈”架构体系升级及能力建设，以效能为目标，结合仿真，红蓝军一起研发了“无损”攻防体系，并且推出与之匹配的度量平台，自动度量攻防结果，数据可视化。目前，常态红蓝技术对抗保持每周200+个故障场景的节奏在持续运作。常态化的红蓝“互怼”在线、实时、随地、无差别……这是支付宝技术蓝军实施攻击行为的几大标签。2017年年底的红蓝技术攻防周，技术蓝军发起攻击，但由于故障组件一处隐藏bug导致故障命中数量远远大于预期，给红军增添了不少麻烦，业务线的技术同学投入大量的人力和资源进行善后。此情此景之下，红军方面不仅没有抱怨，反而给予蓝军鼓励，“这次预期外的故障攻击是最真实的应急锻炼！”2018年年中的一次红蓝技术攻防中，蓝军在周末发起突袭，而刚好红军的相关同学正在举办婚礼。于是，一群程序员赶紧拿出吃饭的家伙，噼里啪啦敲着键盘进行应急，那画面简直不要太美了。还是在2018年的一次对抗中，红军祭出了“尖端武器”——自适应防灾、防抖等，这让蓝军吃尽苦头，几乎每次攻击都无功而返。挫败感飙升的蓝军最终放出大招，让红军接受了非常猛烈的炮火洗礼。有意思的是，似乎蓝军攻击得越欢，红军的同学越高兴……虽然看上去很受虐，但却没毛病，因为蓝军攻击得越狠越深入，被挖掘和发现出来的技术风险就会越确定，防御系统的能力也会因此而得到提升。令人震惊的是，为了防止蓝军的“袭击”，红军除了在防御系统方面下十足的功夫，每年期中和期末的红蓝技术攻防演练，红军都要举办一个仪式——那就是拜关公，除了叩拜，还得给驱邪镇恶的关公献礼，礼品包括旺仔牛奶、格子衬衫、键盘、香烟等。风险防控技术全面开放蚂蚁金服技术风险部门经过不断地升级，并将红蓝技术攻防演练形成常态化。除了每周进行全栈级别的演练，每年还会举行规模极大的“期中考试”和“期末考试”。这意味着，支付宝的风险防控体系持续地经受打磨与锤炼。目前，支付宝的“红蓝对抗”演练已经沉淀出一整套成熟的风险防控体系，通过仿真环境模拟天灾人祸，去考验技术架构的健壮性及技术人员的应急能力，从而全面地提升系统稳定，实现系统的高可靠性和高可用性。所谓的天灾和人祸。天灾指的是，当出现台风、断网、火情等极端异常情况的时候，系统如何快速应对。这有点类似于今年杭州云栖ATEC大会上，蚂蚁金服副CTO胡喜现场演练的异常断网情况下，“三地五中心”自动切换，保证支付服务不中断。人祸则是指因技术人员操作失误引发故障后，系统如何快速应。在蚂蚁金融科技官网（https://tech.antfin.com/）上可以看到，这些技术风险相关的能力已经对外开放，目前共有3款产品，包括容灾应急平台、全链路压测和资金安全监控；另外，还有3款产品，变更管控、巡检平台和黑屏运维管控即将上线对外开放。本文作者：平生栗子阅读原文本文为云栖社区原创内容，未经允许不得转载。

小蚂蚁说：《支付宝客户端架构解析》系列将从支付宝客户端的架构设计方案入手，细分拆解客户端在“容器化框架设计”、“网络优化”、“性能启动优化”、“自动化日志收集”、“RPC 组件设计”、“移动应用监控、诊断、定位”等具体实现，带领大家进一步了解支付宝在客户端架构上的迭代与优化历程。本节将结合禾兮在 OSChina 珠海站现场的分享《移动端分析方案在蚂蚁金服 mPaaS 中的实践》，介绍支付宝客户端自动化日志收集与分析的具体思路。内容将分成三个部分展开：支付宝客户端分析方案的探索；MAS 移动分析框架浅析；mPaaS 技术架构与助力。支付宝客户端分析方案的探索正如我们在《开篇 | 模块化与解耦式开发在蚂蚁金服 mPaaS 深度实践探讨》已经对支付宝的架构演变与开发团队规模发展做过介绍：截止目前，在研发上面，支付宝仅 Android、iOS 客户端开发人员近千人，客户端代码行数超过了数百万行，按业务划分的工程数也已近千个，每个工程都有独立的开发 owner 负责某一个具体的模块。虽然工程师团队及工程量越发庞大，支付宝依旧能够做到日发布的频率以确保业务快速迭代，同时在业务功能日益复杂的环境，保证 App 闪退率仅 0.01%。那么，在如此大体量的用户规模和研发团队下，支付宝又是如何确保用户使用过程中的用户体验呢？我们主要从以下两个维度衡量客户端用户体验：静态：指应用开发过程中，关注 App 本身的安装包大小、存储、涉及到的用户隐私权限、安全策略等，决定用户是否愿意安装并使用你的应用。动态：指应用发布上线后，用户在使用过程中，App 的启动速度，闪退、卡死卡顿等稳定性数据，网络请求，内存以及电量流量等用户实际的使用感受。启动应用是用户使用任何一款应用最必不可少的操作，从点击 App 图标到首页展示，整个启动过程的性能，严重影响着用户的体验。支付宝客户端作为一个超级 App，启动速度当然是我们关注的重要指标之一。支付宝对于应用启动过程中的优化，主要分为以下四个方面：框架治理：梳理启动流程并重构，遵守启动过程中按需加载原则。引用 Pipeline 机制，根据业务优先级规定业务初始化时机。制定统一的开发规范，尽量降低业务方流程对启动性能的影响。业务治理：按需加载，延时执行。线程治理：统一管理已有线程，并调整线程优先级。I/O 治理：关注主线程 I/O，优化合并频繁读写的 I/O 操作，尽量使用统一存储。技术突破：防止启动过程中的 UI 重刷操作。虚拟机优化，包括 JIT 关闭，降低 GC 次数。基础模块调优，分析主线程耗时操作并优化。另外，用户使用过程中 App 的内存、存储、电量及流量等消耗，也是重要的衡量指标。具体的优化点如下：内存：内存分析：memtrace hprof 线下内存分析，遍历对象，根据生命周期标记内存泄露，同时根据 object 创建引用确定业务归属。Native 内存：图像库切换到 native 层，4.x bitmap 像素数据放到 ashme 共享内存，降低 GC。内存优化：对象池复用，减小 bitmap 对内存占用，使用更小的图，尤其注意三方 H5 页面。存储：存储分析：查看应用存储大小。存储优化：使用共享库，业务定向优化，压缩存储等。流量：耗流量原因：分析各种网络请求。流量异常捕获：hook 所有网络请求，根据host聚合流量，超过阈值确定异常。流量优化：PC 底层协议优化，资源增量按需下载，同时通过切面信息调用方。电量：耗电原因：监控 CPU 使用率，各种 sensor、gps、weaklock、网络连接等耗电操作。耗电异常捕获：遍历线程，获取所有线程运行时间，与主线程比较确定异常。耗电优化：高性能 dump 线程栈优化，通过线程映射调用方，评估调用逻辑进行优化。针对以上每个优化点，支付宝都投入了大量精力进行研究和实践，有关启动性能优化的详细内容可以查阅文档《支付宝客户端架构解析：iOS 客户端启动性能优化初探》和《支付宝客户端架构解析：Android 客户端启动速度优化之「垃圾回收」》，其他优化点请持续关注“客户端架构解析”系列文章。基于这些对用户体验优化的内容，支付宝构建了一套完整的超级 App 线上运维体系，实时监控线上 App 发生的异常问题，针对这些问题，以最快的时间定位问题原因并找到对应的解决方案，最后通过动态热修复的技术及时修复线上问题，最终形成一个线上质量保障的闭环，保障应用运行的稳定性。MAS移动分析框架浅析接下来，详细介绍超级 App 运维体系中的移动监控框架具体是如何实现的。移动分析 MAS（Mobile Analysis Service）通过对移动客户端、H5、小程序、PC等多端埋点数据的采集与分析，实现产品核心指标监控，提供页面、设备、留存、性能等基础分析，并支持自定义事件分析、漏斗分析等高阶分析，帮助企业更好地完成业务监控、用户洞察与行为分析，指导产品迭代，精细化产品运营，辅助营销决策，加速业务商业化。主要分为以下四个阶段：整个移动分析的完整链路从左往右看，就是客户端通过调用埋点 SDK 的接口进行数据埋点，埋点 SDK 对日志进行格式化后，先写入客户端本地文件，满足日志上报触发条件后，将本地日志上报到日志服务器并清理本地日志文件以减少存储大小；日志服务器接收到客户端上报的日志后同步到计算平台，经过离线计算和实时计算后，将结果进行展示，用来监控、分析、搜索、推荐等。接下来我们将从移动分析框架的四个阶段，详细介绍数据分析的整个链路逻辑。数据采集根据采集数据时机、应用场景，最终用途的不同，我们把客户端采集的数据分为了以下几类。其中结合 mPaaS 模块化开发框架，报活埋点、押后台埋点、页面自动化埋点、性能埋点及 H5 埋点，由客户端 SDK 自动采集，无需开发者手动调用接口实现，开发者只需要关注自己的业务逻辑，在需要监控的逻辑除埋点统计。为了降低频繁上报日志对应用性能的影响，客户端采集到数据后，会预先保存在应用本地，通过以下三种方式同步到日志服务器：自动上报：满足一定条件后客户端埋点 SDK 自动上报，包括程序每次冷启动都会触发检查日志上报的逻辑。程序进入后台会立即触发上报。写日志时，某种类型的日志默认到达 40 条就触发上报。实时监控：对于比较重要的客户端日志，如异常、应用闪退日志等，可实时上报，产生一条上报一条，便于后台实时监控。动态控制：在自动上报的基础上，通过服务端下发的开关值，修改客户端日志写入和日志上报触发的条件。如在大流量并发的情况下，为减少日志服务器的压力，控制客户端只写入并上报异常或闪退日志，忽略行为日志的统计。数据计算上报到日志服务器的日志，会同步到计算平台进行计算，后台主要包含以下几个系统：mdap：日志采集网关，负责收集客户端埋点日志，收到日志后，直接传输至 JStorm 集群进行计算。JStorm：实时计算引擎，根据处理规则对日志进行实时解析并将需要的数据存储入库。SSDB： kv 数据存储层，底层使用 leveldb，支持单表十亿级记录。ZooKeeper：集群管理、组件间服务发现。数据应用计算平台计算出来的结果，可以为用户提供用户分析、事件分析、行为、性能等数据分析服务。基础分析：关注于 App 的通用分析，包括每日登录用户、新增用户、使用时长、用户留存、页面分析、访问路径等基础分析。高阶分析：用于 App 专注业务的特定分析需求，提供一种灵活的多维分析能力；提供热修复报告，帮助您了解 RPC、修复、回滚相关信息等。性能分析：提供闪退、卡死、卡顿的统计功能。当客户端发生性能问题后，移动分析服务提供实时查看性能分析的统计数据。日志管理：支持按关键字实时搜索查询日志，或通过服务端开关实时控制客户端日志上报逻辑。数据决策在上一步数据应用的基础上，可以与大数据、营销平台及推送平台结合，根据移动分析得到的埋点数据，通过大数据平台进行打标、圈人、用户画像及建模后，可以在营销平台上发起一次营销活动，指定活动的类型，活动算法，参与人群及活动奖品，通过消息推送、数据同步，动态发布等形式，触达到客户端，实现客户端拉新促活、活动推广及操作引导的目的。同时结合运营活动的场景需求，形成了一套完整的数字化运营体系，监控一次运营活动的参与人数、活动发放率、核销率等，观察活动的有效性。mPaaS 技术架构与助力上面介绍的支付宝内移动端分析方案的技术积累和架构实践，已经通过 mPaaS 移动开发平台作为蚂蚁金服金融科技的一部分对外开放。mPaaS(Mobile Platform As A Service)，源于支付宝 App 的移动开发平台，为移动开发、测试、运营及运维提供云到端的一站式解决方案，能有效降低技术门槛、减少研发成本、提升开发效率，协助企业快速搭建稳定高质量的移动 App。在 mPaaS 移动开放平台上，我们将移动分析框架中的本地日志、埋点、自动化埋点、性能监控、Crash报告、诊断日志等模块，作为一个个独立的组件来进行输出。任何一个 App 都可以通过 mPaaS 插件，添加对应的组件，在当前应用中集成这些功能，只需要这样简单的操作，就可以让你的应用具有和支付宝一样强大的移动端分析监控能力。客户端集成了这些移动分析相关的组件后，用户在使用APP过程中会产生相应的日志，经过数据采集、数据上报、数据计算等处理后，计算的结果会同步到 mPaaS 移动分析的大盘上展示，包括应用的基础应用概况、性能稳定数据、流量走向等等，方便开发者实时监控 APP 的概况大盘和稳定性等，实时发现线上问题并修复。目前，mPaaS 移动开发平台已经服务了众多企业，包括蚂蚁金服内部的香港支付宝、网商银行、口碑商家等，同时还有大量的外部蚂蚁生态合作伙伴，包括12306、上海地铁、广州地铁、广发银行等。秉承着「给世界带来小而美的变化」的理念，我们通过 mPaaS 帮助 12306 这样的国民级 App 重构了客户端，使得大家可以用上一个好的体验的 App 进行出行购票，用 mPaaS 这样成熟的底层框架搭建一个 12306 仅需要 2-3 个月的时间。除了 12306 还有支付宝香港版，广发银行手机银行和发现精彩多个客户端，同样在短短几个月的时间内便完成了业务重构。蚂蚁金服ATEC城市峰会·上海2019年1月4日，一场金融科技的前沿探索之旅——蚂蚁金服ATEC科技大会即将起航，你准备好了吗？小蚂蚁为大家准备了满满了攻略福利，等你来拿！了解蚂蚁金服ATEC科技大会更多信息，记得持续关注小蚂蚁（官微：蚂蚁金服科技）蚂蚁金服金融科技官网：https://tech.antfin.com/artic…ATEC科技大会：蚂蚁金服ATEC（Ant Technology Exploration Conference）科技大会是蚂蚁金服在中国举办的最大的技术盛会，旨在向遍布全球的合作伙伴与技术专业人群分享新技术的发展趋势与落地实践，通过对先进的前沿技术探索与讨论，为世界带来平等的机会。ATEC大会一直在路上。过去一年，蚂蚁金服ATEC科技大会走过杭州、硅谷、新加坡、伦敦等全球金融科技中心城市，之后将会造访国内各个金融科技中心城市，与当地受众分享蚂蚁金服对金融科技最前沿的洞察。ATEC科技大会报名方式 & 福利：本次大会门票采用审核制。嘉宾填写个人信息进行报名，报名后3天之内收到报名审核成功的短信，即为报名成功。大会报名截止日期为2018年12月31日24时，额满即止。前50位报名嘉宾将会优先审核通过，先到先得哦~小蚂蚁还为大家准备了本账号读者的专属福利邀请码： SF2B3A 还等什么，赶紧点击下方报名链接，小蚂蚁期待你的到来ATEC报名链接：https://alipaytech.mikecrm.co… 本文作者：平生栗子阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

摘要： 支付宝从最开始的工具型应用，逐渐发展成平台型应用，一直到现在，已经成为了一个超级 App。本文将带领大家进一步了解支付宝在动态化方案的探索以及 Nebula 框架。小蚂蚁说：此前分享的《模块化与解耦式开发在蚂蚁金服mPaaS深度实践探讨》（想要了解更多相关内容，欢迎关注公众号：mPaaS )已经对支付宝在移动端开发架构的设计思路有了初步了解。本文将结合在 iWeb 武汉站的分享，带领大家进一步了解 mPaaS 在移动端动态化方案设计。分享内容将分为以下三个方面：支付宝动态化方案的探索；Nebula 框架浅析；mPaaS 科技赋能支付宝动态化方案的探索任何一种技术方案都是在业务的发展和架构的演化中逐渐探索出来的，因此我们来看一下支付宝架构的演进： 支付宝从最开始的工具型应用，逐渐发展成平台型应用，一直到现在，已经成为了一个超级 App，它拥有多应用的生态，更加开放和动态化，并且保持着高可用，高性能，高灵敏的强大特性。随着 App 的逐渐庞大，整个应用的架构也在进行不断的调整，来适应各种特性。现在的支付宝客户端的架构如图所示： 整体架构分为五层：容器层、组件层、框架层、服务层、应用层。客户端整体采用统一的框架开发，模块化的开发模式，完全插件式的容器，支持模块独立发布，方便大规模团队的并行开发。在这样的框架结构中，同样包括了我们的动态化方案。支付宝中的动态化方案主要有两种框架：Nebula 和小程序。这两种方案不仅解决了需求迭代速度和发版周期之间的矛盾、跨平台开发、实时发布等一些普适问题，而且有效地保证了发布质量，对线上问题进行紧急止血，同时也有助于建立良好的开放生态。Nebula 是支付宝移动端 Hybrid 解决方案，它提供了良好的外部扩展功能，拥有功能插件化、事件机制、JSApi 定制和 H5App 推送更新管理能力。主要功能包括：接入 H5App 后台，方便管理离线或者在线 H5App，实现 H5 应用的推送、更新。加载 H5 页面，并按照 Session 的概念进行管理各个页面。Android 使用 UCWebView，拥有解决系统级 Webview Crash 的能力，内存管理更合理，网络加载提升更快，兼容性更好。彻底告别了在Android下兼容不同 Webview 的问题。支持自定义网络库，自定义网络通道；支持自定义键盘，自定义 Native View替换 H5 标签。提供丰富的内置 JSAPI，实现譬如页面 push、pop，标题设置等功能；支持用户自定义 JSAPI 和插件功能，扩展业务需求。自带埋点功能，接入 H5 监控平台，能够实时看到页面加载的性能、错误报警和监控。还有一种动态化方案就是支付宝小程序：支付宝小程序是一种全新的开发模式，融合了 H5 的易开发性、跨平台性、Native 性能，让开发者可以快速开发高性能的页面，提供优异的用户体验。通过使用支付宝小程序，开发者为支付宝开发了大量优质的小程序，丰富了支付宝生态能力。小程序开放给开发者更多的 JSAPI 和 OpenAPI 能力，通过小程序可以为用户提供多样化便捷服务。Nebula框架浅析Nebula 的架构如图所示，从上至下依次为 H5 应用层、服务层、原生框架层：H5 应用层：基于 HTML 和 JavaScript 技术开发，在 H5 容器上运行的手机应用，它拥有跨平台的特性，配合离线包的使用可以完成实时热修复的功能。 服务层：为开发者提供了高阶语言的 API 来使用手机系统资源，包括：视窗系统，开发者可以使用它来创造应用 UI，包括文字，图片，按键及定制 View资源管理，通过它开发者可以方便的访问如多语言文字，图片和布局等非代码资源应用生命周期管理，它决定应用在手机系统里的开始，结束以及强制关闭的时机H5 容器原生框架层：是手机系统的基础层，它提供了标准 API 来让高阶语言（比如 Java 和 Object-C）使用底层的硬件，并包含了许多为硬件访问的专有软件库。当上层调用某个框架 API 来访问硬件时，手机系统将加载相应的软件库。整个 Nebula 框架的核心部分就是 H5 容器，下面看一下 H5 容器的结构：H5Service，H5Session 和 H5Page都是从 H5CoreNode 类扩展而来，以 H5Service 为根节点，它与其他类一同形成了树状结构构成了页面流程和导航。在一般情况下，H5Pages 是 H5Session 的子节点，而 H5Sessions 是 H5Service 的子节点，在任何情况下只有一个 H5Service 根节点存在。H5Service：是 Nebula 里维护 H5 应用全局状态的基础类， 在 H5 应用的生命周期内只有一个 H5Service 的单例全局实例，H5Service 可以进行的操作包括：创建且打开一个新的 Web activity创建且开启一个新的 Web page从共享空间存储和读取数据注册插件和 Provider监听应用的生命周期H5Session：一个 H5Session 是由一叠 H5Pages 组成的完整业务流程。例如一个收银台的流程包括：一个购物车的小结页面，一个结账方式的选择页面，和最后一个结账确认页面。所有的页面都可以独立存在运作， H5Session 在其中的作用是把这些页面组织起立，按照业务逻辑把它们按序排列来完成业务。当你使用 H5Service 创建且开启一个新的 Web page 时，如果当前没有 H5Session 的话，一个新的 H5Session 实例将被创建，并为后续创建的 Web page 共享。你可以从 H5Session 中移除页面直到页面叠为空，也可以使用 H5Session 所提供的方法来获取首页，以及监听该 H5Session 的生命周期。 H5Page：是用户看得见，摸得着的页面，也是应用生命周期中最重要的一部分。你可以通过 URL 来加载内容，用 H5Param 来定制页面的外观和行为，甚至可以通过获取 H5Page 的视图层次，把 H5Page 视图和其他原生 UI 部件一起内嵌到同一个布局中。下面是 H5 容器的几个重要组成部分：API 管理器主要管理 JS API：Nebula 中已经提供许多内置的 JS API 供开发者使用，比如操控 UI，显示对话框和 Toast，以及使用网络 RCP 服务等。插件管理器主要管理 Plugin：如果现有的 JS API 无法满足你的业务需求，你也可以选择创造一个新的插件。你只需把原生代码打包在插件中，在管理器里注册该插件，便可在 Javascript 层使用新的 JS API 了JS Bridge 是连接原生层和 Javascript 的沟通桥梁：它将 Javascript 代码转译成能在系统框架运行的字节码，同时也把原生层的数据结构转成 Javascript 对象使其能在 Javascript 层处理。这里 Nebula 针对JS Bridge 做了一些优化：在 Android 里，js 调用 native 的通讯是通过 console.log 的方式，这个和其他容器实现不一样，其他容器一般通过 prompt 的方式来实现的，但是使用 prompt 的方式，有两个弊端：使用 prompt 会阻断整个浏览器的进程，如果 native 处理时间一长，会导致页面假死。prompt 是在 UI 层面上会弹出一个模态窗口，在 native 没有对其进行捕获处理的话，会造成一个问题。一旦这个页面放在非此容器的环境下，就会出现一个很诡异的 prompt 弹窗。在支付宝内，曾经出现过这个问题，天猫页面在支付宝 app 里的时候，由于容器机制不同，页面中 bridge 脚本没有判断环境，导致页面中 js 调用 API 的时候，在页面上出现了 prompt 的模态对话框，严重影响了用户体验，但是如果使用 console.log 的话，就不会出现这个问题。console 的方式避免了不兼容环境的体验问题和同时也避免了页面的假死。jsbridge 注入的时机，由于业务逻辑要依赖 bridge，所以业务的所有逻辑都会在 bridge ready 之后才会触发，而 bridge js 本身运行是要一定的时间的，因此注入的时机对于性能的影响显得非常的重要。但由于 H5 页面的生命周期和容器的生命周期是相互独立的，因此在 H5 生命周期的哪个阶段注入这段 bridgejs，对于性能的影响就显得异常重要。现在在支付宝内使用的方式为监听 H5 生活周期的事件，比如说当 Webview 设置 title 结束之后，Android 会放出一个 onReceivedTitle、shouldInterceptRequest 等事件，iOS 会尝试在 webViewDidStartLoad 事件，在监听到这些事件之后，立即注入 bridgejs，让其在 H5 生命周期尽早运行。通过这种方式的注入，经过测试，最早能在页面加载开始后， 50ms 以内就能成功注入 bridgejs。Event 机制：Nebula 提供了一套事件机制来管理事件在 H5Page，H5Session 和 H5Service 之间的流通顺序。一个 H5Event 可以在 H5Page, H5Session 或 H5Service 任何一层发生，事件派遣分为两步完成事件拦截。这个步骤中事件派遣的顺序为 H5Service -> H5Session or H5Page。事件可以在任何节点被拦截 （如果 interceptEvent() 返回 true ），也可以在任何节点被处理 （如果 handleEvent() 返回 true ）：如果事件在派遣过程中被拦截或处理，该事件将被视为已被消费且不再继续流通。如果在派遣过程后事件依旧没有被拦截或处理，会有错误抛给呼叫方处理。仅仅使用传统的 H5 技术展示在线页面，很容易受到网络环境影响，因而降低 H5 页面的性能。在 Neblua 中我们使用离线包技术来解决这个问题。离线包是将包括 HTML、Javascript、CSS 等页面内静态资源打包到一个压缩包内，它的目录结构如图所示：使用离线包可以使容器内的 H5 应用具有接近 Native 的体验，主要优势如下：减少网络环境对 H5 应用的影响：通过下载离线包到本地，然后在客户端打开，把打开H5页面的操作从网络 IO，变成磁盘 IO。直接从本地加载离线包，不仅最大程度地摆脱网络环境对 H5 页面的影响，而且增强了用户体验。提升用户打开 H5 应用的体验：通过离线包的方式把页面内静态资源嵌入到应用中并发布，当用户第一次开启应用的时候，就无需依赖网络环境下载该资源，而是马上开始使用该应用。实现动态更新：在推出新版本或是紧急发布的时候，您可以把修改的资源放入离线包，通过更新配置让应用自动下载更新。因此，您无需通过应用商店审核，就能让用户及早接收更新。下面介绍一下离线包的渲染过程当 H5 容器发出资源请求时，其访问本地资源或线上资源所使用的 URL 是一致的。H5 容器会先截获该请求，截获请求后，发生如下情况：如果本地有资源可以满足该请求的话，H5 容器会使用本地资源。如果没有可以满足请求的本地资源，H5 容器会使用线上资源。因此，无论资源是在本地或者是线上，WebView 都是无感知的。离线包的下载依赖用户当前的网络。一般情况下，只有在连接 WIFI 的情况下才会在后台下载离线包。如果用户处于移动网络下，不会在后台下载离线包。如果当前用户点击 APP，离线包没有下载好，用户就要等待离线包下载好才能用。为了解决离线包不可用的场景，fallback 技术应运而生。每个离线包发布的时候，都会同步在 CDN 发布一个对应的线上版本，目录结构和离线包结构一致。fallback 地址会随离线包信息下发到本地。在离线包没有下载好的场景下，客户端会拦截页面请求，转向对应的 CDN 地址， 实现在线页面和离线页面随时切换。那么本地资源如何寻址呢，我们设计了独特的虚拟域名机制，仅对离线应用有效。当页面保存在客户端之后，WebView 如果要访问的话，是通过 file schema 来从本地加载访问的。然而，用户就能在地址栏里直接看到 file 的路径，这就会导致以下问题：用户体验问题：当用户看到了 file 地址，会对暴露的地址产生不安全感和不自在。安全性问题：由于 file 协议上直接带上了本地路径，任何用户都可以看到这个文件所在的文件路径，会存在一定的安全隐患。基于如上问题的考虑，采用虚拟域名的机制而不直接使用 file 路径来访问。虚拟域名是一个符合 URL Scheme 规范的 HTTPS 域名地址，例如 https://xxxxxxx.h5app.example…Nebula 里面的 H5 容器和离线包，在传统的 Hybrid 框架的基础上进行了极致的优化，使整个 H5 应用具有如下特点：对网络链路强依赖的弱化增强对设备能力的支持增强的用户体验在性能方面，Nebula 在支付宝中经过了亿级用户的考验，crash 和 anr 以及其他稳定性指标有保障。Android 平台基于 UCWebview 深度定制，crash 率和 anr 量远低于系统webview，拥有解决系统 Webview 问题的能力。图中展示的就是在 Android 端，UCWebview 和系统 Webview 之间崩溃率和 ANR 率的对比，稳定性的优势显而易见。最后看一下小程序与 Nebula支付宝小程序复用 Nebula 容器技术栈，重构了开发方式，对外暴露有限个 jsapi 接口，让 app 开发更简单，更加便捷利用支付宝的能力，进而发布、推广、运营。小程序本质上是也是一个 H5 App 离线包，但是有一些自己的特点。小程序是为第三方 App 服务的，运行在独立进程，它的稳定和闪退不会影响到主 App，也支持二方 App 运行在主进程。小程序是支持保活的，极大的提升二次打开的体验。mPaaS技术架构与助力Nebula 有这么大优势，现在不仅在蚂蚁金服内部使用，也能够提供给外部来使用。首先什么是 mPaaS 呢，mPaaS 全称是 Mobile Platform as a Service 。是蚂蚁金服独创的移动研发平台，它源于支付宝 App 近 10 年的移动技术实践和思考，为移动开发、测试、运营及运维提供云到端的一站式解决方案，能有效降低技术门槛、减少研发成本、提升开发效率，协助生态伙伴快速搭建稳定高质量的移动 App。在 mPaaS 中，我们将 Nebula 的 H5 容器、jsapi 、离线包、小程序这些模块作为一个单独的组件来进行输出，在客户端中进行配置。任何一个 App 通过 mPaaS 插件，添加对应的模块，集成这些功能，只需要这样简单的操作，就可以让你的应用具有和支付宝一样强大的动态化能力。 同时 mPaaS 提供的小程序模块，允许用户把运行在支付宝上的小程序，无缝的迁移到自己的 App 中，做到【跨平台跨应用】开发，提高代码的复用能力Nebula 组件化输出，配合 mPaaS 提供的 MDS （移动发布服务） 来实现动态更新。mPaaS 提供的 MDS 服务，能够让每次发布更新就像发邮件一样简单。MDS 具有智能灰度发布的能力，可以通过内部灰度，外部灰度多重验证，保证在正式发布之前，发布的产品质量有充分的保证，同时提供多种升级策略，包括指定人群地域、机型，系统版本，网络环境等多种规则。对于离线包来说，更新离线包的下载对网络环境要求较高，包的大小越大，更新的成功率越低，在 mPaaS 中，我们采用增量差分的更新能力，减少数据冗余及设备带宽，在移动网络条件下优势明显。同时保证更新功能的高可用性，升级接口可用率达 99.99%，在线分钟级触达。下面是 Nebula 的生态基础，首先在集团内部，我们已经支持了不少产品，同时通过 mPaaS ，我们也与外部客户合作，将我们的技术能力输出给他们，典型的几个案例，包括 12306 客户端，广发发现精彩客户端，上海地铁，苏州银行等。尤其是 12306，使用 mPaaS 改版之后，客户端整体的体验更加优越。12306 整个客户端绝大部分都是使用的 H5 技术，他们就是使用 Nebula H5 容器 配合离线包来实现，无论是页面打开速度，还是UI事件响应，体验几乎接近 native。在更新发布方面，12306 的 app 包很少更新，以 AppStore 上的发布记录来看，今年只提交了两个版本，基本上都是通过动态化的方式完成业务的迭代发布。总结下来，蚂蚁金服 mPaaS 中就是通过「Nebula H5容器 + 离线包 + 小程序 + MDS」这样的方式来实现移动端的动态化方案。本文作者：平生栗子阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...