序
可能大部分讀者都在想,爲什麼在這以 dubbo、spring cloud 爲代表的微服務時代,我要還要整理這種已經“過時”高可用集羣架構?
本人工作上大部分團隊都是7-15人編制的開發團隊,對應的公司項目也大都是中小型項目,最大的項目 PV/UV 也就只有 10w/2w 。在這樣的場景下,中小型公司一般都是創業起步沒多久,大部分都需要本着“開源節流”、“以最小的成本把產出最大化”。微服務架構相比於高可用集羣架構,個人理解,對於技術團隊的成員編制相對要多一點,服務器部署成本相對也要高一點。
作爲技術團隊負責人,肯定要爲企業整體成本考慮,否則要不了多久,便是討薪大軍的一員了吧。。。
一、如何選擇
1、高可用集羣
適用於中小型創業公司項目架構,小型技術團隊快速迭代版本發佈部署需求,前期低成本運行,爆發時可通過投入適量成本橫向擴容服務器抗壓。
特點:
- 前期技術開發成本低
- 一定的服務器擴容成本
- 核心團隊編制及技能要求較少
- 項目發佈部署基本無依賴,時間成本低
- 服務器運維成本一般
- 大而全的項目模塊分離設計
- 更省更穩的技術架構選擇
- 微服務架構強迫症不適用
2、微服務架構
適用於業務架構較大的中大型科技公司項目架構,系統可拆分多個項目單獨運營,大型技術團隊、平臺產品規範化管理,前期投入一定的成本,可以低成本擴容指定服務的服務器抗壓。
- 前期一定的技術開發成本
- 較低的服務器擴容成本
- 核心團隊編制及技能要求較高
- 項目發佈部署存在依賴,逐個部署,時間成本較高
- 服務器運維成本一般或較高
- 較清晰的項目模塊分離設計
- 更潮更時尚的技術架構選擇
二、高可用集羣架構
1、必備服務器清單
- 負載均衡服務器
- web項目服務器
- 緩存服務器
- 數據庫服務器(主備)
注意:可能有人會問,若是小型項目單機服務,負載均衡是否就不需要?負載均衡主要工作是分發請求到源服務器,另一個作用也是爲了保護源服務器,不暴露服務器真實IP,大幅度降低服務器被DDoS攻擊的風險,可參考《被人DDoS攻擊了,分析一下原理和防護》 一文。
2、擴展服務器清單
- 更多web項目服務器(集羣負載)
- 異步服務服務器(配置中心、消息隊列、job任務等)
- 數據庫服務器(讀寫分離、主從複製)
- 文件服務器
2、架構圖
三、微服務架構
1、服務器清單
- dubbo / spring cloud 全家桶組件服務器
- 負載均衡服務器
- A模塊 web項目服務器
- B模塊 web項目服務器
- C模塊 web項目服務器
- XXX模塊 web項目服務器
- 緩存服務器
- 數據庫服務器
- 文件服務器
- 異步服務服務器(配置中心、消息隊列、job任務等)
2、架構圖
注:圖片來源 http://yun.itheima.com/open/217.html
四、總結
綜上,我們對於高可用集羣和微服務架構做了簡單的場景和架構圖分析,並不是說什麼場景下一定要用什麼架構,也不是說什麼最潮流就用什麼架構,而是根據實際成本和產出作爲出發點做選擇。
創業公司剛起步,資金可能也就百來萬,搞微服務架構,光技術團隊和服務器一個月的成本就佔了公司一大頭,產品還沒上線,公司就已經倒閉了;
有資源的公司,動不動就能獲得千萬級甚至更高級別的融資,業務方向衆多,若還只是用高可用架構,所有的業務模塊都臃腫在一個項目裏,不論是代碼管理還是人員管理上,都是巨大的資源消耗。