电商项目01
文章目錄
- 一、電商項目整體架構
- 二、我們的思考
- 三、電商發展與技術演變
- 淘寶架構升級
- 什么是4.0 時代？
- 云原生：
- 總結
一、電商項目整體架構
按交易主體
按運營模式
按運營方向
傳統電商 淘寶天貓、京東、唯品會、聚美優品、當當…
社交電商 拼多多、京東、國美、蘇寧
網紅電商 抖音、快手
內容電商 頭條三農領域
常見術語
PV：?Page?view，即網站被瀏覽的總次數
UV：?Unique?Vister的縮寫，獨立訪客
CR： ConversionRate的縮寫，是指訪問某一網站訪客中，轉化的訪客占全訪客的比例 （訂單轉化率=有效訂單數/訪客數）
SPU：?Standard Product Unit （標準化產品單元）,SPU是商品信息聚合的最小單位，是一組可復用、易檢索的標準化信息的集合，該集合描述了一個產品的特性。
SKU： Stock keeping unit(庫存量單位) SKU即庫存進出計量的單位（買家購買、商家進貨、供應商備貨、工廠生產都是依據SKU進行的），在服裝、鞋類商品中使用最多最普遍。 例如紡織品中一個SKU通常表示：規格、顏色、款式。SKU是物理上不可分割的最小存貨單元。
程序 = 算法 +數據結構
系統 =？+ ？（服務 + 數據存儲）
二、我們的思考
容量規劃、架構設計、數據庫設計、緩存設計、框架選型、數據遷移 方案、性能壓測、監控報警、領域模型、回滾方案、高并發、分庫分表
后端架構
項目架構圖、技術選型、數據庫介紹
數據庫開頭對應：
cms 后臺模塊
oms 訂單模塊
pms 商品模塊
sms 營銷模塊
ums 用戶模塊
那大家看到的是一個已經相對來說比較完整的一個分布式電商網站。那他從最初的時候是怎么樣的？
三、電商發展與技術演變
最早的時候：大部分程序員做的
這種架構會產生很多問題，比如高可用問題，服務器掛掉或者訪問量人多會出問題。
加入nigix分擔服務器壓力
一個人登錄的時候在前100以內發送到A服務器，在下單的時候請求打在了B服務器，用戶需要重新登錄。
可以使用分布式session解決問題：
方案一：用ip進行負載均衡，使用ip進行hash，自定義規則，ip不變請求的服務器不會改變。問題：資源浪費，單點故障，（一個服務器掛了還是不能下單），服務器滿了，再次請求也無法訪問
方案二：基于session復制的方式實現，用戶登錄把數據保存在session，將兩個服務器數據同步，讓用戶請求不同服務器都可以有session數據，TomCat通過網絡通信。問題：耗內存、耗寬帶。一個用戶登錄，要廣播所有TomCat，開銷非常大，以太坊 區塊鏈的實現機制就是這樣。
方案三：用戶登錄到服務器后再把數據存儲到redis中，有沒有登錄在redis一查詢就知道。普遍的解決方案，需要增加的額外技術（維護redis的高可用，如果redis掛掉了，也有問題）。
系統分為服務+存儲，多個服務器同時請求一個數據庫，會使數據庫壓力很大，需要優化。
用戶服務器是無狀態的，狀態存儲在redis上。
解決方案：
用的最多的：換數據庫，分庫分表（讀寫分離、對數據庫本身的優化）
個人 網站：內部調用（JVM）完成 數據庫項目都同一臺服務
下單》登錄》session 》http
應用程序優化：
數據庫優化：
1、換數據庫 mysql》redis 》oracle》tidb 關系型性能
讀多寫少（訪問商品）》redis 搜索 es內存搜索（全量、增量）
2、分庫分表（讀寫分離）
jdbc應用層：shardingsphere（shardingjdbc）、tddl
proxy代理層：mycat、mysql-proxy
jdbc應用層分片性能高一點，少了一次代理，Proxy代理分片對程序0侵入，可以使用別的語言編程，更靈活
跨部門的問題：
垂直： 會員部門、商品部門 周四（開發》測試》預演》生產）
會員部門：成功（kpi） 失敗（回滾）
性能解耦、開發的問題
帶來很多問題：1個N個服務，服務之間調用依賴也會增多。
rpc調用：dubbo、fegin、http
1、異步調用 2、分布式事務（數據庫事務A B 兩個數據庫、A服務、B、C）
rocketmq、shardingsphere（mq）、異步下單 （異步、削峰、解耦）
帶來一些問題：消息重復、消息丟失、消息積壓、冪等性問題
拆分服務，微服務架構，垂直拆分，數據匯總
淘寶架構升級
什么是4.0 時代？
云原生：
微服務、容器化部署、DevOps
微服務：
為什么這兩個系統會相互影響？
微服務的本質是把一塊大餅分成若干塊低耦合的小餅，比如一塊小餅專門負責接收外部的數據，一塊小餅專門負責響應前臺的操作，小餅可以進一步拆分，比如負責接收外部數據的小餅可以繼續分成多塊負責接收不同類型數據的小餅，這樣每個小餅出問題了，其它小餅還能正常對外提供服務。
微服務解決的是我們軟件開發中一直追求的低耦合+高內聚、單一原則
DevOps：
DevOps的意思就是開發和運維不再是分開的兩個團隊，而是你中有我，我中有你的一個團隊。我們現在開發和運維已經是一個團隊了，但是運維方面的知識和經驗還需要持續提高。
持續交付：
持續交付的意思就是在不影響用戶使用服務的前提下頻繁把新功能發布給用戶使用，要做到這點非常非常難。我們現在兩周一個版本，每次上線之后都會給不同的用戶造成不同程度的影響。
容器化：
容器化的好處在于運維的時候不需要再關心每個服務所使用的技術棧了，每個服務都被無差別地封裝在容器里，可以被無差別地管理和維護，現在比較流行的工具是docker和k8s。
所以你也可以簡單地把云原生理解為：云原生 = 微服務 + DevOps + 持續交付 + 容器化
總結
電商項目的整體架構，以及不斷變化改進的解決方案。
總結
- 上一篇： linux dd 拷贝文件,Linux系
- 下一篇： 笔趣阁小说TXT采集软件工具