【京東咚咚架構演進】-- 好文收藏

索引：

目錄索引

架構好文學習，攢~~

京東咚咚架構演進 -- By 【瞬息之間】

名詞解釋：

　　Apache MINA： 百度百科

　　HAProxy： 百度百科

1.0 架構筆記：

　　優勢：模型結構簡單---理解起來簡單；開發起來簡單；部署起來也簡單。

　　缺點：效率和擴展---這個模型其實是一個高功耗低效能的模型，不活躍的鏈接在那作高頻率的無心義輪詢，高頻有多高呢，基本在 100 ms 之內，

　　　　　你不能讓輪詢太慢，好比超過 2 秒輪一次，人就會在聊天過程當中感覺到明顯的會話延遲。 隨着在線人數增長，輪詢的耗時也線性增加，

　　　　　所以這個模型致使了擴展能力和承載能力都很差，必定會隨着在線人數的增加碰到性能瓶頸。

2.0 架構筆記：

　　改進點：業務功能體驗的提高上---針對沒法及時提供服務的顧客，能夠排隊或者留言。 針對純文字溝通，提供了文件和圖片等更豐富的表達方式。

　　　　　　另外支持了客服轉接和快捷回覆等方式來提高客服的接待效率。

3.0 架構筆記：

　　改進點：業務劃分服務，且服務進行分層---服務化的第一個問題如何把一個大的應用系統切分紅子服務系統。

　　　　　　按業務重要性級別劃分了 0、一、2 三個級別不一樣的子業務服務系統。 另外就是獨立了一組接入服務，針對不一樣渠道和通訊方式的接入端。

　　　　　　服務架構&分層---a.UI接入層 --- 客服用(web/app..)系統，員工用(web/app/pc...)

　　　　　　　　　　　　　   b.負載均衡層 --- TCP長鏈接，HTTP短鏈接

　　　　　　　　　　　　　   c.路由服務層 --- 路由 Tracker

　　　　　　　　　　　　　   d.業務服務層 --- 業務子系統及API服務

　　　　　　　　　　　　　   e.基礎服務層 --- 基礎框架服務(安全/風控/資源分配...)

　　　　　　　　　　　　　   f.資源服務層 --- DB/Cache/NoSQL/MQ....

　　　　　　消息投遞模型---再也不是輪詢了，而是讓終端每次創建鏈接後註冊接入點位置，消息投遞前定位鏈接所在接入點位置再推送過去。

　　　　　　　　　　　　　這樣投遞效率就是恆定的了，並且很容易擴展，在線人數越多則鏈接數越多，只須要擴展接入點便可。 

　　　　　　　　　　　　　使用了 MongoDB 來單獨存儲量最大的聊天記錄。 

4.0 架構筆記：

　　拍拍網消息缺陷：a.複製工程，定製業務開發，多套源碼維護成本高

　　　　　　　　　　b.獨立部署，至少雙機房主備外加一個灰度集羣，資源浪費大

　　系統持續演進：面向平臺---始考慮面向平臺去架構，在統一平臺上跑多套業務，統一源碼，統一部署，統一維護。 把業務服務繼續拆分，

　　　　　　　　　剝離出最基礎的 IM 服務，IM 通用服務，客服通用服務，而針對不一樣的業務特殊需求作最小化的定製服務開發。

　　　　　　　　　部署方式則以平臺形式部署，不一樣的業務方的服務跑在同一個平臺上，但數據互相隔離。

　　　　　　　　　細粒度服務開發---更細粒度的服務意味着每一個服務的開發更簡單，代碼量更小，依賴更少，隔離穩定性更高。

　　架構VS業務： 技術架構沒有絕對的好與很差， 技術架構老是要放在彼時的背景下來看，要考慮業務的時效價值、團隊的規模和能力、

　　　　　　　　   環境基礎設施等等方面。 架構演進的生命週期適時匹配好業務的生命週期，纔可能發揮最好的效果。

 

 

 

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　蒙

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　2017-08-02 09:20 週三