建站
咨詢
售后
建站咨詢
新聞中心
創(chuàng)建一個互聯(lián)網公司需要幾個人？一位來自舊金山的軟件工程師告訴我們：一個就夠了。這位工程師創(chuàng)建了一個名為「Listen Notes」的播客搜索引擎，像谷歌一樣可以方便地搜索海量播客資源。在這篇文章中，這位工程師向我們介紹了他創(chuàng)建「Listen Notes」用到的各種「無聊」技術。
Listen Notes 地址：https://www.listennotes.com/
Listen Notes 是一個播客搜索引擎和數(shù)據庫。而 Listen Notes 背后的技術實際上毫無新意。沒有 AI，沒有深度學習，沒有區(qū)塊鏈。「任何說我必須使用 AI 的人都沒有使用真正的 AI」，文章作者這樣表示。
作者在前言中說：「閱讀完本文后，讀者應該能夠復制我為 Listen Notes 構建的內容，或者輕松地實現(xiàn)類似的操作。你無需聘請很多工程師。請記住，當 Instagram 融了 5750 萬美元并被 Facebook 以 10 億美元收購時，他們只有 13 名員工——而且并非所有人都是工程師。Instagram 的故事發(fā)生在 2012 年初?，F(xiàn)在是 2019 年了，一個小型工程團隊甚至一個人創(chuàng)造一些有意義的東西比以往任何時候都有可能?！?/p>
這篇介紹了用很多「無聊」技術創(chuàng)建互聯(lián)網產品的文章引起了很多網友的討論，有人表示，技術本身就是一種手段，如果能夠很好地實現(xiàn)產品的功能，即使是「無聊」的技術也會很棒。
也有網友表示，能夠一個人同時掌握前端、數(shù)據庫、搜索引擎、存儲、集群、開發(fā)、源控制和權限管理等很多技術是非常難得的。
在下文中，作者從前端、后端、API 等幾個角度介紹了自己用到的技術細節(jié)。
概述
讓我們從 Listen Notes 項目的需求和功能說起。
Listen Notes 為終端用戶做了兩件事：
- 為播客聽眾提供了網站 ListenNotes.com。該網站可以提供搜索引擎、播客數(shù)據庫、「稍后聽」播放列表、音頻剪輯以及「收聽提醒」（當新播客中提及指定的關鍵字時，它會通知你）。
- 開發(fā)人員的播客搜索和目錄 API。我們需要跟蹤 API 使用情況，從付費用戶處獲取資金，進行客戶支持等等。
一切都在 AWS 上運行。截至 2019 年 5 月 5 日有 20 臺服務器在工作：
運行 Listen Notes 的服務器。
讀者可以通過主機名輕松猜出每個服務器的任務。
- production-web 為 ListenNotes.com 提供網絡流量。
- production-api 提供 api 流量。我們運行兩個版本的 API（截至 2019 年 5 月 4 日），即 v1api（舊版本）和 v2api（新版本）。
- production-db 運行 PostgreSQL（主服務器和副服務器）
- production-es 運行 Elasticsearch 集群。
- production-worker 運行離線處理任務，以使播客數(shù)據庫始終保持最新狀態(tài)，并提供一些神奇功能（例如搜索結果排名、劇集/播客推薦......）。
- production-lb 是負載均衡器。為方便起見，我還在這臺服務器上運行 Redis 和 RabbitMQ。我知道這不是最理想的方案。反正我不是完美的人:)
- production-pangu 是類似生產的服務器，我有時會運行一次性腳本和測試更改。那「pangu」是什么意思？請自行搜索。
這些服務器大多數(shù)都可以水平擴展。這就是為什么我將它們命名為 production-something1，production-something2 ...... 將 production-something3 和 production-something4 再加入其中就非常容易了。
后端
整個后端是用 Django/Python3 編寫的。操作系統(tǒng)是 Ubuntu。
使用 uWSGI 來提供網絡流量。NGINX 放在 uWSGI 進程前面充當負載均衡器。
主要數(shù)據存儲是 PostgreSQL，我有多年開發(fā)和運營經驗——經過測試的技術很完善，所以我晚上能睡得著覺。Redis 用于緩存、統(tǒng)計數(shù)據等多個地方。Elasticsearch 用來索引播客和劇集并提供搜索查詢，就像大多數(shù)無聊的企業(yè)一樣。
Celery 用于離線處理。而 Celery Beat 用于調度任務，類似于 Cron 作業(yè)，但性能更佳。如果將來 Listen Notes 越來越受歡迎并且 Celery＆Beat 導致一些擴展問題，我可能會轉向我為前雇主做的兩個項目：ndkale 和 ndscheduler。
Supervisord 用于每臺服務器上的進程管理。
那 Docker / Kubernetes / serverless 怎么樣？不。隨著經驗積累，你就會知道什么時候不要過度設計。實際上，我在 2014 年為我的前雇主做過一些早期的 Docker 工作，這對于一家市值十億美元的中等規(guī)模創(chuàng)業(yè)公司來說是件好事，但對于一個小型創(chuàng)業(yè)公司來說可能有點「大炮打蚊子」了。
前端
網頁前端主要使用 React+Redux+Webpack+ES。這是非常標準的。在部署到生產時，JS 包將上傳到 Amazon S3 并通過 CloudFront 提供服務。
在 ListenNotes.com 上，大多數(shù)網頁都是半服務器端呈現(xiàn)（Django 模板）和半客戶端呈現(xiàn)（React）。服務器端呈現(xiàn)部分提供網頁的樣板，客戶端呈現(xiàn)部分基本上是交互式網頁應用程序。但是一些網頁完全通過服務器端呈現(xiàn)，因為我的懶惰使事情變得完美以及出現(xiàn)一些潛在的 SEO 優(yōu)勢。
音頻播放器
我使用了一個經過大量修改的 react-media-player 在 ListenNotes.com 上構建音頻播放器，該播放器應用在 Listen Notes 網站、Twitter 嵌入式播放器和第三方網站上的嵌入式播放器中：
第三方網站上的嵌入式播放器。
播客 API
我們?yōu)殚_發(fā)人員提供簡單可靠的播客 API。構建 API 類似于構建網站。在后端使用相同的 Django/Python 堆棧，前端使用相同的 ReactJs（例如 API Dashboard、文檔......）。
ListenNotes 的 API dashboard。
ListenNotes 的 API 文檔。
對于 API，我們需要追蹤用戶在當前計費周期中使用的請求數(shù)量，并在周期結束時收取費用。不難想象，Redis 在這里被大量使用:)
DevOps
機器配置和代碼部署
我使用 Ansible 進行機器配置?；旧希覍懥艘欢?yaml 文件來指定需要什么類型的服務器、什么配置文件和什么軟件。我可以用所有正確的配置文件和軟件啟動一個服務器，并通過「一鍵安裝」完成安裝。這是 Ansible yaml 文件的目錄結構：
我可以在命名方面做得更好。但現(xiàn)在已經足夠好了。
我還使用 Ansible 將代碼部署到生產環(huán)境中?；旧?，我有一個在 macOS 上運行的打包腳本 deploy.sh：
- ./deploy.sh production HEAD web
deploy.sh 腳本有三個參數(shù)：
- 環(huán)境：生產或分段；
- listennotes repo 版本：HEAD 表示「僅部署最新版本」。如果指定了 git commit 的 SHA，那么它將部署特定版本的代碼——當我需要從錯誤的部署撤回時，這特別有用；
- 服務器類型：web、worker、api 或所有服務器。我不必一次部署到所有服務器。有時我會對 Javascript 代碼進行修改，然后我只需要部署到 Web，而無需涉及 api 或 worker。
部署過程主要由 Ansible yaml 文件制定，當然，它很簡單：
- 在 Macbook Pro 上，如果要部署到 Web 服務器，則構建 Javascript 包并上傳到 S3；
- 在目標服務器上，git 將 listennotes repo 克隆到一個以時間戳命名的文件夾，檢查特定版本，然后安裝新的 Python 依賴項（如果有的話）；
- 在目標服務器上，將符號鏈接切換到上述時間戳命名文件夾，并通過 supervisorctl 重新啟動服務器。
我不使用那些花哨的 CI 工具。實際的操作非常簡易。
監(jiān)控和警報
我使用 Datadog 進行監(jiān)控和警報。我在一個簡單的監(jiān)控界面中有一些高級指標。這里所做的一切都是為了在弄亂生產服務器時增強信心。
適用于 Listen Notes 的 Datadog 監(jiān)控界面（截至 2017 年 12 月）。
我將 Datadog 連接到 PagerDuty。如果出現(xiàn)問題，PagerDuty 將通過電話和短信向我發(fā)送提醒。
我還使用 Rollbar 來監(jiān)控 Django 代碼的運行狀況，它會捕捉異常，并通過電子郵件和 Slack 通知我。
我經常使用 Slack。這是個一個人的公司，所以我不使用 Slack 與人交流。我使用 Slack 來監(jiān)視有趣的應用級事件。除了將 Datadog 和 Rollbar 與 Slack 集成之外，我還在 Listen Notes 后端代碼中使用 Slack 傳入 webhooks，以便在用戶注冊或執(zhí)行一些操作（例如添加或刪除內容）時通知我。這是科技公司常用的做法。當你閱讀亞馬遜或 PayPal 早期發(fā)展的一些書籍時，你會發(fā)現(xiàn)兩家公司都有類似的通知機制：每當用戶注冊時，都會有「?！沟穆曇敉ㄖk公室中的每個人。
自 2017 年初推出以來，Listen Notes 只出現(xiàn)過一次長時崩潰（大于 5 分鐘）。在這些操作方面，我總是非常謹慎和務實。網絡服務器顯著過剩，是為了防止某個新聞事件或其他因素導致流量飆升。
開發(fā)
我在舊金山的 WeWork 共享空間工作。有些人可能想知道為什么不在家里或咖啡店工作。那是因為我非常重視效率，我愿意在效率上投資。我不相信堆砌時間就能開發(fā)出好軟件。我很少一天工作超過 8 小時（對不起了，996 的朋友）。我想把每一分鐘都花得有意義。因此，我需要一個精致且相對昂貴的私人辦公室:) 與其為了省錢花更多時間，我選擇花費更少的時間去賺錢:)
我在 WeWork 的辦公室。
我用的電腦是 MacBook Pro。我在 Vagrant+ VirtualBox 中運行（幾乎）相同的基礎架構。我使用與上述相同的 Ansible yaml 文件集在 Vagrant 中配置開發(fā)環(huán)境。
我贊同 monorepo 理念。因此，我只有一個 listennotes repo，包含 DevOps 腳本、前端和后端代碼。這個 listennotes repo 是作為 GitHub 私人 repo 托管。我在主分支上做所有的開發(fā)工作。我很少使用功能分支。
我使用 PyCharm 編寫代碼并運行 dev 服務器（Django runserver 和 webpack dev server）。我知道這很無聊。畢竟它不是 Visual Studio Code、Atom 或 IDE。但 PyCharm 對我來說效果很好。畢竟我很老派。
我的 PyCharm。
其他
我使用許多有用的工具和服務將 Listen Notes 打造為一款產品和一個公司：
- iTerm2 和 tmux 用于獲取終端內容。
- Notion 用于 TODO 列表、維基、記筆記和設計文檔......
- G Suite 用于 @listennotes.com 電子郵件帳戶、日歷和其他 Google 服務。
- MailChimp 發(fā)送每月電子郵件簡報。
- Amazon SES 用于發(fā)送交易郵件和營銷郵件。
- Gusto 用于支付自己和非 Upwork 承包人的工資。
- Upwork 用于尋找承包人。
- Google Ads Manager 管理直銷廣告并跟蹤績效。
- Carbon Ads 和 BuySellAds 用于備用廣告。
- Cloudflare 用于 DNS 管理、CDN 和防火墻。
- Zapier 和 Trello 簡化了播客工作流程。
- Medium 是公司博客的媒介。
- Godaddy 和 Namecheap 用于域名。
- Stripe 用于從用戶處獲取資金（主要用于 API）。
- Google speech-to-text API 用于語音轉換。
- Kaiser Permanente 用于健康保險。
- Stripe Atlas 用于合并 Listen Notes Inc。
- Clerky 為融資（SAFE）和雇傭非 Upwork 承包人生成法律文件。
- Quickbooks 用于記賬。
- 1password 用于管理大量服務的登錄憑證。
- Brex 用于信用卡，還可以獲得額外$ 5,000 AWS 積分，可以在 WeWork 或 Stripe Atlas 的 AWS 積分上應用。
- Bonvoy Business Amex 卡——可以獲得豪華酒店和航班的 Marriott Bonvoy 積分。這是旅行的最佳信用卡積分:)
- Capital One Spark 用于支票賬戶。
膽大心細，馬上行動
如你所見，我們生活在一個創(chuàng)業(yè)的黃金時代。有許多現(xiàn)成的工具和服務可以節(jié)省我們的時間和金錢，提高我們的生產力。使用簡單而枯燥的技術，以一己之力（或一個團隊）創(chuàng)造對世界有用的東西比以往任何時候都更有可能。
隨著時間的推移，公司會變得越來越小。你無需雇傭大量的全職員工。你可以通過購買服務或外包來完成工作。
大多數(shù)時候，創(chuàng)造和傳播的最大障礙是想太多。這怎么辦？那怎么辦？孩子，你把自己看太重了。每個人都忙于自己的生活。沒有人關心你和你創(chuàng)建的東西，直到你證明你值得別人關注。即使你搞砸了最初的產品，也很少有人會注意到?！负暧^思維，細節(jié)到位，迅速反應!」只要你真正解決了問題，就算使用無聊的技術完成簡單（甚至簡陋）的任務也完全沒問題。
網站欄目：創(chuàng)建一家互聯(lián)網公司需要幾個人？一個就夠了
網站URL：http://m.5511xx.com/article/cogocgp.html
