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