視頻我們最早用的是樂視雲的解決方案，對，你沒看錯，是樂視，因為iOS上面的問題很多，很快切到騰訊雲的視頻SDK去了；很遺憾，阿雲當時我印象只有一個js的SDK，編解碼處理，視頻審核都還沒有開放出來，但是出於數據安全的考慮，我還是用OSS備份了我們的視頻資源。沒有依賴開源項目處理，依然是我們快速驗證業務的思路，需要儘快更新迭代，求證數據，初期騰訊雲的SDK在橫屏下有些缺陷，總的說來達到我們的預期了，雖然當時無法做到秒開。也幸虧我們用OSS備份了視頻內容，避免了後來的一次誤操作帶來的更嚴重的影響。
提到OSS，我也多說一些，早期我們也是簡單的搭建了圖片服務器，獨立存儲圖片，作為七牛CDN的回源，但隨著女裝導購的切換，帶來了大量的圖片處理，這裡不得不說，女裝商家要比童裝商家要先進很多，多尺寸圖片非常完備，分辨率高，可以應用在不同場合，而童裝商家的圖片往往很少，很快我們服務器的文件數過多，導致圖片檢索異常慢，服務器負載異常高，所以很快我們就開始使用OSS了，這裡再次提到七牛，不得不說七牛在圖片處理上一些產品細節還是更優的，當時我們有一個圖片裁剪的需求，OSS應用後總是不符我們預期，可能是產品設計同學的理解不同，所以有部分圖片的處理我們通過七牛裁剪後再轉存OSS，當然後續OSS也完善起來了。
隨著我們的業務模塊增多，運維要求也逐步浮出水面，我們也出過因為日誌導致磁盤滿引發統計數據異常的事故。總的說來，阿里雲給我減輕了很多工作量，在兩年的時間裡，基本是我獨立支撐基礎運維，但是我對團隊的要求是需要他們有運維能力，從我的經歷來看，有過運維經歷或者說對於運維有興趣的同學他的技術垂直延展性要好不少，團隊內我也提倡全棧，但是我對他們的要求是從水平、垂直兩個維度來拓展技術棧，而不是簡單的各條線的應用，很多時候我也會自嘲，全棧就是什麼都會做，什麼都要做，什麼都不“深”，其實很多時候深度往往體現了你對技術的熱愛風格，當你不僅僅是熱愛迅速的解決問題的時候，你至少會有PlanB，在同一水平層，你也會更深入一點：）。
我們準備的彈藥充足了，接下來就是如何打造我們的內容了，一方面從現有的運營轉換工作，一方面招募寫手，同時面向校園招募兼職寫手，這個時候我們就需要搭建自己的寫作平臺。寫作平臺的難點在於適合不同的人，所以我們沒有尋求功能強大的富文本組件，而是根據我們的移動端展示樣式，為寫手們提供了統一的排版格式，提升大家創作內容的效率，關注內容，而不是排版；對於內部運營，我們提供了更多小工具，我印象中到Q3的時候，我們已經能為運營同時提供內容、圖片、明星、商品素材。通過關鍵詞，我們可以提供上述內容的及時推薦，這也得益於OpenSearch的強大。不過，我們也遇到了一點麻煩，對於複雜的結構，我們採用了主從表的形式，使用上看起來很便捷，但是這種方式他的索引更新是有差異的，簡單點說主表字段更新會出發索引更新，文檔內容更新，但是從表字段更新，並不保證索引、文檔的更新，一方面和早期都是共享模式有一定關係，另一方面從性能上來說，從表一般數據量大，如果更新頻繁勢必導致索引更新的不穩定，所以他的結果就是如果你是一對多的主從表，從表字段內容變更，搜索結果很可能是無法展示這種變化，主從表不適合從表有大量更新的場景，我們應用的姿勢有誤。不過我們也用了騷操作，從表字段更新後強制更新主表的字段，臨時性的彌補了這個問題，這在數據量小的時候還可以，數據量一旦較大，性能抖動會比較大，同時會導致你的OpenSearch需要更高的規格來適應，這在OpenSearch後期調整後表現比較明顯了，帶來的費用增長長期看也是不划算的。
隨著業務模塊的遞增，我們也面臨服務依賴影響的問題，特別是活動推廣時會突然加大整體負載，但是其實這只是單獨業務模塊的負載，卻影響了整站性能，所以我們結合SLB做了基於域名的業務拆分，沒有做基於路徑的。SLB還有一個好處，有個大約20G流量的DDos防禦，這在一定時候也幫了我們不少忙，這是後話。
基於內容的時尚類導購一切看起來都挺美好，次日留存數據已經可以達到我們認為的行業高點，可是月度留存遲遲不見起色，我們幾個合夥人再次陷入困境，而這一切，在團隊中還悄然無聲……（未完待續）