活動概要

在零售創新的趨勢影響下，恰逢一年一度618來臨之際，在高頻、高額、高密度的交易場景下，如何能為使用者提供穩定而流暢的購物流程？如何做到通過技術創新打造品牌和合作商的基礎設施服務商呢？

 

在剛剛結束的京東雲技術沙龍上海站活動中，多位京東的技術大咖與開發者面對面就零售業以及社交電商方面的核心技術以及成功解決方案進行了深入探討。

沙龍現場座無虛席

 

現場百餘位開發者熱情參與了交流與互動，尤其對“大促”下的資料庫服務、企業級監控的設計與實踐、社交電商的方方面面以及區塊鏈的智慧化溯源等諸多技術領域十分關注。

我們將沙龍中的部分內容整理、總結後放到了本文中，希望也能給相關的從業者們提供參考。（公眾號回覆“PPT0526”可獲取沙龍視訊&PPT）

 

 

京東資料庫服務如何應對“大促活動”？

京東雲產品研發部高階總監 郭理靖

 

眾所周知，京東商城業務繁多，很多業務在研發設計初期並不想選用太多種類的資料庫，因為並不知道著手的業務規模大小，所以開始選擇只使用MySQL是最簡單的，基於研發的速度考慮有時候還選擇寫入日誌和大欄位資料。隨著資料積累量增多，使用者規模擴大，未來會涉及資料切換的問題。因此，對於這些“後來居上”的業務，還是要進行一些資料架構優化的工作。

京東雲資料庫“上馬”了一些彈性資料庫服務，可以做到在一臺物理伺服器上同時配置多個數據庫，將單機利用率提升到比較高的水平；同時配置的靈活排程系統，能夠在兩個資料庫之間完成對壓力不大的資料庫資料遷移，能幫助客戶有效地進行成本控制。另外，在使用MySQL的基礎上，效能不可避免地受限於機器，京東商城內部還使用Jproxy這類分散式資料庫服務。郭理靖表示，在京東商城的實踐中，針對線上系統選擇構建兩個機房，分別是生產環境以及在災備環境。

 

 

關於智慧分析，京東雲在助力電商的過程中，一方面著手SQL日誌分析以及容量分析，例如連線數是不是一直在增長、IO壓力、CP壓力等；同時也嘗試做一些故障自愈以及磁碟清理等。

在“京東雲的服務實踐”方面，在雲端提供豐富的資料庫服務，例如MySQL、Percona、MariaDB、SQL Server、MongoDB等。從京東雲的統計角度來看，國內開發者使用MySQL可以高達95%，另外5%會使用Percona或者MarinDB。

 

 

從海外的調研資料來看，海外資料庫使用者大約80%以上使用者都在用MySQL，而20%以下的使用者會選擇用MariaDB和Percona，之所以這有麼大的差距，原因可能在官方在國內外的宣傳力度上明顯的區別的原因。另外京東雲還在安全、審計、日誌等諸多方面提供了豐富的功能，另外還提供了Binlog備份和下載。

 

 

在監控引擎方面，京東雲的嘗試也是比較細緻的，其中包括監控服務、報警服務等。值得提及的是，其中所有監控項都可以設定規則，比如CPU記憶體超過70%，就可以設定一個簡訊報警，而其中所有的指標都是對接到雲監控系統。“我們也支援只讀例項建立，需要只讀最大支援建立8個只讀例項，每個只讀例項都分配一個獨立域名，都可以用域名進行訪問。”他補充道。

 

 

談及資料運維，如何做到故障自動切換？京東云為此設計了比較完善的自動化系統。起初都是手動切換，選擇這樣的切換方式主要是擔心誤切的情況發生，畢竟很多服務通過域名連結資料庫，而域名的切換會造成一些延時，時間太長又是服務不可接受的。現在資料庫的故障都已經進化到自動切換了。

 

 

資料安全性方面，採用了雲硬碟加密的功能，對於使用者擔心的資料庫資訊“被偷窺”的問題，只要啟動了資料加密的功能，使用雲端RDS就可以充分放心享受其安全保障的服務。對於哪些IP可以訪問特定的資料庫這個事兒，靈活設定白名單即可。

重點強調的一點，在京東雲資料庫服務中還涉及到DRDS，所謂DRDS是分散式關係型資料庫，追溯本源是將京東商城上的Jproxy技術移植到京東雲上，主要作用還是在資料量特別大的情況下，單機無法支撐的前提下完成分庫分表，操控起來比較便捷。

DRDS服務主要解決了以下幾個困難：

1、隨著資料量和訪問量的增長，單機資料庫會遇到很大的挑戰，依賴硬體升級並不能完全解決問題，也就是單機資料庫容量瓶頸亟需被重視；

2、傳統資料庫容量擴充套件往往意味著服務中斷，很難做到業務無感知或者少感知等，被認為是擴充套件窘境；

3、更重要的一點，傳統資料庫使用成本較高，當業務資料訪問量增加到一定程度時，傳統資料庫需要依賴特定的高階儲存和小型機裝置，對於使用者而言，成本較高。但DRDS的使用，恰好就是可以有效地幫客戶進行成本控制。

 

 

具體來說，DRDS服務提供中介軟體，例如針對使用者表，可以將使用者表中的ID進行拆分。當需要查詢使用者時，並不需要修改SQL語句，DRDS會去解析語句，發現訪問的使用者資料表，使用者ID等資訊，其實DRDS起到的作用就是解析SQL語句、分發SQL語句以及彙總SQL語句給使用者端，方便使用者可以更多聚焦自己的業務邏輯開發等，同時有效提高整個效能。

同時，DRDS可以做到多臺部署，但值得注意的一點，整個DRDS系統性能受限於後端例項數量。簡單來說後端的例項量越多，DRDS的效能越好。通過實測，DRDS中介軟體給SQL帶來的延遲是非常低的，DRDS對SQL語句的解析速度進行了專門的優化 ，因此因中介軟體帶來的延遲基本也都可以忽略不計了。

DRDS本身不儲存資料，資料存放在後端的RDS MySQL 資料庫上。為保障系統穩定性，每個分庫所在的MySQL版本必須一致。DRDS會在每個RDS例項上建立8個分庫，另外還會單獨建立0號分庫，用於存放非拆分資料。

系統的最大處理能力取決於分庫的數量，因此在需要建立之後就應該規劃好整個系統的容量以及能力，比較好的做法是根據初步的規劃，前期使用小規格的MySQL例項，但足夠多的分庫數，這樣就可以預留出足夠的擴容能力。

在技術分享中，郭理靖還系統介紹了擴容的方方面面，例如兩核4G的DRDS，效能相對較小，如果將後端RDS升級到更高配置，就被稱為是垂直擴容，操作起來十分容易。無論是水平擴容還是垂直擴容，儘管具體的操作方法不同，但過程平滑且隨時隨地都是共通的。

 

   

儘管DRDS 與傳統的單機資料庫相比，在擴充套件性上有了巨大的提升，但同時也帶來了一些限制，例如可保證同一個分庫中的事務一致性，但不支援分散式事務；只支援單個分庫內的join操作，不支援跨庫的join；只支援UTF8字符集，因此並不是任何基於MySQL的應用都可以無疑遷移到DRDS上，還需要進行一些改造。

 

 

企業級監控系統設計與實踐

  京東雲產品研發部總監 鄭永寬

 

作為本場沙龍的第二位分享嘉賓，京東雲產品研發部總監鄭永寬為開發者們現場帶來了主題為“企業級監控系統設計與實踐”的技術演講。

 

監控是什麼？監控是運維生命線。

監控解決什麼問題？遠遠不止發現問題！

監控還需要解決發現問題以後的定位，和定位後的止損，從而降低故障MTTR，即故障平均恢復時間。像京東這樣的大體量電商，如果發生不明原因的宕機所導致的損失是十分慘重的。為了高效解決降低故障恢復時間的問題，在故障發生之前提前做好相應故障的恢復預案；在故障發生之後明確故障型別並且準確定位故障，是非常有效的手段。

為了解決快速響應的問題，監控系統通常需要具備豐富的資料採集手段、多維度資料實時聚合計算、準確的異常檢測、及時的告警通知、可定製的dashbord、根因定位與輔助決策推薦，以及預案平臺等功能，通過以上功能實現快速止損、業務高可用/可擴充套件等目標。

根據以上功能定位，京東雲會針對每個系統不同的業務特徵，提供故障恢復預案推薦，用以來保證系統的高效運轉；對於監控系統來說，無論是發現問題、定位問題還是解決問題，瞭解其中迴圈迭代的系統狀態十分重要，京東雲的監控平臺根據豐富的監控手段可提供可靠有效的系統運維情況反饋，同時基於監控資料和業務分析進行多樣化的預案推薦，幫助業務快速恢復。

 

 

具體來說，我們首先定義了一套統一的監控標準：即監控需要覆蓋基礎-存活-效能-業務四個層面，從而保證了採集資料的全面，進而避免監控遺漏。即基礎監控涵蓋了機器的基本指標，比如cpu、記憶體、硬碟等；存活監控則聚焦機器和服務程序的存活性；效能監控關注服務對外表現的效能指標，比如PV、平響、錯誤碼等；業務監控則是從使用者角度，監控系統是否提供正常服務。進一步，根據不同的報警，我們可以定位到相應的問題，再輔以對應的預案平臺，從而確保了故障第一時間定位與恢復。

 

 

監控系統需要保證資料採集手段豐富化、計算聚合多樣化、儲存高效化以及資料展示有效化等幾個方面。其中資料的儲存以及資料視覺化展示等是監控系統最基礎的需求，不管多龐大的運維繫統都是如此。

京東雲採用多種採集方式，包括Agent採集，API推送，外部探測點。通過遍佈全國的探測點，可以模擬發起各種協議的訪問，同時提供API推送介面，支援使用者自己傳送資料過來，可以進一步展示使用者需要的資料。另外我們自研的tsdb時序資料儲存，採用基於Cassandra+自研cache+esmeta的方案，我們將最近3h的資料存入自研cache，增加了查詢的時效性和可靠性。其中自研cache基於的Facebook論文gorilla實現，追求極致的壓縮比。通過這些手段，儲存的空間可以降低到1/10，同時保證了查詢效能。

另外京東雲的監控CMDB表現出色。首先CMDB可以將資源和業務同時管理起來，這是監控CMDB解決的第一個問題；另一方面，大規模叢集中的某臺機器發生問題後，通過JNS名字服務可以迅速定位受影響的業務，並基於CMDB提供業務/應用/叢集的監控配置推薦，這是監控CMDB重點突出的地方。

 

    

談及如何定位問題，鄭永寬總結道，首先監控視覺化是關鍵一環，多維度的聚合計算使資料更有意義，這是基於京東雲多年的運維經驗總結得到的。京東雲的監控體系可以定位多種故障原因，例如某一業務是否有變更，是否配有相應的報警，網路等資源是否異常，是哪個業務出現的問題等……通過以上方面的監控，我們可以知道某一業務的故障恢復操作的執行情況，此方式對故障快速定位以及查詢故障來源非常有效。基於以上確認故障原因的能力，京東雲快速迭代升級開發了變更視覺化產品，對可能導致故障發生的所有問題來源進行事件監控，從上線操作、配置變更的單任務監控到平臺全域性事件的監控，進一步助力京東雲監控體系定位問題能力的提升。

 

 

問題定位後，為使使用者接收到有意義的報警進而快速回復問題，我們對異常問題進行分析合併，京東雲支援各種策略的合併，可按照固定接收人報警、不同業務範圍報警、固定時間報警等策略進行報警，減少告警風暴，另外對於通知下游的對接，我們實現了郵件、簡訊、微信、電話等多種方式報警。

未來京東雲還會著手配置化管理功能的優化，更好支援事件自動恢復。“結合監控CMDB和報警設定，我們可以真正把故障和報警聯動起來，對於相關的報警事件，監控系統可以自動調取對應的預案，從而達到系統的故障自愈的目標。”

 

 

社交電商SaaS產品技術架構

京東雲應用研發部社交電商負責人 趙金勇

 

從整個電商發展來看可以被總結為”四化“，分別是去中心化、場景化、碎片化以及個性化。我們發現流量成本越來越高，“帶領著”獲客成本、品牌商運營成本也一路居高不下，這恐怕就是品牌商自己不做運營選擇其他途徑的原因，正所謂“品牌形象宣傳去中心化” 就是這個道理。

 

 

所謂社交電商，必然與”社交”關係密切，進而社交工具自然必不可少。除了憑藉五花八門的推送工具，京東雲社交電商還憑藉京東與生俱來的海量商品以及優勢供應鏈屢獲成績。基於京東大資料營銷的能力，海量使用者的精準畫像以及商品推銷、智慧選品等這些穩定可靠的基礎服務來打造系統。

 

 

京東社交電商支援三級分傭自動結算、靈活設計類目返傭點數、自定義會員晉升規則、自動統計團隊銷售業績以及豐富的營銷推廣玩法等。

技術架構方面，京東雲商微服務架構是資料庫、硬碟以及統一運維。其中公共平臺、開放平臺、裝修服務還有市場、資料搬運、流量統計等系統都是基於微服務架構，業務層提供統一的、原子化的API介面， 上層業務在這些介面之上構建而成。”

 

 

京東社交電商分三端，分別是買家端、供應商端和PC端。社交電商的系統已接入到京東龐大的商品池，大家可以在整體的商品池中挑選自己的產品，共同的良性生態就此構建。

 

 

此外，我們還提供基於京東大資料打造的鵲橋外掛，鵲橋連線人和貨，完成精準營銷。從交易完成之後，所有交易資料和貨源資料以及貨源行為資料彙總到一起，京東大資料平臺就對所有的資料進行分析，完成實時監控，在此基礎上基於資料驅動彰顯出廣告優化、客群聚類、千人千面、自動化營銷。

“整體的系統是基於京東雲技術來構建，京東雲作為京東對外賦能的視窗，提供一些可信賴的基礎服務，包括技術服務以及系統支援，這部分主要涉及電商雲”。

 

 

舉個例子來說，北京網庫資訊科技股份有限公司是國內基於單品供應鏈的B2B電子商務服務公司，以打造中小微企業的全產業正品採購平臺為使命，關注企業優勢單品的線上供應鏈應用，服務包括線上採購、線上批發分銷、線上定製等。

自成立以來，公司服務平臺積累中小企業使用者資料1800多萬，旗下B2B平臺註冊中小企業會員近200萬家，為全國超過30萬家中小企業提供基礎B2B電子商務應用服務，並與其中2400多傢俱有單品優勢的實體企業共同構建了單品電子商務交易平臺，在此過程中與京東社交電商開展了密切合作。

 

 

基於企業級區塊鏈框架系統JD Chain的技術實踐

京東數科區塊鏈產品創新負責人 張作義

 

京東區塊鏈品牌名叫京東智臻鏈，京東區塊鏈的架構體系分為JD Chain和JD BaaS（Blockchain as a Service）兩部分，JD Chain作為核心引擎，在資料賬本、共識協議、密碼演算法、儲存等方面引入新的研究成果和工程架構，解決處理效能、伸縮性、擴充套件性、安全性等基礎和關鍵的技術問題，建立創新性的技術架構和應用方案。JD BaaS是服務平臺，提供靈活易用和可伸縮的區塊鏈系統管理能力，無縫融合包括JD Chain、Fabric在內多種區塊鏈系統的部署管理，向企業級使用者提供公有云、私有云及混合雲環境快速部署能力，降低企業使用成本，加快應用落地。 

談及服務層，大家比較關注身份、許可權、資源排程管理、證書管理還有版本控制、日誌記錄等。“在今年釋出的《2019京東區塊鏈技術實踐白皮書》中，5大類、14個應用案例的資訊都在列。”

如果是BaaS可以被認為是汽車發動機的“底盤”，有了底盤就可以圍繞底盤配置其他零部件，JD Chain就是裡面的“發動機”，適用於不同的場景的區塊鏈應用場景。BaaS幫助企業或者開發者搭上區塊鏈的“順風車”，而且京東也整合了很多在BaaS平臺基礎上的應用服務。

“JD Baas、JD Chain是京東區塊鏈的兩大技術架構體系。基於區塊鏈去匹配各種各樣的應用場景，主題就是怎麼用區塊鏈去創造真實的價值，也可以被稱為是可持續價值。”

 

 

京東 JD BaaS平臺比較重要的特色，就是身份認證服務，這也是區塊鏈和聯盟鏈不同的地方。聯盟鏈是一個許可鏈，京東方面身份認證服務，例如身份註冊、企業證照稽核等一系列內容稽核加入區塊鏈，以保障聯盟鏈各主體的合規性、關聯性、安全性。

在這個過程中，無論是企業還是個人的身份認證資訊都會儲存到區塊鏈中，在區塊鏈節點之間做一個協同，包括對外展示都是基於身份認證發生一系列關係，這較之無認證的關係發生將有很大的區別，也是未來比較看好的方向。

 

 

京東自主智慧財產權區塊鏈底層框架JD Chain於2019年3月正式宣佈開源，在“萬級交易處理、秒級交易確認、海量賬戶和交易、動態伸縮、賬戶儲存、多核並行、密碼演算法”等方面符合經典區塊鏈對儲存、對計算的定義和要求，同時還把Key Value結構用現有recycle極大處理效率，這也是可以支援更高速度的原因。

 

 

零售、物流與數字科技等領域，是京東區塊鏈主要服務的方向。例如參與廣州網際網路法院“網通法鏈”建設、區塊鏈增值稅專用發票試點、與宿遷的電子證照打通試點等，實際賦能數字存證、電子發票、電子證照等方面的諸多實際應用。 

舉個例子來說，區塊鏈的數字存證。我們參與了北京網際網路法院和廣州網際網路法院的區塊鏈專案，需要把使用司法服務的內容搭載一條司法聯盟鏈，主要可以實現什麼作用呢？打比方說簽署一個合同，去公證處公證是必要流程之一，如果有了這個聯盟鏈，所有的操作都可以在司法‘朋友圈’實現。司法聯盟鏈可被理解為是數字簽名的技術，以此判斷合同簽署的合法性，同時簽完的合同會及時備份到這條聯盟鏈中，這樣，法院、公證處以及司法鑑定部門，包括合同雙方的簽署人都能夠及時獲知該資訊。

 

 

此外，京東區塊鏈在防偽追溯方面做得最多，京東區塊鏈防偽追溯平臺曾經受住四五次大促考驗，使用者復購率、使用者轉化率明顯提高，京東目標客群對追溯對消費體驗升級、商品品質保證的高度認可。

 

 

 

以上就是此次沙龍活動分享的大致內容。

關注微信公眾號"京東雲開發者社群"，

回覆“PPT0526”獲取課程視訊&PPT。

 

除了大促技術也可點選→“京東雲”瞭解618大促活動！

全場低至1折哦！

 

 

---