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

架構好文學習，攢~~

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

名詞解釋：

　　Apache MINA： 百度百科

　　HAProxy： 百度百科

1.0 架構筆記：

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

　　缺點：效率和擴展---這個模型實際上是一個高功耗低效能的模型，不活躍的連接在那做高頻率的無意義輪詢，高頻有多高呢，基本在 100 ms 以內，

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

　　　　　因此這個模型導致了擴展能力和承載能力都不好，一定會隨著線上人數的增長碰到性能瓶頸。

2.0 架構筆記：

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

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

3.0 架構筆記：

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

　　　　　　按業務重要性級別劃分了 0、1、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 周三