国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

京東咚咚架構演進

marser / 1955人閱讀

摘要:自從京東開始為第三方賣家提供入駐平臺服務后,咚咚也就隨之誕生了。之后開始接手了京東咚咚,并持續完善這個產品,進行了三次技術架構演進。涅槃至今年京東的組織架構發生了很大變化,從一個公司變成了一個集團,下設多個子公司。

咚咚是什么?咚咚之于京東相當于旺旺之于淘寶,它們都是服務于買家和賣家的溝通。 自從京東開始為第三方賣家提供入駐平臺服務后,咚咚也就隨之誕生了。 我們首先看看它誕生之初是什么樣的。

1.0 誕生(2010 - 2011)

為了業務的快速上線,1.0 版本的技術架構實現是非常直接且簡單粗暴的。 如何簡單粗暴法?請看架構圖,如下。

1.0 的功能十分簡單,實現了一個 IM 的基本功能,接入、互通消息和狀態。 另外還有客服功能,就是顧客接入咨詢時的客服分配,按輪詢方式把顧客分配給在線的客服接待。 用開源 Mina 框架實現了 TCP 的長連接接入,用 Tomcat Comet 機制實現了 HTTP 的長輪詢服務。 而消息投遞的實現是一端發送的消息臨時存放在 Redis 中,另一端拉取的生產消費模型。

這個模型的做法導致需要以一種高頻率的方式來輪詢 Redis 遍歷屬于自己連接的關聯會話消息。 這個模型很簡單,簡單包括多個層面的意思:理解起來簡單;開發起來簡單;部署起來也簡單。 只需要一個 Tomcat 應用依賴一個共享的 Redis,簡單的實現核心業務功能,并支持業務快速上線。

但這個簡單的模型也有些嚴重的缺陷,主要是效率和擴展問題。 輪詢的頻率間隔大小基本決定了消息的延時,輪詢越快延時越低,但輪詢越快消耗也越高。 這個模型實際上是一個高功耗低效能的模型,因為不活躍的連接在那做高頻率的無意義輪詢。 高頻有多高呢,基本在 100 ms 以內,你不能讓輪詢太慢,比如超過 2 秒輪一次,人就會在聊天過程中感受到明顯的會話延遲。 隨著在線人數增加,輪詢的耗時也線性增長,因此這個模型導致了擴展能力和承載能力都不好,一定會隨著在線人數的增長碰到性能瓶頸。

1.0 的時代背景正是京東技術平臺從 .NET 向 Java 轉型的年代,我也正是在這期間加入京東并參與了京東主站技術轉型架構升級的過程。 之后開始接手了京東咚咚,并持續完善這個產品,進行了三次技術架構演進。

2.0 成長(2012)

我們剛接手時 1.0 已在線上運行并支持京東 POP(開放平臺)業務,之后京東打算組建自營在線客服團隊并落地在成都。 不管是自營還是 POP 客服咨詢業務當時都起步不久,1.0 架構中的性能和效率缺陷問題還沒有達到引爆的業務量級。 而自營客服當時還處于起步階段,客服人數不足,服務能力不夠,顧客咨詢量遠遠超過客服的服務能力。 超出服務能力的顧客咨詢,當時我們的系統統一返回提示客服繁忙,請稍后咨詢。 這種狀況導致高峰期大量顧客無論怎么刷新請求,都很可能無法接入客服,體驗很差。 所以 2.0 重點放在了業務功能體驗的提升上,如下圖所示。

針對無法及時提供服務的顧客,可以排隊或者留言。 針對純文字溝通,提供了文件和圖片等更豐富的表達方式。 另外支持了客服轉接和快捷回復等方式來提升客服的接待效率。 總之,整個 2.0 就是圍繞提升客服效率和用戶體驗。 而我們擔心的效率問題在 2.0 高速發展業務的時期還沒有出現,但業務量正在逐漸積累,我們知道它快要爆了。 到 2012 年末,度過雙十一后開始了 3.0 的一次重大架構升級。

3.0 爆發(2013 - 2014)

經歷了 2.0 時代一整年的業務高速發展,實際上代碼規模膨脹的很快。 與代碼一塊膨脹的還有團隊,從最初的 4 個人到近 30 人。 團隊大了后,一個系統多人開發,開發人員層次不一,規范難統一,系統模塊耦合重,改動溝通和依賴多,上線風險難以控制。 一個多帶帶 tomcat 應用多實例部署模型終于走到頭了,這個版本架構升級的主題就是服務化。

服務化的第一個問題如何把一個大的應用系統切分成子服務系統。 當時的背景是京東的部署還在半自動化年代,自動部署系統剛起步,子服務系統若按業務劃分太細太多,部署工作量很大且難管理。 所以當時我們不是按業務功能分區服務的,而是按業務重要性級別劃分了 0、1、2 三個級別不同的子業務服務系統。 另外就是獨立了一組接入服務,針對不同渠道和通信方式的接入端,見下圖。

更細化的應用服務和架構分層方式可見下圖。

這次大的架構升級,主要考慮了三個方面:穩定性、效率和容量。 做了下面這些事情:

業務分級、核心、非核心業務隔離

多機房部署,流量分流、容災冗余、峰值應對冗余

讀庫多源,失敗自動轉移

寫庫主備,短暫有損服務容忍下的快速切換

外部接口,失敗轉移或快速斷路

Redis 主備,失敗轉移

大表遷移,MongoDB 取代 MySQL 存儲消息記錄

改進消息投遞模型

前 6 條基本屬于考慮系統穩定性、可用性方面的改進升級。 這一塊屬于陸續迭代完成的,承載很多失敗轉移的配置和控制功能在上面圖中是由管控中心提供的。 第 7 條主要是隨著業務量的上升,單日消息量越來越大后,使用了 MongoDB 來多帶帶存儲量最大的聊天記錄。 第 8 條是針對 1.0 版本消息輪詢效率低的改進,改進后的投遞方式如下圖所示:

不再是輪詢了,而是讓終端每次建立連接后注冊接入點位置,消息投遞前定位連接所在接入點位置再推送過去。 這樣投遞效率就是恒定的了,而且很容易擴展,在線人數越多則連接數越多,只需要擴展接入點即可。 其實,這個模型依然還有些小問題,主要出在離線消息的處理上,可以先思考下,我們最后再講。

3.0 經過了兩年的迭代式升級,單純從業務量上來說還可以繼續支撐很長時間的增長。 但實際上到 2014 年底我們面對的不再是業務量的問題,而是業務模式的變化。 這直接導致了一個全新時代的到來。

4.0 涅槃(2015 至今)

2014 年京東的組織架構發生了很大變化,從一個公司變成了一個集團,下設多個子公司。 原來的商城成為了其中一個子公司,新成立的子公司包括京東金融、京東智能、京東到家、拍拍、海外事業部等。 各自業務范圍不同,業務模式也不同,但不管什么業務總是需要客服服務。 如何復用原來為商城量身訂做的咚咚客服系統并支持其他子公司業務快速接入成為我們新的課題。

最早要求接入的是拍拍網,它是從騰訊收購的,所以是完全不同的賬戶和訂單交易體系。 由于時間緊迫,我們把為商城訂做的部分剝離,基于 3.0 架構對接拍拍又多帶帶訂做了一套,并獨立部署,像下面這樣。

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

復制工程,定制業務開發,多套源碼維護成本高

獨立部署,至少雙機房主備外加一個灰度集群,資源浪費大

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

而部署方式,只需要在雙機房建立兩套對等集群,并另外建一個較小的灰度發布集群即可,所有不同業務都運行在統一平臺集群上,如下圖。

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

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

細粒度的微服務做到了進程間隔離,嚴格的開發規范和工具庫幫助實現了異步消息和異步 HTTP 來避免多個跨進程的同步長調用鏈。 進程內部通過切面方式引入了服務增強容器 Armor 來隔離線程, 并支持進程內的多帶帶業務降級和同步轉異步化執行。而所有這些工具和庫服務都是為了兩個目標:

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

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

最后我們回到前文留下的一個懸念,就是關于消息投遞模型的缺陷。 一開始我們在接入層檢測到終端連接斷開后,消息無法投遞,再將消息緩存下來,等終端重連接上來再拉取離線消息。 這個模型在移動時代表現的很不好,因為移動網絡的不穩定性,導致經常斷鏈后重連。 而準確的檢測網絡連接斷開是依賴一個網絡超時的,導致檢測可能不準確,引發消息假投遞成功。 新的模型如下圖所示,它不再依賴準確的網絡連接檢測,投遞前待確認消息 id 被緩存,而消息體被持久存儲。 等到終端接收確認返回后,該消息才算投妥,未確認的消息 id 再重新登陸后或重連接后作為離線消息推送。 這個模型不會產生消息假投妥導致的丟失,但可能導致消息重復,只需由客戶終端按消息 id 去重即可。

京東咚咚誕生之初正是京東技術轉型到 Java 之時,經歷這些年的發展,取得了很大的進步。 從草根走向專業,從弱小走向規模,從分散走向統一,從雜亂走向規范。 本文主要重心放在了幾年來咚咚架構演進的過程,技術架構多帶帶拿出來看我認為沒有絕對的好與不好, 技術架構總是要放在彼時的背景下來看,要考慮業務的時效價值、團隊的規模和能力、環境基礎設施等等方面。 架構演進的生命周期適時匹配好業務的生命周期,才可能發揮最好的效果。


寫點程序世間的文字,畫點生活瞬間的畫兒。
微信公眾號「瞬息之間」,遇見了不妨就關注看看。

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/11745.html

相關文章

  • 京東海量運維的演進

    摘要:技術的迅猛發展,給運維人員帶來了越來越多的挑戰。運維的轉型迫在眉睫。京東運維技術服務的演進第一級稱作野蠻生長的階段。京東運維技術服務場景化運營部可能會有垂直的三個部門安全運維和數據。 IT 技術的迅猛發展,給運維人員帶來了越來越多的挑戰。只負責安裝、部署的傳統型運維的發展空間已經受到越來越多的擠壓:互聯網的快速發展,使各種軟件的部署、安裝已經不再是技術問題,各種開源解決方案也讓人懷疑運維人員...

    jemygraw 評論0 收藏0
  • 架構 - 收藏集 - 掘金

    摘要:淺談秒殺系統架構設計后端掘金秒殺是電子商務網站常見的一種營銷手段。這兩個項目白話網站架構演進后端掘金這是白話系列的文章。 淺談秒殺系統架構設計 - 后端 - 掘金秒殺是電子商務網站常見的一種營銷手段。 不要整個系統宕機。 即使系統故障,也不要將錯誤數據展示出來。 盡量保持公平公正。 實現效果 秒殺開始前,搶購按鈕為活動未開始。 秒殺開始時,搶購按鈕可以點擊下單。 秒殺結束后,按鈕按鈕變...

    Riddler 評論0 收藏0
  • 2017年TOP100summit15位大咖擔任聯席主席甄選最值得學習的100個研發案例

    摘要:以下將分別從五大技術專場維度介紹本屆峰會的部分聯席主席與精選案例。天時間集中分享年最值得學習的個研發案例實踐。 從萬維網到物聯網,從信息傳播到人工智能,20年間軟件研發行業趨勢發生了翻天覆地的變化。大數據、云計算、AI等新興領域逐漸改變我們的生活方式,Devops、容器、深度學習、敏捷等技術方式和工作理念對軟件研發從業者提出更高要求。 由麥思博(msup)有限公司主辦的第六屆全球軟件案...

    andot 評論0 收藏0
  • PPT領取 | 70+數據科學、架構演進等最佳實踐限時放送

    摘要:為幫助更多的從業者迅速提升自己的專業技能,現組委會決定將年度峰會的全部限時公開具體細則可在文末查看。由主辦的峰會將于月日在上海海神富特大酒店舉辦。分享領域覆蓋中臺機器學習知識圖譜智能語音與交互等熱門技術。 上世紀1950年人工智能被提出,直至2016年AlphaGo戰勝世界圍棋冠軍李世石后,人工智能迅速引起了全球的矚目,并推動起全球科技的浪潮。自動駕駛、人臉識別、語音交互技術等一擁而上...

    LucasTwilight 評論0 收藏0

發表評論

0條評論

marser

|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<