上一章結尾說,這個團隊的終點比所有人想的都近。這章從那一天講起。

那一天,和一個月後

某天,CTO 通知全部工程師:**暫停開發。**與第三方的合約要重新談;可能會走向資遣;他會去幫大家爭取多一點資源。

政治的細節留給終章,這章只需要兩個事實。第一:一個月後,團隊剩下三個人——我、一個前端、CTO。第二:商城還開著,但已經沒有客人了,登入的主要是公司內部的人。前面二十六天寫的那個系統——尖峰、FSM、跟播的四個視窗——還在跑,只是安靜下來了。

要先把這個背景釘死,因為它顛覆了「為什麼拆微服務」的一切教科書答案。我們不是因為流量大到要獨立擴縮、不是因為團隊多到要解耦協作——恰恰相反:人少到只剩三個,拆是為了讓三個人養得動接下來的日子。

新的活路:採購

公司的新方向,是做採購系統——但這次的訂單,不是自己家的。

原本的採購為什麼好做?因為訂單從我們自己的系統來,Day 13 講過那條路:資料格式自己定、時序自己控。新局面是:訂單來自第三方公司的軟體,對方匯出、我們匯入,格式是人家的、節奏也是人家的——要設計一套能跟外部系統相處的方式。

實際的介面樸素到可愛:人工上傳 Excel。對方從他們的軟體匯出訂單,檔案傳過來,我們的系統吃進去;會多次匯出、多次匯入。撐住這個流程的是一個關鍵約定:對方保證每筆匯出的訂單有唯一 key——我們直接拿它當冪等條件。重複匯入?upsert 掉,無感。這是冪等鍵在這個系統的第三次登場:留言去重用 source+message id、金流靠事實表天生冪等、現在外部訂單靠對方的唯一 key——而它買到的東西,用當年的一句話總結最傳神:**「我們不管他多久會匯一次。」**冪等把頻率變成了別人的自由,連協調會議都省了。

有了訂單,就知道需求量;接下來怎麼採購,是這個新系統自己的業務。而它需要的東西——商品、使用者、權限——有些正躺在那個安靜的 monolith 裡。於是,拆的理由出現了。

明天講實際的拆法——三個完全不同的動作:蓋新房、搬家、降格。

本文改寫自我的部落格系列《Re:從零開始做直播代購電商平台》,本篇完整版:https://blog.aidan.tw/blog/rezero-microservices/