在互聯網應用研發過程中，中間件扮演着極其重要角色，因為數據存取、服務划分、消息傳遞、
負載均衡、DNS、CDN等等。
中間件在互聯網應用開發中有着重要作用，其中以微服務、數據存取、消息隊列三大中間件最
為重要。
微服務，最早程序研發是一個大的整體，存在問題研發困難，困難主要表現在修改后程序容易
導致其他模塊不可用，單體程序還存在一個流量預估難題，平時還好電商大促流量突增，單體程序
流量預估難度極大，而微服務一下子將問題簡化多個量級，只要預估好每個人維護微服務程序就可
以了。
JD微服務是自己研發框架，與dubbo相比整個架構設計緊湊簡潔，dubbo相比設計擴展性強，
各有優劣。核心差異不大，線上有個大流量服務大促時6000萬/分鍾，100萬qps 150台4核16G容
器。dubbo是阿里開源好東西，對業界微服務化極大推動，感謝開源，dubbo能夠支持千萬級、億
級每分鍾掉用量處理，是極其優秀框架，最近又重啟更新，需要用到微服務的可以放心用起來。
微服務本身客戶端實現軟負載均衡，節省大量硬件作為負載均衡使用，缺點也是有的，微服務
橫向擴展容易，縱向也能夠方便分層，但盡量不能分太多層，因為每層均存在網絡耗時。
記得app首頁入口圖初版服務，單個容器規格4核8G內存50G硬盤，但個容器能處理請求10萬/
分鍾，而且還可以加量繼續壓，輕輕松松完成c100k處理。
數據存取，存儲讀取是應用程序永恆主題，分布式緩存redis這篇文章介紹過大型電商互聯網架構中redis運用，
redis內存緩存是快，天下武功唯快不破，但是內存目前還是極其昂貴資源，分布式文件系統，Google
大數據三架馬車之一bigtable，能支撐Google搜索引擎對於網頁存儲與檢索，感興趣也可進行研究使用，
遺憾是google未開源，但百度開源了分布式文件系統BFS對應HDFS、以及分布式數據庫TERA對應
bigtable，據官方公開文檔查詢性能在10ms以下，進行參數設置性能能到1ms。
消息隊列，消息隊列在為復雜程序節藕，大公司不同部門系統、模塊之間數據通訊，移動端數據上
報等多個重要流程，均離不開他，在數據通訊傳輸占有核心地位。
清晰記得新浪微博，在初期有一段時間點贊時響應極其慢，最尷尬的事還經常失敗，用戶體驗極差，
簡直讓用戶抓狂，后來看到網上分享了解到是因為點贊包含多個流程，在原微博上點贊加一，在自己用
戶上增加和這條微博點贊關系，權重計算處權重加一用於微博feed分發這條用等等邏輯，再一次需要全
走完非常慢，用消息隊列節藕，點贊發消息就可以給客戶端反饋成功，性能呈指數級提升，各個模塊取
消息進行消費處理進行相應操作就可以了，用戶體驗極大提升。
對於數據交互通信場景，了解到大數據那塊數據分兩塊一個是離線hive表交乎一個是讀取mysql或提
供微服務拉取數據交互，有前邊這些還不夠，因為又個需要及時增刪改場景就需要消息隊列進行處理，比
如評論或問答用戶回答質量差這時就需要，刪除消息將質量差評論、問答刪除掉。對了目前各大互聯網
公司用的比較多消息隊列是Kafka以及ActiveMQ。
數據上報場景，移動時代數據點擊、瀏覽、GMV、轉化率等各個指標都離不開數據埋點上報，個性
化推薦系統特征工程中數據匯總上報也離不開消息隊列，上報流程一般是Storm實施消費消息數據落到大
數據HDFS、HBase等。這個過程中消息隊列都是必不可少的。
互聯網公司中間件占有重要地位，對於應用快速開發，數據穩定訪問，數據上報等，服務高性能、高
可用發揮着重要作用。中間件之中又以服務划分、服務治理，數據存取，消息隊列中間件最為重要。
其他中間件，例如JD本身有自己研發UMP能方便監控應用性能、可用率、容器cpu、內存、線程等多
個指標，開源比如性能監控有大眾點評CAT。再有智能DNS、CDN、負載均衡lvs、haproxy等等中間件也
在互聯網架構中發揮這重要作用。
容器本身在JD也發揮着重要作用，線上服務100%在容器中，大數據spark那些據了解也在容器化進行
中。以docker代表容器化技術，cpu、內存隔離性好，網絡吞吐也極高，是一種極其優秀技術。
docker目前存在問題，大促時有些個別機器，它的服務cpu、內存占用過高影響其他容器里面服務，這
種情況備戰期間要仔細觀察，盡量和負載高應用避開，這種問題個人看到占比極其小，容器技術在互聯網公
司目前發揮着重要作用。
寫出來記錄一下，一是為后續查找方便，另外如果對讀者如果遇到相應問題正在一籌莫展，文章如果能
帶來一些啟發那就更好了。
掃碼關注公眾號