記微信第三方應用開發所遇到的坎

       通過三個多月的開發，一個微信第三方應用逐漸成形，下一階段進入測試和上線階段。剛開始的一無所知，認爲其非常高大上，到了如今回頭看看，卻也沒見得有太複雜的東西，可是爬過的那一個個坎如今都記憶很是深入，開發微信第三方應用，其主要分爲兩個部分，受權部分和業務部分，業務部分的調用過程都須要受權部分所拿到的受權令牌，那我慢慢講述。

       1、受權，在受權部分，微信每十分鐘會推送受權信息到相應的接口當中，咱們拿到數據後進行AES解密，獲得ticket數據，  隨着經過調用微信接口拿到componenttoken，這樣反覆取到數據又返回調用接口拿到新的受權數據，此流程在最後一步的時候會是拼接出一個url(由微信提供特定的格式url)，這個url會根據你傳入的參數生成一個二維碼供微信公衆號的管理方進行掃碼受權，當掃碼經過後會跳轉到咱們在微信開放平臺中配置的回調url，問題在於當時並不知道，這個url必須是在微信開放平臺中配置的域名下，而且附加的code參數會在掃碼以後在回調的url後面拼接出來傳給咱們，剛開始是計劃在本工程總建立一個頁面，將這個頁面配置成url,可是始終沒能達到預期效果，爲此我請求多路大神，決定將回調的url寫成接口，當掃碼跳轉以後我便經過在掃碼跳轉觸發調用接口，在接口中解析處理http請求頭，從head頭中拿到相關信息。

       2、業務（補倉，處理回調信息，退款，電子發票等，建立卡券和貨架），爲保證各部分穩定運行，我分建四個工程，callback工程處理回調、退款、電子發票業務功能，上架部分，wxmall工程負責補倉和向微信方通知數據更新業務功能，wxtoken工程負責受權數據的獲取和更新。wxcreat工程負責微信的電子卡券建立和貨架的建立及更新等操做。

      卡券建立中，微信方提供的接口能夠建立不一樣類型的電子卡券和貨架獲取cardid和pageid,這須要不一樣的品牌和商家進行自定義，好比卡券的卡號時候自定義，卡券顯示內容，價格等信息，因此商家在正式上線以前須要提供詳細的素材，此是爲必勝客肯德基兩個品牌開發的微信第三方應用，因此數據不可錯亂。

       受權，全部的業務流程都是基於受權令牌數據有效（每次受權數據有效時間2小時）的狀況下，不然關於微信方的業務處理接口都將失效。因此這個工程的做用就是解析微信方的受權數據，判斷現有的數據是否失效，若是即將失效則須要調用更新接口更新受權數據，這些受權數據須要被業務工程讀取引用，在整個開發過程當中，剛開始是使用文件的形式存儲，每次業務調用接口都須要讀取配置文件，這樣在高併發狀況下,cup讀寫過快，估計也扛不住，因而設計爲分佈式，這樣文件只能設置爲共享文件夾，讓不一樣機器均可以讀取文件，可是共享文件夾的穩定性並很差，有時候會從中讀取不到數據，因此爲了根本性解決這個問題，決定採用redis集羣，將受權數據保存到redis中，經過redis進行受權數據共享(其實我想有一種更簡單的方式：在數據庫中建立表專門保存不一樣品牌的受權數據token，由於業務上是不停地在回調調用，咱們只需設置讀取受權數據的頻率便可，不會對數據庫形成壓力，受權方只需將數據存到數據庫中便可，還能夠對其進行管理)

       接收回調通知：此工程比較重要，必勝客肯德基用戶較多（過億的量），當用戶在兩個品牌公衆號上作任何操做，此工程都能接收同調信息而不只僅是支付的信息，因此必須設計爲分佈式（剛開始輸出部分日誌的時候簡直不能看，刷的太快，，，，），爲方便對帳，須要將支付信息保存到數據庫，在這一塊若是直接將數據對數據庫作操做將對數據庫形成壓力，因此經過使用activemq消息隊列，設置先將信息放入activemq，在後臺B2C處理程序中慢慢寫入數據庫並作激活操做，減緩了數據庫壓力。爲此經過相關訂單查到的信息咱們必須在咱們本身的庫中進行保存存檔，後來公司財務反映導入自身的支付碼給微信具備安全不可控性，這對上上市公司會有要求，爲此咱們在保存數據的基礎上再加上了激活動做，只有激活後用戶纔可以正常使用商品。固然在這還須要自定義微信頁面去處理用戶的申請退款請求和電子發票請求，申請退款調用接口信息並保存就好，而電子發票系統是本身後方的發票系統，速度略慢，須要作必定處理防止用戶重複開發票等，這很少講。

       補倉工程，由於是自定義卡券碼，須要咱們本身調用微信接口傳入卡券碼數據，這些卡券碼須要本身調用銀商支付碼，而後在本身的代碼中將支付碼對應惟一的品牌支付碼傳給微信，卡券數量有點多，特別是多品牌，若是是節日活動等等，補倉不及時會有客戶反饋，須要使用定時調度，經過多線程去加快補倉的效率。這工程還有一個功能是調用微信方接口，在用戶完成卡券消費的時候調用接口通知用戶消費行爲，後方系統給不負責直接對調微信服務器。

       建立卡券和貨架，在這一部分還要開發一套能兼容多個產品的兼容性代碼上架產品其實能夠經過main方法直接調用接口進行，其主要麻煩點在於json結構體太過複雜，難於拼接，而且在更新貨架的時候須要帶上全部產品參數，否則的話新上傳的產品直接覆蓋以前的產品，這一點我認爲微信放須要對接口進行改進及其退貨申請、發票申請一些簡單的可以兼容多個產品的html5頁面，其主要難點在於每一個品牌令牌是不同的而且在很短期內會進行更新變化，而調用微信段接口都須要此令牌，難點在此。

       這樣回頭看看所作的部分其實並無太多困難的地方，可是在開發的時候仍是會遇到不少問題，畢竟菜鳥一枚，做爲幾乎全是接口調用的一個部分，我認爲和接口提供方作到充分溝通是頗有必要的，並要有一份詳細的接口文檔，快速發現問題，這樣纔可以加速開發進程（最後補一句，微信提供的技術文檔坑啊，各類不通，不更新，沒提示）。