Cost
所有服務
| 服務 | VM | VCPU | Memory size(GB) | Hard disk size(GB) |
|---|---|---|---|---|
| K8s(Run 69 Pods) | 3 | 16 | 128 | 200 |
| Solr | 2 | 16 | 16 | 200 |
| PostgreSQL | 2 | 16 | 32 | 600 |
| Kafka | 3 | 4 | 4 | 80 |
| ZooKeeper(zk01) | 1 | 16 | 8 | 20 |
| ZooKeeper(zk02,zk03) | 2 | 4 | 4 | 20 |
| Infinispan | 2 | 2 | 4 | 20 |
| HAProxy | 2 | 4 | 4 | 20 |
| Nginx | 2 | 2 | 4 | 50 |
| GitLab | 1 | 8 | 8 | 100 |
| Jenkins | 1 | 2 | 4 | 50 |
| Harbor Registry (IMG Hub) | 1 | 2 | 2 | 100 |
| Elasticsearch | 1 | 8 | 8 | 750 |
| Logstash | 1 | 4 | 4 | 20 |
| Kibana | 1 | 4 | 8 | 100 |
| DNS | 1 | 2 | 2 | 16 |
| MAIL Server | 1 | 4 | 4 | 20 |
| Object Storage (Ceph) | 3 | 4 | 4 | 150 |
故事
2021
5月 我加入精誠，非Oneec身分，但是閒暇時會與Ethan進行相關的討論，並且不時會看SHOPEE跟東森的API文件思考架構
8月 infra加入精誠，非Oneec身分，但是Ethan已經準備好了技術選型並且請這位Infra整理機器，清理空間
9月 PM加入精誠 ，Oneec身分，Ethan請她進行思考
10月 最強的全端RD入場，Oneec身分，Ethan請他跟Infra準備K8S環境底下的高可用環境程式
12月 還在討論Topic，12月中 全端RD回報，準備好了，開工
此時機器 4台ESXI (費用0、營利模式未知、人事 就上面這四位)
此時客戶 1 穩定 0
2022
3月 V1版本出爐(OMS+算量推薦+改量 )
SUCCESS: 通路:東森、MOMO、蝦皮、YAHOO
(這個版本 一家TBS 訂單就撐不住了，而且狀態極度不可控制)
處理訂單的pod開到(64)
花了將盡快四個月對資料
4月 定價模式出爐(6萬/年 通路3個 帳號無限 不限訂單)
6月 開始做出貨
7月 出貨搞定(取號跟小白單有諸多問題 各通路抓BUG不止)
9月 出貨穩定
11月 前面的推薦+改量>>>變成自動化，推薦數字後立刻打平台
12月 OneEC基本穩定 改去救火CDP
此時機器 4台舊機器+4台新機器 (費用120、營利模式帳號費、人事 這一年幾乎快速擴充到10+)
2舊機跑測試 2舊機+4新機跑正式
此時客戶 大約5+ 穩定 0
2023
5月 V1 CDP版本出爐
6月 持續擴張通路跟出貨
7月 設計上架(蝦皮優先 但是可支援SHOPLINE)
9月 上架上線、訂單處理的快取加入
10月 訂單產賣場的問題影響到量的問題始終無解，因此改從平台抓賣場跟商品
此時機器 4台舊機器+8台新機器 (費用240、營利模式帳號費(3種價格)、人事 18)
2舊機跑測試 2舊機+8新機跑正式
此時客戶 大約10+ 穩定 3
2024
3月 量的計算問題解決
4月 推薦的問題解決
5月 依訂單的計價模式出爐
6月 30穩定客戶達標
8月 業務團隊被拔了、訂單抓取方式修正完畢
9月 資料庫瓶頸問題解決(CAP理論，根據情境部分CP部分AP)
10月 最強RD離職
11月 被宣告停止上板
12月 被宣告月底結束
此時機器 4台舊機器+8台新機器 (費用240、營利模式帳號費(4種價格)、人事 End)
2舊機跑測試 2舊機+8新機跑正式
此時客戶 大約110 穩定 30
機器的費用
因我們的Service的關係，走分散式高可用架構，加上服務起始都不小
我們一開始就是從本地出發
蹭地端的流量費用(1G就夠用了，這三年下來沒爆量過)
最終我們地端版的 要250+ 四台是免費的 如果算上去的話加一百
但是如果是雲端，之前的INFRA評估，第一年的客戶還有服務數(第一年的SOLR只有六個SHARD、PG也只有兩個NODE Master+slave)第一年的雲端費用大概是50萬，但是到第四年就算最便宜的GCP也要130萬，因此Ethan選擇買機器
流量的議題
上一次有討論到流量費的原因在這裡
比方說一個客戶 他有三個通路 (蝦皮 YAHOO MOMO)
另一個客戶 他也有三個通路 (蝦皮 Shopline MOMO)
這四家API就有打的頻率 種類 還有宣告欄位的差異
平常來講 我需要打的次數就有可能從10次到100次不等
每一次都是1KB到200KB都有可能的RANGE
因為shopline的訂單會一次把所有資料吐出(資料未必準 需要第三方的webhook比較準確)
但是shopee的你可以宣告極簡欄位來省流量
這一部分也有IP的限制(PCHOME MOMO都有 ，這部分可以透過reverse proxy+header解決 上一次harry也有說)
以這四個通路的大致上用量方法跟流量
S:是小量的 大約就1~10以內
M:是中量的 大約在100以內
*N:是大量的 大約在200上下
| 狀態 | 蝦皮 | YAHOO | MOMO | Shopline |
|---|---|---|---|---|
| 未付款 | X | X | X | 5分 200kb*S 1小時 |
| 待出貨 | 5分 4kb*S 1小時 | 5分 1kb*S 72小時 | 5分 4kb*S 72小時 | 5分 200kb*S 1小時 |
| 出貨中 | 5分 4kb*M 72小時 | X | 5分 4kb*N 72小時 | 5分 200kb*M 1小時 |
| 完成出貨 | 60分 4kb*N 144小時 | 60分 1kb*N 144小時 | 60分 4kb*N 144小時 | 60分 200kb*N 1小時 |
| 完成訂單 | 60分 4kb*M 144小時 | X | 60分 4kb*N 144小時 | 60分 200kb*M 1小時 |
| 取消訂單 | 5分 4kb*M 288小時 | 5分 1kb*S (待出貨的單子去問) | 5分 4kb*N 144小時 | 5分 200kb*M 1小時 |
| 退貨訂單 | 5分 4kb*S 288小時 | 5分 1kb*S 288小時 | 5分 4kb*S 288小時 | 5分 200kb*S 1小時 |
5分 4kb*S 1小時 <<<5分鐘抓一次，抓到的資料量是少次的，每次大概4KB，跟平台請求資料的range大概是1小時
但是頻率其實可以不用那麼快，我們當時是為了跟買賣拚，他們五分鐘我們也五分鐘，可是其實yahoo的訂單快取是十分鐘，等於兩次浪費一次
以上是訂單的
如果要把後面的改量也加入
每一張訂單裡面有三個商品 (每一張)
三個商品帶動可能各自有5個賣場
3*5=15 <<<就會跟5個通路各自進行三次溝通 所以會在上面的數量上再”倍數”擴增
改量的request跟response不會像訂單那麼多(來回都是1KB內的)
但是他的API次數非常多(對於一些對API限速的平台非常傷 Ex pchome 東森 )
當時我在後面有做各式各樣的減速跟算法來減少去跟平台溝通
這部分必須要找出一個商務上可以接受的模式跟方法還有跟客戶的說法
OneEC訂單流程(到推薦)
flowchart TD
訂單啟動器/5min -->各通路normal抓訂單
各通路normal抓訂單 --部分通路要往細節打-->各通路normal抓訂單
各通路normal抓訂單 --快取-->大總管處理
OpenApi -->大總管處理
Excel -->Excel-parse-job --排隊-->大總管處理
Webhook來的訂單 -->大總管處理
大總管處理 --新訂單-->新訂單事件
大總管處理 --出貨訂單-->出貨事件
大總管處理 --沒SP-->產SP
大總管處理 --沒SKU-->產SKU
大總管處理 --取消訂單-->取消事件
大總管處理 --可弄出貨單 -->產出貨明細
產出貨明細 --看贈品邏輯-->產贈品
新訂單事件 -->算量
出貨事件 -->算量
取消事件 -->算量
算量 -->找組合品
找組合品 -->算推薦
算推薦 -->各平台的job
產SKU -->產SP
產SP --是出貨--> 新訂單事件
新訂單事件 --如果訂單是出貨訂單-->出貨事件
發佈留言