去年9月,在國內擁有超過1,100家門市的全聯正式進軍電子支付市場,以旗下百分之百子公司全支付電子支付推出同名電子支付服務,全支付挾全聯1,300萬會員、約830萬PX Pay會員基礎,甫一推出服務,就成為電支市場新秀,根據金管會2022年10月統計資料,全支付擁有214萬用戶,僅次於街口支付、一卡通,在單月代理收付達24億元,僅次於街口支付。
在電子支付市場竄起的全支付是在2021年獲得電支業者營業執照,2022年4月完成系統服務建置,8月進入試營運,9月正式推出電子支付,試營運即吸引大量會員註冊,瞬間流量衝至200到300Mbps,上線10天即宣布達到100萬註冊會員,2個月內吸引超過200萬,背後靠一群年輕的開發團隊,以技術力完成會員、支付、財務系統、App開發、壓力測試等準備工作。
帶領技術團隊的是全支付技術部經理陳世樺,早在全支付公司成立之前,他便先進入全聯,承接PX Pay項目,協助擁有800多萬用戶的PX Pay,在龐大數據量、交易量下,系統能穩定運作,在進入全聯之前,曾在其他電支業者工作過,因此全支付公司成立後,他成為帶領技術團隊從無到有完成各系統開發、挺過服務上線壓力的關鍵人物。
陳世樺表示,在服務正式上線之前,全支付的IT與開發團隊通力合作,考量到服務上線初期可能面臨的高流量,為因應大量會員註冊請求,App從註冊登入流程到API檢查服務,確保承載量RPS可達到7、8千以上。此外,環境建置好之後,確認網路設備、防火牆,所有服務正常維運下,以及Radis、Kafka正常運作,經過壓力測試,瞬間流量湧入不會導致服務不穩,透過一兩周的驗測,才進入試營運階段,後續順利讓服務正式上線。
採用微服務架構從無到有建構電子支付服務
然而,全支付當初準備投入電子支付市場,最先面臨的問題便是技術抉擇,應該採用一體式架構比較好,還是採用微服務架構?
陳世樺表示,許多新創公司會採用一體式架構,因為開發快速、易於部署,較容易維運,可縮短系統建置時間,儘快讓服務推出市場,而採用微服務架構,在開發難度上,初期建構成本高,服務與服務之間如何串接、溝通,需要花費較多的時間,例如會員服務如何拆分,應該包含哪些,交易服務包含哪些東西,如果沒有拆分乾淨,將來可能就會形成技術債。
全支付挾著全聯的通路、數百萬PX Pay會員優勢,為了快速推出電子支付服務,理應選擇一體式架構,然而,最後他們選擇了微服務架構。「儘管開業時間比較晚,從技術面來說,我們還是希望提供穩定的系統。」陳世樺補充。他以過去在電子支付產業開發核心支付系統,進入全聯後又負責PX Pay維運超過半年的經驗,認為面對大量流量、交易量發生,一體式架構可能面臨服務爆量的風險。
儘管全聯在PX Pay相當成功,但既有的PX Pay為第3方支付,無法直接將現行架構來運作全支付的電子支付業務,必需從零開始建置整個服務。
陳世樺指出,電子支付對安控、法規、加解密有更多的要求,為了合規,將特定加解密、加驗簽服務獨立出來,諸如身分證、電話號碼、信用卡、銀行帳戶等高敏感性資料,必需透過該服務解密取得這些資料。採用微服務架構的好處是,交易流程任何調整,都不會影響到獨立出來的特定加解密服務,也能降低對其他高敏感性資料存取行為的影響風險。
「從長期營運角度來看,採用微服務架構雖然更辛苦,但在維運、擴充服務、優化上有很大優勢」,他說。
根據業務邏輯拆分服務,提高服務穩定性
然而,決定採用微服務架構之後,接下來就面臨如何拆分微服務的問題。他們花了相當多的時間,梳理流程、功能,討論如何拆分服務,尤其是電子支付涉及會員、支付、財務三個部分,會員註冊包括聯徵報送、OCR、外籍人士居留證、推播等等,而交易則有銀行帳戶扣款、信用卡扣款、行銷活動回饋、線上及線下交易等等。
陳世樺表示,最初先以功能拆分,再討論是否要進一步拆開個別功能。舉例來說,交易與回饋功能應該綁定一起,還是拆開?當初團隊就這個問題花了不少時間討論。理論上,交易會產生回饋,但是不同的行銷活動的回饋方式並不相同,如果將回饋和支付綁在一起,當有新型能的行銷活動時,得根據新的回饋的方式更新,容易產生風險,最後決定將回饋拆出來為獨立的微服務。
另一個例子是會員註冊,原先的設計是,會員註冊為會員服務底下的功能之一,當使用者申請註冊為會員,註冊資料以會員表,寫入會員資料庫儲存。但是,申請電子支付帳戶必需通過實名制認證方能成為會員,包括身分證字號輸入、聯徵報送、手機OTP,有些消費者因沒有最終完成整個程序,並非正式會員,這些「非會員」資料仍會寫到資料庫裡,並標記為「申請中」狀態。
陳世樺指出,這些資料並非來自真正的會員,可能影響後面資料分析應用,而這些「非會員」資料報送主管機關是否合適?如果決定不報送主管機關,需要設法排除這些資料,可能牽動整個會員服務。
考慮到服務的穩定性,最後決定拆分業務邏輯及資料流,把會員註冊從會員服務裡拆出,獨立為微服務。
如此一來,當會員註冊發生故障,最糟的情形是使用者當下無法申請會員,不致於影響到既有會員的服務,會員開啟App仍能正常使用會員服務。
這個做法的效益在後來獲得印證。聯徵中心曾通知全支付,為實施異地備援演練,暫時停止對外服務,包括全支付會員註冊的聯徵報送,暫停服務時間為周末下午,為消費者在全聯採買熱門時段,因會員註冊獨立為微服務,聯徵暫停服務期間雖然無法註冊會員,但仍保持會員服務的正常使用。
曾身為工程師的陳世樺表示,工程師最擔心的是,調整部分程式碼,導致其他的功能無法正常運作,當系統愈來愈龐大,牽一髮動全身,心理壓力也隨之加大,導入微服務架構,對工程師而言,調整幅度縮小,上線之前的QA測試範圍也變小,縮短改版上線時間。當初決定微服務架構開發,當時曾有工程師反映開發相當辛苦,現在反而慶幸採用微服務。
目前全支付已開發超過100個微服務,逐漸面臨有效管理大量微服務的問題,為解決微服務管理壓力逐漸增加的問題,2023年準備導入K8s。
不可能在有限資源、人力、時程內做出100分產品,現實是必需先讓使用者試用,再根據意見調整,做出大家喜歡的產品。── 全支付技術部經理 陳世樺
導入敏捷式開發,避免技術債堆疊
然而,技術團隊剛開始以微服務架構開發,還是發生一些問題。曾經有專案開發至20%到30%,才發現規畫錯誤,必須打掉重練,先前的辛苦開發付諸流水,對當時正全力籌備的團隊帶來不小的打擊。
陳世樺歸納幾個可能的原因,一個是RD對需求的理解不足,另一個可能是PO(Product Owner)部門敘述不夠清楚。他認為開發團隊較為年輕,因為缺乏銀行、電子支付相關的經驗,難免會犯錯,「犯錯是不可避免的,但要知道為什麼犯錯,怎麼避免」。
後來他們在開發流程中參考敏捷式開發,不過,陳世樺坦言,全支付導入的並非教科書等級敏捷式開發,而是採用其精神,強化需求與開發間的溝通。在進入開發之前,由PO與RD開會討論,下周或下個月開發規畫專案,確認技術面、法規面沒有問題後,再啟動專案進入開發,之後幾個月再開會重新檢視調整。在開發流程面,透過每天的會議,開發團隊向PO、需求單位說明每天驗證工作內容,提出遭遇的問題,RD在會議中和PO討論是否需要調整,提早發現問題,很快進行調整修正。
陳世樺指出,一般而言,開發中發現的問題有兩種解決方法,最快的方式是按現有程式邏輯作調整,但日後可能留下技術債,另一個發現的問題可能也涉及其他的專案,為避免將來面臨相同的問題,重新開發新程式,雖然花費時間比較久,但是能夠避免技術債堆疊。
為了提高團隊成員對需求、功能、系統有更高的瞭解及掌握,新加入的成員會由資深有經驗的工程師帶領,並讓新成員儘量歷練會員、支付、財務3個團隊,讓新人有機會碰觸不同團隊負責業務範圍,讓財務團隊理解為何會員團隊API會這麼設計、交易團隊能理解財務團隊需要的資料等等。
由於部分成員缺乏銀行、電支經驗的知識經驗,陳世樺也透過部分專案會議,和他們分享開發經驗,包括流程要怎樣設計比較好,某項功能應重視效能或是穩定,透過潛移默化的方式,讓比較資淺的開發成員從中學習到他的想法,以及過去的工作知識經驗。
開發人員才是第一線
在全支付籌備期間,他帶領團隊開發App,特別重視穩定性。陳世樺表示,外界多認為行銷或業務是面對消費者的第一線,或認為客服才是第一線,但是從開發的角度來看,RD才是對使用者的第一線,因為用戶開啟App,最先看到的是開發的成果,因此RD才是第一線,客服才是第二線。由於市場競爭激烈,對用戶來說,服務好不好用相當直覺,使用體驗不好用直接刪掉,立即在App商店開予負評。RD對開發的產品要有相當的品質,確保沒有問題,全支付目前200多萬用戶,未來甚至增加至300萬或400萬用戶,他期許團隊推出的產品服務要做到品質至上。
為了確保使用體驗符合需求,全支付後續也通過蒐集App的使用數據追蹤分析,去瞭解每個功能的使用情形,例如使用者有沒有按下付款,有沒有成功,還是完全沒有使用,某項功能或服務的使用變化等等,通過App的使用情形,瞭解使用者的習慣,最後回饋到PO、行銷,持續優化App。
他經常向團隊成員強調,「最好的架構是不斷重構再重構的架構,沒有人可以一次做到100分」。
陳世樺認為,最重要的是團隊要體認到,「不可能在有限資源、人力、時程內做出100分產品,現實是必需先讓使用者試用,再根據意見調整,做出大家喜歡的產品」。
儘管在電支市場,全支付目前還是新手,但靠著母公司的支持,短短時間衝刺數百萬電支用戶,陳世樺認為,在集團協助之下,全支付擁有很強的核心競爭,其他行動支付、電子支付能做到的,未來全支付也可以。如同全聯董事長林敏雄所說,全支付要做第一,「不只是公司經營,RD團隊也是如此,這是上下一致的信念」。
CTO小檔案
全支付電子支付技術部經理 陳世樺
學歷:高雄海洋科技大學資訊管理系
經歷:從事軟體業約17年,早期多為系統整合開發及金融業相關軟體開發,2014 年加入街口支付擔任技術經理職務,主要帶領支付團隊開發核心支付系統,2020年進入全聯,為PXPay 技術經理,帶領團隊開發及維運 PXPay App。2021年轉至全支付,帶領技術團隊開發全支付App
公司檔案
全支付電子支付
地址:臺北市中山區敬業四路33號9樓
成立時間:2020年
主要業務:專營電子支付業務
員工數:約90人
董事長:林弘斌
總經理:游金榮
技術部門檔案
直屬主管:游金榮
技術部門名稱:技術部
技術部門主管職稱:經理
技術部門人數:近40位,持續增加中
技術部門分工:iOS與安卓團隊、前端、後端(包括會員、支付、財務)、QA、Infra團隊
公司大事記
●2020年:9月全支付公司成立
●2021年:6月取得金管會核發電子支付專營機構業務許可
●2021年:11月更名為全支付電子支付
●2021年:12月宣布與全盈支付合作,通路共享策略聯盟
●2022年:發表全支付服務,8月下旬App先開放下載
●2022年:9月全支付正式上線。上線10天達到100萬會員
●2022年:10月上線52天宣布會員數達到200萬
熱門新聞
2024-10-05
2024-10-07
2024-10-07
2024-10-07
2024-10-07
2024-10-07
2024-10-07