Uploadcare是一種文件基礎設施即服務解決方案。我們爲處理文件提供預製構建，爲管理複雜技術提供簡單的控件。這些控件包括widget，Upload API，REST API和CDN API。這些API每天一共要處理350M的請求。
只需幾行代碼即可上傳，存儲，處理，緩存和交付文件。我們支持Dropbox，Facebook和許多其他外部來源上傳。我們還允許用戶將文件直接上傳到他們的存儲空間中。
是的，你可以自己處理文件，你可以搭建基本的系統並運行地很快。但是存儲怎麼樣?正常運作嗎? 是否有清晰友好的用戶界面? 能否快速交付到偏遠地區? 我們分析了大多數用例，發現投資開發自己的文件基礎設施是沒有意義的。
設置Uploadcare很快，解決了用戶通常在處理大文件和批量文件時遇到的許多問題。此外，用戶不再需要在每個瀏覽器中測試系統並維護基礎設施。
ploadcare利用AWS構建了無限可擴展的基礎設施。建立在AWS之上，每天可以處理350M的文件上傳，操作和交付請求。在2011年開始時，AWS唯一的雲替代方案是Google App Engine，我們不想構建相當複雜的解決方案。我們也不想購買任何硬件或使用合作點。
我們的堆棧處理接收文件，與外部文件源通信，管理文件存儲，管理用戶和文件數據，處理文件，文件緩存和分發以及管理用戶界面儀表板。
從一開始，我們基於微服務架構構建了Uploadcare。
這些是我們在堆棧的每一層面臨的挑戰。
後端
Uploadcare的核心是運行在Python上。在佛羅倫薩的Europython 2011會議真正啓發了我們，再加上事實是Python足以解決我們所有的挑戰。另外之前我們還有在Python中工作的經驗。
我們選擇使用Django構建主要應用程序，因爲它在Python生態系統中的具有舉足輕重的地位並且功能十分完整。我們的生態系統內的所有通信都通過幾個HTTP API，Redis，Amazon S3和Amazon DynamoDB進行。我們決定使用這種架構，以便我們的系統可以在存儲和數據庫吞吐量方面進行擴展。這樣我們只需要在數據庫集羣之上運行Django。我們使用PostgreSQL作爲數據庫，因爲當提到集羣和擴展時，它被認爲是行業標準。
上傳，外部源
Uploadcare允許用戶使用小部件上傳文件。我們支持多個上傳源，包括僅需要URL的API。
上傳的文件由Django應用程序接收，大部分由Celery完成。它很適合處理隊列，它擁有一個強大的社區和大量的教程和示例。Celery處理上傳大文件，從不同的上傳源檢索文件，存儲文件，並將文件交付到Amazon S3。與外部源的所有通信都由單獨的Amazon EC2實例來處理，負載均衡由AWS彈性負載平衡器處理。負責上傳的EC2實例與應用程序的其餘應用保持分開。
當我們在保留資源以降低成本和提高效率時，在AWS中遇到的兩個問題是：AWS狀態頁面報告不準確，並且未能提前計劃。
文件存儲，用戶和文件數據
我們使用Amazon S3進行存儲。EC2上傳實例，REST API和處理層都與S3直接通信。如果他們願意的話，S3讓我們能夠永久存儲客戶檔案。
文件和用戶數據由高度定製的Django REST框架進行管理。起初我們使用了開箱即用的Django REST框架，因爲它幫助我們快速部署功能。然而，隨着我們對REST API應如何工作的展望，我們對它實施了定製來適應我們的用例。我們的定製添加的代碼越來越多，從而導致更新框架變成了一個痛點。我們正在尋求修改堆棧的這一部分，以避免添加進一步定製框架時，使這個問題複雜化。
我們使用微型框架Flask來處理敏感數據和OAuth通信。它是輕量級和高效的框架，同時不包括我們不需要的任何功能，如隊列，ORM層或高速緩存。
我們在博客上關於雲安全的文章中更詳細地探討了這個話題，解釋了Uploadcare如何從社交媒體獲取內容，以及如何處理最終用戶隱私。
處理
我們每天處理的350M API請求包括許多處理任務，例如圖像增強，調整大小，過濾，面部識別和GIF到視頻轉換。
我們的文件處理要求需要使用異步框架進行IO綁定任務。Tornado是我們目前使用的，而aiohttp是我們打算在將來的生產中實施的。兩個工具都支持處理大量的請求，但是aiohttp比較好，因爲它使用的是asyncio，而且是Python原生的。
我們的實時圖像處理是一個CPU綁定的任務。 由於Python是我們服務的核心，我們最初使用PIL，然後是Pillow。我們還在改進。當我們認爲調整大小是最耗資源的操作時，我們的工程師Alex創建了名爲Pillow-SIMD的叉型指令，並做了大量優化，使其比ImageMagick快15倍。優化之後，現在Uploadcare需要服務器處理的圖像減少6倍。這裏，通過服務器也意味着處理EC2實例和第一層緩存分離。處理實例也與ELB配對，這有助於將文件提取到CDN。
緩存，交付
有三層緩存有助於提高整體性能：
1.在處理引擎中進行緩存，從而相同的操作不會運行多次
2.CDN-Shield內的緩存，因爲CDN邊緣，不會影響起點，緩存更有效
3.在CDN邊緣上的緩存作爲最接近用戶設備的邊界
爲了交付文件，在nginx和AWS彈性負載均衡器的幫助下，文件將被推送到Akamai CDN。我們還使用Amazon CloudFront，但由於缺乏覆蓋，我們將Akamai作爲默認CDN。另外Akamai還有很多很酷的功能，例如，它允許我們自動調整imagea格式然後再發給用戶瀏覽器。
值得補充的是，我們的文件接收/交付比率有很大程度基於交付。
前端
如我們所說，對於複雜技術的簡單控件不能沒有整潔的UI用戶區域，包括起始頁，儀表板，設置和文檔。
最初使用Django。早在2011年，考慮到我們以Python爲中心的方法，那是最好的選擇。後來，我們意識到我們需要更快地在網站上進行迭代。 導致我們從前端分離Django。那時我們決定建一個SPA。
爲我們的前端頁面，文檔和其他網站部分構建SPA是一個持續的過程。它是通過Node.js完成的，異步的，並提供同構渲染。爲了與我們較老的基於Django的前端進行通信，它通過nginx使用JSON API。 這是一個經驗法則：一旦分離，我們的前端和後端之間的通信仍將通過JSON API進行。
對於構建用戶界面，我們目前使用React，因爲它在構建工具包時提供了最快的渲染。不僅如此：React有一個很好的社區，可以幫助你減少代碼並構建更多的功能。值得一提的是，Uploadcare不是以前端爲中心的SPA：我們沒有把事情搞得太複雜。如果是，我們會結合Ember。
然而，有一個機會讓我們轉向更快的Preact，它的座右銘是使用儘可能少的代碼，並且因爲它更多地使用瀏覽器API。
在客戶端，我們使用Redux.js處理數據，並通過React Router進行路由。後者是強大的React社區的一個很好的例子。
前端將來的任務之一就是配置Webpack Bundler來分解不同站點部分的代碼。目前，當你加載站點頁面時，你還同時會獲取所有其他頁面的代碼。Webpack還是一個代碼構建的工具，具有大量的社區示例，可用作入門套件。 我們正在考慮使用Browserify或Rollup，但是它們沒有運行時，並且比Webpack工作速度慢，或者要求我們做更多的編碼以提供類似的功能。 此外，異步塊更容易處理Webpack。
至於靜態網站頁面，很多都是Markdown格式的文件，它們位於GitHub的倉庫中。總的來說，我們正在使用GitHub Pull Request Model進行部署。然後，來自一個倉庫的文件將通過jinja2啓發的nunjucks，然後是markdown-it和posthtml。 例如，我們的文檔是以這種方式構建的。
對於樣式，我們使用PostCSS及其插件(如cssnano)來壓縮代碼。
你可能會說，我們喜歡後處理器的想法。例如，posthtml是一個解析器並提供抽象語法樹的字符串，它很容易使用。
所有這一切使我們能夠提供良好的用戶體驗，並儘可能少地使用代碼，快速實現需要的更改。
部署
如上面提到的，我們使用GitHub Pull請求模型。過程中的某些部分是自動的，而其他部分需要手動干預。 我們使用以下步驟：
1.我們爲一個功能在倉庫中創建了一個分支
2.提交給分支。然後在TeamCity中進行自動測試
3.如果測試通過，則創建PR，然後由開發團隊進行自動測試和代碼審查
.如果測試通過/審查通過，我們將更改合併到分段分支，然後通過TeamCity和Chef自動部署
.部署時，我們通過TeamCity運行集成測試
.如果一切順利，我們會將更改合併到生產分支，並通過TeamCity自動運行一次以上的測試
.如果測試通過，我們確保它不是一個星期五晚上，我們部署到生產環境。這裏的主要腳本由devops運行。
我們通過Slack通道獲得有關部署狀態的通知。關於報告，我們從監控堆棧獲得了很多輸入，其中包括報告錯誤和異常的Rollbar，用於日誌記錄的LogDNA，用於外部測試我們的服務的Pingdom，用於監控AWS統計信息的Amazon CloudWatch，以及Datadog用於整合報告和監控服務器和服務的健康狀況。
團隊管理，任務，溝通
利用Slack，還有G Suite來發送電子郵件，Trello來制定計劃，HelpScout和Intercom來與用戶成功溝通並處理用戶關係等。
版本
由於我們提供了完整的處理文件的預製構建，所以我們鼓勵所有人在其產品的不同部分使用類似的預製構建。我們的堆棧是一個很好的例子，它是一個預製構建的組件的集合。我們可以隨時繼續添加更多組件。 例如，我們正在使用Segment來對發送的數據進行分析，而這些數據又由Kissmetrics，Keen IO，Intercom等進行處理。我們正在使用Stripe處理付款。
我們實踐了所講的內容：關注你想要創建的內容，並讓這些預製構建處理它所做的具體任務。本文由 健康大部落std.jkdbl.com整理髮布