京東是中國最大的自營式電商企業(yè)剪菱，京東的應用系統(tǒng)繁多摩瞎，系統(tǒng)間調用邏輯復雜；作為電商平臺孝常，響應要求塊旗们，保證良好的用戶體驗；面對618之類的促銷活動构灸，要能支撐訪問量劇增的情況上渴，因此京東技術架構需要做到快、準喜颁、穩(wěn)稠氮，即高可用“肟《決戰(zhàn)618》這本書里的很多方案都給我們提供了解決問題的思路隔披。

未來已來
要應對各種可能存在的對網絡、對應用的攻擊寂拆；要做好系統(tǒng)監(jiān)控奢米，提前根據業(yè)務預估，進行流量壓測纠永；梳理應急預案鬓长，對預案進行實戰(zhàn)演練〕⒔總之涉波，目的就是確保系統(tǒng)的高性能，在遇到一場情況時都能快速處理茂装，并可以進行系統(tǒng)怠蹂、機房及網絡的各種切換。
伴隨著京東整體技術水平的不斷進步少态，備戰(zhàn)的智能化日益提升城侧，很多預案都可以利用機器自動執(zhí)行，人在其中大都是起到查漏補缺彼妻、監(jiān)控的作用嫌佑。

技術備戰(zhàn)利器
“工欲善其事，必先利其器侨歉∥菀。”數年的618備戰(zhàn)，研發(fā)團隊不斷積累經驗幽邓，設計并制造了兩個重要武器——ForceBot與Chaos Monkey炮温。ForceBot（全鏈路軍演壓測系統(tǒng)）意為“軍演機器人”，它部署在京東各地的CDN節(jié)點牵舵，能夠發(fā)起模擬真實用戶的柒啤、超大規(guī)模的倦挂、購物流程全覆蓋的訪問流量，以便進行有效的軍演壓測担巩。Chaos Monkey（全場景故障演練系統(tǒng)）是一套工具鏈方援，用以進行各個場景的、不同層面的故障模擬涛癌，包括網絡犯戏、機器、OS拳话、DB先匪、中間件、核心服務假颇、流量入口胚鸯、IDC。通過Chaos Monkey笨鸡，各團隊可以驗證自身系統(tǒng)在出現故障情況下的可用性表現與應對的降級能力。

首頁優(yōu)化之路
（1）數據檢驗坦冠。對每個依賴的服務進行了嚴格的檢驗形耗，并檢查數據內容是否符合規(guī)范，是否有空字段拋出辙浑。如遇異常情況則自動降級激涤，且返回一份幾分鐘前的無錯數據，保證數據的有效性判呕，杜絕出現天窗情況倦踢。
（2）多級緩存。在既要保證效率侠草，又要展示個性化數據的情況下辱挥，技術人員在設計中使用多級緩存來盡量減少后端服務壓力。
（3）降級開關边涕。為了防止首頁出現異常情況晤碘，設計了自動和手動的降級開關。同時充分建立各類系統(tǒng)容災方案功蜓，保證首頁在極端情況下可以隨時切換至上一個正常版本园爷，從而確保京東首頁的正常展示和運行。
（4）托底頁面式撼。定時向CDN推送一份包含所有請求的靜態(tài)文件夾童社，這樣保證在源服務器網絡異常不能訪問的極端情況下，還能有一份完整的頁面展示給用戶著隆。
（5）前端降級扰楼。后端接口可能偶爾會出現錯誤甘改，或者直接宕機，但是不能因為接口出錯而使得頁面顯示出現錯誤灭抑，這就需要前端來配合給出一套合理的災備方案十艾。

網站監(jiān)控
通常在一個大型的web項目中有很多監(jiān)控，比如對后端的服務API腾节，接口存活忘嫉、調用、延遲等監(jiān)控案腺，這些一般都用來監(jiān)控后臺接口數據層面的信息庆冕。但是對于大型網站系統(tǒng)來說，從后端服務到前臺展示會有很多層劈榨，如內網VIP访递、CDN等。通常的網站監(jiān)控并不能準確地反映用戶看到的前端頁面狀態(tài)同辣，比如：頁面第三方系統(tǒng)數據調用失敗拷姿、模塊加載異常、數據不正確旱函、空白開天窗等响巢。這時候就需要從前端DOM展示的角度去分析和收集用戶真正看到的東西，從而檢測出頁面是否出現異常問題棒妨。
解決方案：
1踪古、前端規(guī)則錄入。這是一個獨立的web系統(tǒng)券腔，系統(tǒng)主要用來收集用戶錄入的頁面信息伏穆、頁面對應的規(guī)則、展示錯誤信息纷纫。通過調用后端頁面抓取服務來完成頁面檢測的任務枕扫，系統(tǒng)可以創(chuàng)建三種類型的檢測頁面：常規(guī)監(jiān)控、高級監(jiān)控涛酗、可用性監(jiān)控铡原。
（1）常規(guī)監(jiān)控。錄入一個頁面地址和若干檢測規(guī)則商叹。注意這里的檢測規(guī)則燕刻，研發(fā)人員把常用的一些檢測點抽象成了一條類似測試用例的語句。每條規(guī)則用來匹配頁面上的一個DOM元素剖笙，用DOM元素的屬性來和預期做匹配卵洗，如果匹配失敗，系統(tǒng)就會產生一條錯誤信息。
（2）高級監(jiān)控过蹂。主要用來提供高級頁面測試的功能十绑，一般由有經驗的工程師來撰寫測試用例。這個測試用例寫起來會有一些學習成本酷勺，但是可以模擬web頁面操作本橙，如：鼠標單擊、移動等事件脆诉，從而做到精確捕捉頁面信息甚亭。
（3）可用性監(jiān)控』魇ぃ可用性監(jiān)控測重于對頁面的可訪問性亏狰、內容正確性等比較嚴重的問題做即時監(jiān)控。通常這類頁面只需要在程序里面啟動一個線程不斷地去獲取頁面HTML偶摔，就可以對結果進行檢測匹配了暇唾，所以選擇了Node.JS來完成這種網絡密集型任務。
2辰斋、主動錯誤上報
（1）頁面腳本執(zhí)行錯誤監(jiān)控策州。頁面引入一段監(jiān)控腳本來監(jiān)聽頁面生成錯誤事件返回的錯誤信息，自動上報給后端服務亡呵，在系統(tǒng)里面可以匯總所有報錯信息抽活，以及對應的客戶端瀏覽器版本、操作系統(tǒng)锰什、IP地址等。
（2）頁面主動上報丁逝。這個功能需要工程師在代碼中調用錯誤上報API汁胆，來主動提交錯誤信息。主要使用的場景有：頁面異步服務延時無響應霜幼、模塊降級托底主動通知等嫩码。

交易平臺架構——基礎用戶服務
用戶基礎服務中間件根據調用方的重要程度、調用量罪既、訪問的用戶信息字段等對數據層的訪問進行動態(tài)規(guī)劃：主數據還是從數據铸题，是否擊穿到數據庫等，針對核心交易調用的數據琢感，隔離出獨立的數據緩存，同時支持自動容錯訪問到共享的基礎用戶數據。在數據隔離方面梢夯，按敏感度劃分阿蝶，敏感數據進行加密存儲（如密碼）、掩碼傳輸（如昵稱）柬甥；按訪問頻率劃分饮六，訪問頻繁的持久化存儲到緩存其垄，非頻繁訪問的進行臨時存儲；按調用方對用戶服務的敏感級別劃分卤橄，對敏感級別高的接入方绿满，其用戶數據單獨隔離存儲。在接口隔離方面窟扑，用戶內部接口與外部調用接口隔離喇颁，數據更新接口和數據查詢接口隔離，交易主流程依賴的服務接口跟非交易主流程依賴的服務接口隔離辜膝。這樣就有效保障了交易主流程的可靠无牵、穩(wěn)定，經過了歷年618考驗厂抖，基礎用戶服務已穩(wěn)如磐石茎毁。

交易平臺質量控制
1、自動化測試：能在軟件開發(fā)流程中提升效率的忱辅、能在質量保證環(huán)節(jié)提升質量的自動化是可以去做的自動化測試七蜘，不為了自動化而去做自動化
（1）初始化測試數據
（2）調用被測應用接口
（3）結果對比
問題和挑戰(zhàn)：存儲的分庫分表、接口入參不能重用墙懂、測試執(zhí)行的自動化調度橡卤、測試結果的可視化、與持續(xù)集成系統(tǒng)的接入等损搬。
線上環(huán)境的日常測試中碧库，我們的初期目標定位于線上多實例的存活、連通性驗證巧勤。如果是HTTP接口嵌灰，可以遍歷某個應用下的所有IP，針對每個IP單獨發(fā)送請求颅悉，檢查返回值是否符合預期沽瞭。如果是JSF接口，我們可以針對每個分組剩瓶，遍歷分組下所有的實例IP驹溃，在上線過程中灰度發(fā)布，發(fā)布完成后進行驗證延曙，驗證沒問題后再進行下一個分組的發(fā)布豌鹤。
在618期間的線上自動化測試場景中，我們更關注流量高峰下系統(tǒng)的穩(wěn)定性搂鲫，系統(tǒng)會不會出現因為性能問題造成響應慢傍药、拒絕服務的問題。為了解決這一問題，我們在線上從各個流量入口（PC端拐辽、微信端拣挪、App端、M端等）來發(fā)起請求俱诸，針對核心系統(tǒng)的核心業(yè)務菠劝，在UI層面進行自動化巡檢，一旦發(fā)現如頁面響應時間過長睁搭、超時等問題赶诊，立刻報警，團隊成員立刻介入园骆，第一時間定位問題舔痪、解決問題。
在線上環(huán)境的自動化測試中锌唾，我們也嘗試過對線上的讀寫接口進行業(yè)務邏輯的回歸驗證锄码，只不過如何保證測試數據與線上真實數據的分離，如何保證線上測試執(zhí)行不影響線上流量晌涕，如何對測試過程寫入的臟數據進行過濾刪除等滋捶，都是需要考慮的問題。
2余黎、線上壓測
性能測試模型由三部分組成：web管理工具集群重窟、Agent代理集群和目標服務器集群。在該模型中惧财，Controller可通過HTTP協議調用Agent測試代碼中的測試場景巡扇，再由Agent對目標服務器發(fā)起請求，以完成整個壓測過程垮衷。該模型有三個優(yōu)點：
（1）管理端是Web管理頁面霎迫，可以統(tǒng)一發(fā)送請求、統(tǒng)一收集數據帘靡，結果準確、可靠瓤帚。
（2）支持在線編輯腳本描姚、啟動場景，同時支持多用戶同時操作戈次，大大降低性能測試場景執(zhí)行和推廣的難度轩勘。
（3）Agent端支持水平擴展，通過J-one.jd.com（統(tǒng)一工作平臺）任意擴展Agent怯邪，最大限度模擬生產環(huán)境的流量绊寻。目標服務器作為壓力承受端，也可以水平擴展，模擬多服務器負載均衡澄步、容災等場景冰蘑。
性能分析：在分布式框架下，針對不同的系統(tǒng)應用村缸、不同的測試目標祠肥，以及不同的性能關注點，根據性能指標的表現梯皿，采取逐步定位仇箱、從外到內、由表及里东羹、逐層分解的分析原則剂桥。通常可按以下順序進行：中間件配置（Apache/JBoss/JSF參數配置属提、數據庫參數配置）->應用系統(tǒng)日志->應用系統(tǒng)瓶頸（線程池配置权逗、代碼、SQL語句垒拢、算法等）->第三方服務提供者性能瓶頸旬迹。

app技術支持
1、HTTP狀態(tài)碼：快速發(fā)現web問題
當某個域名在指定時間單位出現50x和40x的次數超過一定閾值求类，系統(tǒng)就會默認發(fā)送告警奔垦。這樣運維團隊就能及時得知當時的域名、具體的HTTP狀態(tài)碼尸疆、具體發(fā)生問題的機器椿猎、當時單位時間內發(fā)生的次數以及請求的URI。
2寿弱、網絡撥測：發(fā)現用戶真實的網絡問題
通過該監(jiān)控系統(tǒng)犯眠，當運維團隊發(fā)現某地區(qū)的運營商出現延遲增大或者丟棄頻繁的情況時，就會切換該地區(qū)的入口VIP症革，以提升該地區(qū)用戶的訪問質量筐咧。
3、性能測試平臺TP
為了讓壓測過程更人性化噪矛，平臺功能也在不斷優(yōu)化和完善中量蕊，2017年再次簡化了創(chuàng)建任務、執(zhí)行測試任務的方式艇挨，同時加入和優(yōu)化了對被壓系統(tǒng)的監(jiān)控視圖残炮，測試人員可以更為全面地觀察測試發(fā)送的流量以及系統(tǒng)實際承受的流量，便于隨時調整壓測方案缩滨。

秒殺系統(tǒng)
1势就、海量服務泉瞻，日常大規(guī)模高并發(fā)
采用微服務架構，每個服務安排一個團隊維護苞冯，不同服務之間低耦合袖牙，有利于代碼的開發(fā)和優(yōu)化，相互之間獨立工作抱完，提高了開發(fā)效率贼陶。并且微服務的架構也更有利于進行水平擴展，按需擴容可只對需要的系統(tǒng)進行擴容巧娱，一方面有利于快速擴容碉怔，另一方面也降低了擴容對整體系統(tǒng)帶來的潛在危險。
2禁添、卓越性能撮胧，瞬時流量涌入低延時
在預加載時間段，客戶端會向服務端請求數據老翘，服務端根據一定規(guī)則判斷下發(fā)當前場次數據或下一場次預加載數據芹啥。如果客戶端預加載成功下一場次的數據，則在場次到點切換之后不再向服務器發(fā)送請求铺峭，直接使用本地預加載數據墓怀。通過這種預加載的方式將整點切場的部分流量分攤到預加載時間段，大大削弱了切場整點的尖峰流量卫键。
3傀履、高效可用，全面穩(wěn)定無宕機
在迭代頻繁的情況下保持線上業(yè)務服務的持續(xù)穩(wěn)定可用：立體式的系統(tǒng)和業(yè)務監(jiān)控莉炉，完善清晰的降級路徑钓账，嚴密科學的容錯兜底邏輯

流控策略
使用nginx+openresty將流控策略功能從業(yè)務服務前置到了前端nginx模塊中，作為獨立的流控服務
1絮宁、在前端nginx中接入風控系統(tǒng)梆暮，非法流量將在防刷限流服務中被直接攔截
2、對于超出業(yè)務服務處理能力的正常流量绍昂，綜合考慮業(yè)務服務集群性能指標啦粹，如cpu使用率、負載窘游、QPS等卖陵，把它們加到流控策略，指標值由上述數據采集系統(tǒng)收集张峰。當這些性能指標達到一定閾值后，由于這些流量不是異常流量棒旗，不能直接生硬地攔截喘批，所以流控服務與客戶端建立排隊策略撩荣，將這部分流量的請求結果直接設置為排隊消息∪纳睿客戶端接收到排隊消息后餐曹，將彈出排隊提示，排隊時間由服務端下發(fā)敌厘，排隊時間達到后重新請求獲取正常的業(yè)務數據
3台猴、進行入口檢查和接口調用頻率檢查策略

崩潰自動化分析
升級底層SDK，增加了內存警告崩潰的捕獲俱两。同時饱狂，完全自主地實現了一套崩潰自動化分析系統(tǒng)。該系統(tǒng)從日志分析宪彩、問題模塊統(tǒng)計歸類休讳、日志展示、篩選緯度以及監(jiān)控上都做了更深層次的優(yōu)化和探索尿孔。

無線業(yè)務安全
1俊柔、數據聚合及分發(fā)模塊。解析各個業(yè)務方傳來的數據活合，并且可能在處理過程中需要聚合一些調用其他第三方接口回傳回來的數據雏婶，在轉換為統(tǒng)一的數據格式后，落入DB或者分發(fā)到每個業(yè)務的流式計算模塊中白指。DB中的數據可供數據分析人員進行離線分析留晚，開發(fā)可實施的風控策略并進行離線驗證
2、流式計算模塊侵续。接收數據聚合和分發(fā)模塊傳入的統(tǒng)一格式的業(yè)務請求數據倔丈，實時地實現各種復雜的風控策略，并且將風控的結果寫入緩存中状蜗，供規(guī)則引擎模塊查詢
3需五、規(guī)則引擎模塊。為每個業(yè)務分配一個固定的業(yè)務標志AppID轧坎，然后通過傳入的請求攜帶的AppID區(qū)分業(yè)務宏邮，進而明確需要查詢的緩存，這個緩存中的數據恰恰是流式計算模塊為該業(yè)務計算出的風控結果

渠道引流技術運營
1 立體監(jiān)控
數據采集：紅綠燈渠道 秒級渠道 模調渠道 變更追蹤
故障識別：規(guī)則引擎 宏觀視圖 走向智能
故障處理：定位工具 故障知識庫 自動處理網關
2 快速擴容
中控式缸血、模板化的擴容流程系統(tǒng)蜜氨。擴容中控系統(tǒng)在最高層負責流程的調控、執(zhí)行捎泻；在擴容流程各環(huán)節(jié)的層面上飒炎，擴容中控系統(tǒng)提供模板化的能力，把每個環(huán)節(jié)里的各個操作步驟整合到模板里來笆豁，供高層的中控系統(tǒng)進行操控執(zhí)行郎汪。在更下一層的步驟層面上赤赊，則需要把各種具體操作變成可以由機器執(zhí)行的標準化接口。
3 自動容災
對于一般服務的數據煞赢，采用一主兩備跨機房的災備模式抛计；對于重要服務的數據，采用同城雙活的災備模式照筑；對于核心服務的數據吹截，則實現了異地雙活。
4 質量保障
前端頁面掃描與監(jiān)控
后臺接口自動化測試
自動化壓測
自動化安全掃描
一站式智能發(fā)布驗證
小程序測試探索：靜態(tài)代碼的掃描凝危、調試與性能測試平臺波俄、小程序自動化

數據庫SQL優(yōu)化
1、慢SQL平臺媒抠，對線上慢SQL進行自動化弟断，可視化管理
2、郵件推送趴生，當有慢SQL產生阀趴，每天會定時發(fā)郵件給相關研發(fā)，提醒他們及時進行關注和優(yōu)化苍匆，并且會把慢SQL提交Jira系統(tǒng)刘急，進行有效的跟蹤，直至該慢SQL被優(yōu)化完成

緩存平臺
1精確的故障檢測和自動故障切換
2無損擴容
3監(jiān)控和報警
4自動彈性調度浸踩，對集群的各項指標進行監(jiān)控叔汁，比如OPS、內存使用率检碗、網絡流量等進行監(jiān)控据块，統(tǒng)計這些指標一段時間內是否達到了設置的閾值，當超過擴容的閾值時則自動觸發(fā)擴容折剃，當低于縮容的閾值時自動進行縮容另假，釋放資源。
5服務端升級怕犁，在同一臺物理機上創(chuàng)一個新版本的實例边篮，當舊實例銷毀后并不會導致物理機上實例數超限等問題，通過數據復制流程把舊實例上的slot全部遷移到新的實例上奏甫，由于數據是在同一個物理機上流動戈轿，因此速度會比網絡傳輸快很多。

故障演練系統(tǒng)
系統(tǒng)總會遇到各種各樣無法預料的問題阵子，有些基礎設施的故障是無法避免的思杯，不可控的。研發(fā)團隊在做系統(tǒng)架構時挠进，就針對基礎設定前提：
1智蝠、機房宕機
2腾么、網絡交換機宕機，導致整個機柜設備脫離網絡
3杈湾、服務器主機宕機
4、網絡會因“渣土車”導致網絡的延遲攘须、丟包
5漆撞、系統(tǒng)所依賴的中間件、DB有可能會無法正常連接
6于宙、系統(tǒng)的進程宕機
7浮驳、系統(tǒng)的主機環(huán)境會面臨磁盤寫滿、CPU高負載運行捞魁、內存滿等
當面臨這些故障時至会，系統(tǒng)應當正常運行，至少應當受限運行谱俭，絕不允許將錯誤拋給用戶奉件。也就是說，當系統(tǒng)遇到這些故障時昆著，應當在不影響用戶訪問县貌、下單等用戶體驗的情況下正常運行。

多中心網絡監(jiān)控和災備
1 各中心會有到全國省份城市的網絡質量速度檢測數據API凑懂，提供給GSLB作為調度數據依據之一煤痕，實時調度避開擁堵網絡，選擇最優(yōu)中心提供服務
2 各中心機房內部網絡監(jiān)控接谨，包括網絡設備摆碉、專線、服務器等脓豪，點到點分布式監(jiān)控每個節(jié)點的網絡質量

網絡自動化
白盒監(jiān)控巷帝，對全網所有設備進行100%的監(jiān)控，針對不同種類的端口制定不同的采集策略跑揉，從端口流量锅睛、CRC到設備的CPU、內存和ICMP探活历谍。
黑盒監(jiān)控现拒，將大量業(yè)務部署到監(jiān)控客戶端(Agent)，中央模塊根據Agent的位置(Rack望侈、POD印蔬、機房)為其下發(fā)不同的探測任務，同時Agent之間進行交叉探測脱衙，并將監(jiān)測到的數據上報給中央模塊侥猬，這樣可以站在業(yè)務側的角度例驹，更加真實客觀地反映出網絡的健康狀態(tài)。通過各種細顆粒度的監(jiān)測退唠，中央模塊支持按服務進行匯聚鹃锈，獲得網絡服務各種緯度的健康狀況，如機架瞧预、集群屎债、POD、機房垢油、專線等盆驹。
對于公網部分，在所有機房的出口部署監(jiān)控程序滩愁，針對三大運營商全國所有省市的探測節(jié)點進行探測躯喇，通過這部分數據可以得知數據中心出口的網絡健康狀態(tài)和各地運營商的網絡健康狀態(tài)。

全局流量調度系統(tǒng)
當訪問域名目標IP不可用或有預期問題時硝枉，通過域名解析或其他手段調度到正常IP地址廉丽，以達到正常訪問網站目的，即流量調度檀咙。

防攻擊系統(tǒng)
物理資源：京東在數年前就已完成異地多機房雅倒、多線路的網絡布局，核心業(yè)務在京東的每個骨干節(jié)點中都會部署熱備服務弧可，同時依靠用戶接入部維護的智能調度系統(tǒng)進行負載均衡蔑匣，當任意一個節(jié)點可用率下降時，通過智能調度系統(tǒng)便可以將業(yè)務流量收斂到正常節(jié)點中棕诵，保證業(yè)務穩(wěn)定性不受損失裁良。
網絡結構：防攻擊系統(tǒng)需要在攻擊流量進入業(yè)務集群之前進行清洗，保證業(yè)務集群能夠正常穩(wěn)定運行校套。
軟件架構：傳統(tǒng)的DDoS攻擊檢測是靠簡單的閾值來進行的价脾，通過統(tǒng)計某個周期內發(fā)現的數據包數目，與配置的攻擊閾值進行比較笛匙，超過閾值的就是攻擊行為侨把，小于閾值的就沒有攻擊。新的防攻擊分為兩大核心：攻擊發(fā)現系統(tǒng)妹孙、攻擊清洗系統(tǒng)

反刷單系統(tǒng)
刷單作為一個缺乏標注數據的識別場景秋柄，如何在此場景下提升模型的識別率和準確率是業(yè)界公認的難題。對此蠢正，反刷單團隊主要采用了兩種解決方案：一是無監(jiān)督的樣本增強骇笔，通過樣本聚類的方式擴展正負樣本；二是構建了刷單的GoldenSet，在這個訂單聚合上可以計算出模型在召回和準確率上的提升效果笨触，實現模型的自動化效果評估懦傍，加速模型迭代。

信息安全
安全的攻防不再是個人或團隊的技術對抗芦劣，而是體系的對抗粗俱。安全也不應該是后加的內容，而是在產品或服務構建初期就嵌入其中，就像一架飛機的每一個零件都必須是安全可用的结啼。
一、安全體檢后自主選擇改善目標。通過對各部門所用的CI系統(tǒng)承疲、項目管理系統(tǒng)、上線系統(tǒng)幻林、漏洞管理系統(tǒng)瑞你、人資系統(tǒng)等系統(tǒng)的分析，得出各團隊執(zhí)行SDL前的安全體檢值油宜。業(yè)務部門根據自身的發(fā)展現狀掂碱，自行選擇希望達到的安全體檢值。有了目標之后慎冤，信息安全部有針對性地為業(yè)務部門導入所需的SDL階段和活動疼燥，并指導業(yè)務部門如何提升。
二蚁堤、寬進嚴出醉者。信息安全部在每一個階段都制定了考核標準，比如披诗，在安全測試階段撬即，信息安全部為部門提供對應的培訓，每個團隊完成培訓后必須定期反饋結果呈队。沒有完成考核的部門不予通過剥槐，沒有通過考核的部門需要重做本階段的活動，直至指標達到要求宪摧。
三粒竖、授人以漁而非授人以魚。通過SDL的推行几于，將信息安全部的能力輸出給各業(yè)務部門蕊苗。POP團隊通過執(zhí)行SDL，在部門內部建立了測試的標準化和自動化的工具孩革，保證部門內的所有項目都統(tǒng)一執(zhí)行標準岁歉，不但自行測試出項目中的安全漏洞，而且自行發(fā)現隱藏在現有系統(tǒng)中的安全漏洞。

安全保障
一锅移、備戰(zhàn)階段
1 安全風險 在每一次重保的備戰(zhàn)時熔掺，把京東針對大促期間存在的風險都會列出來，做差距的比較非剃。包括引導發(fā)布置逻、資產分析、隱患自查备绽、響應演練券坞、監(jiān)控感知。為了保證比較高效地完成跨部門的協調工作肺素，引入了引導發(fā)布的工作機制恨锚，通過引導發(fā)布機制讓所有人都能夠知道每個層面應該如何加強安全，安全團隊首先自己會把所有涉及不同層面的東西來復盤倍靡，制定好之后讓各個業(yè)務部門自查猴伶。
2 資產分析 重保備戰(zhàn)前一個半月，安全團隊集中搜集各個業(yè)務部門的核心業(yè)務系統(tǒng)塌西，各業(yè)務線安全官負責對業(yè)務系統(tǒng)的系統(tǒng)架構他挎、網絡通信、數據存儲捡需、業(yè)務邏輯办桨、賬號權限、系統(tǒng)部署配置等安全控制點進行檢查站辉，對系統(tǒng)進行源代碼級別的安全檢查和滲透測試呢撞，將核心業(yè)務系統(tǒng)的安全風險降低至可接受的水平。
3 JSRC 每年的重保之前的一個多月庵寞，京東安全響應中心每周都有一些不同的活動狸相，2016年618保障時最大的獎項是無人車，通過重獎捐川，保證重保之前把所有的風險都發(fā)現出來脓鹃。在2017年618大促，信息安全部發(fā)動JSRC的1000多名白帽子古沥，開展了全民保障618活動瘸右，在618之前積極告知網絡中安全漏洞，累計提交漏洞217個岩齿，其中深層次太颤、影響范圍大的高危嚴重漏洞20余個，在618大促前消除了隱藏的安全漏洞盹沈。
4 實操演練 2016年的重保龄章，安全團隊準備了十大預案，根據這些預案，在真實生產環(huán)境中演練重大漏洞做裙、信息泄露岗憋、DDoS攻擊的應急和響應。如在DDoS的演練中锚贱，安全團隊分級專門做了不同場景的聯動仔戈，當測試流量引過來時，首先看自己怎么防拧廊；如果防不住的监徘，IDC有什么能力幫我們扛一部分；如果IDC扛不住吧碾，運營商怎么在這個基礎上幫我們聯動抵制流量凰盔。用這種方法充分地把這個事情全部做一遍。
二倦春、保障階段
1 監(jiān)控 2017年哮天犬監(jiān)控系統(tǒng)在原有的一個大屏幕的基礎上廊蜒，增加了2塊屏幕，12個監(jiān)控點溅漾。用戶登錄、惡意賬號登錄著榴、資產添履、入侵、web攻擊脑又、安全漏洞暮胧、威脅情報等30多類數據從不同層面匯聚，呈現整體的安全態(tài)勢问麸。
2 總結-復盤-改善 首先把整個漏洞發(fā)現的風險都做了折損往衷，發(fā)現多少問題，處理多少問題严卖，所有的漏洞和安全事件都有價值席舍。對出現的問題進行復盤，確認持續(xù)改進的計劃和監(jiān)督保證落地哮笆。

安全漏洞閉環(huán)管理
業(yè)務部門所屬的應用系統(tǒng)及其IP地址来颤、端口、服務和組件信息同步到大海資產管理系統(tǒng)中稠肘，掃描引擎定期從大海系統(tǒng)中增加掃描對象并加載掃描任務福铅，并提交到掃描引擎。業(yè)務部門的源代碼管理系統(tǒng)也與掃描引擎自動化對接项阴。一旦掃描完成滑黔，將掃描結果發(fā)送至脈象平臺，用于整體安全態(tài)勢的分析。一旦發(fā)現安全漏洞略荡，則通過ITSM工單系統(tǒng)進行跟蹤庵佣，安全漏洞的跟蹤和修復狀態(tài)定期通過安全數據周報的形式告知各業(yè)務部門。
安全官檢查和外部接報的信息安全事件撞芍，經過驗證后秧了，一方面通過ITSM工單進行跟蹤；另一方面序无，在大海系統(tǒng)中檢查存在問題的關聯系統(tǒng)和信息验毡，調度引擎再次執(zhí)行關聯檢查和掃描，杜絕安全漏洞的次生影響帝嗡。

預測系統(tǒng)
歷史數據的獲取晶通、數據清洗、模型選擇和訓練哟玷、模型應用狮辽、模型效果監(jiān)控和更新等。

訂單履約中心自動化工作流系統(tǒng)架構
引入工作流巢寡，實現了流程集中控制喉脖，避免了流程分散造成的數據不一致和流程混亂現象。與“流程集中控制”相對的是“流程分散”抑月，即流程由各業(yè)務系統(tǒng)本身控制树叽，由于業(yè)務系統(tǒng)關注于業(yè)務本身，往往難以兼顧流程邏輯谦絮。
客戶端流量控制技術题诵。該技術也是在引入工作流過程中實現的。在工作流的前端是接單系統(tǒng)层皱，它的職責是接收從上游傳來的訂單數據性锭，也就意味著會受到618訂單洪峰的沖擊。從歷史上看叫胖，這個洪峰最高達到10000次/s調用草冈。而供應鏈履約中心通過客戶端流量控制技術，把洪峰削平了瓮增，下游十幾個系統(tǒng)只需要按平滑后的流量來建設系統(tǒng)疲陕，大大節(jié)約了系統(tǒng)建設成本。通過客戶端流量空值技術钉赁，供應鏈履約中心還可以在運行時維護整個訂單履約流程流量的穩(wěn)定性蹄殃，保證各個生產終端（例如各個倉庫）可以按約定的節(jié)奏均衡地生產。
分環(huán)節(jié)內存隊列技術你踩。通過使用“內存隊列”技術诅岩，以及流程中各系統(tǒng)服務的SLA達成讳苦，將訂單履約工作流時效從原來的30min縮短到了秒級，為保證定時達（1天內可以選擇三個配送時段）吩谦、極速達（2h內將商品送達）等業(yè)務提供了保障鸳谜。前不久，京東創(chuàng)造了從下單到送到用戶手中最快10min的世界紀錄式廷「琅ぃ“環(huán)節(jié)”指的是工作流的環(huán)節(jié)，每個環(huán)節(jié)都有自己的任務隊列滑废，這樣做不是為了速度蝗肪，而是為了控制，包括流量控制蠕趁、流程攔截薛闪、優(yōu)先級調整等。
監(jiān)控與報警方案俺陋。除了接入京東的統(tǒng)一監(jiān)控平臺實現基本的監(jiān)控功能外豁延，還根據業(yè)務特點，實現了任務積壓及趨勢腊状、有積壓情況下處理能力的趨勢诱咏、異常數據等方面的監(jiān)控，報警前加了一定的分析功能缴挖。例如胰苏，如果系統(tǒng)出現了積壓，同時系統(tǒng)處理能力在不斷上升醇疼，說明這時狐仙了業(yè)務高峰，而不是系統(tǒng)出問題了法焰；如果系統(tǒng)吞吐量在下降秧荆，響應時間正常，且沒有積壓埃仪，則說明是業(yè)務量在降低乙濒。

618前的工作
知己知彼，百戰(zhàn)不殆卵蛉。為了應對618颁股，首先要評估系統(tǒng)會有多大的流量。其次傻丝，評估在這么大流量下甘有，系統(tǒng)要保持什么樣的狀態(tài)才能滿足下游系統(tǒng)生產。最后葡缰，需要通過壓測來評估驗證我們的系統(tǒng)能否經得住考驗亏掀。
評估的依據還是業(yè)務部門給出的促銷方案忱反，以及歷史上的促銷數據和流量數據。并同上游系統(tǒng)溝通滤愕，了解上游系統(tǒng)的流量以及擴容方案温算，一起來評估自己系統(tǒng)的調用數據。有了流量數據后间影，再來評估現有的應用系統(tǒng)注竿、緩存系統(tǒng)、存儲系統(tǒng)能否支持這一流量魂贬。如能支持巩割，會有什么樣的表現，什么樣的QPS随橘，什么樣的并發(fā)量喂分，什么樣的TP99，什么樣的CPU使用率和負載机蔗。如果不能支持蒲祈，有哪些地方需要改進，哪些地方可以優(yōu)化萝嘁，哪些地方可以降級梆掸。針對降級，又如何定義啟用場景牙言，啟用后又有哪些不足和補救措施酸钦。如果某系統(tǒng)或某服務出現故障，可以采取哪些應急的措施能降低影響咱枉。有了這些數據卑硫，再去找下游系統(tǒng)，協商SLA蚕断、并發(fā)數欢伏、TP99等信息。當然亿乳，對下游系統(tǒng)的要求會寬泛許多硝拧，也要協同考慮倉配系統(tǒng)的實際生產要求，根據木桶原理定義出每一個系統(tǒng)的并發(fā)數和調用量的限制葛假。
在評估完成后障陶，需要根據評估結果進行線上的壓力測試，檢驗現有資源情況能否滿足618的需要聊训。由于線上一直都有用戶訂單數據在執(zhí)行抱究，因此壓測時間就選在了用戶相對較少的凌晨時分。壓測的方式带斑，主要是模擬大量的調用媳维，以較高的并發(fā)量來調用某個系統(tǒng)酿雪，觀察該系統(tǒng)的表現。對于某些特定的系統(tǒng)侄刽，還可以采用減少線上應用實例個數的方式來輔助壓測指黎。壓測之后，就能得到某個量級的沖擊下各個系統(tǒng)的表現州丹，評估出是否能滿足本次618的需要醋安。如果無法很好地滿足，則需要依據生產能力來評估墓毒，最低調用量要滿足多少吓揪，以及相應的降級措施和之后的系統(tǒng)改進方案。
對于定義出的降級方案和應急的策略所计，需要整理成詳實的柠辞、可操作的文檔，并通過實際演練的方式讓團隊中的每個人都熟練掌握主胧。除了面向整個團隊的宣貫之外叭首，還采用問答考試的方式，線上的Chaos Monkey演練等方式來確保每個人都能掌握踪栋。

物流架構
1焙格、基于業(yè)務的數據庫拆分 該服務器上的非核心庫全部原封不動地遷移到其他服務器上；核心時效庫中的非核心表也拆分到其他服務器的新庫上夷都。核心庫只應付海量訂單信息寫入眷唉，是的后續(xù)TPS的優(yōu)化變得更加有針對性
2、網絡I/O優(yōu)化 按照峰值調用量囤官、峰值數據傳輸流量大小等評估緩存結構設計是否合理冬阳，在調用次數與數據冗余上進行綜合考慮和取舍，同時將分布式緩存集群也按業(yè)務進行了合理的分離
3党饮、磁盤I/O優(yōu)化 從根本上優(yōu)化應用日志輸出（精簡肝陪、有效、每個請求的日志都綁定唯一的標志劫谅，方便排查問題），真正做到打印日志是一門藝術嚷掠；日志按業(yè)務或分包文件捏检，配置不同的日志級別和滾動策略，控制所有日志文件總大小不能超過服務器磁盤空間大小的70%不皆；根據實際情況調整日志工具的BufferSize贯城，在適當場景下使用異步日志
4、多級緩存策略 為應對618等高流量的特殊時期霹娄，并且為了進一步提升服務的高并發(fā)能犯、高性能鲫骗，團隊采用多級緩存的方式對數據進行處理，同時針對不同的業(yè)務應用踩晶，采用不同的緩存策略执泰。例如，對于京配服務渡蜻、特色服務推薦等響應時間要求較高术吝，而數據一致性要求相對較低的應用而言，采用了分布式緩存加本地熱點緩存的方式茸苇。對于分布式緩存排苍，采取的是定期全量緩存更新策略，數據首先寫入數據庫系統(tǒng)学密，每天在固定的時間將數據同步到分布式緩存系統(tǒng)淘衙。同時針對本地緩存，采用熱點數據的方式腻暮，針對某些秒殺活動彤守，基于歷史數據或者其他信息進行本地緩存預加載的方式。并且針對不同的業(yè)務數據西壮，設定合理的本地緩存的時效時長遗增，從而更有效地提升系統(tǒng)的訪問效率，進而提高系統(tǒng)性能
5款青、平衡海量數據和實時計算的架構
（1）選用ElasticSearch作為數據落地的存儲引擎做修，借助ElasticSearch高效的讀寫性能，完成實時數據模型的存儲和查詢功能
（2）通過Kafka實時接收線上業(yè)務數據抡草，通過實時數據引擎饰及，根據預先設定的實時數據模型進行數據實時處理，并將實時處理明細落地到ElasticSearch
（3）通過調度系統(tǒng)匯總查詢統(tǒng)計需求康震，由調度系統(tǒng)轉發(fā)用戶查詢請求燎含，并提供動態(tài)查詢參數，這樣能夠控制非常消耗ElasticSearch集群的查詢請求腿短，保證ElasticSearch集群的資源消耗是可控的屏箍，又能夠做到滿足用戶復雜的查詢統(tǒng)計需求
（4）對于實時性能沒有非常高的查詢統(tǒng)計需求，增加數據中間緩存層橘忱，將固化的統(tǒng)計需求結果定時刷新到數據緩沖層赴魁，這樣就可以將ElasticSearch集群壓力轉移到數據緩沖層，緩解ElasticSearch集群查詢壓力的同時钝诚，提高請求的吞吐能力
6颖御、自定義的業(yè)務監(jiān)控系統(tǒng) 目前京東公司級監(jiān)控系統(tǒng)做到的監(jiān)控包含：網絡層面、服務器層面凝颇、應用層面潘拱、JVM層面疹鳄、數據庫層面。但是各個業(yè)務系統(tǒng)也有可能對自身的業(yè)務數據的正確性也比較敏感芦岂，針對此類需求瘪弓，公司級監(jiān)控系統(tǒng)就很難做到深入所有的業(yè)務系統(tǒng)，所以團隊自研發(fā)了一套表數據級別的監(jiān)控系統(tǒng)FDM盔腔。
FDM系統(tǒng)可以針對不同的表配置不同的監(jiān)控任務：異常數據掃描SQL杠茬、異常判定條件、任務執(zhí)行計劃弛随、報警策略等瓢喉。

京豆安全檢驗機制
狹義的安全性每一個需要接入京豆臺賬的系統(tǒng)都需要申請統(tǒng)一的密鑰，并且對所申請的密鑰要有相應的角色控制舀透，即在發(fā)起系統(tǒng)間調用的時候栓票，需要傳入相應的密鑰，并查看密鑰是否與所申請的接口匹配
廣義的安全性 采用了多中心交易實現多個異地機房同時提供交易服務愕够，任何一個機房出問題后都能由其他機房接管走贪。用戶盡可能在最近的機房完成交易，并且在單機房內形成流量閉環(huán)(將用戶數據封閉在一個機房惑芭，解決了數據復制延遲帶來的后發(fā)先至的問題坠狡。實現單機房流量閉環(huán)，需要移動網關遂跟、單品頁逃沿、購物車、結算頁幻锁、優(yōu)惠券等多個系統(tǒng)路由規(guī)則一致凯亮，統(tǒng)一合作)。

商家系統(tǒng)升級優(yōu)化
一 高并發(fā)下的多級緩存技術 商家系統(tǒng)提供的店鋪信息哄尔、類目假消、品牌信息會被下游核心系統(tǒng)(如購物車、結算頁岭接、財務系統(tǒng)等)依賴富拗，這些下游系統(tǒng)的特點是并發(fā)高、要具備99.99%的可用性鸣戴。對于這種場景啃沪，我們不僅使用分布式緩存，如Redis葵擎，還會使用如Google Guava這種本地緩存谅阿，以提高可用性和接口性能半哟。
二 異常情況下的降級特技 系統(tǒng)跟機器一樣酬滤，在高并發(fā)場景下會出現各種問題签餐，例如訪問突然劇增、網絡超時等盯串，此時氯檐，需要有各種降級策略來保護系統(tǒng)，主要分為自動降級体捏、人工降級
自動降級：有些服務在一段時間內有可用率波動時可通過自動降級來減少故障時間冠摄，例如店鋪信息讀服務接口依賴的Redis可用率在90%以下的時候，會把讀服務自動降級為本地緩存几缭。
人工降級：當出現嚴重錯誤的時候河泳，例如在數據庫宕機主從自動切換不了的時候會有個大開關人工一鍵降級，將所有的讀庫服務切到從庫上年栓，保障核心服務正常可用。
三 多機房部署與容災 對于京東這種交易規(guī)模線上服務宕機都是以秒來計算的牧牢，宕機的每一秒都會成為事故疮蹦，針對一些諸如天氣、施工導致的線纜被破壞等不可控因素否副，也要有應對方案汉矿。商家系統(tǒng)應用依賴的資源，例如MYSQL集群备禀、Redis集群洲拇、ElasticSearch集群，同時部署在雙機房痹届，平時流量均勻分布呻待，一旦出現機房網絡異常，運維可以切換队腐，同時商家系統(tǒng)通過降級系統(tǒng)可以從應用緯度進行熱切換蚕捉，實現在1min之內恢復服務可用率
四 隔離術
1 進程隔離 應用按業(yè)務拆分后獨立部署，每個業(yè)務單元都部署在不同的實例上柴淘，這樣保證每個實例之間是物理隔離的迫淹，任何一個子系統(tǒng)出問題不會影響其他系統(tǒng)
2 線程隔離 我們會將應用內部的請求進行分類，不同的請求使用不同的線程
3 集群隔離 針對不同的業(yè)務領域为严，我們使用不同的集群進行物理隔離敛熬，例如店鋪數據和畫像數據分別在不同的緩存集群，任何一個集群出現問題均互相不影響
4 讀寫隔離 商家系統(tǒng)提供了不同緯度的讀寫服務第股，讀服務占比90%应民，寫服務占比10%，例如通過Redis主從模式將讀寫分離

商智系統(tǒng)接口可靠性備戰(zhàn)
梳理 從優(yōu)先級、應急聯系人诲锹、影響范圍(菜單與業(yè)務級別)繁仁、接口文檔、歷史壓測性能報告归园、接口是否經歷過大促六個方面黄虱，對所有外部接口進行梳理和分類，并整理成完善的文檔庸诱，以備發(fā)生問題時及時跟蹤定位捻浦。
壓測 對所有的外部接口進行統(tǒng)一壓測。研發(fā)團隊根據商智當前的QPS等系統(tǒng)壓力數據桥爽，預測出618期間接口可能產生的壓力值朱灿，然后同接口提供方逐一進行溝通，提出性能預期钠四，并進行壓力測試母剥。對于不滿足性能預期的接口，團隊與接口提供方進行了溝通形导，在保障618的大前提下环疼，接口提供方迅速地進行了對應的改造和優(yōu)化。
監(jiān)控 對所有外部接口添加UMP監(jiān)控朵耕，并配置短信報警炫隶，當接口不可用或者請求量超出預估值時，系統(tǒng)將通過短信的方式通知相關人員阎曹，第一時間做出調整或者處理伪阶。
應急預案 對四個高優(yōu)先級的核心接口制定應急預案，采用類似快照的方式处嫌，在每天接口壓力最小時栅贴，預先抓取所有商家的接口返回值，并且持久化到本地Hbase中熏迹。與此同時檐薯，在Hbase上添加了一層Redis緩存，以提升訪問性能注暗。一旦接口不可用坛缕，可以在1min內將接口依賴切換回本地數據，最大限度地避免商家的使用受到影響捆昏。
對于優(yōu)先級較低的接口赚楚，制定了接口壓力過大時通過人工控制接口的訪問頻次進行降級的應急預案。例如骗卜，實時流量與實時銷售的相關接口宠页，在原定的秒級間隔刷新的基礎上左胞，新增了可配置的開關。當接口壓力過大時举户，可以人工將緩存時間延長罩句，進而降低對外調用的頻次；當接口壓力下降之后敛摘，又可以人工將緩存時間縮短或直接關閉緩存，在商家無感知的情況下乳愉，動態(tài)控制調用壓力兄淫，保障系統(tǒng)的穩(wěn)定可用。

智能調度出口流量平臺
1蔓姚、智能負載均衡——客戶端進程內負載捕虽。當客戶端所在機房的網絡運營商與商家所在機房的運營商屬于同一網絡運營商時，可以直接在本地調用商家接口坡脐，即客戶端根據不同的商家選擇不同的機房作為流量出口泄私。通過智能匹配的方案，即可從根本上解決這些跨運營商或跨地域的問題备闲，從而提升調用的成功率晌端。
2、智能負載均衡——服務端均衡恬砂。如果部署應用所在機房與商家所在機房不是用同一個運營商網絡咧纠，此時業(yè)務系統(tǒng)會通過PEER系統(tǒng)提供的接口，并通過JSF將流量導向與商家機房相同運營商的機房泻骤，這樣就可以實現與商家在同一個運營商網絡上進行接口交互漆羔，大大提高了接口的可用率。
3狱掂、智能調度流量出口機房演痒。關于機房的智能篩選，我們會提供三個策略：
策略一：手動設置默認機房趋惨，手動調整鸟顺，即為每個代理商設置一個默認的機房ID，保存商家信息
策略二：根據實時可用率器虾，選擇一個服務性能最高的機房诊沪，通過監(jiān)控平臺根據key或者實時可用率，篩選出最近5min可用率最高的機房
策略三：綜合策略一和策略二曾撤，通過閾值&開關控制端姚，避免網絡抖動可用率不穩(wěn)定，可能會造成商家的不良切換挤悉。增加一個開關和閾值渐裸，當開關打開時巫湘，默認機房可用率不低于閾值即可使用，低于閾值再通過監(jiān)控平臺篩選出一個可用率最高的機房
通過這三個策略昏鹃，可以真正實現整體機房的智能調用尚氛，為系統(tǒng)服務的穩(wěn)定性提供了堅實的保障
4、智能降級洞渤。引入熔斷機制阅嘶，優(yōu)雅降級，避免某個業(yè)務線或某個接口出現問題后長時間占用系統(tǒng)資源
5载迄、智能平衡流量讯柔。通過權重平衡每個機房的出口流量

戶簿系統(tǒng)的特性
1、存儲可擴展
2护昧、組件化服務
3魂迄、圖像預處理
4、多維度查詢
5惋耙、安全訪問控制
6、安全存儲與安全傳輸
7绽榛、圖片水印
8湿酸、智能識別

單機部署遇到分布式部署產生了分布式日志收集系統(tǒng)，單體應用遇到微服務產生了分布式調用跟蹤系統(tǒng)灭美，短流程遇到長流程產生了足跡系統(tǒng)

印尼電商平臺
1稿械、異步化 異步化能很好地控制并發(fā)，并提高效率冲粤。例如在用戶注冊的過程中美莫，如果涉及日志的記錄，將日志記錄做異步化處理能很好地減少注冊功能的響應時間梯捕。另外厢呵，針對一些實時性要求比較高的場景，如庫存的扣減傀顾，仍然可以用異步化的思想襟铭，將扣減在緩存中進行操作，異步到數據庫中短曾。這樣能減少數據庫的并發(fā)壓力寒砖，當然也需要考慮實現緩存和數據庫中的數據的最終一致性
2、多級緩存 緩存在業(yè)界各個系統(tǒng)中都用得很多嫉拐，也被談及得很多哩都，說明緩存仍然是提升系統(tǒng)性能的一大利器。從瀏覽器緩存到CDN婉徘，再到Nginx緩存漠嵌，JVM緩存咐汞、分布式緩存，從前到后儒鹿，將用戶所需要的信息盡快地返回給用戶化撕。例如，印尼電商平臺的M站约炎，PC站首頁等實時性要求不是很高的數據植阴，在瀏覽器和CDN緩存后，大量的請求不用經過后臺服務器就可以返回給用戶圾浅。對實時性要求比較高的數據掠手，如庫存數據、促銷數據贱傀，仍然可以在Nginx中緩存幾秒來有效地控制并發(fā)請求。除了這些常用的緩存伊脓，我們還使用了Google的PWA技術府寒，讓用戶在移動端斷網的情況下仍然可以瀏覽內容
3、降低依賴 在大型分布式系統(tǒng)中报腔，如果訪問量比較大株搔，有一個系統(tǒng)響應慢，可能會導致整個系統(tǒng)崩潰效應的發(fā)生纯蛾。所以纤房，根據業(yè)務的重要性，有一些優(yōu)先級比較低的服務翻诉，針對這個服務的調用超時時間可以設置得低一些炮姨。訪問超時了就不返回結果，即相當于降級了碰煌，例如商品評論舒岸。還有一些服務，例如在商詳頁的庫存查詢芦圾，如果庫存訪問超時就默認返回1蛾派，讓用戶可以進入結算頁下單，在結算頁和下單流程中會對庫存做校驗
4个少、系統(tǒng)拆分洪乍，請求分散 在印尼電商平臺的促銷活動中，曾經發(fā)生過搜索量過大導致整個主站訪問不了的情況夜焦。將搜索和主站分拆能有效地降低相互的影響壳澳，即使搜索系統(tǒng)出現問題，用戶仍然可以瀏覽下單茫经。另外钾埂，將請求進行分散也能降低單一系統(tǒng)的壓力河闰。在商品詳情頁中有價格、庫存等信息褥紫，如果所有這些請求都需要經過商品詳情頁的服務無疑會對系統(tǒng)造成過大壓力姜性，而將這些請求在頁面上分拆到其他域名，則能提升整個系統(tǒng)的承載力和穩(wěn)定性髓考。
5部念、串行改并行 在微服務化后，實現一個業(yè)務常常需要調用多個服務氨菇，例如實現一個業(yè)務需要調用A儡炼、B、C三個服務查蓉，如果這三個服務并不依賴對方的請求結果乌询，那么可以并發(fā)調用這三個服務再對結果進行組合，這樣能大大提升整個服務的響應時間

在研發(fā)團隊規(guī)模較小豌研、應用數比較少妹田、人員相對穩(wěn)定的情況下，以jar包復用代碼的方式是能起到比較好的效果的鹃共，jar包復用避免遠程RPC調用的開銷鬼佣，應用數較少的情況下測試成本也不高。這種方式對人員要求較高霜浴，需要大家有判定系統(tǒng)邊界的能力并遵守規(guī)則晶衷，但在業(yè)務逐漸復雜，團隊人員規(guī)模擴大阴孟，系統(tǒng)演進因拆分而變多的情況下晌纫，很難保證JAR中的代碼是一些公共服務，結果就是jar中的代碼會越來越臃腫永丝，越來越龐大缸匪，包含各種業(yè)務，系統(tǒng)間耦合性越來越高类溢，同時系統(tǒng)數量的增加也對研發(fā)效率造成了巨大的沖擊凌蔬，一個功能同時需要改多個業(yè)務系統(tǒng)，發(fā)布時間也在不斷膨脹闯冷。

京東全球購可用性保障
1砂心、Nginx、JIMDB蛇耀、JVM多級緩存辩诞，以及數據托底，確保門戶網站的高可用
2纺涤、雙機房部署译暂，防單點抠忘，確保每個機房能獨立承擔百分百流量
3、限流外永，以確保流量沖擊時崎脉，系統(tǒng)高可用
4、依賴服務自動降級伯顶，避免非必要功能影響系統(tǒng)可用性
5囚灼、重新規(guī)劃PC、M祭衩、App灶体，不同平臺應用徹底解耦，去除相互影響

系統(tǒng)的DevOps之路
1掐暮、質量保障的平臺化自動化
DevOps的本質是在平臺化自動化基礎上的敏捷蝎抽。團隊正在持續(xù)迭代開發(fā)一套DevOps平臺，它給面向最終用戶的線上服務路克、數據服務和運營平臺提供閉環(huán)支撐樟结。閉環(huán)支撐包括兩層含義：從系統(tǒng)研發(fā)的生命周期角度來看，從研發(fā)的調試環(huán)境衷戈，到測試環(huán)境狭吼，再到預發(fā)布環(huán)境层坠，最終到線上環(huán)境部署殖妇，DevOps平臺提供一致的編譯方式、配置管理和部署方式破花，用平臺化自動化方式提高研發(fā)工作的效率谦趣；從自動化運維角度來看，DevOps提供了故障管理座每、系統(tǒng)管理前鹅、變更管理、資源管理和數據管理等一整套解決方案峭梳。通過UI和自動化方式舰绘，保證運維操作準確度，提高工作效率葱椭。
2捂寿、測試從線下延伸到線上
由于平行搜索系統(tǒng)中業(yè)務的重要性，除了系統(tǒng)和應用級別的監(jiān)控孵运，我們添加了大量核心業(yè)務的監(jiān)控秦陋。具體實現是通過業(yè)務測試腳本不斷地驗證線上服務治笨，把測試結果寫入監(jiān)控數據庫赤嚼，并通過報表系統(tǒng)以時間序列展示業(yè)務狀態(tài)。我們選用的監(jiān)控系統(tǒng)架構是OpenTSDB+HBase+Grafana逞壁。監(jiān)控只能看到業(yè)務歷史狀態(tài)，還需要告警系統(tǒng)第一時間把業(yè)務失效的信息通過郵件和短信方式告知相關人員姿骏，具體實現是在Icinga系統(tǒng)上進行二次開發(fā)。
3嘲玫、大數據支撐質量管理
平行搜索系統(tǒng)業(yè)務涉及數千個三級類目去团、數十億個商品和數億個用戶行為，我們把用戶行為的大數據進行抽取鬼雀、清洗、匯總和分析励烦，定期生成測試數據。以最少的測試用例却音，覆蓋更多的功能和用戶行為阿纤，并且保證了測試用例的實效性。

瀏覽器端的日志采集
1藐窄、日志采集 瀏覽器的日志采集方式，首先需要在統(tǒng)計頁面日志的頁面中預先植入一段JavaScript腳本刹枉，當頁面被瀏覽器加載時微宝，會執(zhí)行該腳本。腳本中預設了一些采集需求钟鸵，包括收集頁面信息贡未、訪問信息（訪次俊卤、上下文）岂昭、業(yè)務信息约啊、運行環(huán)境信息（瀏覽器信息记盒、訪問時間、訪問地址）等信息碾盟。日志采集腳本在被執(zhí)行后，會向服務器端發(fā)送一條HTTPS的請求，請求內容包含了收集到的日志信息骡尽。
2、服務器日志接收 日志服務器在成功接收到瀏覽器發(fā)送的日志請求后，立刻向瀏覽器發(fā)送一個請求成功的響應，日志請求的響應不影響頁面的加載套媚。日志服務器在接收到日志請求后，會對日志請求進行分析處理，包括判斷其是否為爬蟲环葵、是否為刷流量行為张遭、是否為惡意流量宝剖、是否為正常的日志請求等扑眉，對日志請求進行屏蔽和過濾，以免對下游解析和應用造成影響。
3、日志存儲 服務器接收到日志請求后，會依據請求的內容及約定的格式對其進行格式化落地。例如妹萨，當前頁面，上一頁面摩桶、業(yè)務信息、瀏覽器等信息以特定的字段標識蔗崎，字段之間使用特定的分隔符芳撒，整條日志以特定的格式記錄下來冬耿。結合業(yè)務的時效性需求酷师，將日志分發(fā)到實時平臺或者落地成離線文件荷憋。
經過數據的收集（采集-上報-接收-存儲）荡碾，我們將用戶在瀏覽器端的行為日志實時記錄下來局装。除植入代碼人工干預外坛吁，可以保證數據的準確性劳殖，數據的過濾和篩選保證了異常流量的干擾，格式化數據方便了后續(xù)的數據解析處理拨脉。

移動設備的日志采集
1哆姻、采集方式 移動設備上app應用的數據采集主要使用的是SDK工具，App應用在發(fā)版前將SDK工具集成進來玫膀，設定不同的事件行為場景矛缨，當用戶觸發(fā)相應的場景時，則會執(zhí)行SDK相應的腳本帖旨，采集對應的行為日志劳景。
2、日志存儲 用戶的各種場景都會產生日志碉就，為了減少用戶的流量損耗盟广，我們將日志先在客戶端進行緩存，并對數據進行聚合瓮钥，在適當時機對數據進行加密和壓縮后上報至日志服務器筋量，同時由于數據的聚合和壓縮也可以減少對服務器的請求情況。

數據產品服務
產品設計之初碉熄，主要解決兩大業(yè)務痛點桨武，首先是整合眾多的數據產品，統(tǒng)一訪問入口锈津，統(tǒng)一數據分析邏輯呀酸，統(tǒng)一數據指標體系。另一個是快速實現各事業(yè)部的數據可視化需求琼梆。

項目經理能力要求
1性誉、項目管理專業(yè)技能
項目、項目集和項目組合中特定領域相關的知識茎杂、技能與行為错览，包括項目管理專業(yè)知識和技能，同時加上業(yè)務領域的專業(yè)知識煌往，可以稱之為“硬實力”倾哺，是成為一個優(yōu)秀項目經理必要但不充分條件。
2刽脖、領導力
對企業(yè)完成事業(yè)目標有幫助的領導方面及跨領域的相關知識羞海、技能與行為，可以稱之為“軟技能”曲管，通俗來說包括人際交往能力却邓、認知能力、學習能力翘地、管理能力申尤、解決問題的能力癌幕、影響力以及情商等衙耕。
3昧穿、戰(zhàn)略與商業(yè)管理
為提高工作表現以及更好地傳遞工作成果的相關行業(yè)和組織的知識與專業(yè)技能。作為項目經理橙喘，要懂業(yè)務时鸵，要有商業(yè)敏銳度，要看到并能夠挖掘項目的意義和價值厅瞎，厘清用戶真正的需求和痛點饰潜，這一條特別符合由多個項目組成的項目集或項目組合的管理。

項目管理的監(jiān)控階段
1和簸、建立問題跟蹤機制彭雾，做好進度跟蹤和控制
為監(jiān)控項目進度與項目計劃的偏差程度，項目組采取了以下問題跟蹤機制：在周例會锁保、日例會及其他渠道反饋的需跨部門協調薯酝，且無法立即解決的問題，項目經歷記錄到問題跟蹤表中爽柒，限定解決時間吴菠，并分配責任人和責任部門；跟進人每日跟進問題解決進度浩村，協調資源并推進問題解決做葵，在每周五向所有干系人發(fā)送的項目周報中附上問題跟蹤表，同步最新解決進展心墅。
2酿矢、問題重要緊急程度不同，觸達渠道也不同
根據問題或風險的重要緊急程度怎燥，建立不同的反饋渠道棠涮，常規(guī)問題反饋至備戰(zhàn)接口人群，抄送備戰(zhàn)工作小組刺覆；重要問題反饋至備戰(zhàn)工作小組群組严肪，抄送主管副總裁、備戰(zhàn)總指揮及項目經理谦屑，同時在備戰(zhàn)咚咚群中發(fā)送消息驳糯；緊急問題必須第一時間發(fā)送至微信“0級系統(tǒng)負責人群”，相關負責人會第一時間關注并盡快解決氢橙；重要且緊急的問題除第一時間發(fā)送至微信“0級系統(tǒng)負責人群”緊急處理外酝枢，還需在問題解決之后，把問題描述悍手、原因帘睦、解決方案發(fā)送至郵件發(fā)送相關干系人袍患，并抄送主管副總裁、備戰(zhàn)總指揮竣付、項目經理诡延、備戰(zhàn)工作小組及項目管理/接口人小組缆镣。
3辩撑、利用項目管理系統(tǒng)(PMP)脑蠕，輔助做好項目管控
京東自研的項目管理系統(tǒng)——京東研發(fā)管理平臺玖翅，從項目基本信息艘刚、工時填報及審批饮笛、風險和問題管理庇茫、干系人管理傍睹、項目進度管理棺牧、變更管理巫糙、成本核算等方面，對項目全方位進行管控颊乘，尤其是支持基于任務填報工時参淹、審核工時，成本估算精細到具體任務疲牵，對項目進行高效率的指導和控制承二。