參考：創業公司搭建自己的技術架構

2020 年 2 月 21 日
筆記

閱讀本文大概需要 2.8 分鐘。

作者：huojg

cnblogs.com/huojg-21442/articles/8194348.html

其實這裡面主要給大家說的是技術選型。

由於我中型互聯網公司工作，針對用於手機APP或者pc的後台開發，基本可以支撐幾萬用戶。本文會對可能用到的相關技術進行技術選型的說明，以及技術的架構介紹

技術指標

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

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.

建議：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, 分片，集群，主從等等，很麻煩。建議直接用阿里的

也可以用來處理分散式的數據共享session的工具、

資料庫

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

DRDS 要花錢，成本較高，沒有必要
自建，不用中間件，直接1寫2隻讀，然後配置讀寫分離的數據源，內網SLB進行讀集群。解決之。

搜索

apache solr 搜索引擎。相比其他用起來還可以。

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

程式碼管理工具

Jenkins 與 Sonar 集成是程式碼管理工具重要體現。

apache中sonar程式碼管理。是我們優化方案找出程式碼不規格的重要工具、Jenkins是我們打包發布重要工具。

一些典型的業務場景說明

把業務底層做成SOA模組，通過分散式調用框架對外提供服務。

後期進行SOA到微服務的改造都會涉及。單獨做一個小的系統來運行定時任務熱點數據放快取，然後通過MQ來更新快取日誌等數據有必要可以考慮上個Mongo。