以招行为例，微信公众账号开发高级篇

规划要超前

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

架构要合理

微信平台不是一个单纯的链接入口，它更是连接企业服务与用户之间的管道。因此微信平台需要有合理的架构设计，使平台能在不同的交互模式以及各种形态的服务资源之间灵活地进行切换，并保持良好的体验。总的来说，微信的交互包括：点击菜单的轻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平台，从设计之初就考虑了这点，通过将消息承载与业务流程分离，使基础平台变成与业务无关的底层平台，而各种业务流程则通过流程引擎进行解析，实现业务的动态加载。

招行平台的业务流程引擎设计工具，也参考了传统呼叫中心的可视化流程开发方法，将各种常用的流程处理组件封装，称为“元件”，使后期进行业务的二次开发效率得以大幅提升，并且降低了对开发人员的技能要求，只要稍有编程基础的开发人员就可以快速完成业务流程的定义和发布。而且这套引擎不是一个封闭的系统，通过自定义节点，我们可以调用外部系统接口，实现与其他系统的对接，并且可以调用自定义功能，具有很强的灵活性。

专业的多客服体系

招行微信平台最早的出发点就是建一个基于互联网渠道的在线客服平台。因此，在平台选型时首选已在中国电信集团IM客服上有了沉淀和积累的IMCC平台，于2010年建设的基于营销QQ的800010000平台已经有了5000万好友，上百台服务器的集群架构。IMCC有很多针对呼叫中心专业客服而设计的功能，所谓多客服，其实跟电话的呼叫中心很类似，用户从一个号码（电话、QQ、微信等）呼入，后台有一个呼叫中心团队来处理用户的聊天请求。因此系统需要有ACD服务器来实现不同的路由及排队策略，比如先来先服务、平均分配或者按比例分配、上次服务优先、VIP插队等。另外，呼叫中心团队要能按技能组进行排队和路由，比如咨询的是一组，VIP服务是另一组，还要允许一个工号有多种技能，可以作为不同技能队列的资源放到资源池排队。

专业的呼叫中心业务十分密集，在操作效率上要求很高，坐席在操作上要求尽可能减少低效的动作。例如重要消息置顶功能，可以避免重要的聊天信息在窗口滚动中难以查找，还有来话原因采集，只需要在采集树上简单点击，就可以完成。除此之外，为了提高话务员知识检索的效率，我们设置了在聊天消息中触发知识库自动检索的功能，只要维护得当，从用户的输入中就可直接触发检索出答案，大大降低了话务员的工作强度。

微信、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实现了多个账号之间相同用户关联，可以把分散在多个公众账号的用户统一识别、管理，既能体现子账号的个性化，又能将好友资源集中管理。

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

作者简介：黄榕振，深圳云软信息技术有限公司联合创始人兼技术副总裁。在一线带领团队开发了招商银行信用卡微信客服、民生银行微信客服、广东联通沃卡等应用。

本文选自程序员电子版2014年9月刊，该期更多文章请查看这里。2000年创刊至今所有文章目录请查看程序员封面秀。欢迎订阅程序员电子版（含iPad版、Android版、PDF版）。

本文为ImapBox原创文章，未经允许不得转载，如需转载请联系market#csdn.net(#换成@)