《前言》
（一） winner2.0 框架基礎分析
（二）plsql報表系統
（三）sso單點登入
（四） 簡訊中心與訊息中心
（五）錢包系統
（六）gpu支付中心
（七）許可權系統
（八）監控系統
（九）會員中心
（十一）winner前端框架與rpc介面規範講解
（十二）上層應用案例
（十三）總結
《rpc介面使用規範》
rpc（remote procedure call），遠端過程呼叫）
這樣一看確實叫rpc更合適一下，細緻講一下我們winner2.0中介面請求規範，我們從簡到繁的說一下演變過程（以下就簡稱rpc）。
首先在1.0時代，我們當時也沒有很多思路，只做了簡單簽名驗證也沒有考慮許可權、版本等問題，主要是用webservice。
我們看一下常規情況我們是這麼用的：
我們的目的是為了防止webservice 介面被惡意呼叫，尤其是篡改資料後呼叫所以用了兩種手段做安全驗證：
1，使用rsa對引數加密（rsa是非對稱加密，公鑰加密私鑰解密，一般使用兩對rsa）。
2，使用md5做簽名驗證（客戶端與服務端約定乙個字串做加密種子，將所有引數+加密種子 算出來唯一的md5值）
這樣做基本對於安全性而言已經夠了，但是在使用過程中五六年下來總是覺得用著不順手。大致幾點如下：
a，介面沒有許可權管制。比如我們乙個介面同時有a、b兩個專案呼叫，這個時候我想停止給b專案使用，介面就沒有控制權。
這種情況經常出現在給第三方呼叫時候，我們不想給第三方使用了，這個時候又關不掉，關掉了我們自己的專案也用不了了。
b，我們這樣寫介面沒有版本的概念。同樣以第三方呼叫我們的介面來舉例，如果我們公升級專案更改了引數，所有的第三方就開始
罵娘了，每個第三方客戶端都要去公升級系統，而且我們一刀切呼叫不見得有時間來配合我們公升級。有版本號的話，我們可以讓老使用者
依然可以繼續使用，新接入的就使用最新的介面。
c，對於移動客戶端沒有管理概念。 這個屬於特殊的業務，我們公司的硬體終端如果我想限制某一台終端呼叫，之前的做法是不行的。
d：引數過多時**繁瑣。 如果9個引數，客戶端就要給8個引數依次加密，當然可以寫工具類處理，但還是繁瑣了。
f：沒有統一的json返回引數規範。每個專案都是自己定義返回結果，沒有規範。客戶端開發時沒有規律可循。
另外還有一些小問題，但最主要的就這幾點，所以我們在winner2.0中我們商量出了一套標準，所有的介面基於這套標準開發。
首先，得益於mvc的到來，我們基本放棄了使用webservice這種方式提供介面，轉而使用webapi的形式。
其次，我們介面只接收三個固定引數：商戶號，json資料，簽名字串。
最後，我們統一了返回json的資料標準，以及錯誤編碼。
這裡我貼一張jason 寫的介面文件中的介面api協議：
公共引數就是所有介面都需要接收這些基本的引數，再乙個子json才是具體的傳值引數。 這段json用商戶號對應的md5種子
加密，主要也省去了每個引數客戶端單獨加密，服務端又單獨解密的繁瑣。
與此同時，我們還需要上送客戶端的硬體id，會用的資訊，商戶資訊等。主要就在服務端能做更細緻的控制。
失業程式設計師的自我救贖
王小波在 時代 裡寫道，那一天我二十一歲，在我一生的 時代。我有好多奢望。我想愛，想吃，還想在一瞬間變成天上半明半暗的雲。後來我才知道，生活就是個緩慢受錘的過程，人一天天老下去，奢望也一天天消失，最後變得像挨了錘的牛一樣。可是我過二十一歲生日時沒有預見到這一點。我覺得自己會永遠生猛下去，什麼也錘不了...
程式設計師的自我救贖（前言）
程式設計師的自我救贖 前言 記得第一次登陸的時候，在個人資料裡寫近期願望是當上專案經理。轉眼間7年過去了，我也當了四年多專案經理。驀然回首之間，也不再糾結被別人叫程式設計師還是叫軟體工程師。其實在當專案經理的4年裡，前兩年確實很忙。到第二年的時候，我開始不再碰 恰好微軟在.net這一塊也開始流行 使...
程式設計師的自我救贖 7 2 許可權系統實際應用
前言 一 winner2.0 框架基礎分析 二 plsql報表系統 三 sso單點登入 四 簡訊中心與訊息中心 五 錢包系統 六 gpu支付中心 七 許可權系統 八 監控系統 九 會員中心 十一 winner前端框架與rpc介面規範講解 十二 上層應用案例 十三 總結 許可權系統實際應用 講到許可權...