Java高可用集羣架構與微服務架構簡單分析

前言

可能大部分讀者都在想，爲何在這以 dubbo、spring cloud 爲表明的微服務時代，我要還要整理這種已經「過期」高可用集羣架構？

本人工做上大部分團隊都是7-15人編制的開發團隊，對應的公司項目也大都是中小型項目，最大的項目 PV/UV 也就只有 10w/2w 。在這樣的場景下，中小型公司通常都是創業起步沒多久，大部分都須要本着「開源節流」、「以最小的成本把產出最大化」。微服務架構相比於高可用集羣架構，我的理解，對於技術團隊的成員編制相對要多一點，服務器部署成本相對也要高一點。

做爲技術團隊負責人，確定要爲企業總體成本考慮，不然要不了多久，即是討薪大軍的一員了吧。。。

1、如何選擇

一、高可用集羣

適用於中小型創業公司項目架構，小型技術團隊快速迭代版本發佈部署需求，前期低成本運行，爆發時可經過投入適量成本橫向擴容服務器抗壓。

特色：

• 前期技術開發成本低
• 必定的服務器擴容成本
• 核心團隊編制及技能要求較少
• 項目發佈部署基本無依賴，時間成本低
• 服務器運維成本通常
• 大而全的項目模塊分離設計
• 更省更穩的技術架構選擇
• 微服務架構強迫症不適用

二、微服務架構

適用於業務架構較大的中大型科技公司項目架構，系統可拆分多個項目單獨運營，大型技術團隊、平臺產品規範化管理，前期投入必定的成本，能夠低成本擴容指定服務的服務器抗壓。

• 前期必定的技術開發成本
• 較低的服務器擴容成本
• 核心團隊編制及技能要求較高
• 項目發佈部署存在依賴，逐個部署，時間成本較高
• 服務器運維成本通常或較高
• 較清晰的項目模塊分離設計
• 更潮更時尚的技術架構選擇

2、高可用集羣架構

一、必備服務器清單

• 負載均衡服務器
• web項目服務器
• 緩存服務器
• 數據庫服務器（主備）

注意：可能有人會問，如果小型項目單機服務，負載均衡是否就不須要？負載均衡主要工做是分發請求到源服務器，另外一個做用也是爲了保護源服務器，不暴露服務器真實IP，大幅度下降服務器被DDoS襲擊的風險

二、擴展服務器清單

• 更多web項目服務器（集羣負載）
• 異步服務服務器（配置中心、消息隊列、job任務等）
• 數據庫服務器（讀寫分離、主從複製）
• 文件服務器

二、架構圖

3、微服務架構

一、服務器清單

• dubbo / spring cloud 全家桶組件服務器
• 負載均衡服務器
• A模塊 web項目服務器
• B模塊 web項目服務器
• C模塊 web項目服務器
• XXX模塊 web項目服務器
• 緩存服務器
• 數據庫服務器
• 文件服務器
• 異步服務服務器（配置中心、消息隊列、job任務等）

二、架構圖

注：圖片來源 http://yun.itheima.com/open/217.html

4、總結

綜上，咱們對於高可用集羣和微服務架構作了簡單的場景和架構圖分析，並非說什麼場景下必定要用什麼架構，也不是說什麼最潮流就用什麼架構，而是根據實際成本和產出做爲出發點作選擇。

創業公司剛起步，資金可能也就百來萬，搞微服務架構，光技術團隊和服務器一個月的成本就佔了公司一大頭，產品還沒上線，公司就已經倒閉了；

有資源的公司，動不動就能得到千萬級甚至更高級別的融資，業務方向衆多，若還只是用高可用架構，全部的業務模塊都臃腫在一個項目裏，不管是代碼管理仍是人員管理上，都是巨大的資源消耗。