2016 北京架構師高峰會
心得整理
Joey Chen (91)
現實限制
VS
未來擴展
架構是演進的,而演進的難度在於
CONTENT
01
相關主題
02
借鏡觀形
03
總結
http://bit.ly/ArchSummit-bj2016
相關主題
FinTech 金融科技
社交網路與視頻直播
雲服務架構探索
大數據處理及系統架構
機器學習實踐
新聞資訊與廣告
01 相關主題
架構演進-從0到1,再到100 高可用架構之道
日新月異的移動架構 電商系統架構如何應對業務爆發式增長
隨著業務發展,系統各種問題隨之而來,這時就要
考慮架構升級,以滿足在穩定性、擴展性、效能和
成本方面等的要求,這樣的演進不斷隨著業務發展
而發生,在剛好的時機做剛好的設計。
以支付寶為例,2015年大促每秒超過8萬筆支付,一分鐘故
障可能影響近500萬筆交易,影響甚鉅。如何透過架構升級
來預防問題發生、即時發現問題、快速甚至自動化處理問題,
系統架構的設計直接決定可用性的高低。
Mobile已經超過PC的使用率,mobile端架構如何
權衡Web和Native,如何滿足用戶苛刻的流暢度、
穩定度、耗電與網路需求,高併發大流量下移動架
構的設計,考量未來的擴展要求與眼前需求急迫性,
做出最剛好的選擇。
電子商務飛速發展,各大電商公司都在發展過程中,架構演
進的痛點與寶貴歷程值得參考。成功不可複製,失敗或可避
免,如何吸取教訓、避免閉門造車與摸石過河,相當重要。
STUDY
研究案例
如何實現高併發、高可用的選購系統
唯品會
京東核心中間件如何支撐業務快速發展
京東
2016 Q3 淨收入 毛利額 訂單數 其他
京東 607億 96億 超過4億筆 2016 雙11, 390億
唯品會 120億 29.3億 6010萬筆
活躍用戶 2080萬
複購用戶 1670萬
連續16季營利
單位:人民幣
借鏡觀形
京東
架構演進歷程
京東架構演進
開源框架與現成解決方案
初期-技術轉型
(PHP & .NET 轉 Java)
自主研發
2013
精細化運營
近期-演進
中期-推廣
成本 & 研發能量
PROBLEMS
京東-初期效能問題
直接存取DB
同步調用多API
HTTP短連接調用
缺少服務標準和治理,找不到服務提供方
WORK
京東-初期 效能問題-解決方式
分散式 Redis Cache,保護資料庫
分散式 Active MQ,異步處理
RPC framework 實現服務治理
TCP 長連接
ZooKeeper 服務註冊中心
PROBLEMS
京東-中期 延展性問題
開源代碼掌握不深,大促回應速度不即時
指數增長的規模,開源框架撐不住
應用接入多,非核心影響核心服務
機器集群規模增長,故障數增加,穩定性下降
WORK
京東-中期 大促性能問題-解決方式 01
減少網路傳輸:優化協議、數據壓縮、批次傳輸
異步處理、NIO、異步事件
減少內存數據拷貝
優化複製協議:並行複製、增量複製
優化文件存取:順序追加、組提交、內存映射文件
WORK
京東-中期 可用性問題-解決方式 02
解決雪崩效應:自主研發註冊中心
(ZooKeeper > 1,600)
DB
local
cache
scale-
out架構
WORK
京東-中期 渲染問題-解決方式 03
服務註冊時,提供應用級別和業務資訊
按照業務進行物理隔離
按照核心業務進行物理隔離
WORK
京東-中期 可靠性問題-解決方式 04
監控指標:盡可能蒐集系統指標,含硬體、網路性能
客戶端產生TPS性能指標和成功指標,定時上傳
報警策略自定義:依據指標、應用、集群配置
歷史數據海量,存儲問題:ElasticSearch
訂單丟失:消息應答、強制寫入硬碟、主從複製、強迫成功
WORK
京東-中期 相容性問題-解決方式 05
客戶端協議加入版本標籤
服務端向後相容
客戶端路由策略,權重由服務端動態控制
減少客戶端依賴,重要資訊由服務端保存
動態下發客戶端參數,減少不必要的修改重啟
PROBLEMS
京東-近期 維運問題
災備策略
跨機房網路延遲
中間層運維壓力增大
微服務與異步的問題定位
WORK
京東-近期 災備問題-解決方式 01
集群或分片跨物理機部署容災
集群或分片跨機房部署容災
集群跨機房部署、雙活、主從和複製
定期巡檢
WORK
京東-近期 中間層問題-解決方式 02
自助申請,自動創建服務器
故障檢測,自動 failed-over
依據負載,自動遷移
基於 docker 自動彈性擴容,容災、隔離需求、主機負載
WORK
京東-近期 偵錯問題-解決方式 03
京東-備戰
唯品會
架構設計要點整理
PROBLEMS
唯品會-架構歷史問題
全數PHP,效能低,難擴展
服務粒度太粗,重用性低
可靠性低、運維成本高
業務邊界模糊、耦合嚴重
容量擴展不易
PHP相關框架,各團隊產品版本不一致
STUDY
系統架構設計原則
業務驅動
高可用性
可擴展性與高伸縮性
低成本
高性能
安全性
STUDY
系統擴展模型
X軸 : 水平擴展
Y軸 : 業務垂直切分
Z軸 : 海量資料
分區、分庫、分表
STUDY
系統擴展性設計
業務邏輯拆分服務粒度,合理建模
系統分層,增加可伸縮性
服務化解耦,增加重用性
優化 mobile app 接入方式,引入服務網關,增量推送
通訊使用異步,減少同步,改造定時任務
限流防洪、削峰、熔斷、防機器人
STUDY
系統服務化設計原則
服務無狀態
服務可重用
適當顆粒度
統一寫接口
服務可治理
服務間鬆耦合
STUDY
分散式交易
全局唯一 ID (雪花演算法)
最終一致性
定時補償
STUDY
優化數據訪問
訪問量大的數據,讀寫分離
訪問量大且數據量大,做分庫分表
有效率且正確地使用 cache
依據業務特性,做 partition
依特性進行數據庫封存策略
重要數據庫需有主從架構
去交易化:樂觀鎖 + 唯一索引
總結
03 總結
恰如
其分
預想未來,避免過早最佳化
架構是演進式,而非一步到位
認清限制與現況
沒有完美,剛好才是最好
Q & A
Thanks for your listening

Arch summit 2016北京心得 by 91