以微服務打造電子支付新黑馬，全支付靠技術力服務百萬會員

去年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萬