移動互聯網初創團隊服務選擇對于創業型團隊來說，服務器托管費用+帶寬成費用+運維成本，是壓在頭上的三座大山。滿足業務性能需要，又要降低成本，盡快實現收支平衡，是當務之急。
一、不靠譜的 App Engine
1. Google App Engine 云服務在國外的成功，不代表國內巨頭們各種 *AE 仿造品的成功。在微博上搜搜就可以看到小伙伴們吐槽的各種不穩定，另外，*AE們對資源使用最大數各種規定限制，加上為了計費、閹割功能的各種限制，使它的價格優勢成為雞肋。*AE們就好比100M共享帶寬的小區寬帶，以低價賣給每個上網用戶5M的帶寬，前幾十個用戶感覺這網速真不錯，等他賣了100個以上用戶5M帶寬，而這部分用戶白天上班去了，晚上下班回來都在上網，其中又有一部分看視頻、BT下載，于是乎，白天網速快，晚上慢得要死，連200K帶寬都達不到。要知道，不怕神一樣的對手，就怕豬一樣的隊友，在國內的 App Engine 環境下，水平參差不齊的開發者的代碼質量、習慣性的資源濫用、別人網站被攻擊殃及池魚對*AE性能的影響，導致*AE的穩定性非常差。
2. 所以，*AE們也意識到公共 App Engine 不穩定，所以又推出專用 App Engine，但費用一下就翻了很多倍。所以，*AE只是個人博客、個人開發者玩玩的工具，真正用作項目，還是需謹慎。根據實際的經驗，*AE們還真不如VPS穩定。
二、成本低的小而美VPS
1. 對于初創團隊來說，購買服務器、交換機，托管服務器費用、帶寬月使用費，是極其昂貴的。購買可以彈性升級硬件配置的云服務VPS，是降低成本不錯的選擇。國內VPS，1G內存、1~2核CPU、1M帶寬、多線BGP，大概價格在100元/月左右，支持備案，可以作為最低入門選擇，有條件可以購買兩臺互為熱備，阿里云主機可以作為參考。大多數VPS服務商使用的都是廉價的SATA磁盤。如果你對磁盤IO要求較高，可以選擇提供有SAS磁盤的IAAS云主機服務商，比如UCloud。
2. 市場上的VPS商家主要有 Xen、OpenVZ、KVM 三種開源的虛擬化技術。全虛擬化的 Xen 更像獨立主機，服務器資源按VPS實際大小平均分配，一般無法超售。半虛擬化的 OpenVZ 在同樣的性能測試下，會比 Xen 高一些，但是，一臺物理內存16G的服務器，可以分配出總內存大小超過16G很多倍的VPS，服務商可以超售，想賣多少臺VPS就可以賣多少臺，所以不推薦使用。KVM 在最新的 Linux 發行版中，已經是集成，但是，商業化應用還不成熟，基于 KVM 的 VPS 服務商很少。
3. VPS的操作系統，建議選擇64位的Linux。在32位Linux下，PHP能給處理的整數不能超過正負2^31=2147483648，如果以后接入新浪微博、淘寶、騰訊等第三方開放平臺，他們的接口里會有超過32位的整數（比如新浪用戶ID、淘寶商品ID）。如果不幸使用32位Linux，你只能將這些整數當成字符串處理了，以后配合Sphinx等搜索引擎，會非常麻煩。
4. 現在，可以在北京進行備案的域名有：國際域名 .com .net .org，國內域名 .cn .com.cn .中國，國別域名 .cc，其他的域名均不能進行備案。僅北京有限制，其它省市正常提交備案即可。我們原來申請的 .me 域名，在北京無法備案，后來只好拿到蘇州去備案了。所以，在選擇域名的時候，需要慎重。
5. 使用 VPS，一定要定期在本地，做好數據備份，不要相信所謂的 7*24服務，99.99%安全穩定性，只要有人的VPS出問題了，都歸為那 0.01%。
三、應對峰值帶寬的云存儲
1. 對于DAU（日活躍用戶）過十萬的網站、APP應用來說，CDN或云存儲是必需品。使用云存儲不是因為存儲空間，因為一塊幾TB的SATA磁盤很便宜，使用云存儲是因為高出平均帶寬值幾倍至幾十倍的峰值帶寬。做手機APP應用，峰值帶寬更集中，當你向所有用戶群發PUSH一條消息，用戶被喚醒打開APP應用，幾分鐘的時間，會消耗幾十倍的帶寬峰值。圖片、下載，是最主要的帶寬消耗者。也許，數據接口API只需不到1M的帶寬，而圖片對帶寬的峰值需求則會達到100M。為了幾分鐘的峰值，去購買100M昂貴的帶寬，其他時間帶寬都空閑，是一件非常奢侈的事。
2. 國內提供云存儲服務的商家有很多，真正好用得卻不多，提供FTP等公共通用協議的云存儲更是微乎其微。使用第三方云服務，切忌千萬不要吊死在一棵樹上。支持FTP等公共協議，如果將來有問題，能夠方便的進行數據遷移和技術替代。如果云服務廠商一直能夠提供優質的服務，那么，也就可以長期使用他們的云服務。相信優秀的云存儲提供商，是不會懼怕這一點的。
3. 之前，我用過阿里云的開放存儲服務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 )：
4. 后來，本博客的圖片、附件下載，改用了 又拍云存儲。相比于其他的云存儲，又拍云支持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.s135.com; access_log off; location / { proxy_cache_valid 200 600s; expires 600s; proxy_pass <a href="http://view_store_server_pool;">http://view_store_server_pool;</a> } location ~ /resize_width/(d+)/(.*) { set $width ; rewrite ^/resize_width/(d+)/(.*) / 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 <a href="http://view_store_server_pool;">http://view_store_server_pool;</a> } location ~ /resize_height/(d+)/(.*) { set $height ; rewrite ^/resize_height/(d+)/(.*) / 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 <a href="http://view_store_server_pool;">http://view_store_server_pool;</a> } } ......
(2)又拍云存儲支持 Token 防盜鏈。對于圖片類防盜鏈來說，判斷域名、Reffer就夠了。但是對于軟件下載等防盜鏈來說，Reffer等信息都可以偽造，比較靠譜的方法，還是Token防盜鏈。
四、可選的關系型數據庫服務（即 MySQL 服務）
1. 資源消耗的大戶在于 MySQL，影響整體性能的因素也在于 MySQL。對于創業型團隊來說，不要過度依賴 MySQL，不要將高并發業務邏輯都用 MySQL 來處理。在 MySQL 前加個 Memcached 做 SQL 查詢緩存，跟 MySQL 的 Query Cache 區別不大，治標不治本，命中率不高，還降低了實時性。現在的移動應用，交互性比較強，實時性要求非常高，Web 時代緩存幾分鐘的老方法，已經不能適合移動互聯網時代的需求。因此，MySQL 只適合存儲一些并發查詢量不大的核心數據，或作為數據的備份，只寫入不查詢。我遇到過很多創業團隊，用戶飛速增長時，最后都是被 MySQL 數據庫的性能瓶頸蹩了腳，最后不得不減緩產品功能開發的腳步，來做性能調優，失去了與競爭者、模仿者、山寨大王騰訊的競爭優勢。創業團隊靠什么和大公司競爭，靠得就是靈活與速度，跑贏大公司。
2. 在不依賴 MySQL 的條件下，那么，最低配的關系型數據庫服務（比如阿里云的最低配內存 240M、磁盤IOPS 150、最大連接數 60，70元/月），就能適合自己的需求了，不然，勉強滿足一般業務配置的關系型數據庫服務的費用，就得 700~3000 元/月了。
3. 如果購買最低配的關系型數據庫服務，還不如省掉 70元/月的費用，在自己 1GB 以上內存的 VPS 上，自己搭建一個 MySQL 數據庫，磁盤IOPS、最大連接數、存儲空間還不受限制。自己做好 MySQL 的主主、主從同步備份，定時dump備份就可以了。需要注意的是，很多VPS默認沒有開啟sawp，使用 MySQL 請一定記得開啟。
4. 如果說 VPS 云服務是必選項的話，關系型數據庫服務則是可選項。
五、結構化存儲 NoSQL 數據庫
1. 既然不依賴 MySQL 數據庫，那么，對于高并發訪問，就需要依賴結構化存儲 NoSQL 數據庫了。雖然一些云計算服務商，也提供了結構化存儲服務，但是，不推薦使用。因為他們使用的都是私有協議，你無法在他們的服務質量、穩定性變差了，價格變貴了，或出現別的更好服務商時，快捷地遷移數據。數據遷移、代碼修改的成本太高，還要收到一些服務商規定的單個鍵值對數據大小不能超過多少、數據導出單個文件大小不能超過多少，使用了，就等于被綁架了。當你準備遷移時，發現不能停服務、數據量太大導入導出速度慢、數據一致性問題受影響，你會發現，早知如此，何必當初。
2. 所以，對于 NoSQL 來說，本著使用軟件，而不使用服務的原則。尋找開源、免費、付費 NoSQL 軟件，安裝在自己的 VPS 上，做到多機備份，要好得多。現在的 NoSQL 已經超越了單純的 Key-Value，對于 List、結構化存儲的支持，已經可以取代 MySQL 的大部分功能。
3. 對于我們團隊來說，NoSQL（自行開發的BigSea數據庫） 與 MySQL 在業務中的使用比例為 80% 比 20%，MySQL 主要用于給內部編輯、銷售人員使用的后臺管理系統。而對于APP、網站流量，95% 的數據庫訪問為 NoSQL，5% 為 MySQL。
4. 如果用 MySQL 數據庫，一條聯合查詢的SQL，也許就可以處理完業務邏輯，但是，遇到大量并發請求，就歇菜了。如果用 NoSQL 數據庫，也許需要十次查詢，才能處理完同樣地業務邏輯，但每次查詢都比 MySQL 要快，十次循環NoSQL查詢也許比一次MySQL聯合查詢更快，應對幾萬次/秒的查詢完全沒問題。PHP 從 5.3 版本開始，已經可以真正地支持多線程。如果加上PHP多線程，通過十個線程同時查詢NoSQL，返回結果匯總輸出，速度就要更快了。關于 PHP 多線程的使用，我接下來會再寫篇文章細說。
六、防DDOS、CC、Web注入攻擊
1. 世界上總會有人看你不爽，于是就想著利用不對稱的服務器、帶寬資源，DDOS、CC攻擊你。在云計算時代之前，小規模的攻擊可以依靠iptable，大規模的攻擊只能依靠昂貴的專業防火墻了。在云計算時代，可以使用一些專業的防DDOS、CC攻擊服務商，比如：與騰訊云合作的安全寶、跟百度合作的加速樂。
2. 使用這類服務，有一點需要注意，對于域名的@記錄，CNAME別名記錄和MX郵件記錄會沖突，如果將@記錄由A記錄改為CNAME記錄，可能會導致該域名下綁定的企業郵箱服務器收不到郵件。
七、云監控
1. 對于一家沒有專門系統運維人員的創業企業來說，可以使用第三方云監控來代替運維人員。使用云主機，硬件故障找云計算服務商解決；操作系統故障，云監控中的服務器監控項目很細，通過故障報警就可以定位出問題；剩下的就剩下Web程序代碼問題了，使用Nginx+PHP語言運行服務的，將PHP慢日志打開，如果云監控報Web服務502、504錯誤，快速檢測一下PHP慢日志，看看那個PHP文件的哪行代碼導致的，作為源頭查下去（比如慢日志中顯示是MySQL Query查詢的代碼執行慢，則進一步追查能否正常連接MySQL服務器，沒問題則再追查MySQL自身的問題），一步步快速去解決。
2. 用過阿里云監控、盛大云監控、監控寶，功能大相徑庭。誰的免費版本功能越多、贈送的免費短信通知越多（對于故障的第一時間告知，相比郵件監控通知、手機APP監控通知，短信的延遲速度是最小的），就用誰的。
京公網安備 11010502049343號