現(xiàn)在市面上的編程語言以面向?qū)ο鬄橹髁鳌Ｃ嫦驅(qū)ο笙纫獜囊恍┳罨镜淖銎?。比如?4歲就結婚了，不然怎么面向?qū)ο缶幊獭Ｈ缓髣偨Y婚就生娃了，不然對象跑了咋辦?new一個？創(chuàng)建銷毀開銷很大的，還是生個娃持續(xù)持有對象的引用的好。
為啥有些人開口說話能說很久，有些人說話有一搭沒一搭的？據(jù)我觀察發(fā)現(xiàn)，動手干活差不多的兩個人，會說的將來發(fā)展的會更好。原因從具體實例來感受一下。
和朋友聊天，真的，好幾年前人人網(wǎng)出來的總有點技術極客精神，聊天我們聊技術。人家問我你們視頻是怎么存儲怎么播放的。我說我就是做內(nèi)容,meta的，其他和我無關。天兒就聊死了，自己的格局就下來了。如果說我做的有開發(fā)平臺的東西，里面有上傳視頻的。先調(diào)用云存儲的接口進行一個初始化，他們返回給我們一個視頻介質(zhì)上傳url。JS端將介質(zhì)分片的方式上傳到url上。如果網(wǎng)絡中斷或者瀏覽器關閉啥的，可以調(diào)用續(xù)傳接口用新返回的url繼續(xù)傳。續(xù)傳接口帶著總文件大小和目前已經(jīng)收到的文件的大小，JS可以依據(jù)這個判斷從哪個分片繼續(xù)傳。云存儲在另一個部門，他們負責和云轉(zhuǎn)碼部門進行通信，云轉(zhuǎn)碼將介質(zhì)轉(zhuǎn)成各種格式，至于從原始高清文件轉(zhuǎn)成各種碼率，怎樣取樣的，DRM數(shù)字版權管理又是怎么做的，由云轉(zhuǎn)碼部門負責。他們內(nèi)部是用什么策略分發(fā)到各個DNS節(jié)點上的。調(diào)度部門又是怎樣調(diào)度來節(jié)約視頻網(wǎng)站最寶貴的帶寬的，具體細節(jié)我不是很清楚。云轉(zhuǎn)碼部門將轉(zhuǎn)換好的各種碼率和視頻url通過MQ的形式傳給我們，我們存到數(shù)據(jù)庫里。
那人家就又問了，MQ你們用的啥呀？我說apache的qpidd。額~~，人家不知道，聊天就聊死了。所以得說MQ都差不多的，和rabbit mq一樣都是基于AMQP高級消息隊列協(xié)議的。這是公司統(tǒng)一的集群，說是安裝部署挺方便的。主流的編程語言也都支持，所以就用了。因為主要是跨部門的通信，主要以方便，節(jié)約溝通成本為主，所以我們的消息體也就是json先壓縮再base64。也沒用protobuf那些二進制的，因為萬一遇到問題，二進制可讀性差，缺乏自描述，不容易排查。
高并發(fā)服務必須有一些緊急方案，比如服務熔斷，降級，隔離，限流，異步RPC等。服務熔斷，降級，隔離大家比較傾向于用netflix開源的分布式服務彈性框架Hystrix。Hystrix也可以限流。但是我們服務用的guava的RateLimiter這種成熟的令牌桶算法來實現(xiàn)。
服務限流是個很簡單的事情。我們的代碼也就幾百行，但是里面有一套比較完整的設計思想，目的是根據(jù)一定的策略(如：url, 平臺來源，url+平臺來源)來做一個業(yè)務細粒度的限流。
