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