開放平臺兩三點感悟
Author:放翁（文初）
Mail:fangweng@taobao.com
圍脖：http://t.sina.com.cn/fangweng （多加一個圍脖，也潮一把）
有淘寶的同學在旺旺上和我說，你最近很少寫blog了哈，是不是忙著照顧孩子啊，我尷尬的笑了笑。是的，照顧“小孩”，自己家的小孩和開放平臺這個小孩。以前人家說，三十而立，我今年虛歲33了，兒子就快能夠“立”起來了，一直想寫點技術和生活的體會，但是總少一些沖動。今天就下面這張圖，讓我突然想寫點什么。
看到一篇文章的這張圖，立刻在新浪“圍脖”上曬了一把，留言道：“騎車運動中，稍后解釋”。結果同僚回應道：“不用解釋，一目了然”。其實如果真的就這些數字，的卻是一目了然，但是如果你經歷過開放服務的發展的話，其實這些數字僅僅只是現在的一個快照，你能看到的也就是現在的一個現狀，對比昨天，才能知道今天的數字發生了什么變化，將來意味著會發生什么樣的變化。
08年初，Ben的一句“兩周能搞出一個雛形來，兩個公司就合作開放服務”，我就誤打誤撞的開始研究和構建開放平臺。當時國外Yahoo算是有一個像樣的開放平臺，Flickr API是Yahoo開放平臺使用最廣泛的服務，在服務開放流程，安全性和服務接口設計上成為我設計借鑒的范例。但這僅僅是開始，要開放，其實有著更深層次的要求。看看下面兩張服務市場占有率的圖，比較一下08年和10年的情況
08年中旬 2010年
Amazon PAAS類的服務，今天已經成為服務類型中占據第一位的服務，Social服務也隨著Facebook占據了第二位。最近又開始熱炒地理經緯的服務，其實就是Map服務的一個演變。上面的變化其實可以發現兩點：
1. 技術的成熟使得PAAS的服務在高門檻背后成長的更加快。
2. 業務的成熟也會推動開放服務的不斷發展，因為開放的目的就是用最簡單有效的技術方式來實現業務創新。
上面的圖片和信息都是來自于一篇關于GlueCon大會的報道，Glue？沒錯，膠水，我記得最近幾次在淘寶技術大學介紹開放平臺的技術體系架構的時候，都談到快餐式的應用構建方式。在互聯網創新需求的推動下，需要利用類似于麥當勞的快餐方式來Glue那些面包，生菜，牛肉快速滿足用戶需求變化。淘寶當年把線下開店搬到線上來，最終吸引客戶的是什么？低風險，小投入（今天就未必了），嘗試創業。今天要做一個互聯網應用，是否也能夠類似的有一個平臺，不需要再關心域名，站點，推廣，基礎服務，那么就需要不同層次的服務提供商，從PAAS，到數據服務提供商，到流程服務提供商等等。
看看GlueCon的首頁寫的一些技術點：
一些老面孔技術，一些經歷過的事，接著后面將講述自己在做開放平臺的經歷，我只是一個技術人員，分享的也就是技術學習的過程，沒有創業的輝煌，沒有專家的深度，有的就是一些感悟。
雛形
ASF，嗯，沒看錯，不是apache軟件服務聯盟，是應用服務框架。當你第一天覺得你要開放內部服務的時候，就需要審視一下你的后臺架構體系，是否是能夠開放的。也許有人會覺得開放無非就是將一些API封裝一下以Http的某種方式暴露出去。對，“暴露”，當你內部就只有一條“遮羞布”的時候，一旦被人扯掉，你就真的暴露了。
因此，在阿里軟件早期做SAAS的模式下，希望對內部架構做一次完整的服務化改造。其實今天的淘寶在開放初期也是經歷了服務化改造的。服務化改造，在當時我學習的是OSGI和SCA兩種框架模型，在模塊化理念上兩者基本上是一樣的設計思路，但是OSGI在我看來更加適合應用模塊化而非架構體系的服務化，因此在開源項目Tuscany 0.91版本的基礎上構建了適合于開放服務體系的ASF，基于配置將業務模塊化，服務的依賴和發布通過模塊來申明。（其實到了Tuscany 1.0以后很多實現就是ASF定制改造的功能，具體對ASF感興趣的可以看看我blog以前的說明，源代碼估計隨著Alisoft的結束而消失了）。模塊化的推行并非一帆風順，很簡單，不論是開發人員和架構人員對于框架約束模塊化的開發模式并不是很適應，同時由于框架本身也在不斷成長，總會受到一些抱怨。其他不多說，這個階段學到的幾點：
1. 多一些業務性的指導要比冷冰冰的技術文檔來的更有利于框架的推廣。（很多時候模塊化最大的問題就是粒度，拆分過細，導致依賴復雜，調試成本大，拆分過粗，服務隔離效果差，模塊化作用淡化）一句話，沒有不好的技術或者框架，只有不適合的技術和框架，任何好的技術和框架都要知道什么時候怎么用，不然就好比期望要一個能醫百病的靈丹妙藥一樣不靠譜。
2. 邀請參與好過自上而下的推廣。老大起先可能會很支持的幫你去自上而下的強制推廣，但是任何一個產品或者框架的成熟需要使用來反向驅動改進，因此邀請更多的人參與，會讓后期由被動轉為主動。（這點說起來比較容易，但是做起來比較難，因為很多技術人員喜歡自己創造成就感，就算和別人一樣挖同樣的洞，深1cm也算是種成就感#_#）。不過在淘寶這邊，感覺氛圍還不錯（不是廣告，呵呵），有人愿意參與，有人愿意學習。簡單來說這里的人有產品的觀念，而非簡單的技術觀念，滿足用戶需求是基本，把自己的力氣用在自己最擅長的地方，其他的借鑒或者使用兄弟團隊的技術和產品。
SOAP到REST。最早SAAS平臺采用的是Web Service的方式來對外開放服務，原因是WS有成熟的多語言體系框架，同時WS配套的WS-Security是安全的基礎保證。因此服務化都是采用WS的方式，身份認證也采用X.509證書的方式來認證，當然當時也采用平臺頒發X.509證書（沒有搞授權中心去授權），并且將證書內容保存到數據庫和內存中，便于校驗。但這個過程中，我們認為成熟被多語言支持的WS，卻給我們搞了很多麻煩，.net和java及php對于SOAP的理解在細節上還有很多偏差，特別是對復雜的對象類型，當然在證書上.net的技術專家一起陪著我們搞了許久，最后還是我們自己通過比較蹩腳的辦法繞過了問題。
逐漸的將服務都轉變成為REST的方式，輕量化的服務體系對于服務發布者或者使用者來說都是一種解脫。下面的圖是當前REST方式和SOAP方式的使用量對比：
學到的：
1. 啥都要靠自己去實踐才知道是不是真的靠譜。
2. 作對了99%是應該的，但是1%的問題沒有處理好，那么就會降低用戶體驗，因為用戶容易看到問題，而正常服務是被認為理所應當的。
成長
服務差異化。隨著服務平臺的成熟，接入的服務也各自呈現出他們的特點，一成不變的Http請求相應的交互服務模式在業務和性能上不能滿足需求。類似于短信服務的異步消息，RSS類型的訂閱消息，就需要平臺支持異步回調。大數據量的服務（視頻，文件上傳下載），如果在經過服務平臺中轉數據流，就會導致帶寬浪費，因此需要將安全校驗和業務交互流程分離。
服務安全體系的變化。WS-Security到簡化的OAuth 0.1 。沒看錯，OAuth0.1的簡化版，那個年代什么東西都是新的，就和前面談到的OSGI，SCA，OAuth等等，因為國外的服務體系也是這一年半發展起來的。現在很多網站都標榜自己支持OAuth，支持Open ID等等，但其實去看看Google，Yahoo的大量API的安全體系，其實都是做了定制化，原因很簡單，就是要在安全的同時盡量降低復雜度，提升可用性，多一次交互就會帶來不穩定的因素。TOP和以前的阿軟開放平臺都是采用了一次令牌授權的方式，而OAuth則是采用了2種令牌，3次交互。其他優點沒看出來，不過將安全信息放入到Http頭中確實很好。我記得上次回郵件的時候說：“如果能夠讓我重新做一次協議制定，那么我會讓平臺安全邏輯完全無侵入業務協議”。一來保證業務協議的無侵入，二來在性能方面來說消息頭的處理會極大降低異常服務判斷及丟棄的應用系統資源損耗。
服務分流與隔離。很多技術我在以前的blog中都有描述，因此這里也就輕描淡寫的說一下。后端服務者看來服務開放平臺就是為他一家服務的，但是其實所有的服務在服務開放平臺上是對等的，而服務當前多數以Http的應答模式開放，當后端服務處理出現問題時，那么服務平臺的前端資源將被耗盡，間接影響到了其他正常的后端服務，因此需要對服務能夠做分流和隔離。這里學習了LVS和Haproxy的設計理念，在四層以簡單的ip分流做對應用粗粒度的保護（大ISV有固定的一些ip），在七層兩方面通過URL的服務名稱做服務分流，再通過集中式緩存協同集群判斷后端服務的可用性，在必要時部分切斷中轉，來保證其他服務的可用性。
Memcached成為基礎組件。高速系統必須要有緩存來支持，因此當時選擇了剛剛被推出廣受好評的Memcached，系統運行期的服務訪問控制和服務路由都靠集中式緩存來支持。但是集中式緩存最大的問題就是如何容災，數據丟失就去數據庫取，那么就會導致一些攻擊使得系統奔潰，因此只能讓集中式緩存有類似于服務器一樣的HA冷熱備份。考慮在服務端做基本不靠譜，一來我不熟悉C，二來如果在服務端做，那么就會演變成為分布式緩存，分布式緩存最大的問題就是數據一致性的問題。（幾階段提交，數據節點分區等等，復雜的設計帶來的就是可用性和效率的降低，CAP就不再贅述了，看見幾個緩存或者NOSQL的設計者一直都在談CAP及RWN數值關系的問題）因此變相考慮實現客戶端來支持集群，客戶端支持集群很簡單的思想，就是多放一份，但是需求是，不影響效率（因此多放一份就不應該同步做），也要保證簡單的數據一致性（根據算法優先獲取或者存儲固定節點數據，即同等節點在客戶端來看不等同）。因此就搞了一個Memcached的客戶端組件，本來只是希望做客戶端集群效果，不過看了原始的BIO的效率不高，就順帶優化了一把，不過后來我現在的同事用NIO又做了一版。（NIO早期不適合用于老版本的Memcached協議，因為沒有會話碼）
服務流控。資源不收錢，那么自然不用白不用，因此有很多應用瘋狂拉數據，從阿里軟件的角度或者淘寶的角度都是不希望這樣的情況發生的，因此出現了服務流控。對應用的頻率和總量控制，一來保證了應用本身不會因為程序問題擊垮后臺服務，二來也提供了應用的層次設計，為應用良性成長奠定了基礎。（當然商業上也有更多的想象空間）
以上都是自己還想得起來的一些技術點，感悟到的內容如下：
1. 量體裁衣，適用就好。有時候在做設計的時候容易陷入盲區，總認為流程就是這樣走的，就好比第一個點中提到的關于業務數據流是否真的必須經過開放平臺一樣，其實安全校驗通道和數據通道可以是不同的兩個通道，數據通道在獲取了安全認證以后可以拿著令牌去建立，這樣就可以既滿足需求，又降低了系統消耗。（其實和LVS的三種模式的演變很類似）
2. 系統先做繁再做簡單。記得小學的時候老師總是和我們說，書是先讀厚，然后讀薄。這和我們設計系統一樣，開始的時候我們往往會想得很全面，然后不斷的增加復雜的設計來保證我們的業務可用性，但是后續會發現，復雜本身就是降低業務可用性的罪魁禍首，因此不斷的審視需求，重構設計，最后以簡單易擴展的方式滿足業務需求。我上次和淘寶技術大學的新入職的同學說，我比在坐的優勢就在于可以較快的從復雜的設計跳出做到簡單的設計，這其實就是積累的經驗，但是他們的優勢在于可以看到一些經驗背后的不足。
3. 從需求的角度看問題。分布式緩存最大的問題是什么，就是數據一致性，為了這個一致性不得不犧牲性能。而對于性能要求很高的場景下如何保證一致性和可用性，則可以從客戶端實現數據冗余來做文章。另一個例子，現在TOP的分布式即時日志分析模型中數據獲取部分是每個Slave主動請求去“拖”服務器的日志，而淘寶的監控系統則是在應用服務器上設置了Agent計算和收集日志并“推”送給單點，這一推一拖的差別在什么地方，監控系統也好，日志系統也好，最基本的前提是不能影響業務系統，推會導致誰都無法掌握主動權去控制非業務性需求對業務系統的影響，而拖則將主動權交給了非業務性需求，根據業務的適應情況，調節頻率和處理內容的數量，有效的利用資源。（這其實就是需求角度看問題）
4. 技術并非無業務性。其實類似的流控，服務范圍限定等等，都是提升業務想象空間的技術基礎。這年頭賣軟件不賺錢了，賣服務，而賣服務也是差別化的服務，低層次的免費體驗，高層次的增值收費，產生良性循環。
5. 不要盲目崇拜。有同學和我說TOP支持OAuth么？這么流行的不支持，不太好吧。咋們是實在人，在沒有服務好用戶以前先不想著貼牌子在身上。我自己也是G的粉絲，但是很多時候對于新技術而言需要的是一種嗅覺和辨別能力，不然聞到G拉屎都覺得香了。我雖然轉到淘寶才10個月，但是是3個同學的師兄（淘寶的新人都需要一個師兄），其中有個大學剛畢業的同學，開始的時候寫代碼就開始套模式，有新技術就考慮學一把。代碼被我要求返工了4次。和他后來談起的時候，說到對于新技術的學習，其實為了看見牛的時候能夠記得起有一把牛刀可以用，而不是整天提著一把牛刀滿大街砍小雞。還是那句話，找到合適的場景，在去深入學習和了解技術背后的思想。
困頓
淘寶“出逃”。09年初，淘寶開始搭建自己的開放平臺TOP，原因很簡單，淘寶需要的是淘寶服務開放平臺，而非一個服務集成平臺，服務集成平臺對于專業化和產品化運營API是較為不利的。于此同時產品化服務這個詞開始慢慢進入我的腦子。
北京的搜索團隊，支付寶都和我交流過關于開放的考慮，但是一系列問題卻問倒了我，也問倒了他們，為什么要開放，客戶群在什么地方，應用形態是怎么樣的？其實就是API產品化的問題，對于沒有開放過的服務提供者來說都是抱著嘗試的態度去做開放，但是基本上不靠譜（國內的技術能力和創新意識都還處于初級階段）。看到早期的SNS開放出來其實還是以傳統意義的桌面版游戲結合SNS的互動產生效果。而類似于搜索，支付這些專業化程度較高的服務，開發者如何去使用，安全性如何保證，其實都還很模糊。
到了09年4，5月份，開放平臺逐步轉變成為內部服務平臺，技術驅動力隨著商業目標的模糊越來越弱，5月底我要求做最后一個版本SIP5.6，然后就暫時終止繼續開發。
產品化
09年8月，阿里軟件被多家子公司合并，我主動要求從云公司來到淘寶，因為我還有沒有完成的目標，開放平臺，同時也只有在這里我才會體會到產品化的含義，踏踏實實的在我30歲的時候經歷一個產品，而不在存粹的技術實驗室中打滾。
有點晚了，明天繼續寫…
1. 透明化（系統，業務）
2. 客戶第一（服務可用性，易用性，商業價值）
3. 平臺要死哪里是致命的一擊