经过三个多月的开发，一个微信第三方应用逐渐成形，下一阶段进入测试和上线阶段。刚开始的一无所知，认为其很是高大上，到了现在回头看看，却也没见得有太复杂的东西，但是爬过的那一个个坎现在都记忆非常深刻，开发微信第三方应用，其主要分为两个部分，授权部分和业务部分，业务部分的调用过程都需要授权部分所拿到的授权令牌，那我慢慢讲述。
一、授权，在授权部分，微信每十分钟会推送授权信息到相应的接口当中，我们拿到数据后进行AES解密，得到ticket数据， 随着通过调用微信接口拿到componenttoken，这样反复取到数据又返回调用接口拿到新的授权数据，此流程在最后一步的时候会是拼接出一个url(由微信提供特定的格式url)，这个url会根据你传入的参数生成一个二维码供微信公众号的管理方进行扫码授权，当扫码通过后会跳转到我们在微信开放平台中配置的回调url，问题在于当时并不知道，这个url必须是在微信开放平台中配置的域名下，并且附加的code参数会在扫码之后在回调的url后面拼接出来传给我们，刚开始是计划在本工程总创建一个页面，将这个页面配置成url,但是始终没能达到预期效果，为此我请求多路大神，决定将回调的url写成接口，当扫码跳转之后我便通过在扫码跳转触发调用接口，在接口中解析处理http请求头，从head头中拿到相关信息。
二、业务（补仓，处理回调信息，退款，电子发票等，创建卡券和货架），为保证各部分稳定运行，我分建四个工程，callback工程处理回调、退款、电子发票业务功能，上架部分，wxmall工程负责补仓和向微信方通知数据更新业务功能，wxtoken工程负责授权数据的获取和更新。wxcreat工程负责微信的电子卡券创建和货架的创建及更新等操作。
卡券创建中，微信方提供的接口可以创建不同类型的电子卡券和货架获取cardid和pageid,这需要不同的品牌和商家进行自定义，比如卡券的卡号时候自定义，卡券显示内容，价格等信息，所以商家在正式上线之前需要提供详细的素材，此是为必胜客肯德基两个品牌开发的微信第三方应用，所以数据不可错乱。
授权，所有的业务流程都是基于授权令牌数据有效（每次授权数据有效时间2小时）的情况下，否则关于微信方的业务处理接口都将失效。所以这个工程的作用就是解析微信方的授权数据，判断现有的数据是否失效，如果即将失效则需要调用更新接口更新授权数据，这些授权数据需要被业务工程读取引用，在整个开发过程中，刚开始是使用文件的形式存储，每次业务调用接口都需要读取配置文件，这样在高并发情况下,cup读写过快，估计也扛不住，于是设计为分布式，这样文件只能设置为共享文件夹，让不同机器都可以读取文件，但是共享文件夹的稳定性并不好，有时候会从中读取不到数据，所以为了根本性解决这个问题，决定采用redis集群，将授权数据保存到redis中，通过redis进行授权数据共享(其实我想有一种更简单的方式：在数据库中创建表专门保存不同品牌的授权数据token，因为业务上是不停地在回调调用，我们只需设置读取授权数据的频率即可，不会对数据库造成压力，授权方只需将数据存到数据库中即可，还可以对其进行管理)
接收回调通知：此工程比较重要，必胜客肯德基用户较多（过亿的量），当用户在两个品牌公众号上做任何操作，此工程都能接收同调信息而不仅仅是支付的信息，所以必须设计为分布式（刚开始输出部分日志的时候简直不能看，刷的太快，，，，），为方便对账，需要将支付信息保存到数据库，在这一块如果直接将数据对数据库做操作将对数据库造成压力，所以通过使用activemq消息队列，设置先将信息放入activemq，在后台B2C处理程序中慢慢写入数据库并做激活操作，减缓了数据库压力。为此通过相关订单查到的信息我们必须在我们自己的库中进行保存存档，后来公司财务反映导入自身的支付码给微信具有安全不可控性，这对上上市公司会有要求，为此我们在保存数据的基础上再加上了激活动作，只有激活后用户才能够正常使用商品。当然在这还需要自定义微信页面去处理用户的申请退款请求和电子发票请求，申请退款调用接口信息并保存就好，而电子发票系统是自己后方的发票系统，速度略慢，需要做一定处理防止用户重复开发票等，这不多讲。
补仓工程，因为是自定义卡券码，需要我们自己调用微信接口传入卡券码数据，这些卡券码需要自己调用银商支付码，然后在自己的代码中将支付码对应唯一的品牌支付码传给微信，卡券数量有点多，特别是多品牌，如果是节日活动等等，补仓不及时会有客户反馈，需要使用定时调度，通过多线程去加快补仓的效率。这工程还有一个功能是调用微信方接口，在用户完成卡券消费的时候调用接口通知用户消费行为，后方系统给不负责直接对调微信服务器。
创建卡券和货架，在这一部分还要开发一套能兼容多个产品的兼容性代码上架产品其实可以通过main方法直接调用接口进行，其主要麻烦点在于json结构体太过复杂，难于拼接，并且在更新货架的时候需要带上所有产品参数，不然的话新上传的产品直接覆盖之前的产品，这一点我认为微信放需要对接口进行改进及其退货申请、发票申请一些简单的能够兼容多个产品的html5页面，其主要难点在于每个品牌令牌是不一样的并且在很短时间内会进行更新变化，而调用微信段接口都需要此令牌，难点在此。
这样回头看看所做的部分其实并没有太多困难的地方，但是在开发的时候还是会遇到很多问题，毕竟菜鸟一枚，作为几乎全是接口调用的一个部分，我认为和接口提供方做到充分沟通是很有必要的，并要有一份详细的接口文档，快速发现问题，这样才能够加速开发进程（最后补一句，微信提供的技术文档坑啊，各种不通，不更新，没提示）。