C2C Payment

六年前左右 在上一家公司Y拍的第一份任務
就做輕鬆付這個案子
這個案子當年就五六個人組成的scrum team
由於這份一起做產品的緣故
當年這些人 後來很多都成了我在Y!最好的夥伴與戰友
當時我才進公司一個月多 就被指派進去war room
從第一行程式開始做起 開始跟同事討論資料庫的設計
開始討論系統的架構 前端有同事參考了RoR設計了一個簡單的MVC架構
到與銀行串接的規格 與拍賣或是其他內部property串接的規格等等
這些都讓我們在war room裏頭的同事 雖然很累 卻也很有成就感
雖然只是在台灣 不過也會去參考外國像是google checkout, paypal甚至是大陸的支付寶
看看人家有哪些功能 我們也能做的
當時雖然是透過scrum這樣的方式快速開發
不過卻也能在許多設計上有許多還不錯的想法
像是引入跟log4j類似功能的log4cpp作為預設的logger系統
exception的處理能夠透過簡單的方式產生類似java的code stack trace
client server架構透過Y!內部的herb server
跟銀行串接部分由於銀行只有提供java api 還有透過java實作herb server
MVC架構也算是很清楚乾淨
程式語言部分 前端用php 後端用cpp 很少部分的partner api使用java
最後到上線的時候 這樣一個服務就用了
4台的frontend 8台的backend 2台batch 2台partner 2台property
還不含資料庫的部分
到後來由於有機器整合的案子 所以機器的數量大幅的縮減以節省成本
不過也可以想見當時系統一開始上線的時候 其實是有點複雜的

不過當時一開始的確是很有野心的
功能上像是現在paylink所做的延遲支付一開始就有實作出來
支付方式一開始就有ATM 帳戶自行互轉 跟信用卡
可以儲值 也可以透過ACH的方式提款
其實就已經像是一個小型的銀行帳務系統了
而且在設計用戶資料庫的時候 也有想要支援非公司內部的需求
想要規劃像是paypal或是google checkout可以讓其他人透過open API的方式進行支付
交易安全的部分 除了透過銀行的機制做實名認證
也能夠依據不同的認證程度作交易額度的控管
甚是也有在天馬行空的想跨國支付的可能性

可是最後由於種種的因素 這個系統剛推出的時候
其實並不是很成功
很多功能都因為種種的因素不能上線
其實讓我這個開發這個產品的軟體設計人非常的失望
雖然後來幾年陸續又做了幾個不錯的功能
像是多退少補 或是 便利商店超商取貨等功能
透過輕鬆付的交易 也慢慢成長到一個不容忽視的交易量了
後來在公司也做了不少其他電子商務的案子 不過總是沒有這種由第一行開始生出來的系統來的感情深厚
不過最後也由於對於這個產品的無力感 當時一起開發的夥伴一個一個離開
也讓我終於離開了這家公司

不過我想當年的這個產品 我從上線開始到後來一年幾十個億的交易量
也還持續在成長
雖然已經不在公司了 不過也是一個會讓這個開發者感到驕傲的事情

NoSQL

目前的許多的網站 越來越多開發者使用所謂的NoSQL的資料庫來取代原有的關聯性資料庫
我只是就我所瞭解的幾個點來分析一下 究竟在怎樣的情況使用傳統的關聯性資料庫 怎樣的情況 我會考慮選擇使用NoSQL類型的資料庫
1. data scale
NoSQL被重新拿出來實作 最主要的一個需求 應該是在像Google或是Facebook等網站 對於大量資料存取的需求. 他們的需求 並不是Mega或是Giga等級的資料數量 而是全世界的使用者 每天
都有數Tera byte的user gererate data需要被分析. 在這種數量級的資料傳統的SQL很快就會達到他的極限 一般來說MySQL在處理千萬筆資料的時候效能就開始變差 而Oracle比較好 在billion的資料數量級都還可以表現的不錯 不過通常NoSQL處理的資料數量等級是每天可能就會新增一billion的資料 在那種資料量需求之下 NoSQL相較之下 就會很突出
2. transaction require
在很多分析的文章中會提到ACID與BASE的比較 或是CAP的理論
我從實際maintain的角度來看 如果系統出現異常 某些資料庫當機了 這時候有兩種選擇

某些資料 壞掉或是不ㄧ致的狀況是可以被允許的 事後不需要修復相關的資料 (像facebook的訊息錯掉 大部份是沒關係的 使用者並不會來要求修復資料) 可是系統不能整個停掉也就是不能有single point failure. Service的品質重要性高於資料正確性 這種類型的應用就NoSQL可能會比較好
相反的有些類型的服務 系統ㄧ致性的重要性遠高於系統的穩定性 像是Billing或是Payment系統好了 如果系統有異常會導致資料錯誤 我們寧願讓系統下線也不願意錯誤的資料持續進來 這種類型的系統 可能傳統的資料庫會比較符合我們的需求

Facebook與VISA或是銀行帳務系統是兩種應用光譜的極端 一種是RDBM系列 一個是NoSQL系列的 可是在大部份著情況 可能不是那麼極端 或許就有一些其他的因素可以考慮在內
3 query and index
目前的NoSQL雖然有部份已經能支援簡單的query 可是跟RDBM比起來還是非常的原始 只支援key value pair的查詢 對於application的開發來說 其實是很大的一個限制. 更不用說需要作filter或是order by的查詢 如果那些功能對你來說很重要 那還是乖乖的用RDBM吧
但是如果你所開發的程式可以透過簡單的演算法避開所有的查詢 (或是直接請需求端把所有 不重要的query拿掉) 那或許NoSQL還有機會

4. failure tolerate.
在read only的系統 其實兩者的差別並沒有那麼多 因為RDBM可能透過multiple slave的方式自動的把資料replicate到許多node上即使ㄧ兩個node死了 也不會影響系統讀取的動作
差別主要在於write的動作 以設計面來說NoSQL的service quality絕對會比傳統的資料庫好 當然這個差別並不是沒有代價的 以資料來說一個資料commit 可能只是master成功了 可是slave都還沒有sync 也有可能是所有node全部都update完成才算是成功 或是有N個node只要有其中兩三個node成功就算是寫入成功 這三種策略對於系統的反應時間與系統寫入失敗的機會就有很大的差別
如果寫入一個master node就算成功 寫入的速度會比較好 因為不需要將後面數十個node都update好了才能回應給client端省下了不少反應時間 可是寫入的機器可能就是single point failure. 而且 NoSQL通常用的就不是single master而是multi master並且是自動fail over的機制 直覺上看來multi master應該是比較好 為什麼RDBM不這樣實作呢 這個就又回到兩種資料庫基本的設計理念的不同了 當資料的consistent很重要時 NoSQL這種方式有時候是會出問題的 因為他基本上就是用consistent 換取了 availability.
通常一個record如果資料replicate成N份的話 如果資料內容不ㄧ致 問題就在於我們要相信哪份資料 而且每次read可能並不能aware到有這樣的不一致 如果這個資料的內容是賬戶的餘額的話 問題就很大了 我究竟要相信那份資料 而有些transaction是跟command的前後order與內容強烈相關的 像兩筆交易如果會把餘額扣光 那兩筆成功的順序就變得非常的critical 如果這時候有幾個node之間資料不一致的狀況的話 那問題會變得非常複雜 所以才會說有transaction相關的資料 會建議保守的用RDBM就好了

Software scalability

一個網站在受到歡迎之前
通常不須要考慮太多的技術上如何最佳化的問題
如果一個網站一天有五萬個人點閱
在個人網站來說 可能算是還不錯的規模了
可是粗估一下流量也不過是一秒兩三個request罷了
所以在這種程度的service 通常其實只要一臺電腦跟好一點的頻寬 就可以支撐起大部份的服務了
而其實可能有九成的小網站或是小部落格 都是某人桌底下的一台低調的server而已

可是如果你是想設計google或是yahoo這種入口型的的網站
如何有效率的從有限的硬體裡頭 榨出更高的request/second 就變的非常重要
這個問題 可以分析的切入點有很多
我主要是講的部份是如何切割你的系統以承受更高的使用量
在網站突然開始流行的年代 有一派人的想法其實只是用更強大的硬體規格解決量的問題
這其實也是一種不錯的方案
這個方案的好處是非常的簡單 就是花錢買最好的機器
如果當年的個人電腦 只能承受每秒100個request 而我業務上的需求如果需要500-1000 request/second
那我就用很貴的經費買最佳化過的硬體跟compiler 也就是類似超級電腦或工作站的機器
軟體都不需要修改 只要把程式放到最好的機器上 問題就解決了
反正當我業務成長到某個階段的時候 又會有更好的硬體出現 可以解決網站效能的問題
這個方式好處是相對來說軟體的設計簡單 複雜的是硬體如何最佳化的設計
但是缺點是很貴 在PC一臺只要五萬台幣的年代 一台工作站軟體加硬體合起來
幾百萬甚至上千萬有時候是跑不掉的
不過這也是現在很多銀行所使用的方式
銀行後台很多所謂的IBM的大型主機 其實也就是一臺很穩定很強大但是也很貴的機器

不過在網路泡沫化之後 這種燒錢的方案 慢慢的比較不受歡迎了
另外的一個因素也是因為現在的PC 效能也不可同日而語了
現在的PC 記憶體也是好幾G CPU不只一顆
所以現在所看到的大型網站的機房 其實大部份都是上百上千台的PC組成的
像我所熟悉的電子商務網站來說好了
看起來就是一般的網站 可是後台 其實有上百台機器相互串聯合作所組出來的服務
如何將網站的功能平均的分散到這些PC上 就是軟體的設計與架構了
不過這個方案 以成本來算的話 若硬體成長十倍也表示購買PC的預算要多十倍
中間還有機器每個月多消耗十倍的電能 十倍的機房空間
還有更多硬體可能壞掉要維修的維護成本
像google 那種規模的機房 平均一天都幾顆硬碟故障或是機器要重開維護也是很平常的
所以中間的取捨也是設計要考慮的因素


不過我們以第二種 軟體的設計解決量的問題 通常就會碰觸到分散式設計的概念
通常這個分散設計的方式可以分成兩種
一種是橫的把網站分成很多的子系統
另一種就是把一個系統 切成許多的一樣的farm

如何將網站分成許多的子系統
如果兩個子系統之間是獨立不互相關連的存在的
那這兩個系統 就可以存在於兩組不同的機器上
當然也就可以把相同的loading 交給更多的機器處理
如果你可以把一整個網站的功能 切成10個獨立的子系統
那最樂觀的狀況 可能就表示你的網站可以承受的量 是原本沒有切割前的10倍左右
現實的狀況當然會有某個子系統可能是所謂的瓶頸 也就是bottle neck
不過通常效能提升個三五倍通常不是問題

另一種就是把同一個服務不同客戶的資料放在不同的機器上
也就是分farm的概念
像一些有名的blog 雖然資料很多量也很大 不過不同的user之間 其實沒有太大的關連性
所以我們就可以所有的user分成N等分 等分到N組的機器上
而每一組的機器都是必須有完整的功能
所以假設我們一組機器可以服務一百萬個使用者 那五百萬個使用者就是把系統切成五組farm
當系統又成長到一千萬的時候 我們只要繼續加機器就可以解決

待續...

遠景

在想一個產品的時候
很多人常常會因為現實的環境 技術或是資本上的門檻 而自我設限
在當年還可以自己空想的年代
我常常會問自己一個問題
你覺得你的技術 在五十年後一百年後 還是這樣一成不變嗎
已經沒有想像或是進步的空間了嗎
當你的想法是以十年為一個週期 想像空間 就會以幾十年的遠景與產品規劃
產品就不會保守
就像很多現代的產品其實在star track 影集中都已經出現了
那就是想像的力量

就像汽車產業 會有所謂的概念車 未來車
或許這些技術 還沒有量產 可是這些技術 已經研發好在那邊等市場成熟了
電動車或是自動駕駛的車 都是這樣的遠景下的一個產品

手機上網為例子
幾年前 很多人都覺得手機就是這樣了 就是講講電話就夠了
在當時 的確投資在手機上網 3G 4G WiMax 等等似乎都等不到真正的殺手級應用 而處在賠錢的狀態
但是持續的問自己 五十年後的手機 還只是只能講電話而已嗎
如果你想像中的未來不是那樣 就一定知道要投資更聰明的手機
也就是所謂的smart phone
結果不用五十年 只不過十年的光景
現在的手機 已經可以結合隨身聽 GPS 還有相機了
那就是想像的力量
以實際的操作來說 當然投資的時間點 是一個重點
很多技術 都是突破某個門檻之後 才在市場上大爆發
在那的突破點之前 通常都是賠錢的份
不過這也是那麼多的科技大廠 要投資這麼多錢 在研發上面
雖然研發不一定成功 不過十個產品 只要有一個成功 往往成果是很甜美的

回頭問一下 我所在的產業
電子商務或是網路公司 的未來是什麼呢
十年之後 我們的網站就是無窮迴圈的改版嗎 就是把營業額在擴張之外
我們能夠提供這個產業 什麼新的遠景嗎
如果不持續的這樣想
就不可能有下一個flickr 下一個facebook

園丁

有次在原住民的餐廳中看到這句話
人不擁有土地

每個人在這個世界都是過客
但是很多人一輩子 努力工作 只為了要擁有自己生活的窩
擁有自己個土地 自己的空間
但是我希望人並不是擁有土地 而是成為土地上的園丁
不要整天想要從土地上挖出錢來 榨出更多的油水
而是照顧好你的土地 你的環境
跟土地的關係 應該不是擁有與被擁有這樣的關係
而是土地提供人們生活的的庇護 人應該成為照顧土地上的一草一木的守護者

在資本主義的社會中
土地是一個商品
是不動產
是累積財富的一個標的
許多的財團 養地 等土地增值 在賣出 賺到一筆天價的財富
或是 像幾年前看到一個新聞 有人為了賺錢 把土地挖成一個洞一個洞的
土挖走了 錢賺走了 環境卻破壞光了
這樣的人 跟土地有什麼感情呢

應該在有能力的時候 把一部份的時間或是金錢 投資在土地上
不是做土地的買賣 而是怎樣讓土地從荒地 變成綠樹成蔭
除了水泥牆之外 怎樣讓人與土地的關係更和諧 甚至把更多的土地還給自然
像個園丁一樣 一輩子呵護著這片土地

醫生

大學時期念過居禮夫人的傳記
中間有一段關於有人建議他把他的發現申請成專利
但是他拒絕了 因為他覺得這個發現並不是屬於他個人的

在小學的時候念到史懷哲的故事
原本可以過著優渥的生活
卻到非洲行醫
台灣過去的馬偕醫生也是如此

過去念物理的學生時代
大部份的科學家像愛因斯坦在追求他的理論時
並沒有從他所建構或發現的理論中 獲得實質的回饋
人追求真理或是努力工作 不是為了金錢
而是有更崇高的意義

或許因為過去知識很難轉換成金錢 或者知識經濟沒有這麼發達
所以追求知識的動機相對來說很單純
不像在資本主義當道的社會
很多人做每件事情都以金錢來衡量
許多過去社會地位其實算是還蠻崇高的職業
像老師或是醫生等 變成有效率的賺錢工具之後 感覺似乎就變了
現在的人選擇當醫生 可能很多人並不是因為這個職業可以救人
而是因為這個工作錢賺很多
醫術好的 可能一個早上看診 就可以賺進非常不錯的收入
醫生變成了像推銷員一樣 推銷藥廠的哪些新的藥 效果比較好 當然中間的回扣也賺比較多
醫生很像吸血鬼一樣 在救人的同時 也把病人的積蓄給吸光

當然大部份醫療行為應該是有意義而且是好的
只是我的感覺或許就像法國導演導的一部電影 企業戰士裡頭所演的
醫生在片中反而成了有點反派的角色
很多醫生或許只是把醫術當作賺錢的工具 已經沒有對貧窮病人的憐憫之心
就像佛教裡頭說的
當你幫助人的時候 只是為了得到某些回饋的時候
這樣的出發點為善 是沒有功德的

或許我的想法 還是有點天真
不過這個社會也因為還有很多天真 善良的人們
所以才會也些希望吧

How to spend your money

對於怎樣花錢 每個人都有不一樣的考量
有人考慮C/P值 有人花一分一毫都斤斤計較 錢就是要花在刀口上
不過在我家
有時後 新聞有報導說 哪邊的水果銷不出去的時候
過幾天我家就會多出很多水果 可以吃個一個禮拜吃不完
其實我家真的很想吃那個水果嗎 倒也不見得
所以為什麼會有這樣的選擇呢?
可能因為在花錢買水果的這個過程 我們可能又幫助了一些農民的生活
也就是說 要不要去花這個錢 除了價錢的高低之外值不值得之外
其實還有很多的其他的考慮的因素
像對生態環境的影響 奢侈品或是必需品 買商品還是買廣告 與社會公平正義等等

或許有些人覺得想太多了 花錢就是多少錢與多少價值的問題而已
不過我覺的錢 就像是另一張選票一樣 決定這個社會的發展走向哪個方向
每個人有自己的選票 當每個人都花在一些高耗能高污染的產品的時候
我們的未來 就是會走向 越來越糟的環境 越來越高的污染
當我們每個人都喜歡買些名牌精品的時候
往好的方面想 可能精緻工業會得到更多的重視 但是其實更仔細想
那些錢 其實是給中間的行銷 品牌給賺走了 其實你只是讓那些有錢的人更有錢罷了
舉另外的例子
一樣是從台北到高雄的交通 可以有很多選擇
客運 自行開車 高鐵 火車等等
如果只考慮時間或許是飛機或高鐵 如果把價格考慮進來 多點人的話或許會考慮自己開車
但是如果在考慮一下 哪一種交通最環保最低耗能呢
那可能就不是開車了 應該還是要選擇大眾交通工具
你花一樣的錢在交通上 公共運輸可能有30%在燃料 70%給司機或是客運公司賺走了
如果自行開車可能 60%給中油40%給產油國家給賺走了
污染指數的話 大眾運輸因為有許多人共用 所以平均下來應該也是比較有效率的方式
當然這個效率 一定不是指對個人的通車時間 vs 價格
所以當你多花些時間在公共運輸上頭 而不是自己開車的話 其實是比較環保的
如果這樣想的人多了 我們才不會步上美國那種高度依賴石油的社會

像上面的例子 其實就是有考慮到一些錢 到底給誰賺走的問題 錢究竟怎麼流怎麼跑的問題
究竟花這個錢 是讓貧富差距更大 還是更平均的因素
就像花一樣的錢捐給一些慈善團體或是花在買名牌包或是鞋
或許捐錢的C/P值 接近零 可是他其實對整個社會的和諧是比較有幫助的
花錢在精品上 很多時候只是讓那些富豪們 賺更多的錢
像很多大老板們 有錢買台法拉利 可是沒錢對自己公司的員工更好一些 甚至連基本的勞健保都要省 這種案例也比比皆是
看了真的很令人生氣
... 待續