從零到一，美芽的技術實戰 | UPYUN Open Talk NO.4

姚東旭 美芽 CTO

美芽做爲一個美妝視頻社區，在 2015 年 2 月份上線以後，極受女性用戶的歡迎。這次美芽 CTO 姚東旭在 UPYUN Open Talk No.4 廈門場，分享了美芽從零到一的整個產品生命週期，帶給創業公司不少值得借鑑的地方。

美芽在萌芽過程當中，同不少初創產品同樣，有常見的三個特色：

1. 較小的用戶規模。雖然偶有例外，譬如「足跡」的爆發式增加，傳言 DAU 有 300 萬，而通常的產品不會有這種運氣；
2. 快速的需求變化。初創產品蘊含不少的不肯定性。沒法同時兼顧產品細節，也沒法在較短期內將功能極盡完善，於是一般狀況下會盡快推向市場，以驗證想法的正確性；
3. 還沒有完善的團隊。互聯網創業公司對於技術人員的強烈需求，與市場的供不該求，有着難以消解的矛盾。加上創業公司沒法高價請人，一般狀況下的應對之策只能是一人多用。

面對這樣的境況，相比較代碼的執行效率或線上接口的響應效率，更爲注重開發效率是美芽的應對之策。而影響開發效率主要包括三方面：一是溝通成本，以客戶端和後端同窗的溝通爲主；二是重複輪子，已經有成熟的開源實現了，卻用本身的代碼重複實現了；三是過分設計。

溝通成本：協議 / 流程

1）協議

在協議方面，不少項目在設計先後端交互協議時很是隨意，好比 /Post/Show/xx ，實現起來也沒有統一標準。

從請求沒法明確看出該以哪一種方式獲取數據，客戶端同窗必須詢問服務端，或者在文檔裏清晰的描述出來。特別是對於新加入的開發者，須要一個熟悉的過程。好比刪除一個帖子，使用 DELETE 或 GET 方法，也並無統一的標準，針對這個問題，美芽是選用 REST風格。

REST能夠翻譯爲表現層狀態轉化，這裏應該還有個主語，那就是 Resource（資源），特指網絡上的具體信息，好比帖子和評論。美芽在設計客戶端請求接口的時候都是針對一個資源作操做。REST定義了一個對資源操做的標準，使用 HTTP 的四個動詞表示對資源的操做，GET，POST，DELETE，PUT。以用戶帖子爲例：

1. GET /posts 獲取帖子列表，
2. GET /posts/id 獲取編號爲 id 帖子的內容，
3. POST /posts 發佈帖子，
4. DELETE /posts/id 刪除編號爲 id 的帖子，
5. PUT /posts/id 修改編號爲 id 的帖子。

不管新加任何功能模塊，包括評論或點贊等都執行這一標準。在開發客戶端的過程當中，就避免了添加新功能時對接口作其餘的約定。

以模型 Post 舉例，接口能夠變成在獲取帖子時，將 id 傳過去，返回來就是須要的對象。帖子在後端或數據庫中的字段，在客戶端對應的就是 Post 模型的屬性。

再也不須要有文檔去介紹它，只須要自動生成一份數據庫字典就把全部東西解決了，少了不少中間成本。在客戶端要建立帖子就變得極其簡單，客戶端用定義好的方法請求到後端，服務端收到請求後就往數據庫裏新建一個資源。美芽在客戶端接口設計的時候都是針對資源操做。

總結來講，接口設計面向資源、而非功能。在客戶端有各類功能和操做，在接口上面確定不能全部的東西都按客戶端的要求設計，這樣會增長很大成本。咱們在接口設計上只關注數據，至於怎麼操做是客戶端的事情，將數據和表現分離。

2）流程

開發流程，剛出道的時候因爲流程不完善，會出現各類問題，好比剛上線的代碼或剛修正了一個 Bug隨意發佈，發佈上去後又發現有問題。

針對這點，美芽制定了本地環境 - 開發環境 - 預發環境 - 生產環境四個環節。每一個人在本地環境完成後將代碼提交，會自動發佈到集成開發環境；預發環境的存在，是想在上線以前，在一樣的生產環境下，作最終的確認，以後再更新到用戶環境中。

代碼管理的流程，從倉庫來講，首先有 master 和 dev 兩個長期分支，master 是主幹分支，dev 是開發的集成環境 。當要修改 bug或者開發新特性時會新建一個新分支，問題修復後須要將這個分支 merge 到 dev 分支，須要上線時就合併到 master，這是一個特定的生命週期。

代碼在推向預發環境前要通過其餘成員的審覈，審覈以後纔會合併。合併後使用 git hooks 工具，自動將代碼更新到預發環境，在App客戶端 內部會作一些開關控制它用哪一個環境。

在整個過程當中，對全部同窗都是透明的，咱們使用了 Slack 做爲消息樞紐，Slack 訂閱了 Github 通知事件。團隊裏面的每一位成員，只要關注項目都會看到全部的動態，包括特性上線、Bug修復等。還有一個工具 fabric， 這是一個 異常上報 組件，客戶端集成 fabric sdk後就能夠將異常上報到 fabric，fabric再通知到 Slack, 團隊成員就能在 slack 中看到客戶端運行動態了。

重複輪子：框架 / 類庫 / 開源軟件

先看框架。其一，爲了保證開發效率，但願框架使用起來可以足夠簡單，新的團隊成員也可以很好地適應。關於頗受爭議的 ORM 須要觀察它的適用狀況，在用戶規模尚小、數據量較小時，ORM 可以快速實現業務需求，而當量級漸長就該果斷捨棄；其二，框架必須保證功能強大，以儘量減小開發量。

基於以上的綜合考慮，美芽選擇選擇使用瞭如下PHP框架和工具：

一、PHP 採用 Laravel 框架，框架在設計的時候支持 RESTful，在代碼層面當新加一個路由資源的時候，新加一個 Controller 就能夠解決了。

二、DB migration，這個是修改數據表結構的一個工具。剛剛說起的需求會較不穩定，常常會遇到字段的增減，而此類操做若是隻是手動修改，並須要同步到其它環境，將極其不利於管理。DB migration 這個機制是用要代碼表示數據庫字段的增刪。

譬如在增設字段時，新增一個類表示對數據表的操做，其中，up 方法就是執行修改，down 是回滾修改。等到上線時，就只需更新 PHP代碼，這就統一了表結構的統一操做，全部的東西都用代碼呈現，呈現又是文本，能夠進行版本管理。人員對數據庫的全部操做都有紀錄。

三、Command。好比，開發一個命令行工具，讓用戶輸入一個名字，根據名字調用信息，須要包含輸入參數，和選項參數以及輸出。Command 會將這些東西作包裝，不須要開發除了產品業務邏輯以外的東西。

四、Queue，進行不少操做時不能同步等待，好比推送一條消息，發佈一條評論讓對方收到消息通知，確定不能在請求裏同步處理，而是要放到隊列裏異步執行，再推送到蘋果的服務器最後推送到用戶。這個例子是項目中用的，咱們添加隊列的時候只需在服務器上執行一條命令打開這個隊列。

五、 Tinker，這也是命令行的工具，能夠作到在執行這條命令的時候，把整個項目環境加載進去。並且是一個交互式的操做，好比要取一個對象就能夠直接查詢，把信息打出來。相比較調試代碼時用url或者添加各類參數，這種處理方式會很是方便。

六、還有一個是對 Log 的處理，使用時只須要配置一下，在當前環境下須要打的 Log 級別，在代碼中直接使用便可，或者在生產中將這類信息都保留。

上面使用的每一項都不是太複雜，或者難度特別大，本身作也均可以。但在資源有限的狀況下，初創團隊更重要的是投入更大的時間和精力在業務上。這個框架是集成了開發中一些通用的內容，減小了不少額外的開發工做。

雖然看上去 Laravel 框架很是美好，但美好都是有代價的，Laravel 框架很是的慢。由於它提供了各類封裝、加載了不少東西，致使一個空的接口響應時間也須要幾十毫秒。因此更適合量不大的初創產品。但與此同時，美芽也正在積極解決效率問題。

再來看 iOS 類庫，REST 只是定義了標準，而沒有提供完整的工具來實現，一般服務端返回的是 JSON 格式數據，客戶端將收到的 JSON 格式轉換成 NSDictionary，再由 NSDictionary 轉換成 NSObject, 這可能對應到客戶端的一個 Model 或者一個具體對象；客戶端發請求到服務端時，就須要將 NSObject 轉化成 NSDictionary， 再轉換成 JSON 格式，而後發送到服務端。這個過程很是煩鎖，並且須要對每一個類都實現一套 encode decode 的邏輯，而實質上咱們關心的只是 Value 而已。咱們引進了 Mantle 庫，這個庫會幫你實現這一系列封包解包的過程。

再加上 TMCache AFNetworking 這兩個庫（前者用來實現快速的對象緩存，然後者基本上每一個 iOS 程序員都熟悉的一個網絡框架），就能實現整個產品的 Model 層。

最後介紹一套開源軟件 ELK(Elasticsearch Logstash Kibana)，這一套軟件主要用來處理日誌，進而分析問題，其中Elasticsearch 負責存儲+搜索、Logstash 負責蒐集、Kibana 負責展現，經過 ELK咱們能夠隨時觀察事件的發生，並做出及時穩當的處理。

好比客戶端訪問服務器時返回系統繁忙這些錯誤，或者是帖子加載過慢這些問題均可以經過這一套軟件展現出來。雖然看似複雜，但實際操做卻極其簡單，如今咱們主要分析程序內部日誌，Nginx access log 和 Nginx error log。

這些日誌會先經過 logstash 採集，存儲到 ES 上，再經過 Kibana 展現出來。

同時，這一套工具還有對運營數據分析的支持。接入這套工具，美芽實現了各類業務的簡單統計，包括註冊統計、地區分析、時間分析、用戶活躍時間等等。接入 ELK 也是很是簡單的，只需將原始數據導入，調用一些查詢語句就能夠展示，只須要調用一下接口、填入統計數據便可，業務上不須要作什麼操做和修改，更無需修改數據庫和代碼主邏輯。

美芽 總體宏觀架構以下圖所示：美芽用戶經過 APP 或者PC 版跟 Nginx 交互再訪問 API，這裏所產生的日誌都會寫文件，在文件寫入以後就會有 Logstash Agent 會翻譯成固定的格式存到 Elsearch， 同時 API 內部也會將日誌會先輸出到消息隊列中，由消息隊列再異步輸出到 Logstash Agent，Dashboard 會調用 kibana 的接口，以運營能接受的形式展示出來，以下圖：

會管理線上服務器的客戶端開發，纔是一名好運維。

特別介紹下美芽的運維，盡一人多用之能事，運維也兼作開發。在代碼的上線流程中並不須要運維的參與，但軟件安裝、配置更新就須要運維處理。美芽的運維，主要是經過 Saltstack，用 YAML 來描述服務器的狀態。YAML 做爲一種比較簡潔的數據格式，是純文本的，也就是說服務器的全部狀態均可以進行版本管理，服務器的狀態可根據每一個版本里面的配置文件體現出來服務器當前是什麼樣的狀態。

看下面一個簡單的示例，下圖是一個 logstash 的 saltstack 配置：

首先是有一個 master 節點，這是一箇中心節點，而後有不少的 minion 節點須要被更新。

執行如下一條命令就能夠將全部的 minion 更新了，命令有兩個參數，一個是 prod，是一個分組的概念，好比五臺服務器，把五臺服務器都放到分組裏面；後面一個參數 production, 表明生產環境。操做時，前半部分是針對五臺服務器作的工做。