京東咚咚架構演講

咚咚是什麼？咚咚之於京東至關於旺旺之於淘寶，它們都是服務於買家和賣家的溝通。 自從京東開始爲第三方賣家提供入駐平臺服務後，咚咚也就隨之誕生了。

京東咚咚的架構歷程有四個階段，1.0版的誕生，2.0版的成長，3.0版的爆發，到4.0版的涅槃，如下是京東咚咚2015年至今的4.0版架構模式：

2014 年京東的組織架構發生了很大變化，從一個公司變成了一個集團，下設多個子公司。 原來的商城成爲了其中一個子公司，新成立的子公司包括京東金融、京東智能、京東到家、拍拍、海外事業部等。 各自業務範圍不一樣，業務模式也不一樣，但無論什麼業務老是須要客服服務。 如何複用原來爲商城量身訂作的咚咚客服系統並支持其餘子公司業務快速接入成爲咱們新的課題。

 

最先要求接入的是拍拍網，它是從騰訊收購的，因此是徹底不一樣的帳戶和訂單交易體系。 因爲時間緊迫，咱們把爲商城訂作的部分剝離，基於 3.0 架構對接拍拍又單獨訂作了一套，並獨立部署，像下面這樣。

雖然在業務要求的時間點前完成了上線，但這樣作也帶來了明顯的問題：

 

1. 複製工程，定製業務開發，多套源碼維護成本高

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

 

之前咱們都是面向業務去架構系統，現在新的業務變化形勢下咱們開始考慮面向平臺去架構，在統一平臺上跑多套業務，統一源碼，統一部署，統一維護。 把業務服務繼續拆分，剝離出最基礎的 IM 服務，IM 通用服務，客服通用服務，而針對不一樣的業務特殊需求作最小化的定製服務開發。 部署方式則以平臺形式部署，不一樣的業務方的服務跑在同一個平臺上，但數據互相隔離。 服務繼續被拆分的更微粒化，造成了一組服務矩陣（見下圖）。

而部署方式，只須要在雙機房創建兩套對等集羣，並另外建一個較小的灰度發佈集羣便可，全部不一樣業務都運行在統一平臺集羣上，以下圖。

 

更細粒度的服務意味着每一個服務的開發更簡單，代碼量更小，依賴更少，隔離穩定性更高。 但更細粒度的服務也意味着更繁瑣的運維監控管理，直到今年公司內部彈性私有云、緩存雲、消息隊列、部署、監控、日誌等基礎系統日趨完善， 使得實施這類細粒度劃分的微服務架構成爲可能，運維成本可控。 而從當初 1.0 的 1 種應用進程，到 3.0 的 六、7 種應用進程，再到 4.0 的 50+ 更細粒度的不一樣種應用進程。 每種進程再根據承載業務流量不一樣分配不一樣的實例數，真正的實例進程數會過千。 爲了更好的監控和管理這些進程，爲此專門定製了一套面向服務的運維管理系統，見下圖。

統一服務運維提供了實用的內部工具和庫來幫助開發更健壯的微服務。 包括中心配置管理，流量埋點監控，數據庫和緩存訪問，運行時隔離，以下圖所示是一個運行隔離的圖示：

細粒度的微服務作到了進程間隔離，嚴格的開發規範和工具庫幫助實現了異步消息和異步 HTTP 來避免多個跨進程的同步長調用鏈。 進程內部經過切面方式引入了服務加強容器 Armor 來隔離線程， 並支持進程內的單獨業務降級和同步轉異步化執行。而全部這些工具和庫服務都是爲了兩個目標：

 

1. 讓服務進程運行時狀態可見

2. 讓服務進程運行時狀態可被管理和改變

京東咚咚架構的變化過程，通過了很大的變化，隨着公司規模的壯大，架構模式也在隨之變化，所以，每一個架構都不是最完美的，都須要與時俱進才能持續發展。

文章引用原文地址：https://mp.weixin.qq.com/s?__biz=MzAxMTEyOTQ5OQ==&mid=401186254&idx=1&sn=1b3c81386973c99cad99079fcd6be6e3&scene=21#wechat_redirect