技術架構的選擇決定公司的格局範圍

適用範圍

本文主要針對中小型互聯網公司，特別適用於手機APP或者pc的後臺架構，基本能夠支撐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, rocketMQ， robbitMQ,Kafka

各有好處， 可是考慮到運維的難度，推薦rocketMQ。

Redis

用來作緩存， 自建成本有點高，須要Codis, 分片，集羣，主從等等，很麻煩。 建議直接用阿里的

數據庫

主要基於讀寫分離和主從複製考慮，目前能夠自建和選用阿里的DRDS。

DRDS 要花錢，成本較高，沒有必要

自建， 不用中間件，直接1寫2只讀， 而後配置讀寫分離的數據源，內網SLB進行讀集羣。解決之。

搜索

建議ELK， 能夠自動同步數據庫，除了搜索引擎的功能外，還能夠作日誌搜索，監控系統。

一些典型的業務場景說明

把業務底層作成SOA模塊，經過分佈式調用框架對外提供服務。

後期進行SOA到微服務的改造都會涉及。

單獨作一個小的系統來運行定時任務

熱點數據放緩存，而後經過MQ來更新緩存

日誌等數據有必要能夠考慮上個Mongo

須要本文中提到的詳細的技術以及技術架構介紹的能夠加羣:650385180，我會把這些詳細資料分享在羣的共享區，有須要的朋友能夠加羣獲取，羣裏也有我和同事們錄製的一些學習視頻，包含Java工程化、高性能及分佈式、高性能、性能調優Spring，MyBatis，Netty源碼分析等知識點的講解。

阿里Java高級架構師免費直播講解知識點，分享知識，多年工做經驗的梳理和總結，帶着你們全面、科學地創建本身的技術體系和技術認知！