適用範圍

本文主要針對小型網際網路公司，特別適用於手機APP的後臺架構，基本可以支撐5萬日活
本文會對可能用到的相關技術進行技術選型的說明，以及相對應的裝置的採購。

技術指標

說一下一些技術指標的計算過程可以作為其他同學的參考

• QPS， 如果是5萬日活，使用集中在每天的4小時，每個使用者大概產生100的請求，那麼平均下來，我們系統大概應該支撐的請求為：50000 * 100 / (4 * 60 * 60) = 350 qps/s
• 業務資料 業務量，我們自己是新聞業務，可能會有其他的業務，比如遊戲，商城等等，基本每天新增的業務資料都會在同一個量級， 每日10000， 另外跟使用者相關的資訊也是比較大的一塊，比如使用者的訂閱等行為，一共5萬的使用者，儲存相關資訊可能大概需要100條的資料。
• 快取大小 主要業務資料和使用者相關的熱點資料限時儲存在快取中， 大概需要5個G左右。
• 日誌大小 使用者日誌和請求日誌。 大概每天3個G左右

技術架構

整體架構因為是小公司，我們基於阿里雲來搭建，對圖中的內容和技術選型進行一下說明：

負載均衡

 可選方案： SLB, Nginx.
 - SLB要收錢，但是比較便宜，有保證，不會掛。 但是可配置的很少，不能根據域名做ip對映
 - Nginx, 沒啥缺點，需要一定的知識。
建議： SLB + Nginx, SLB繫結域名作為統一的入口，然後每個伺服器上再搭建Nginx.

CDN

用於快取靜態檔案等等。 七牛和阿里的都還可以。
- 七牛要做的久一點， 各種圖片處理的介面要完善一些
 
- 阿里的CDN要稍微好一點點， 但是沒有不安全的訪問方式，訪問稍微沒有那麼靈活。 圖片處理功能弱一點。

分散式呼叫框架

目前可選的有ZK + dubbo. ZK + Motan, ZK + dubbox, edas。

• dubbo, 阿里的服務治理框架，已經不維護了，切換反應有點慢
• dubboX, 噹噹基於dubbo搞的，還在維護可以一用，推薦。
• Motan, 微博的服務治理礦建， 剛開源，需要學習一下， 推薦。
• Edas, 阿里雲服務，要收錢，侵入型很強，不推薦

MQ

可選的有： ActiveMQ, 阿里雲訊息， robbitMQ, 
各有好處， 但是考慮到運維的難度，推薦阿里雲訊息。

Redis

用來做快取， 自建成本有點高，需要Codis, 分片，叢集，主從等等，很麻煩。 建議直接用阿里的

資料庫

主要基於讀寫分離和主從複製考慮，目前可以自建和選用阿里的DRDS。
- DRDS 要花錢，成本較高，沒有必要
- 自建，  不用中介軟體，直接1寫2只讀， 然後配置讀寫分離的資料來源，內網SLB進行讀叢集。解決之。

搜尋

建議ELK， 可以自動同步資料庫，除了搜尋引擎的功能外，還可以做日誌搜尋，監控系統。

一些典型的業務場景說明

• 把業務底層做成SOA模組，通過分散式呼叫框架對外提供服務。
• 單獨做一個小的系統來執行定時任務
• 熱點資料放快取，然後通過MQ來更新快取
• 日誌等資料有必要可以考慮上個Mongo