移動互聯網初創型團隊須要什麼樣的雲計算服務？

　　對於創業型團隊來講，服務器託管費用+帶寬成費用+運維成本，是壓在頭上的三座大山。知足業務性能須要，又要下降成本，儘快實現收支平衡，是當務之急。

　　1、不靠譜的 App Engine

　　一、Google App Engine 雲服務在國外的成功，不表明國內巨頭們各類 *AE 仿造品的成功。在微博上搜搜就能夠看到小夥伴們吐槽的各類不穩定，另外，*AE們對資源使用最大數各類規定限制，加上爲了計費、閹割功能的各類限制，使它的價格優點成爲雞肋。*AE們就比如100M共享帶寬的小區寬帶，以低價賣給每一個上網用戶5M的帶寬，前幾十個用戶感受這網速真不錯，等他賣了100個以上用戶5M帶寬，而這部分用戶白天上班去了，晚上下班回來都在上網，其中又有一部分看視頻、BT下載，因而乎，白天網速快，晚上慢得要死，連200K帶寬都達不到。要知道，不怕神同樣的對手，就怕豬同樣的隊友，在國內的 App Engine 環境下，水平良莠不齊的開發者的代碼質量、習慣性的資源濫用、別人網站被攻擊殃及池魚對*AE性能的影響，致使*AE的穩定性很是差。

　　二、因此，*AE們也意識到公共 App Engine 不穩定，因此又推出專用 App Engine，但費用一下就翻了不少倍。因此，*AE只是我的博客、我的開發者玩玩的工具，真正用做項目，仍是需謹慎。根據實際的經驗，*AE們還真不如VPS穩定。

---

　　2、成本低的小而美VPS

　　一、對於初創團隊來講，購買服務器、交換機，託管服務器費用、帶寬月使用費，是極其昂貴的。購買能夠彈性升級硬件配置的雲服務VPS，是下降成本不錯的選擇。國內VPS，1G內存、1~2核CPU、1M帶寬、多線BGP，大概價格在100元/月左右，支持備案，能夠做爲最低入門選擇，有條件能夠購買兩臺互爲熱備，阿里雲主機能夠做爲參考。大多數VPS服務商使用的都是廉價的SATA磁盤。若是你對磁盤IO要求較高，能夠選擇提供有SAS磁盤的IAAS雲主機服務商，好比UCloud。

　　二、市場上的VPS商家主要有 Xen、OpenVZ、KVM 三種開源的虛擬化技術。全虛擬化的 Xen 更像獨立主機，服務器資源按VPS實際大小平均分配，通常沒法超售。半虛擬化的 OpenVZ 在一樣的性能測試下，會比 Xen 高一些，可是，一臺物理內存16G的服務器，能夠分配出總內存大小超過16G不少倍的VPS，服務商能夠超售，想賣多少臺VPS就能夠賣多少臺，因此不推薦使用。KVM 在最新的 Linux 發行版中，已是集成，可是，商業化應用還不成熟，基於 KVM 的 VPS 服務商不多。

　　三、VPS的操做系統，建議選擇64位的Linux。在32位Linux下，PHP能給處理的整數不能超過正負2^31=2147483648，若是之後接入新浪微博、淘寶、騰訊等第三方開放平臺，他們的接口裏會有超過32位的整數（好比新浪用戶ID、淘寶商品ID）。若是不幸使用32位Linux，你只能將這些整數當成字符串處理了，之後配合Sphinx等搜索引擎，會很是麻煩。

　　四、如今，能夠在北京進行備案的域名有：國際域名 .com .net .org，國內域名 .cn .com.cn .中國，國別域名 .cc，其餘的域名均不能進行備案。僅北京有限制，其它省市正常提交備案便可。咱們原來申請的 .me 域名，在北京沒法備案，後來只好拿到蘇州去備案了。因此，在選擇域名的時候，須要慎重。

　　五、使用 VPS，必定要按期在本地，作好數據備份，不要相信所謂的 7*24服務，99.99%安全穩定性，只要有人的VPS出問題了，都歸爲那 0.01%。

---

　　3、應對峯值帶寬的雲存儲

　　一、對於DAU（日活躍用戶）過十萬的網站、APP應用來講，CDN或雲存儲是必需品。使用雲存儲不是由於存儲空間，由於一塊幾TB的SATA磁盤很便宜，使用雲存儲是由於高出平均帶寬值幾倍至幾十倍的峯值帶寬。作手機APP應用，峯值帶寬更集中，當你向全部用戶羣發PUSH一條消息，用戶被喚醒打開APP應用，幾分鐘的時間，會消耗幾十倍的帶寬峯值。圖片、下載，是最主要的帶寬消耗者。也許，數據接口API只需不到1M的帶寬，而圖片對帶寬的峯值需求則會達到100M。爲了幾分鐘的峯值，去購買100M昂貴的帶寬，其餘時間帶寬都空閒，是一件很是奢侈的事。

　　二、國內提供雲存儲服務的商家有不少，真正好用得卻很少，提供FTP等公共通用協議的雲存儲更是微乎其微。使用第三方雲服務，切忌千萬不要吊死在一棵樹上。支持FTP等公共協議，若是未來有問題，可以方便的進行數據遷移和技術替代。若是雲服務廠商一直可以提供優質的服務，那麼，也就能夠長期使用他們的雲服務。相信優秀的雲存儲提供商，是不會害怕這一點的。

　　三、以前，我用過阿里雲的開放存儲服務OSS，可是，穩定性比起阿里雲主機ECS等其餘服務，要差多了。下面是用阿里雲自家的雲監控，監控最近一個月阿里雲主機和OSS上的文件，雲主機的可用性99.99%，而OSS可用性只有97.83%，月宕機累積時間31.27小時。而OSS每次一遇到升級，就更坑爹了，很少說，本身看他們的公告吧（ http://bbs.aliyun.com/read.php?tid=146819 、 http://bbs.aliyun.com/read.php?tid=141828 、 http://bbs.aliyun.com/read.php?tid=139381 )：

　　

　　


　　四、後來，本博客的圖片、附件下載，改用了又拍雲存儲。相比於其餘的雲存儲，又拍雲支持FTP上傳、下載管理文件，同時對於圖片類文件的處理功能，也比較強大：
(1)、支持縮略圖&水印，能夠支持自定義版本：限定寬度，高度自適應；限定高度，寬度自適應；限定最長邊，短邊自適應；限定最短邊，長邊自適應；限定寬高；等比縮放等多種縮略模式。

　　

　　示例：
　　原圖：http://yphoto.b0.upaiyun.com/test/gzhd.jpg
　　限定寬度(600px)，高度自適應：http://yphoto.b0.upaiyun.com/test/gzhd.jpg_b
　　限定最長邊(100px)，短邊自適應：http://yphoto.b0.upaiyun.com/test/gzhd.jpg_100

　　固然，經過 Nginx 的 image_filter 也能夠實現其中的限寬或限高自適應功能、並緩存在本地，只是功能要少，缺乏了又拍雲存儲的CDN加速功能。Nginx image_filter 配置示例：

http
{
  proxy_cache_path /Data/cache/nginx/app levels=1:2  keys_zone=cache_app:200m inactive=7d max_size=10g;

   upstream view_store_server_pool{
      server 192.168.1.2:80;
    server 192.168.1.3:80;
  }

  server {
    server_name  view.store.zyan.cc;

    access_log  off;
    location / {
      proxy_cache_valid  200 600s;
      expires 600s;
      proxy_pass http://view_store_server_pool;
      }

    location ~ /resize_width/(\d+)/(.*) {
      set $width $1;
      rewrite ^/resize_width/(\d+)/(.*) /$2 break;
      image_filter   resize  $width -;
      image_filter_jpeg_quality  90;
      image_filter_buffer 10m;
      proxy_cache cache_app;
      proxy_cache_valid  200 600s;
      expires 600s;
      proxy_pass http://view_store_server_pool;
      }

    location ~ /resize_height/(\d+)/(.*) {
      set $height $1;
      rewrite ^/resize_height/(\d+)/(.*) /$2 break;
      image_filter   resize  - $height;
      image_filter_jpeg_quality  90;
      image_filter_buffer 10m;
      proxy_cache cache_app;
      proxy_cache_valid  200 600s;
      expires 600s;
      proxy_pass http://view_store_server_pool;
    }
  }
  ......

　　(2)、又拍雲存儲支持 Token 防盜鏈。對於圖片類防盜鏈來講，判斷域名、Reffer就夠了。可是對於軟件下載等防盜鏈來講，Reffer等信息均可以僞造，比較靠譜的方法，仍是Token防盜鏈。

　　

---

　　4、可選的關係型數據庫服務（即 MySQL 服務）

　　一、資源消耗的大戶在於 MySQL，影響總體性能的因素也在於 MySQL。對於創業型團隊來講，不要過分依賴 MySQL，不要將高併發業務邏輯都用 MySQL 來處理。在 MySQL 前加個 Memcached 作 SQL 查詢緩存，跟 MySQL 的 Query Cache 區別不大，治標不治本，命中率不高，還下降了實時性。如今的移動應用，交互性比較強，實時性要求很是高，Web 時代緩存幾分鐘的老方法，已經不能適合移動互聯網時代的需求。所以，MySQL 只適合存儲一些併發查詢量不大的核心數據，或做爲數據的備份，只寫入不查詢。我遇到過不少創業團隊，用戶飛速增加時，最後都是被 MySQL 數據庫的性能瓶頸蹩了腳，最後不得不減緩產品功能開發的腳步，來作性能調優，失去了與競爭者、模仿者、山寨大王騰訊的競爭優點。創業團隊靠什麼和大公司競爭，靠得就是靈活與速度，跑贏大公司。

　　二、在不依賴 MySQL 的條件下，那麼，最低配的關係型數據庫服務（好比阿里雲的最低配內存 240M、磁盤IOPS 150、最大鏈接數 60，70元/月），就能適合本身的需求了，否則，勉強知足通常業務配置的關係型數據庫服務的費用，就得 700~3000 元/月了。

　　三、若是購買最低配的關係型數據庫服務，還不如省掉 70元/月的費用，在本身 1GB 以上內存的 VPS 上，本身搭建一個 MySQL 數據庫，磁盤IOPS、最大鏈接數、存儲空間還不受限制。本身作好 MySQL 的主主、主從同步備份，定時dump備份就能夠了。須要注意的是，不少VPS默認沒有開啓sawp，使用 MySQL 請必定記得開啓。下面提供一個 MySQL 5.6 版本適合在 1GB 內存 VPS 上的 my.cnf 配置文件。

下載文件

點擊這裏下載文件

　　四、若是說 VPS 雲服務是必選項的話，關係型數據庫服務則是可選項。

---

　　5、結構化存儲 NoSQL 數據庫

　　一、既然不依賴 MySQL 數據庫，那麼，對於高併發訪問，就須要依賴結構化存儲 NoSQL 數據庫了。雖然一些雲計算服務商，也提供告終構化存儲服務，可是，不推薦使用。由於他們使用的都是私有協議，你沒法在他們的服務質量、穩定性變差了，價格變貴了，或出現別的更好服務商時，快捷地遷移數據。數據遷移、代碼修改的成本過高，還要收到一些服務商規定的單個鍵值對數據大小不能超過多少、數據導出單個文件大小不能超過多少，使用了，就等於被綁架了。當你準備遷移時，發現不能停服務、數據量太大導入導出速度慢、數據一致性問題受影響，你會發現，早知如此，何須當初。

　　二、因此，對於 NoSQL 來講，本着使用軟件，而不使用服務的原則。尋找開源、免費、付費 NoSQL 軟件，安裝在本身的 VPS 上，作到多機備份，要好得多。如今的 NoSQL 已經超越了單純的 Key-Value，對於 List、結構化存儲的支持，已經能夠取代 MySQL 的大部分功能。

　　三、對於咱們團隊來講，NoSQL（自行開發的BigSea數據庫） 與 MySQL 在業務中的使用比例爲 80% 比 20%，MySQL 主要用於給內部編輯、銷售人員使用的後臺管理系統。而對於APP、網站流量，95% 的數據庫訪問爲 NoSQL，5% 爲 MySQL。

　　四、若是用 MySQL 數據庫，一條聯合查詢的SQL，也許就能夠處理完業務邏輯，可是，遇到大量併發請求，就歇菜了。若是用 NoSQL 數據庫，也許須要十次查詢，才能處理完一樣地業務邏輯，但每次查詢都比 MySQL 要快，十次循環NoSQL查詢也許比一次MySQL聯合查詢更快，應對幾萬次/秒的查詢徹底沒問題。PHP 從 5.3 版本開始，已經能夠真正地支持多線程。若是加上PHP多線程，經過十個線程同時查詢NoSQL，返回結果彙總輸出，速度就要更快了。關於 PHP 多線程的使用，我接下來會再寫篇文章細說。

---

　　6、防DDOS、CC、Web注入攻擊

　　一、世界上總會有人看你不爽，因而就想着利用不對稱的服務器、帶寬資源，DDOS、CC攻擊你。在雲計算時代以前，小規模的攻擊能夠依靠iptable，大規模的攻擊只能依靠昂貴的專業防火牆了。在雲計算時代，可使用一些專業的防DDOS、CC攻擊服務商，好比：與騰訊雲合做的安全寶、跟百度合做的加速樂。

　　二、使用這類服務，有一點須要注意，對於域名的@記錄，CNAME別名記錄和MX郵件記錄會衝突，若是將@記錄由A記錄改成CNAME記錄，可能會致使該域名下綁定的企業郵箱服務器收不到郵件。

---

　　7、雲監控　　一、對於一家沒有專門系統運維人員的創業企業來講，可使用第三方雲監控來代替運維人員。使用雲主機，硬件故障找雲計算服務商解決；操做系統故障，雲監控中的服務器監控項目很細，經過故障報警就能夠定位出問題；剩下的就剩下Web程序代碼問題了，使用Nginx+PHP語言運行服務的，將PHP慢日誌打開，若是雲監控報Web服務50二、504錯誤，快速檢測一下PHP慢日誌，看看那個PHP文件的哪行代碼致使的，做爲源頭查下去（好比慢日誌中顯示是MySQL Query查詢的代碼執行慢，則進一步追查可否正常鏈接MySQL服務器，沒問題則再追查MySQL自身的問題），一步步快速去解決。　　二、用過阿里雲監控、盛大雲監控、監控寶，功能截然不同。誰的免費版本功能越多、贈送的免費短信通知越多（對於故障的第一時間告知，相比郵件監控通知、手機APP監控通知，短信的延遲速度是最小的），就用誰的。