京東物流系統架構演進中的最佳實踐
每年“雙十一”都是網購狂歡節，假設當天哪個電商系統出現系統不可用，那幾乎是災難性的，不僅會導致使用者快速流失，而且，公司將承受重大損失，甚至在未來競爭中失敗。即使對於創業公司，在當前獲取使用者如此昂貴和競爭如此激烈的情況下，系統不可用的代價也是非常大的，會遭到使用者的拋棄而失敗。
青龍系統作為京東後臺物流系統，系統高可用也同樣重要，因為，即使在平時，物流系統出現不可用的情況，會造成訂單時效履約失敗，極大影響使用者體驗，這也是無法接受的；同時，系統不可用也會導致數十萬員工無法正常工作，對於效率極大影響，公司損失也非常大。我們在研發過程中，對於系統高可用，也積累了豐富經驗，主要包括：合適的架構方案；大系統小做，服務拆分；併發控制，服務隔離；灰度釋出；全方位監控報警；核心服務，平滑降級。
首先是選擇合適的架構方案。網際網路系統一般可以分為前端應用系統和後端資料庫系統，前端應用系統實施分散式叢集部署技術上是比較成熟的，後端資料庫系統實現異地多活技術難度很大，目前也只有阿里，京東這樣的公司才真正實現。因此，對於大多數應用，前端應用雙機房叢集部署，後端資料庫系統採取成熟的主備從的模式，也就是單個機房作為寫入，備庫在另外機房，可以快速進行切換，讀庫雙機房部署，是優選的方案。對於這個架構方案，存在跨機房寫延長的問題，可以根據場景利用非同步的方式進行解決，一般也是沒有問題的。對於青龍系統來講，也有些特別，利用分揀中心的本地伺服器和操作人員的裝置，實現離線生產，進一步提高可用性。
大系統小做，服務拆分，是網際網路應用的特點，也符合敏捷交付的理念。對於傳統軟體，如Windows，Office等，都要經過一個漫長的需求，研發，測試，釋出週期，在“唯快不破”的網際網路時代，這顯然是無法滿足業務要求的，即使最後上線，也可能因為週期太長而不再適用了。因此，對一個網際網路服務，一般會首先完成最核心的功能，快速進行上線，不斷進行迭代，後續再進行輔助功能跟進。對於核心功能，隨著使用者數的增加，會不斷進行服務拆分，如何進行拆分，拆分到什麼樣的粒度，是不是微服務是解決問題的銀彈？這些都要根據實際的應用場景來評估，絕不是越細越好，而是要達到一個優雅的平衡。
併發控制，服務隔離。併發控制，現在已經成為網際網路服務基本要求，在應用程式端和資料庫端，也都有成熟的方案，如果忽略，可能造成災難性的後果。對於重要的服務，還要進行隔離，例如同一個服務，要提供給內部呼叫，公司級呼叫和公司外開放服務呼叫，開放服務呼叫者我們一般認為是不可靠的，甚至有可能是惡意的，如果不進行隔離，開放服務呼叫有可能使得服務資源佔滿，對內也無法提供服務。從技術上，可以是硬體級隔離，全部隔離，也可以是前端應用的隔離。
灰度釋出也是網際網路服務的一大利器，有了灰度釋出，才使得快速迭代成為可能，並且，很多服務因為各種原因線下也是很難測試的，只能在線上測試。如果沒有灰度釋出，只能全量釋出，就存在較長測試周期問題，如果沒有重複勉強上線，就存在很大的系統崩潰的風險。按照使用者，區域進行灰度釋出是比較常用的方法。
全方位監控報警，可以分為技術層面和業務層面，技術層面包括對CPU，記憶體，磁碟，網路等的監控，業務層面，包括對處理積壓量，正常的業務量等。做到全方位監控，才有可能在影響使用者之前，提前解決問題，提升系統可用性。否則，等使用者發現問題，在很大的壓力下，技術團隊更難處理，導致系統不可用時間加長。
最後就是，核心服務，平滑降級。任何技術手段，都不可能保障100%可用，並且，即使能夠做到，其代價也是巨大，不經濟的，因此，對於核心服務來講，能夠平滑進行降級，提供基礎的服務，也是非常重要的。對於青龍系統來講，就利用分揀中心本地伺服器和操作人員的裝置，研發了離線生產系統，來應對集中服務萬一不可用的情況。
舉兩個案例來做簡單說明。
第一個是電子簽收的案例。電子簽收對於京東物流意義重大，不僅提升效率降低成本，而且實現了所有業務資料化，為智慧物流奠定基礎。我們最早做的時候，也是遵循了MVP原則，開發了一個很簡單的原型系統，內部測試可行後，才進行第二步，也就是和京東雲合作，接入京東雲圖片處理系統，支援百億張圖片儲存，找到安全認證夥伴，接入安全認證服務。這些完成後，我們就開始線上測試，不斷提升使用者體驗。第三部，在大規模推廣之前，我們完成了系統降級服務，也就是確保京東雲，安全認證服務，甚至，我們自身的電子簽收管理系統不可用的情況下，如何保證配送員的業務不受到影響。
第二個案例是去IOE的案例。青龍系統最初也是基於IOE開發，後來，隨著系統規模的擴大，去IOE成為必然，在整個過程中，我們也是遵循了很多架構實踐。例如，第一步，我們是先去IE（IBM小型機和EMC儲存），將核心業務系統庫拆到Oracle PC伺服器上，並且，將資料進行同步，在驗證服務完成後，把讀服務遷到小型機，穩定後，再遷全部服務，並且，保證服務可以隨時遷回。第二步，我們開發了雙寫服務，逐步將Oracle，遷移到MySQL叢集。第三步，完成MySQL的資料聚合，確保資料服務。在整個過程中，都確保了系統在任何情況下，都可以會退，確保業務正常。
相關推薦
京東物流系統架構演進中的最佳實踐
每年“雙十一”都是網購狂歡節，假設當天哪個電商系統出現系統不可用，那幾乎是災難性的，不僅會導致使用者快速流失，而且，公司將承受重大損失，甚至在未來競爭中失敗。即使對於創業公司，在當前獲取使用者如此昂貴和競爭如此激烈的情況下，系統不可用的代價也是非常大的，會遭到使用者的拋棄而失敗。 青龍系統作為京東後臺物流系
京東618：一箇中心五個原則，談談物流系統的大促優化實踐
作者:者文明 編輯:木環、郭蕾 在京東的訂單流鏈路中，可以簡單的劃分為訂單前和訂單後兩部分，我們在京東主站上搜索商品、瀏覽商品詳情、把商品加入購物車、提交併支付訂單等環節屬於訂單前，訂單提交之後，訂單資訊流就進入訂單後的物流系統部分。每逢 618 大促期間，大家可能會更多的聚焦到網站 PV、秒殺系
騰訊技術工程 |騰訊海外計費系統架構演進
lin app https aqi 鏡像 靜態編譯 可能 快速發布 遠程代理 作者簡介：abllen，2008年加入騰訊，一直專註於騰訊計費平臺建設，主導參與了騰訊充值中心、計費開放平臺、統一計費米大師等項目，見證了米大師從0到1，業務營收從PC到移動多終端再到全球化的跨越
jmeter使用中最佳實踐方法
clu control 模擬 rem 添加 語言 html 需求 threads 官方文檔（Best Practices-最佳實踐部分摘選）：https://jmeter.apache.org/usermanual/best-practices.html 一、線程組 Use
分庫分表技術演進&最佳實踐
移動網際網路時代，海量的使用者每天產生海量的數量，比如： 使用者表 訂單表 交易流水錶 以支付寶使用者為例，8億；微信使用者更是10億。訂單表更誇張，比如美團外賣，每天都是幾千萬的訂單。淘寶的歷史訂單總量應該百億，甚至千億級別，這些海量資料
淘寶系統架構演進
參考：https://baijiahao.baidu.com/s?id=1582105537948510772&wfr=spider&for=pc https://baijiahao.baidu.c
Kubernetes系統架構演進過程與背後驅動的原因
1、背景 各種平臺都會遇到一個不可迴避的問題，即平臺應該包含什麼和不包含什麼，Kubernetes也一樣。Kubernetes作為一個部署和管理容器的平臺，Kubernetes不能也不應該試圖解決使用者的所有問題。Kubernetes必須提供一些基本功能，使用者可以在這些基本功
分庫分表技術演進暨最佳實踐
每個優秀的程式設計師和架構師都應該掌握分庫分表，這是我的觀點。 移動網際網路時代，海量的使用者每天產生海量的數量，比如： 使用者表 訂單表 交易流水錶 以支付寶使用者為例，8億；微信使用者更是10億。訂單表更誇張，比如美團外賣，每天都是幾千萬的訂單。淘寶
京東推薦系統架構揭祕：大資料時代下的智慧化改造
在電商領域，推薦的價值在於挖掘使用者潛在購買需求，縮短使用者到商品的距離，提升使用者的購物體驗。 京東推薦的演進史是絢麗多彩的。京東的推薦起步於2012年，當時的推薦產品甚至是基於規則匹配做的。整個推薦產品線組合就像一個個鬆散的原始部落一樣，部落與部落之前沒有任何工程、演算法的交集。201
圖解分散式系統架構演進之路
介紹 分散式和叢集的概念經常被搞混，現在一句話讓你明白兩者的區別。 分散式：一個業務拆分成多個子業務，部署在不同的伺服器上 叢集：同一個業務，部署在多個伺服器上 例如：電商系統可以拆分成商品，訂單，使用者等子系統。這就是分散式，而為了應對併發，同時部署好幾個使用者系統，這就是
去哪兒網支付系統架構演進(上)
去哪兒支付系統自2011年搭建以來，在五年的時間裡逐漸從一個高耦合的單一系統發展為眾多子系統組成的高併發、高可用、支援多種交易支付業務的分散式系統。業務從最初的非代收到現在多種非代收、代收場景的支援，B2B業務的從無到有，支付方式從單一網銀支付到現在銀行卡、拿去花、代金券、紅包、立減、積分、趣遊寶等多種的組合
海量資料的分庫分表技術演進，最佳實踐
每個優秀的程式設計師和架構師都應該掌握分庫分表，移動網際網路時代，海量的使用者每天產生海量的數量 使用者表 訂單表 交易流水錶 以支付寶使用者為例，8億；微信使用者更是10億。訂單表更誇張，比如美團外賣，每天都是幾千萬的訂單。淘寶的歷史訂單總量應該百億，甚至千億級別，
微服務架構上雲最佳實踐（轉自阿里中介軟體）
摘要：7月27日，雲棲社群、阿里中介軟體舉辦了首屆阿里巴巴中介軟體技術峰會，揭祕阿里10年分散式技術乾貨。在首屆阿里巴巴中介軟體技術峰會上，具有10年研發經驗的阿里巴巴中介軟體技術專家李顏良結合EDAS團隊上雲兩年多以來積累的經驗為大家分享瞭如何進行微服務拆分、微服務架構上雲最佳實踐以及微服務架構常用的模式，
阿里架構師，講述網際網路分散式系統架構設計中的“高併發”
一、什麼是高併發 高併發（High Concurrency）是網際網路分散式系統架構設計中必須考慮的因素之一，它通常是指，通過設計保證系統能夠同時並行處理很多請求。 高併發相關常用的一些指標有響應時間（Response Time），吞吐量（Throughput），每秒
低延遲系統的 11 個最佳實踐
八年前，谷歌發現每 500ms 的延遲會讓網路堵塞程度增加 20%，而亞馬遜也察覺 100ms 的延遲會使銷量降低 1%。從那以後，開發者就在減少延遲方面絞盡腦汁，以至於前端開發者試圖從他們用的 JS、CSS 甚至 HTML 中擠出每一毫秒。這篇文章接下來要介紹的就
ActiveMQ架構設計與最佳實踐
ActiveMQ是最常用、特性最豐富的訊息中介軟體，通常用於訊息非同步通訊、呼叫解耦等多種場景，是JMS規範的實現者之一。 一、架構設計概要 ActiveMQ提供兩種可供實施的架構模型：“M-S”和“network bridge”；其中“M-S”是HA方案，“
【物流系統】——C#中Oracle批量匯入（一）
前提 匯入資料量1W，因為在小編做這個xml匯入之前系統中已經有execl匯入了，小編也沒多想，就按照前人的封裝做了一版，數量不大的時候使用起來完全沒有毛病。 封裝在DbHelper中，執行多條SQL語句,實現資料庫事務的方法。資料庫用的Oracle
核心交易系統架構演進
key bdb 不存在 金額 分片 ffd 折扣 模版 amp 前言 隨著雙11進入千億時代，電商平臺正在向“全球化，娛樂互動化，無線化，全渠道”發展。 為實現全民互動，電商平臺會進行低價預售，狂歡紅包，購物券，紅包雨，商品半價，滿n減1等多種促銷方式。 核心交易鏈路設計
新手入門：零基礎理解大型分散式架構的演進歷史、技術原理、最佳實踐
本文引用了阿豪的微信公眾號文章分享，感謝原作者的分享。 1、前言 隨著社會的發展、網際網路技術的進步，以前的大型機服務端架構很顯然由於高成本、難維護等原因漸漸地變得不再那麼主流了，替代它的就是當下最火的網際網路分散式架構。 從若干年前大行其道的傳統大型機到如今的分散式架構，技術發展已經經歷了好幾個階段，