热门标签 | HotTags
当前位置:  开发笔记 > 运维 > 正文

微信公众招商银行账号开发高级篇

招行经过一年多的发展,2014年已超过1500万粉丝,高居银行类微信公众号榜首,堪称最成功的微信公众账号案例。深圳云软作为招行信用卡微信平台的研发厂商,就微信公众账号开发的高级应用,总结了以下几点经验。
摘要:招行经过一年多的发展,2014年已超过1500万粉丝,高居银行类微信公众号榜首,堪称最成功的微信公众账号案例。深圳云软作为招行信用卡微信平台的研发厂商,就微信公众账号开发的高级应用,总结了以下几点经验。

2013年4月,招商银行信用卡微信公众账号以“小招”的亲民形象推出,不到半年时间即获得数百万用户的青睐,经过一年多的发展,截至目前已有超过1500万粉丝,高居银行类微信公众号榜首,堪称最成功的微信公众账号案例。深圳云软作为招行信用卡微信平台的研发厂商,就微信公众账号开发的高级应用,总结了以下几点经验。

规划要超前

大部分企业在规划时,抱着试试看的态度,投入不足,仅是因为领导说要做微信而做微信,并未做长远打算,导致浅尝即止。很多微信公众账号只是挂了个链接链到页面,做个微网站,没有深入考虑怎样通过良好的体验把企业的服务提供给客户。一个超前的规划,首先必须选好平台——具有稳定合理的架构,足够的业务灵活性和开放性,可以逐步叠加和发展业务,可以灵活调整体验,可以对接后端的各种系统资源等。

架构要合理

微信平台不是一个单纯的链接入口,它更是连接企业服务与用户之间的管道。因此微信平台需要有合理的架构设计,使平台能在不同的交互模式以及各种形态的服务资源之间灵活地进行切换,并保持良好的体验。总的来说,微信的交互包括:点击菜单的轻App体验、聊天窗口的消息交互、页面的交互三大类,其中消息交互又包括自动消息交互和人工消息交互。从长远的规划看,平台需要满足以下要求:

1. 高性能和高可用;

2. 容量的可扩展性;

3. 可监控、可管理;

4. 业务可扩展,可以灵活进行业务变更和加载;

5. 开放性,可由客户进行业务流程的二次开发,提供标准化的接口与第三方系统进行对接,包括接入多种IM渠道等。

我们很多客户都已在应用或规划全渠道接入,可以实现微信、微博、QQ、WebChat、邮件等多种模式。

平台架构上很多细节的设计,都是来自业务及运营的需求,如下所示。

1. 对并发量的要求,决定了接口设计的模式,采用异步、无状态、多线程的接口模式,才能满足超大并发量的处理,并且易于扩展。招行目前每天发出的消费提醒,就达到400万条,高峰期半个小时可达20多万条。

2. 对可靠性的要求,决定了缓存的持久化,保证了即使某个节点的程序宕机甚至物理故障,也不会丢失交易数据。我们早期的方案也存在缺陷,在特殊的情况下如果接口程序崩溃或者重启,就会使发送队列中的数据丢失。虽然量不大,但对银行业务却很重要,会导致用户的投诉。

3. 数据库性能对DB交易量的支持,以及对分布式架构的要求,决定了数据库中间层的存在。一个好的架构,不仅要支持单个数据库把性能发挥到极致,还要考虑服务器硬件如果出现瓶颈也能进行扩展,因为数据库由于计算能力、I/O吞吐、存储等多方面的原因,始终会在某个点达到无法超越的瓶颈,就像12306,当海量的用户请求在短时间内涌入时,会给系统带来极大的压力,整个系统的最后瓶颈往往就是数据库,解决的办法就是采用分布式解决方案。云软IMCC在架构上支持横向和纵向的扩展,理论上只要网络带宽许可,就可支撑无限容量。

4. 通信连接的效率,微信的协议是HTTP双向POST的协议,采用短连接方式。这种通信方式其实效率是很低,每次请求都需要建立连接、释放连接。对于单个服务节点,其性能远低于TCP长连接,协议的字节冗余也比较多,对传输带宽要求较高,但好处在于可以方便地通过多节点进行扩展,开发的难度也较低。随着计算机性能和网络带宽的提高,以前要按字节来节省的传输数据量已可被忽略,短连接方式以后会得到广泛的应用。虽然我们平台内部的通信采用TCP长连接,在百兆网络环境下最高可以达到每秒数万次的消息量,效率高很多,但缺点是对开发的要求比较高,需要处理很多网络异常事件,也不便于多节点扩展。

招行轻体验、重后台的体验设计

招行在微客服产品上的设计充分体现了“关注用户体验,重视服务细节”的用心服务理念。虽然招行在微信平台上实现了其传统客服和App上超过70%的业务服务功能,但在用户体验上你会觉得很清爽,很多功能你不用的时候都是躲在后面的,展示出来的只是最常用的功能,而一旦你需要,通过简单直接的操作,就能获得,正所谓呼之即来,挥之则去,不用的时候绝不占你眼球。比如你对小招说:“境外消费”,小招就能很快找到所对应的答案以及兑换手续费等相关问题。配合招行后来提供的语音识别功能,更是将操作简化到说到就能做到的程度。这种模式我们称为平铺模式,相对以往需要通过多级菜单、多次交互才能找到自己想要的功能,平铺模式可以做到所想即所得,特别对于微信这样的移动终端,展示的容量有限、操作输入不方便的情况下显得更加方便。

应用了很多跨界的方法来解决问题

在通信行业,流量控制是非常常见的,它可以阻挡系统能力以外的请求,不至于将系统弄垮,用户可能会得到“系统正忙”之类的提示,但在计算机和互联网行业,流控的概念还没有得到广泛应用。以微信为例,微信自己有提供对外的流控,超过一定频次就予以拒绝,却没有考虑外部系统的流控,当超过系统处理能力的请求涌入时,就只能丢弃,因此提供的是有损服务。对于有损服务,我们就需要采用缓存重发的机制来保障数据的有效送达,对日常聊天还没太大影响,但对一些要求严格的金融服务,就会造成客户投诉。

再比如我们参考了NGN中业务与承载分离的设计理念,把消息传输、会话控制与业务流程引擎分离,分层次的软件架构设计,不仅是满足业务灵活度的关键,也是进行软件架构扩展的核心。作为一个千万级用户的运营平台,在追求稳定服务的同时,还要能不断推出灵活的新业务,而不是每次业务发生变化都要去更新升级软件,甚至重启服务才能加载新的业务功能。招行所使用的云软IMCC平台,从设计之初就考虑了这点,通过将消息承载与业务流程分离,使基础平台变成与业务无关的底层平台,而各种业务流程则通过流程引擎进行解析,实现业务的动态加载。

微信、QQ等个人聊天软件,都是无状态的,用户可以不用管对方是否在线,不计较什么时候回复,但这给专业客服带来了很大麻烦。例如户可能发了一句话就走开了,但会话窗口就一直挂在那里,客服每天可能会接入数百个会话,如果一直占用,会使客服无法专注处理,后台的各种KPI考核也无法进行。因此,专业的人工客服应用场景,一定是有状态的会话,就像一通电话,有接入有挂断。但考虑到用户体验,我们也在研究是否有可能实现无状态会话的无缝兼容,即在用户侧感觉是无状态的,什么时候都可以发消息,但在客服侧处理称为有状态的,能保证会话效率和质检考核,这套系统目前还在研发中。

客观看待智能客服的应用

招行是微信智能机器人最成功的案例,虽然同是IMCC基础平台加小艾机器人,电信和联通在应用时效果却并不十分理想。原因在于,电信和联通的业务太过复杂,产品数千种,知识库数10万条,问题过于开放。而招行信用卡业务领域相对比较窄,而且投入了大量人力进行人工知识识别和添加,才使得小招招人喜爱。由于技术局限,智能机器人目前存在两个一直未能解决的问题:1. 自动学习能力;2. 真正的语义理解能力。如果有哪家公司能在这两方面有所突破,将会给智能机器人应用带来极为广阔的前景。

对实际应用而言,我们认为,如果坐席数量没有到达10人以上,那么应用智能机器人的投入和收益并不匹配,反而不如通过关键字应答等简单方法来。根据我们统计的招行微信数据,用户70%的操作是菜单操作,25%是5个字以内的短词,剩下的是与人工客服的对话。新研制的关键字匹配方法具备模糊匹配、最长匹配优先、自动分拣未命中等方法,已经可以在很大程度上替代智能机器人。

招行的安全措施

“安全”是金融类微信应用的基本要求,在保障安全性方面,招行采用专线接入的方式,保证了数据不在公网传输。最新消息显示,腾讯已在进行加密协议的研发测试,未来会使银行的信息安全更有保障。

其他安全方面采取的措施包括:应用HTTPS协议,页面传递参数加密防止中间人攻击,应用动态密码键盘防止黑客截获密码,后台安全策略等。除此之外,应用安全扫描工具对系统进行模拟攻击和漏洞扫描,也是必要的工作。

新高级接口应用

【群发的挑战】

招行已有1300万粉丝,群发一条消息到全量客户,将给系统带来极大的压力。腾讯的消息下发能力非常强,1000多万的消息只需要几个小时就可以全部送达,这些客户收到消息后必然会作出反应,简单的有查询余额、浏览页面,如果是互动式的活动,将会产生致命冲击,在微信没有提供高级群发接口之前,招行试过群发,基本上每次都导致系统的阻塞甚至宕机。因此,理想的群发模式,必须是流量可控,可按照目标用户清单进行精确定位的模式。即包含两种模式:1. 需要全量通知所有用户的,根据活动的性质(纯告知、互动);2. 根据客户群细分结果,按照目标用户清单进行定时定向发送。

腾讯提供的分组群发高级接口,限制是每天100次,每次1万条,也就是说每天最多100万(实际是99万),无法满足全量用户通知的需求,但又不能采用MP后台进行全量群发,这种情况就需要使用腾讯提供的分组功能,将用户分成多个批次。我们很多客户把这个分组功能与客户群分组搞混了,使用分组功能实现客户群细分。其实,客户群细分是经常变动的,不断通过接口同步腾讯的数据,既不合理也不科学,而应尽可能将客户群细分的工作放在企业一侧的CRM系统,通过客户标签的方法维护,才能保证基于CRM的精确营销得以实施。

【矩阵账号、分权分域管理和UnionID】

现在很多集团级企业都存在多账号的管理需求,但是由于微信OpenID只能跟一个公众账号对应,导致各个账号上积累的用户没办法统一管理。UnionID实现了多个账号之间相同用户关联,可以把分散在多个公众账号的用户统一识别、管理,既能体现子账号的个性化,又能将好友资源集中管理。

虽然招行平台可以支持多账号,每个账号单独管理,但并非账号开得越多越好。因为分权分域的管理,如果粒度过细,会给使用和管理带来过重负担,开发的工作量也相应加大。对于集团级的矩阵账号应用,我的建议是:子账号的粒度最小是城市,更小的粒度,如支行、分店等,建议通过参数二维码的方式进行客户渠道的区分识别,在后台标识出客户的归属,以便后续可以提供针对性的营销和服务。

以上就是微信公众招商银行账号开发高级篇 的详细内容,更多请关注其它相关文章!


推荐阅读
  • ArchSummit深圳2014将于7月18日拉开帷幕,所有讲师已确认,涵盖9个热门话题,共36场精彩报告。InfoQ中文站提供了详细的讲师和报告列表。 ... [详细]
  • 一面问题:MySQLRedisKafka线程算法mysql知道哪些存储引擎,它们的区别mysql索引在什么情况下会失效mysql在项目中的优化场景&# ... [详细]
  • mysql 分库分表策略_【数据库】分库分表策略
    关系型数据库本身比较容易成为系统瓶颈,单机存储容量、连接数、处理能力都有限。当单表的数据量达到1000W或100G以后,由于查询维度较多, ... [详细]
  • 深入探讨ASP.NET中的OAuth、JWT与OpenID Connect
    本文作为前文关于OAuth2.0和使用.NET实现OAuth身份验证的补充,详细阐述了OAuth与JWT及OpenID Connect之间的关系和差异,旨在提供更全面的理解。 ... [详细]
  • 免费获取:全面更新的Linux集群视频教程及配套资源
    本资源包含最新的Linux集群视频教程、详细的教学资料、实用的学习课件、完整的源代码及多种软件开发工具。百度网盘链接:https://pan.baidu.com/s/1roYoSM0jHqa3PrCfaaaqUQ,提取码:41py。关注我们的公众号,获取更多更新的技术教程。 ... [详细]
  • 收割机|篇幅_国内最牛逼的笔记,不接受反驳!!
    收割机|篇幅_国内最牛逼的笔记,不接受反驳!! ... [详细]
  • 自SQL Server 2005以来,微软的这款数据库产品逐渐崭露头角,成为企业级应用中的佼佼者。本文将探讨SQL Server 2008的革新之处及其对企业级数据库市场的影响。 ... [详细]
  • 58同城的Elasticsearch应用与平台构建实践
    本文由58同城高级架构师于伯伟分享,由陈树昌编辑整理,内容源自DataFunTalk。文章探讨了Elasticsearch作为分布式搜索和分析引擎的应用,特别是在58同城的实施案例,包括集群优化、典型应用实例及自动化平台建设等方面。 ... [详细]
  • 本文介绍了在一卡通项目中设计加密管理方案时,证书服务器的配置步骤及其在用户权限控制中的应用。首先概述了证书服务器的基本设置,包括操作系统的选择和证书服务的安装,随后详细描述了服务器证书及客户端证书的创建过程。 ... [详细]
  • 深入解析Spark核心架构与部署策略
    本文详细探讨了Spark的核心架构,包括其运行机制、任务调度和内存管理等方面,以及四种主要的部署模式:Standalone、Apache Mesos、Hadoop YARN和Kubernetes。通过本文,读者可以深入了解Spark的工作原理及其在不同环境下的部署方式。 ... [详细]
  • API网关作为微服务架构中的关键组件,扮演着系统与外部世界交互的唯一接口角色。它不仅封装了系统的内部复杂性,还为不同客户端提供了个性化的API接口。本文将探讨API网关的重要性及其核心功能。 ... [详细]
  • 本文详细介绍了如何配置Apache Flume与Spark Streaming,实现高效的数据传输。文中提供了两种集成方案,旨在帮助用户根据具体需求选择最合适的配置方法。 ... [详细]
  • 本文深入探讨了Redis中的两种主要持久化方式——RDB(Redis Database)和AOF(Append Only File),并详细解析了两者的实现机制、优缺点以及在实际应用中的选择策略。 ... [详细]
  • 本文深入探讨了服务器的主要作用,包括加速访问、增强安全性和绕过访问限制等,并详细介绍了如何正确配置代理服务器。 ... [详细]
  • 本文探讨了XSS攻击的基本原理及其防御方法,重点介绍了如何在前后端实施有效的安全措施来防止XSS攻击。 ... [详细]
author-avatar
大约在冬季1122_867
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有