釘釘ISV應用開發的一些心得

zephyr發表於2017-06-05

1. 背景

前段時間從前到後完整地做完了一個簡單的釘釘上的 ISV 應用 —— 猿活動。

最開始想做這麼一個小工具，是想到，平時部門中經常會組織一些分享活動，但是這些分享活動卻沒有一個比較直觀的“站點”來記錄一次又一次的，很多人的努力的付出，這是很可惜的事。同時，在做這些活動的時候，也缺少一些互動的手段，比如現場簽到，打賞什麼的。

好吧，剛開始的時候是這樣想的，當然，在做的過程中，也發現釘釘的基於“組織”的應用場景，在某些情況下限制挻大的（比如現場的互動，因為到現場的人並不一定是某個“企業”的成員），所以功能上也簡化了很多。（其實真相是隻有 3 個週末時間，只能先搞出目前這些簡單功能了）

中間在做的過程中碰到了另一個朋友，他有一些想法，並且自己也盡力做了很多工作，就差個程式設計師。我見功能很簡單（就是最簡單的文章呈現功能），就幫他做出來了。之後，我也隨便把他的這塊內容管理功能，及我之前想的活動相關的功能，合在一起，變成了現在這個應用的樣子了。

http://ape.fgt.im 這個頁面中的 5 張圖就把這個小東西的功能說完了。

有興趣的，可以掃描上面的二維碼安裝試試看（需要企業管理員許可權才能安裝應用），或者直接訪問 http://ape.fgt.im。

技術方面，前後端是完全分離的。

後端用 Python 寫的，一套東西是 tornado 和 sqlalchemy 。程式碼在：http://gitlab.alibaba-inc.com/yesheng.zys/ec

前端是 AngularJS 那套，程式碼在：http://gitlab.alibaba-inc.com/rdcdata/z/tree/master/src/ec

其實還有另外一套東西，掃碼登入的那個簡單後臺，也是一個單獨的前端專案（配合約定的後端服務的格式工作），程式碼在： http://gitlab.alibaba-inc.com/rdcdata/z/tree/master/src/zadmin

2. 做一個套件與做 N 個套件沒區別

先說第一點心得。這方面你應該已經理解 ISV 中的套件是如何工作的了，如果不清楚，可以先看看：

一般我們最開始來做一個套件時，會習慣性地把套件相關資訊（ suite_key, suite_secret,token 等）作為配置寫到配置檔案當中。最開始我也是這樣乾的。但是在對接流程時，這樣我經常會有非常彆扭的感覺。原因是，除了套件本身的資訊，在 ISV 的授權流程當中，企業相關的資訊，你還是得作一般化的，比較正式的持久化處理，因為會有 N 個企業用到你的套件，每個企業都有自己的一套“配置資訊”。簡單來說，企業這套資訊你要放到關聯式資料庫的表中儲存。

再者釘釘的應用場景一般是基於“組織”的，也就是說你的業務資料模型中，“企業”一定是一個獨立的實體（很多業務的實體表中，都會有一個“企業”的外來鍵）。

現在，“企業”已經是一個連線業務流程，跟釘釘授權流程的一箇中間角色了。再細想釘釘的授權流程，企業的授權物件，是“套件”，而企業的授權狀態本身有多種，這也是一個需要在記錄的東西。到這裡，其實已經能看出來，如果在資料模型中沒有“套件”這個實體，已經會讓人不舒服了。

更進一步，套件本身還有近 10 個屬性，而且有幾個屬性還是動態的。（這跟你接一個統一的使用者系統，只在相關表中記一個使用者 ID 完全不是一回事了）

與其在配置檔案中寫死套件的幾屬性，再搞個快取系統什麼的去維護這個套件另外幾個屬性，同時忍受資料模型中因為沒有“套件”這個實體的不完整感：

你就專門為套件建一個表，每個套件作為一條記錄來維護相關資訊，是一個更直觀，更經濟，更靈活的處理方式。

而多出“套件”這個維度的代價，僅僅受限在 ISV 授權流程中，並不會蔓延到你的業務流程中去，因為你的業務流程只關注這是哪個企業的資料，而不關心它到底是從哪個應用來的。

我用 6 張表處理 ISV 授權的流程資料：

  • dingding_isv_corp_relieve 是企業取消授權時的一個歷史記錄。
  • dingding_isv_corp_app_agent 是 app_id 與 agent_id 的對應關係，這在獲取企業授權之後，通過服務端服務可以查詢到，並且在啟用應用時需要用到相關資訊，在 jsapi 簽名響應時也需要響應 agent_id 資訊。
  • dingding_isv_agent 這個記錄企業中的 agent 的狀態。

把套件作為單獨是的實體在系統中處理之後，建立套件本身就是一個隨手的事了。

  • 新建一條記錄，填上新建套件的 token 和 aes_key 。
  • 新建套件的回撥地址中，需要標識套件。（用引數或寫在路徑中，我是寫在路徑中的，比如http://ape.fgt.im/dingding-isv-callback/SUITE）

成功建立套之後，再把 suite_key 等資訊補到資料庫中就好了。

這一步開發出的，隨時隨手建立套件的能力，為之後我們的除錯提供了巨大的方便。

整個流程的視訊演示：

（http://v.youku.com/v_show/id_XMTY1MjI4ODMzMg==.html）

3. 使用 SSH 遠端轉發除錯後端

這算是所有跟公網回撥相關的場景的標準處理方式了吧，以前做微信的公眾號開發時就這樣乾的。

簡單來說，像釘釘的推送這種，它需要訪問公網機器，並且之後的除錯你也不方便在手機上作靜態的 DNS 設定，這在開發時是比較不方便的，直接登入伺服器寫程式碼畢竟沒有自己本地機器舒服。

所以我們想到的一個辦法，就是通過代理把遠端伺服器上的訪問導到本機。而這種遠端轉發的能力，是 SSH 自帶的。兩步就可以了：

  • 在 sshd 的配置中（比如 /etc/ssh/sshd_config）新增： 
    GatewayPorts clientspecified

    這讓客戶端可以指定轉發埠。

  • 然後本機啟： 
    ssh -R 0.0.0.0:9000:localhost:8888 root@host
     

    就是把到達遠端任意網路卡的 9000 埠訪問都轉到本機的 8888 埠上來。這樣我們本機服務啟到 8888 上就可以正常響應釘釘伺服器對公網機器的訪問了。

更多的細節可以參考： http://www.ibm.com/developerworks/cn/linux/l-cn-sshforward/

4. 為各個環境建立利於前端除錯的應用

因為是前後端程式碼完全分離的結構，所以前端的除錯上需要稍微單獨設計一下。前後完全分離，就是後端除了渲染一個頁面（裡面會載入前端資源）之外，剩下的全是響應 json 的服務。

之前開發 PC 上的頁面是，我們的做法是本地啟一個靜態 Web 服務就好了，後端資源的地址前端隨意控制的。這樣我改前端程式碼，直接在瀏覽器重新整理就能看到效果，除錯很方便。

但是換到做釘釘的移動端頁面時，情況有點不同，就是登入流程及釘釘的 jsapi 部分。業務上的登入流程需要在釘釘環境才能完成，單獨的瀏覽器環境無法登入（當然你可以單獨做另一套登入機制）。釘釘的 jsapi 部分在單獨的瀏覽器上更沒辦法。

所以，我們需要在釘釘上除錯。這方面，最簡單直接的辦法就是讓釘釘掃二維碼來開啟指定頁面（同網內部地址都可以）。不過在登入上有個小問題，就是 corp_id, app_id 這些引數，為了登入流程正常完成，你可能總是需要自己把這些引數寫死加上之後，再生成二維碼讓釘釘來掃。（而為了找這些引數，可能你總是需要多次登入管理後臺，相信我，這事一點也不有趣）

“開發體驗”對心情的影響是很重要的，也效率的影響也是極大的，我希望的環境是開啟電腦寫完程式碼就能看到結果，還要去找引數，還去拼地址，還去生成二維碼，還去掃碼，太麻煩。

我現在的作法是，直接建立一個為開發除錯而用的套件，裡面又為各個前端環境建立不同的應用（比如CDN測試環境，公司時的本機環境，家裡時的本機環境）。這樣，我只需要本機啟一個靜態 Web 伺服器（本機 IP 相對是固定的），改完前端程式碼，在釘釘中直接開啟相應的應用就可以了，其它事都不用管，世界清靜了。


相關文章