作者 | Sudeep Chauhan

譯者 | 核子可樂(lè)

策劃 | 蔡芳芳

2020 年 3 月，COVID-19 疫情全面爆發(fā)，我們的初創(chuàng)公司 Milkie Way 也遭受巨大打擊，差點(diǎn)破產(chǎn)。因?yàn)槲覀冊(cè)趯?duì) Firebase 和 Cloud Run 進(jìn)行內(nèi)部測(cè)試的期間，一不小心在幾個(gè)小時(shí)里燒掉了 72000 美元（約 47 萬(wàn)人民幣）。

2019 年 11 月，我們開(kāi)始開(kāi)發(fā) https://announce.today 服務(wù)，希望借此打造 MVP 產(chǎn)品的可用功能 V1 版本。作為初步嘗試，我們的代碼以簡(jiǎn)單的底層棧為依托，使用 JS、Python 代碼并將產(chǎn)品部署在 Google App 引擎之上。

因?yàn)閳F(tuán)隊(duì)規(guī)模很小，所以我們的重點(diǎn)放在編寫(xiě)代碼、設(shè)計(jì) UI 以及準(zhǔn)備產(chǎn)品身上。我們沒(méi)在云管理上花多少心思，當(dāng)時(shí)的目標(biāo)很簡(jiǎn)單——能支撐起基本的開(kāi)發(fā)流程（CI/CD）就行。

在這款 V1 Web 應(yīng)用程序中，用戶(hù)體驗(yàn)并不算流暢。但沒(méi)關(guān)系，我們的訴求只是開(kāi)發(fā)出一些可供用戶(hù)體驗(yàn)的產(chǎn)品，同時(shí)也構(gòu)建了更好的 Announce 版本。隨著 COVID 疫情全面來(lái)襲，我們認(rèn)為這正是做出改變的最佳時(shí)機(jī)，沒(méi)準(zhǔn) Announce 會(huì)成為各國(guó)政府在全球范圍內(nèi)發(fā)布公告的理想選擇。

當(dāng)時(shí)用戶(hù)還沒(méi)有創(chuàng)建任何內(nèi)容，但我們認(rèn)為能在平臺(tái)上提供一些既有數(shù)據(jù)可能更好。所以我們又建立了 Announce-AI 項(xiàng)目，旨在自動(dòng)發(fā)布由 AI 創(chuàng)建的豐富內(nèi)容。這里的豐富內(nèi)容是指各類(lèi)事件、地震等安全警告，以及本地用戶(hù)可能關(guān)心的相關(guān)新聞。

?

1 技術(shù)細(xì)節(jié)

為了開(kāi)發(fā) Announce-AI，我們決定使用 Cloud Functions。由于我們抓取數(shù)據(jù)的周期還很短，所以 Cloud Functions 幾乎是完美的選項(xiàng)。但在決定擴(kuò)展規(guī)模之后，我們馬上遇到了麻煩——Cloud Functions 的超時(shí)時(shí)間長(zhǎng)達(dá) 9 分鐘。

于是我們開(kāi)始研究 Cloud Run，并發(fā)現(xiàn)它提供規(guī)模可觀的免費(fèi)資源使用層！必須承認(rèn)，那時(shí)候我們對(duì) Cloud Run 并不夠了解，只是匆忙要求團(tuán)隊(duì)在 Cloud Fun 上部署“測(cè)試”Announce-AI 功能。我們當(dāng)時(shí)想得很簡(jiǎn)單：盡快熟悉 Cloud Run，在探索中不斷學(xué)習(xí)。

為了簡(jiǎn)單起見(jiàn)，我們?cè)趯?shí)驗(yàn)中只引入一個(gè)很小的站點(diǎn)，就使用了 Firebase 作為數(shù)據(jù)庫(kù)（因?yàn)?Cloud Run 不提供任何存儲(chǔ)功能）。站點(diǎn)規(guī)模真的很小，完全用不上 SQL Server 或者任何其他成熟的商業(yè)數(shù)據(jù)庫(kù)。

我創(chuàng)建了名為 ANC-AI Dev 的新 GCP 項(xiàng)目，設(shè)置了 7 美元的云資源使用預(yù)算，并選擇使用 Firebase Project on the Free(Spark) 計(jì)劃。我們當(dāng)時(shí)覺(jué)得，最糟糕的結(jié)果應(yīng)該無(wú)非就是超出每日 Firestore 的免費(fèi)限額，對(duì)吧？

在稍稍調(diào)整了代碼之后，我們開(kāi)始部署流程，向其發(fā)出了幾條手動(dòng)請(qǐng)求，而后就留下它保持運(yùn)行。

?

2?噩夢(mèng)由此開(kāi)始

測(cè)試當(dāng)天一切順利，我們又回到了 Announce 本體的開(kāi)發(fā)當(dāng)中。在第二天下班之后，我稍微睡了一會(huì)。醒來(lái)之后，我發(fā)現(xiàn)郵箱里有幾封來(lái)自 Google Cloud 的提醒郵件，而且郵件之間的間隔只有幾分鐘。

第一封郵件：Firebase Project 自動(dòng)升級(jí)

第二封郵件：預(yù)算超支

幸運(yùn)的是，我使用的信用卡設(shè)有 100 美元消費(fèi)限額。于是收費(fèi)停止，谷歌暫停了我們的所有賬戶(hù)。

第三封郵件：信用卡支付被拒

我跳下床，登錄 Google Cloud Billing，并看到一張約 5000 美元的賬單。說(shuō)實(shí)話(huà)，那一刻我慌得不行，根本沒(méi)辦法正常思考。我到處張望，想弄明白出了什么問(wèn)題，包括到底該怎么付清這筆 5000 美元巨款。

但問(wèn)題在于，賬單金額每分鐘都在上漲。

5 分鐘之后，賬單數(shù)額增長(zhǎng)到了 15000 美元；20 分鐘后，數(shù)額增長(zhǎng)至 25000 美元。我不確定這一切什么時(shí)候會(huì)停，或者說(shuō)恐怕永遠(yuǎn)不會(huì)停止？

2 個(gè)小時(shí)后，數(shù)額最終定格在 72000 美元。

這時(shí)我和我的團(tuán)隊(duì)正忙著瘋狂確認(rèn)情況。我徹底呆若木雞，根本不知道接下來(lái)該做點(diǎn)什么。我們停用了結(jié)算功能，同時(shí)關(guān)閉了所有服務(wù)。

由于我們?cè)谌?GCP 項(xiàng)目中使用的都是同一張對(duì)公支付卡，所以谷歌已經(jīng)全面關(guān)停了我們的賬戶(hù)及項(xiàng)目。

?

3?噩夢(mèng)仍在繼續(xù)

事情發(fā)生在 3 月 27 日星期五晚上，即我們計(jì)劃發(fā)布 Announce V1 的三天之前。由于谷歌凍結(jié)了綁定同一張信用卡的全部項(xiàng)目，我們的產(chǎn)品開(kāi)發(fā)工作陷入了僵局。士氣低落，這家年輕的公司前途未卜。

所有云項(xiàng)目都被關(guān)停，開(kāi)發(fā)工作陷入僵局

到這天午夜，我終于緩過(guò)神來(lái)，開(kāi)始展開(kāi)調(diào)查。我把調(diào)查工作中的每個(gè)步驟都詳細(xì)記錄在了文件當(dāng)中……并將文件命名為“第 11 章”。

另外兩位團(tuán)隊(duì)成員也加入了調(diào)查工作，與我一同不眠不休地探索真相。

第二天，也就是 3 月 28 日星期六，我打電話(huà)或發(fā)郵件給了十幾家律師事務(wù)所預(yù)約面談。大多數(shù)律所拒絕受理，只有一封郵件發(fā)來(lái)回復(fù)，讓我具體解釋解釋整個(gè)過(guò)程。必須承認(rèn)，這件事即使對(duì)工程師來(lái)說(shuō)也是細(xì)節(jié)過(guò)多、復(fù)雜難懂，我壓根不知道該怎么用簡(jiǎn)單易懂的語(yǔ)言向律師做出說(shuō)明。

作為一家自負(fù)盈虧的公司，我們拿不出 72000 美元。

到這時(shí)，我甚至認(rèn)真研究過(guò)了《破產(chǎn)法》的第 7 章與第 11 章，并對(duì)接下來(lái)可能發(fā)生的一切做好了心理準(zhǔn)備。

?

4?喘息之機(jī)：GCP 的漏洞

就在同一個(gè)周六，我開(kāi)始查閱更多內(nèi)容，特別是 GCP 說(shuō)明文檔中的各種條目。好吧，我們確實(shí)犯了錯(cuò)誤，但谷歌在一筆實(shí)際支付都沒(méi)完成的情況下就給我們計(jì)上了 72000 美元的賬，這正常嗎？！

GCP 與 Firebase 

1. 自動(dòng)將 Firebase 賬戶(hù)升級(jí)為付費(fèi)賬戶(hù)

在注冊(cè) Firebase 時(shí)，我們從沒(méi)想過(guò)這還帶自動(dòng)升級(jí)的，提示條款中也絕對(duì)沒(méi)有提及。我們的 GCP 項(xiàng)目確實(shí)接受了結(jié)算條款，因?yàn)橹挥羞@樣才能正常使用 Cloud Run；但 Firebase 不是，我們用的可是免費(fèi)計(jì)劃。GCP 突然就進(jìn)行了升級(jí)，并向我們收取巨額費(fèi)用。

事實(shí)證明，他們就是這么設(shè)計(jì)的，理由是“Firebase 與 GCP 深度集成。”

2. 所謂的計(jì)費(fèi)“限額”根本不存在，預(yù)算管理至少延遲了一天

GCP Billing 實(shí)際至少了延遲了一天。谷歌在大多數(shù)說(shuō)明文檔中都建議用戶(hù)使用 Budgets 與自動(dòng)關(guān)閉云功能。但你猜怎么著？在中斷功能被觸發(fā)或者通知到云用戶(hù)時(shí)，問(wèn)題可能已經(jīng)發(fā)生了。

結(jié)算過(guò)程大約需要一整天時(shí)間，所以我們第二天才收到計(jì)費(fèi)提醒。

3. 谷歌應(yīng)該向我們收取 100 美元，而不是 72000 美元！

由于我們的賬戶(hù)一直沒(méi)有實(shí)際支付，所以 GCP 應(yīng)該先根據(jù)賬單信息收取 100 美元的費(fèi)用，并在無(wú)法繼續(xù)付款后停止服務(wù)。但實(shí)際情況并非如此，后來(lái)我弄清了原因，問(wèn)題仍然跟用戶(hù)這方無(wú)關(guān)。

我們賬戶(hù)的第一筆費(fèi)用約為 5000 美元，下一筆就暴漲到了 72000 美元。

我們賬戶(hù)的計(jì)費(fèi)上限為 100 美元

4. 別相信 Firebase 儀表板！

不只是 Billing 功能，就連 Firebase 儀表板也要超過(guò) 24 個(gè)小時(shí)才能正常更新。

根據(jù) Firebase 控制臺(tái)說(shuō)明文檔，Firebase 控制臺(tái)的儀表板數(shù)字可能與 Billing 賬單報(bào)告“略有不同”。

以我們的情況為例，二者的差異高達(dá) 86585365.85%，也就是 86 萬(wàn)倍。而且在向我們發(fā)出賬單之后，Firebase 控制臺(tái)的儀表板仍然顯示當(dāng)月出現(xiàn)了 42000 次讀取 + 寫(xiě)入操作（低于每日上限）。

?

5?新的一天，新的挑戰(zhàn)

我之前曾在谷歌工作過(guò)大約六年半，也寫(xiě)過(guò)幾十份項(xiàng)目說(shuō)明文檔、取證報(bào)告。結(jié)合過(guò)往工作經(jīng)驗(yàn)，我整理出一份文件，向谷歌概述了這次事件，并總結(jié)了谷歌方面的錯(cuò)誤和疏漏。照理來(lái)說(shuō)，兩天后的周一，谷歌工作小組就會(huì)正常上班并接手處理。

增訂：部分讀者朋友建議我直接跟之前的谷歌同事聯(lián)系。事實(shí)上，我沒(méi)有動(dòng)用任何原有的人脈，使用的就是普通開(kāi)發(fā)商 / 公司采取的常規(guī)辦法。于是乎，我在聊天頻道、咨詢(xún)、冗余的電子郵件和一個(gè)個(gè)小錯(cuò)誤身上浪費(fèi)了無(wú)數(shù)時(shí)間。下面，咱們具體來(lái)看交涉過(guò)程中的種種細(xì)節(jié)。

離開(kāi)谷歌的那一天

與此同時(shí)，我們也在整理自己這邊犯下的錯(cuò)誤，并制定新的產(chǎn)品開(kāi)發(fā)策略。團(tuán)隊(duì)里還有不少人根本不清楚發(fā)生了什么，只知道公司遇上了大麻煩。

作為前谷歌員工，我有豐富的“犯錯(cuò)”經(jīng)驗(yàn)，還給谷歌造成了數(shù)百萬(wàn)美元的損失。但谷歌的企業(yè)文化拯救了員工（當(dāng)然，涉事工程師還是得寫(xiě)一份長(zhǎng)長(zhǎng)的事件回顧報(bào)告）。這一次，我不再是谷歌人，我們手頭的資金有限、而之前投入巨大心力的成果正身陷風(fēng)險(xiǎn)。

先來(lái)看一個(gè)數(shù)字：1160 億，這是我們的測(cè)試代碼在一個(gè)小時(shí)之內(nèi)讀取 Firestore 數(shù)據(jù)庫(kù)的次數(shù)。

這是我人生中第一次遭遇如此重挫，有可能徹底改變整個(gè)公司乃至我生活的未來(lái)方向。關(guān)于問(wèn)題，我們可以說(shuō)很多，但其中最重要的反而是個(gè)簡(jiǎn)單的道理——保持堅(jiān)強(qiáng)。

作為一家小公司的管理者，我手底下只有一支由 7 名工程師 / 實(shí)習(xí)生組成的團(tuán)隊(duì)。谷歌那邊大概得 10 天左右才能與我們進(jìn)一步接洽。在此期間，我們必須恢復(fù)開(kāi)發(fā)，找到解決賬戶(hù)關(guān)停的方法。此外，產(chǎn)品及功能的設(shè)計(jì)工作也得盡快重啟。

?

6?我們到底做了什么？

因?yàn)閳F(tuán)隊(duì)規(guī)模不大，我們希望盡可能使用無(wú)服務(wù)器架構(gòu)。而 Cloud Functions 與 Cloud Run 等無(wú)服務(wù)器解決方案處理問(wèn)題的基本思路，就是超時(shí)。

具體來(lái)講，實(shí)例會(huì)持續(xù)將 URL 抓取到網(wǎng)頁(yè)當(dāng)中；但在 9 分鐘后，該實(shí)例就會(huì)超時(shí)。

可能是失敗激發(fā)了腦中的智慧，我在幾分鐘內(nèi)就在白板上列出了一大堆設(shè)計(jì)問(wèn)題。不知道為什么，在部署之前，我們能想到的就只有快速犯錯(cuò)、快速?lài)L試。

Announce-AI 在 Cloud Run 上的“Hello World”版本

為了克服超時(shí)限制，我建議使用 POST 請(qǐng)求（將 URL 作為數(shù)據(jù)）將作業(yè)發(fā)送至某一實(shí)例，且并發(fā)使用多個(gè)實(shí)例以替代串行使用單一實(shí)例。這樣 Cloud Run 中的每個(gè)實(shí)例只會(huì)抓取一個(gè)頁(yè)面，所以永遠(yuǎn)不會(huì)超時(shí)。另外，由于 Cloud Run 的處理操作能夠精確到毫秒，所以全部頁(yè)面都將得到并發(fā)處理，整體性能得以高度優(yōu)化。

部署在 Cloud Run 上的抓取器

如果仔細(xì)觀察，就會(huì)發(fā)現(xiàn)流程中缺失了一些重要的部分：

不中斷的指數(shù)遞歸：由于沒(méi)有 break 語(yǔ)句，因此實(shí)例不知道該何時(shí)中斷。

POST 請(qǐng)求可以具有相同的 URL。如果存在指向上一頁(yè)的反射鏈接，則 Cloud Run 服務(wù)將陷入無(wú)限遞歸當(dāng)中；而最糟糕的是，這個(gè)遞歸將呈指數(shù)增長(zhǎng)（我們將最大實(shí)例數(shù)設(shè)置為 1000！）。

大家可以想象，這意味著多達(dá) 1000 個(gè)實(shí)例會(huì)不斷查詢(xún)，且每幾毫秒就向 Firebase 數(shù)據(jù)庫(kù)寫(xiě)入一次。查看數(shù)據(jù)發(fā)布事件，我們發(fā)現(xiàn) Firebase 在某一時(shí)間點(diǎn)上的每分鐘請(qǐng)求數(shù)量增長(zhǎng)到了 10 億個(gè)！

GCP Billing Account 的月末交易摘要 

1160 億次讀取，3300 萬(wàn)次寫(xiě)入

總體來(lái)看，我們這套部署在 Cloud Run 的“Hello World”版本共執(zhí)行了 1160 億次讀取與 3300 萬(wàn)次寫(xiě)入……我的媽呀！

Firebase 上的讀取操作成本：

(0.06 美元 / 100,000) * 116,000,000,000 = 69,600 美元

1600 個(gè) Cloud Run 計(jì)算時(shí)

經(jīng)過(guò)測(cè)試，我們假設(shè)該請(qǐng)求因日志記錄的停止而終止，但實(shí)際上它只是轉(zhuǎn)入后臺(tái)進(jìn)程。由于我們沒(méi)有刪除服務(wù)（我們這是第一次用 Cloud Run，還不太了解具體細(xì)則），因此繼續(xù)有多個(gè)服務(wù)緩慢運(yùn)行。

在 24 個(gè)小時(shí)之內(nèi)，這些服務(wù)版本各自擴(kuò)展到了 1000 個(gè)實(shí)例，共消耗掉 16022 個(gè)計(jì)算時(shí)。

?

7?我們犯了什么錯(cuò)誤？

在云上部署了存在缺陷的算法

根據(jù)之前的討論，我們確實(shí)發(fā)現(xiàn)了一種通過(guò) POST 請(qǐng)求使用無(wú)服務(wù)器資源的新方法。這確實(shí)是種獨(dú)創(chuàng)性的方法，在互聯(lián)網(wǎng)上并沒(méi)有現(xiàn)成的參考，遺憾的是其中存在著我們當(dāng)初沒(méi)有意識(shí)到的大問(wèn)題。

使用默認(rèn)選項(xiàng)部署 Cloud Run

在創(chuàng)建 Cloud Run 服務(wù)時(shí)，我們?cè)诜?wù)中選擇使用默認(rèn)值，即 max-instances 被設(shè)置為 1000，concurrency 設(shè)置為 80。一開(kāi)始我們并不知道，這些預(yù)設(shè)值對(duì)我們的測(cè)試程序來(lái)說(shuō)可以算是最不適用的組合。

如果我們把 max-instances 設(shè)定為 2，那我們的成本只會(huì)是現(xiàn)在的五百分之一，即由 72000 美元轉(zhuǎn)變?yōu)?144 美元。

如果我們將 concurrency 設(shè)定為 1，那么基本不會(huì)產(chǎn)生任何費(fèi)用。

在不完全了解的情況下使用 Firebase

有些經(jīng)驗(yàn)必須從實(shí)踐當(dāng)中獲取。Firebase 不像是能夠直接學(xué)習(xí)的編程語(yǔ)言，它是谷歌提供的一項(xiàng)容器化平臺(tái)服務(wù)，其中使用的是大量預(yù)定義規(guī)則，而且規(guī)則內(nèi)容跟用戶(hù)的直覺(jué)或者傾向沒(méi)有任何關(guān)系。

另外，在 Node.js 中編寫(xiě)代碼時(shí)，必須注意后臺(tái)進(jìn)程。如果代碼進(jìn)入后臺(tái)進(jìn)程，則開(kāi)發(fā)者很難意識(shí)到該服務(wù)仍在運(yùn)行、而且在很長(zhǎng)一段時(shí)間內(nèi)持續(xù)運(yùn)行。后來(lái)我們發(fā)現(xiàn)，這正是我們大多數(shù)云功能同樣出現(xiàn)超時(shí)的原因所在。

別在云上搞“快速失敗、快速學(xué)習(xí)”

云平臺(tái)像是一把雙刃劍。如果使用得當(dāng)，它確實(shí)威力巨大；但如果使用不當(dāng)，后果也將極為嚴(yán)重。

翻翻 GCP 說(shuō)明文檔，大家就會(huì)發(fā)現(xiàn)它的頁(yè)數(shù)比幾本小說(shuō)加起來(lái)還多。換言之，了解云定價(jià)及使用方式不僅非常耗時(shí)，而且要求相關(guān)人員充分了解云服務(wù)的工作原理。所以，別以為在傳統(tǒng)頭銜前面加個(gè)“云”是騙人的——這真是項(xiàng)技術(shù)活！

Firebase 與 Cloud Run 真的很強(qiáng)大

在峰值時(shí)期，Firebase 每分鐘能夠處理約 10 億次讀取，這真是太強(qiáng)大了。我們已經(jīng)在 Firebase 上測(cè)試了 2 到 3 個(gè)月，目前仍在繼續(xù)學(xué)習(xí)，但完全沒(méi)有觸及到它的極限。

Cloud Run 也是如此！當(dāng) Concurrency == 60, max_containers == 1000 且每條 Request 用時(shí) 400 毫秒時(shí)，Cloud Run 每分鐘能夠處理 900 萬(wàn)條請(qǐng)求！

60 * 1000 * 2.5 * 60 = 9,000,000 請(qǐng)求/分鐘

相比之下，谷歌搜索每分鐘也只能完成 380 萬(wàn)次搜索。

使用 Cloud Monitoring

雖然 Google Cloud Monitoring 不會(huì)停止計(jì)費(fèi)，但它能及時(shí)發(fā)送警報(bào)（延遲僅為 3 到 4 分鐘）。Google Cloud 的原型 / 命名結(jié)構(gòu)有一定學(xué)習(xí)曲線(xiàn)，但在投入時(shí)間和精力之后，儀表板、警報(bào)與指標(biāo)確實(shí)能讓我們更為輕松。

這些指標(biāo)將保留 90 天。遺憾的是，我們?cè)诖舜问录械闹笜?biāo)已經(jīng)過(guò)期了，否則我很樂(lè)意在本文中向大家展示。

?

8?好消息：我們沒(méi)倒閉！

但很懸，太懸了

在認(rèn)真閱讀了關(guān)于此次事件的報(bào)告之后，經(jīng)過(guò)一系列咨詢(xún)、討論與內(nèi)部研究，谷歌直接免除了我們的賬單！

謝謝你，谷歌！

我們又恢復(fù)了活力，能夠繼續(xù)開(kāi)發(fā) Announce。而且這一次，我們擁有更好的視角、更強(qiáng)的架構(gòu)與更安全的實(shí)現(xiàn)思路。

谷歌是我最欣賞的科技企業(yè)，這不只是因?yàn)樗且患抑档脼橹ぷ鞯膫ゴ蠊?#xff0c;同時(shí)也因?yàn)樗兄軓?qiáng)的同理心。谷歌提供的工具很合開(kāi)發(fā)者的胃口，很重視說(shuō)明文檔質(zhì)量（大多數(shù)情況下），而且一直在不斷發(fā)展。(作者注：這只是我作為獨(dú)立軟件開(kāi)發(fā)者的個(gè)人感受，絕非軟文或者刻意吹捧。)

?

9?接下來(lái)怎么辦？

經(jīng)歷了這次事件，我們花了幾個(gè)月時(shí)間學(xué)習(xí)云架構(gòu)和我們自己的業(yè)務(wù)體系。幾周之后，我們的知識(shí)提升到新的境界，于是開(kāi)始使用經(jīng)過(guò)改進(jìn)的算法通過(guò) Cloud Run 抓取“整個(gè)網(wǎng)絡(luò)”。

而在事后的整體分析中，我們決定放棄 V1 版本架構(gòu)，轉(zhuǎn)而使用更具可擴(kuò)展性的基礎(chǔ)設(shè)施為產(chǎn)品提供支持。

在 Announce V2 中，我們不再構(gòu)建 MVP；相反，我們打造出一套平臺(tái)，借此快速迭代新產(chǎn)品，并在安全環(huán)境中進(jìn)行全面測(cè)試。

這段經(jīng)歷確實(shí)拖慢了我們的腳步……V2 在 11 月底才正式亮相，比原計(jì)劃的 V1 發(fā)布日晚了大約 7 個(gè)月。但 V2 可擴(kuò)展性更強(qiáng)，能夠更充分地動(dòng)用云資源，同時(shí)也擁有更好的優(yōu)化水平。

我們還得以將其推向所有平臺(tái)，而不僅僅是 Web 平臺(tái)。

更重要的是，我們利用同一套平臺(tái)構(gòu)建起第二款產(chǎn)品 Point Address。這兩種產(chǎn)品不僅可擴(kuò)展性極佳、擁有出色的架構(gòu)與高效性，還建立在同一套平臺(tái)之上。這使我們得以快速將業(yè)務(wù)靈感轉(zhuǎn)化為現(xiàn)實(shí)，并立即將其引入實(shí)際產(chǎn)品當(dāng)中。

原文鏈接：

https://blog.tomilkieway.com/72k-1/

https://blog.tomilkieway.com/72k-2/

有道無(wú)術(shù)，術(shù)可成；有術(shù)無(wú)道，止于術(shù)

歡迎大家關(guān)注Java之道公眾號(hào)

好文章，我在看??

總結(jié)

以上是生活随笔為你收集整理的应用上云2小时烧掉近50万，创始人：差点破产，简直噩梦的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。