以前看的一本書淘寶這十年來，一起回顧下電商系統(tǒng)的發(fā)展歷程，其實也折射了目前很多系統(tǒng)技術發(fā)展的變革。從單機版到目前淘寶的技術狀態(tài)。
（一）目的
- 一起了解學習的分布式專題技術可以串起來。
- 2.了解電商系統(tǒng)相關的技術知識。
- 3.面試，工作可以應用到。
（二）一個電商系統(tǒng)到底包含什么
圖有點長，網(wǎng)上找的但是如果要做這個系統(tǒng)老費勁了。體力活。美國，蘇寧，京東電商大型網(wǎng)站都是上萬人研發(fā)。可見系統(tǒng)的龐大。
（三）系統(tǒng)的歷史
- 淘寶第一版--個人網(wǎng)站
LAPM 【linux+apche+php+MySQL】
- 1.JAVA早期的電商網(wǎng)站
多個模塊在一個系統(tǒng)中，通過jdbc的訪問同一個數(shù)據(jù)庫。
存在的問題，隨著流量越來越大，數(shù)據(jù)庫查詢速度慢，系統(tǒng)反應慢等等，單機的性能瓶頸。
- 2.java電商網(wǎng)站，引入集群
加機器的方式解決，集群的方式來解決。
存在的問題，訪問的那臺機器是不知道的。
- 3.java電商網(wǎng)站，引入負載
增加負載的方式，分為硬負載f5，軟負載Nginx。
存在的問題，第一次訪問的機器是A機器，第二次因為負載了訪問了B機器。
- 4.java電商網(wǎng)站，負載后，請求的4種解決方案。
（1）hash的方式，通過請求IP的hash值綁定要請求的服務器。
存在的問題，abc每次請求都發(fā)A機器，這個就是受單點的問題，如果A機器掛了，abc的請求得不到轉(zhuǎn)向，一直請求A機器，用戶一直訪問不了，一直報錯。
（2）session的復制，通過A和B機器進行相互的session復制
存在的問題，Tomcat廣播的形式，造成資源的浪費，100萬用戶在線，等于每個tomcat里面都有100萬的用戶session的信息，對系統(tǒng)的浪費承諾很大。適用于小型網(wǎng)站。
（3）基于cookie的方式，cookie包含session的數(shù)據(jù)
解決了上面session復制，資源的浪費，服務端的壓力的問題。
存在的問題，數(shù)據(jù)不安全的問題，用戶數(shù)據(jù)的都在客戶端，存在破解的可能。手機一般都使用這種cookie的方式，手機都是單獨自己使用的，不存在公共部分。
（3）session集中存儲的方式，加入redis或者其他中間件
存在的問題，相比前集中增加了redis中間件，增加了運維和開發(fā)的成本。如果用戶量非常大，用中間件的方式也是可用性非常高的。
- 5.java電商網(wǎng)站，數(shù)據(jù)庫原來一個應用一個數(shù)據(jù)庫，需要集群數(shù)據(jù)庫用同一個。
5.java電商網(wǎng)站，數(shù)據(jù)庫分讀寫，解決高并發(fā)讀寫的問題，master和slave流量的問題。
存在的問題：下單之后到主庫，然后立馬查詢到從庫。這個時候主庫信息還沒同步到從庫中，系統(tǒng)可能就報錯了。這種問題解決方案只有一個TDDL，sharding-jdbc。
- 6.java電商網(wǎng)站，讀寫分離，分庫分表。
proxy：應用程序在訪問數(shù)據(jù)庫的時候，中間攔了一層，通過攔截可以知道是select 還是insert，update判斷是走主庫還是從庫。proxy需要維護，維護高可用，協(xié)議要攔截性能要下降。
應用層：shardingJDBC基于jdbc底層的請求原理，請求的時候改成sql的方式。訪問讀庫還是從庫。開發(fā)人員需要了解shardingJDBC的業(yè)務，增加了開發(fā)成本和學習的成本。數(shù)據(jù)庫管理需要。
- 7.java電商系統(tǒng)，增加搜索引擎和redis集群
search cluster 全量同步，和定時增量同步都是通過讀mysql的binlog完成的。解決數(shù)據(jù)庫壓力。
redis cluster 通過緩存到redis中，直接從redis中獲取，減少數(shù)據(jù)庫的讀寫。
CDN 通過將靜態(tài)文件放到指定的服務器，通過CDN下載靜態(tài)資源。
（四）分布式時代
引文：商品模塊和會員模塊兩個不同的人開發(fā)，他們是互相調(diào)用的關系，商品模塊的人開發(fā)完畢了，但是會員模塊的老鐵說，今天不上了，這是不是很尷尬，商品模塊的需要回滾到滿足會員模塊的，兩個人就開始掐架了，我好心寫了你讓我回滾，會員模塊的說其實我也不想，這個產(chǎn)品經(jīng)理不讓上。隨著系統(tǒng)越來越大，各個模塊變成了系統(tǒng)，每個系統(tǒng)是由不同小組來完成的，為了滿足互相之前不受影響，就開始服務化。
- 說說淘寶的HSF 和 dubbo
提供對Dubbo和HSF兩個RPC框架的支持。阿里巴巴第一代RPC框架Dubbo是國內(nèi)第一款成熟的商用級RPC框架，已于2011年正式對外開源，目前已發(fā)展成為國內(nèi)開源價值最高、用戶使用規(guī)模最大的開源軟件之一。最新一代RPC框架HSF，全稱High Speed Framework，也叫"好舒服"，"很舒服"框架，是阿里內(nèi)部對這一款高性能服務框架的昵稱，是一款面向企業(yè)級互聯(lián)網(wǎng)架構(gòu)量身定制的分布式服務框架。HSF以高性能網(wǎng)絡通信框架為基礎，提供了諸如服務發(fā)布與注冊，服務調(diào)用，服務路由，服務鑒權，服務限流，服務降級和服務調(diào)用鏈路跟蹤等一系列久經(jīng)考驗的功能特性。
他們之前的互相調(diào)用很復雜。至少功能進行了解耦，會員和商品之前的依賴關系，會員上線失敗只會局部的影響。但是會產(chǎn)生一個問題互相的調(diào)用，占用更多的網(wǎng)絡資源。
- 分庫分表的方式繼續(xù)優(yōu)化
每個應用一個數(shù)據(jù)庫不在整個使用一個數(shù)據(jù)庫了，每個應用一個庫，對于比較復雜的利于訂單，產(chǎn)品通過sharding-jdbc來進行分表。用的最多的hash取模的方式，hash比較均勻，避免數(shù)據(jù)熱點的問題。但是hash的方式不容易進行擴展，之后會說如何針對hash進行擴展。
- 消息中間件
異步和解耦，雙11下單的量很大，從Notify>metaq>rocketMq都是一樣的。削峰填補。下個單需要查庫存，告訴統(tǒng)計系統(tǒng)，還有風控系統(tǒng)。平常時候統(tǒng)計系統(tǒng)是不用的，而是雙11的時候使用，總不能平常的時候把統(tǒng)計系統(tǒng)的代碼注釋吧？到雙11在把代碼放開，然后在上線。利用rocketMq的來解決。
- 圖片服務
- oss tfs的方式。上傳一次，公用的都可以拿到。給每個圖片識別一個號，第二次上傳會讀hash，如果這個hash已經(jīng)存在就不在上傳。時間換空間的一個問題。解決數(shù)據(jù)庫的一個問題。
- 數(shù)據(jù)庫存儲圖片名稱和路徑，圖片的物理地址存儲到硬盤里面。分布式肯定有問題！冗余AB服務器都存一份，或者搞個圖片服務器。不可取。
- 流的方式儲存到數(shù)據(jù)庫里面。占用硬盤資源，需要轉(zhuǎn)碼對數(shù)據(jù)庫的IO。
- 運營系統(tǒng)
日志系統(tǒng)，風控系統(tǒng)，報表系統(tǒng)，調(diào)用鏈系統(tǒng)。
PS：看到電商是如此復雜是不是有點頭疼，越往后業(yè)務越來越細分，運維的工作量越來越大。兩個程序員最怕的點【改需求，改別人的代碼】。分布式基本就是2個點，應用和數(shù)據(jù)庫。
堅持原創(chuàng)的35歲IT老兵！感謝您能夠看完這篇文章！感謝關注，評論，轉(zhuǎn)發(fā)！
