mig33 wrote:
是你在硬凹吧？請問你...(恕刪)
你知道預購預付流程圖是怎樣安排嗎？
233萬筆預購預付要呼叫金流驗證系統幾次？預購系統要等待驗證系統回應需要多少ms?
你一直沒辦法把帳務跟訂單明細分開處理？
來，不用閃躲，直接告訴我如果照你堅持的預購付款系統處理233萬筆訂單，系統要呼叫金流驗證系統、畫面要跳轉到驗證付款方式幾次？
個人積分：286分
文章編號：76801911
個人積分：286分
文章編號：76801952
個人積分：286分
文章編號：76801975
個人積分：5081分
文章編號：76802526
個人積分：44分
文章編號：76803051
JasonQ wrote:
來，不用閃躲，直接告訴我如果照你堅持的預購付款系統處理233萬筆訂單，系統要呼叫金流驗證系統、畫面要跳轉到驗證付款方式幾次？
JasonQ wrote:
不用等系統回應？然後繼續進入訂購成功的流程？
233萬筆訂單系統要回應幾次？
開發團隊會選擇用最快速的方法把系統做出來
所以目前會採用的方式，的確就是他們衡量過最快的方法
用API的確比用檔案匯入快(指開發程式上)
API串接，變數名稱都定義好了
JSON甚至連陣列和物件也都定義好了
叫用起來很快
反之你前面長篇大論提到的檔案匯入
程式還要去處理哪些文字要代入哪個變數
我以前還見過別公司不願意學呼叫API的工程師
要求匯入檔案要放在指定的FTP上
結果我們還要額外花功夫寫程式去處理FTP相關的東西
我心裡著實把對方公司那個只會檔案匯入的工程師罵到翻
以上情節如有雷同，在此先抱歉，但再來一次我心裡照罵
你一直把焦點放在233萬筆訂單的金流串接
我覺得你忽略了，真正的問題在前段
也就是開放預購時湧入的流量，才是最大的考驗
只要網站能撐過開放預購時湧入的流量
付款階段的流量不會比開放預購大(頂多打平)
有多少人要訂口罩？現在不知道
假設是400萬人要訂口罩，預購流量就是400萬
3/19會決定其中233萬人才是成功購買者
如果系統能撐過400萬人的預購階段
接下來的付款階段會進一步縮小到233萬
這233萬也不會全用刷卡
因為只有電腦版才提供刷卡服務
電腦版要插入健保卡或自然人憑證
很多人光是看到要搞定讀卡機就放棄了
於是會選擇手機APP，這方式只提供ATM轉帳
在ATM轉帳的情況下，幾乎都是銀行端在處理
你所在意的畫面連跳轉都不用跳轉
就看是一分鐘還是多久跟銀行串一次資料
銀行系統通常半夜有一些時段停止服務
假設一天運作22小時=1320分鐘
每分鐘串一次資料，那一天就是串接1320次
付款期限不知道給多久，假設4天 (後面3天留給物流)
串接次數就是5280次
如果有一半的人採用ATM付款
就等於串接5280次處理掉一百多萬筆訂單
當然還是會有些選擇用信用卡付款的人
但這數量會少於預購階段的流量(頂多打平)
畫面跳轉就跳轉，跳轉後是銀行的系統在處理
銀行處理完後就帶回來
簡單說頭過身就過，預購應付得了後面就跟著過
JasonQ wrote:
你還沒回答，你吃一餐點三樣商品要拿幾張發票？付款幾次？
這問題重要嗎？
我通常三樣商品會一起點，拿一張發票
但有時覺得不用吃這麼多的情況下
先拿一兩樣商品，後面覺得還可以吃的下時
又再拿一兩樣商品去結帳
話說如果有客人就是要一樣一樣結帳時
(但客人也排了一次又一次的隊結帳)
商店能怎樣，不提供客人一樣一樣結帳嗎？
個人積分：59分
文章編號：76803464
個人積分：286分
文章編號：76803890
mig33 wrote:
JasonQ wro...(恕刪)
開發團隊的新聞稿告訴你預付貨款模式是個挑戰....
你卻堅持這不是挑戰、不是問題，很簡單，不會對系統造成負擔.....
到底是你支持團隊還是我相信他們的說法？
發票就是購物憑證附帶交易清單，你可以一張發票處理三筆交易，也可以接受一次支付三項商品交易，卻不斷叫囂因為網路科技進步，所以要即時逐筆交易明細與帳款？
“你一直把焦點放在233萬筆訂單的金流串接
我覺得你忽略了，真正的問題在前段
也就是開放預購時湧入的流量，才是最大的考驗
只要網站能撐過開放預購時湧入的流量
付款階段的流量不會比開放預購大(頂多打平)
有多少人要訂口罩？現在不知道
假設是400萬人要訂口罩，預購流量就是400萬
3/19會決定其中233萬人才是成功購買者
如果系統能撐過400萬人的預購階段
接下來的付款階段會進一步縮小到233萬”
你也知道流量會影響系統穩定性，怎麼這麼確定大多數人都用網路ATM訂購？
既然知道這樣設計可能會有潛在風險，卻還在有限開發時間堅持面對風險，正面挑戰？
你高興就好，反正反走過必留下痕跡....
到底誰在狡辯硬凹，時間可以證明....
這個2.0系統是來自報稅系統核心...
報稅系統的網路繳費模式是如何執行，有用過就知道....
現在只是預購系統的身份確認而已，等抽籤完開始線上支付....，那時才是瓶頸....
個人積分：44分
文章編號：76804073
JasonQ wrote:
開發團隊的新聞稿告訴你預付貨款模式是個挑戰....
你卻堅持這不是挑戰、不是問題，很簡單，不會對系統造成負擔.....
我說的是他們會用最快速的方式來開發系統
至於是不是問題
那是跟其它方法做比較得出來的
(跟你提的主意比較起來不會比較難)
例如每筆訂單的付款狀態橫豎都是要做的
就是跟哪家串的區別 (除了不做最快最簡單)
你的說法一開始講的好像不用取得訂單的付款狀態(爛尾)
後頭又改成說用檔案匯入的方式來做(古法遵製)
不然請你解釋
既然你認為你說的方式比較簡單
那開發團隊為什麼不採用你說的方式？
你覺得開發團隊沒事找事做
要放著你所謂比較簡單的方法不用
要去用比較複雜的方法？
又請問你：
做一輛汽車跟做一輛太空梭，哪個比較簡單？
請你選一個比較簡單的你自己做看看
什麼都不簡單？所以你的意思是乾脆不要做了？
你可以不做汽車和太空梭
但口罩2.0系統因為有挑戰就不要做？
就讓時間來驗證
看開發團隊會不會修正成你所說的方式？
(改用貨到付款，取消串接銀行金流，檔案匯入收款明細)
個人積分：286分
文章編號：76805511
個人積分：44分
文章編號：76805890
JasonQ wrote:
我的發文有哪一點提到不用取得訂單付款狀況？
"會計系統"是"會計系統"
各筆訂單的狀態會放在"銷售系統"裡
從下面你的回文來看，你說的東西是"會計系統"
你當我分不清楚會計系統和銷售系統的差別嗎？
你略過銷售系統的訂單狀態需要處理沒提(然後只提到拆帳)
那自然是指總帳金額，而不是指訂單收款明細
https://www.mobile01.com/topicdetail.php?f=638&t=6042341&p=12&p=12,12#76798233
JasonQ wrote:
“先付款是串、後付款也是串
接銀行是串、接超商也是串
所以串接金流這部分的工是無法省下的”
不對喔....
先付款是一對多....目前準備233萬份，所以至少是一個預購系統要呼叫233萬次串接金流....
到貨付款是跟業者拆帳，目前已知是四大超商，所以是一個“會計系統”對應四家業者的帳務系統....就算是日日結帳好了，也不過4×20天=80次....
你不會不知道，這兩種系統營運壓力有多大差別吧？
而且我提到：
先付款是串、後付款也是串
接銀行是串、接超商也是串
所以串接金流這部分的工是無法省下的
指的就是233萬筆的訂單收款明細遲早要回來的
你還說 "不對喔...."
代表你認為可以省下這部分的工
