海豚瀏覽器的雲端之路

海豚瀏覽器于2010年2月正式發佈Android版本，在正式發佈的近一年之後從一個純用戶端的產品開始反覆運算式地進化，逐漸加入各種雲端服務的功能，海豚瀏覽器的雲端之路也因此而啟程。 在創業之初，因為資源、人手的各種緊缺，自然而然的雲端服務的部署也就成為首選。 當時在國外的創業型小公司中，亞馬遜雲平臺（Amazon AWS）備受青睞，因此我們也毫不猶豫的選擇了AWS做為服務商，並且在海豚閱讀（Dolphin Webzine）的第一次發佈裡做了大規模的嘗試，隨後又相繼推出了海豚同步， 海豚聲納等雲服務。

起初接觸雲平臺其實更多地仍然是把雲平臺當成普通的IDC主機租用服務在用，體驗到的優勢是相對於物理主機而言，雲主機（instance）上線/下線都比較方便。 而且不像國內很多主機服務是預充值或者預付款的消費模式，AWS平臺的付款直接與信用卡掛鉤，用多少就付多少，非常靈活。 隨著時間的推移，對雲平臺認識的淺顯和不充分，導致我們吃了不少的苦頭，當然也積累了不少經驗教訓。 到現在，整個AWS雲平臺（見圖1）的大部分服務我們都有實際使用的經驗。

圖1：AWS服務棧

雲平臺上的擴充性

說到雲平臺的使用就不得不先說說水準擴展（scale out）。 之前我們的做法是在服務正式對外發佈之前，部署多套同角色的機器（比如前端機器和應用伺服器），就為了保證能夠應對突發的流量增長。 這些備用機器的部署和使用在雲平臺上其實是沒有多大必要的。 在AWS上完全可以通過ELB這樣的一個彈性負載等化器來自動實現服務的水準擴展，ELB支援多種協定，並且可以自訂水準擴展的條件，對於服務的開發者來說，這省了不少開發的活，而且對於普通的負載均衡應用場景來說， 它完全可以替代Nginx或者HAProxy。

對於垂直擴展（scale up）來說，有兩點比較重要，一是對雲主機升降級時類型的選擇，二是瞭解雲主機的生命週期。 EC2上的雲主機有固定的好幾種類型，首選一般都是64位機器，這樣方便記憶體擴容，如果對於CPU消耗比較高（比如HTTPS連接），那麼優先選High-CPU型的，如果是對記憶體要求比較大（比如MongoDB）， 那麼優先選High-Memory型的。 海豚的大多數機器選型集中在micro/small用作監控和前端，small/medium部署應用服務、訊息佇列，medium/large做資料庫和離線計算。 xlarge再往上用得很少，基本上都靠水準擴展解決了。 對於雲主機的生命週期來說，restart和stop/start是有區別的，升降級的時候必須要stop雲主機，升降級完畢再啟動的時候，機器的內部IP會發生變化（IP通過DHCP分配的）， 這一點經常會給依賴IP的服務配置造成問題。 解決的辦法有兩個，一個是通過VPC來自己控制IP位址分配，另外一個就是使用Elastic IP這樣的靜態位址。

雲平臺上的存儲

和計算資源一樣，存儲資源是一個雲平臺的核心要素之一。 雲平臺上的存儲按照使用場景分為三大類型：

·臨時存儲。 AWS的instance storage就是臨時存儲的一種，主要用來存放緩存和一些中間結果等內容。 要注意的是臨時存儲的內容在雲主機stop以後就會被清空，因為通過df命令往往看不出來這一點，所以之前有過把instance storage當成持久化存儲的經歷，損失就很慘重。

·持久化存儲。 持久化存儲最常指的就是物理硬碟，在AWS平臺上，EBS就是這樣的一個可以以任意大小被掛載的「硬碟」，實際上它的實現是一個網路檔案系統，因此它的訪問速率受限於網路頻寬，而且不是那麼穩定。 通常可以通過在EBS標準的volume上做RAID或者使用最新推出的Provisioned IOPS volume來解決I/O速率問題。 另外儘管EBS是持久化存儲，並不意味著它就不會發生資料的丟失，EBS的年化不良率有0.1%-0.5%，因此對於單存儲節點來說需要週期性去做EBS的鏡像和備份，以防止意外的發生。

·大規模冗余存儲。 S3就是這種存儲類型的樣例。 S3不是一個檔案系統的架構，I/O速率和延遲也不及EBS，但它的好處在於一方面可以在一個比較低的價格（和EBS差不多）提供99.999999999%的可靠性，另外一方面可以存取非常大規模，比如PB級別的資料， 這些資料可以在不限於AWS的任何地方使用。 海豚就用S3存儲了幾乎所有的鏡像、資料備份和各種日誌。 除此之外，S3和CloudFront（AWS的CDN解決方案）集成程度很高，因此海豚也通常使用S3作為APK等內容分發的管道。

(責任編輯：蒙遺善)