序
可能大部分讀者都在想,為什么在這以 dubbo、spring cloud 為代表的微服務(wù)時(shí)代,我要還要整理這種已經(jīng)“過(guò)時(shí)”高可用集群架構(gòu)?
本人工作上大部分團(tuán)隊(duì)都是7-15人編制的開(kāi)發(fā)團(tuán)隊(duì),對(duì)應(yīng)的公司項(xiàng)目也大都是中小型項(xiàng)目,最大的項(xiàng)目 PV/UV 也就只有 10w/2w 。在這樣的場(chǎng)景下,中小型公司一般都是創(chuàng)業(yè)起步?jīng)]多久,大部分都需要本著“開(kāi)源節(jié)流”、“以最小的成本把產(chǎn)出最大化”。微服務(wù)架構(gòu)相比于高可用集群架構(gòu),個(gè)人理解,對(duì)于技術(shù)團(tuán)隊(duì)的成員編制相對(duì)要多一點(diǎn),服務(wù)器部署成本相對(duì)也要高一點(diǎn)。
作為技術(shù)團(tuán)隊(duì)負(fù)責(zé)人,肯定要為企業(yè)整體成本考慮,否則要不了多久,便是討薪大軍的一員了吧。。。
一、如何選擇
1、高可用集群
適用于中小型創(chuàng)業(yè)公司項(xiàng)目架構(gòu),小型技術(shù)團(tuán)隊(duì)快速迭代版本發(fā)布部署需求,前期低成本運(yùn)行,爆發(fā)時(shí)可通過(guò)投入適量成本橫向擴(kuò)容服務(wù)器抗壓。
特點(diǎn):
前期技術(shù)開(kāi)發(fā)成本低
一定的服務(wù)器擴(kuò)容成本
核心團(tuán)隊(duì)編制及技能要求較少
項(xiàng)目發(fā)布部署基本無(wú)依賴(lài),時(shí)間成本低
服務(wù)器運(yùn)維成本一般
大而全的項(xiàng)目模塊分離設(shè)計(jì)
更省更穩(wěn)的技術(shù)架構(gòu)選擇
微服務(wù)架構(gòu)強(qiáng)迫癥不適用
2、微服務(wù)架構(gòu)
適用于業(yè)務(wù)架構(gòu)較大的中大型科技公司項(xiàng)目架構(gòu),系統(tǒng)可拆分多個(gè)項(xiàng)目單獨(dú)運(yùn)營(yíng),大型技術(shù)團(tuán)隊(duì)、平臺(tái)產(chǎn)品規(guī)范化管理,前期投入一定的成本,可以低成本擴(kuò)容指定服務(wù)的服務(wù)器抗壓。
前期一定的技術(shù)開(kāi)發(fā)成本
較低的服務(wù)器擴(kuò)容成本
核心團(tuán)隊(duì)編制及技能要求較高
項(xiàng)目發(fā)布部署存在依賴(lài),逐個(gè)部署,時(shí)間成本較高
服務(wù)器運(yùn)維成本一般或較高
較清晰的項(xiàng)目模塊分離設(shè)計(jì)
更潮更時(shí)尚的技術(shù)架構(gòu)選擇
二、高可用集群架構(gòu)
1、必備服務(wù)器清單
負(fù)載均衡服務(wù)器
web項(xiàng)目服務(wù)器
緩存服務(wù)器
數(shù)據(jù)庫(kù)服務(wù)器(主備)
注意:可能有人會(huì)問(wèn),若是小型項(xiàng)目單機(jī)服務(wù),負(fù)載均衡是否就不需要?負(fù)載均衡主要工作是分發(fā)請(qǐng)求到源服務(wù)器,另一個(gè)作用也是為了保護(hù)源服務(wù)器,不暴露服務(wù)器真實(shí)IP,大幅度降低服務(wù)器被DDoS攻擊的風(fēng)險(xiǎn),可參考《被人DDoS攻擊了,分析一下原理和防護(hù)》 一文。
2、擴(kuò)展服務(wù)器清單
更多web項(xiàng)目服務(wù)器(集群負(fù)載)
異步服務(wù)服務(wù)器(配置中心、消息隊(duì)列、job任務(wù)等)
數(shù)據(jù)庫(kù)服務(wù)器(讀寫(xiě)分離、主從復(fù)制)
文件服務(wù)器
2、架構(gòu)圖
三、微服務(wù)架構(gòu)
1、服務(wù)器清單
dubbo / spring cloud 全家桶組件服務(wù)器
負(fù)載均衡服務(wù)器
A模塊 web項(xiàng)目服務(wù)器
B模塊 web項(xiàng)目服務(wù)器
C模塊 web項(xiàng)目服務(wù)器
XXX模塊 web項(xiàng)目服務(wù)器
緩存服務(wù)器
數(shù)據(jù)庫(kù)服務(wù)器
文件服務(wù)器
異步服務(wù)服務(wù)器(配置中心、消息隊(duì)列、job任務(wù)等)
2、架構(gòu)圖
四、總結(jié)
綜上,我們對(duì)于高可用集群和微服務(wù)架構(gòu)做了簡(jiǎn)單的場(chǎng)景和架構(gòu)圖分析,并不是說(shuō)什么場(chǎng)景下一定要用什么架構(gòu),也不是說(shuō)什么最潮流就用什么架構(gòu),而是根據(jù)實(shí)際成本和產(chǎn)出作為出發(fā)點(diǎn)做選擇。
創(chuàng)業(yè)公司剛起步,資金可能也就百來(lái)萬(wàn),搞微服務(wù)架構(gòu),光技術(shù)團(tuán)隊(duì)和服務(wù)器一個(gè)月的成本就占了公司一大頭,產(chǎn)品還沒(méi)上線(xiàn),公司就已經(jīng)倒閉了;
有資源的公司,動(dòng)不動(dòng)就能獲得千萬(wàn)級(jí)甚至更高級(jí)別的融資,業(yè)務(wù)方向眾多,若還只是用高可用架構(gòu),所有的業(yè)務(wù)模塊都臃腫在一個(gè)項(xiàng)目里,不論是代碼管理還是人員管理上,都是巨大的資源消耗。
-
JAVA
+關(guān)注
關(guān)注
19文章
2975瀏覽量
105154 -
集群
+關(guān)注
關(guān)注
0文章
88瀏覽量
17209
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
微服務(wù)容器化部署好處多嗎?
云服務(wù)器 Flexus X 實(shí)例,Docker 集成搭建 Redis 集群
![云<b class='flag-5'>服務(wù)</b>器 Flexus X 實(shí)例,Docker 集成搭建 Redis <b class='flag-5'>集群</b>](https://file1.elecfans.com//web3/M00/05/BF/wKgZPGeEpoGAYOG4AAC1_vyawpY390.png)
容器化能替代微服務(wù)嗎??jī)烧哂泻螀^(qū)別
Java微服務(wù)中如何確保安全性?
寶藏級(jí)微服務(wù)架構(gòu)工具合集
確保網(wǎng)站無(wú)縫運(yùn)行:Keepalived高可用與Nginx集成實(shí)戰(zhàn)
![確保網(wǎng)站無(wú)縫運(yùn)行:Keepalived<b class='flag-5'>高</b><b class='flag-5'>可用</b>與Nginx集成實(shí)戰(zhàn)](https://file1.elecfans.com/web3/M00/00/12/wKgZO2dGcZOAFKfHAABeakMUbaM263.png)
k8s微服務(wù)架構(gòu)就是云原生嗎??jī)烧呤鞘裁搓P(guān)系
SSR與微服務(wù)架構(gòu)的結(jié)合應(yīng)用
架構(gòu)與設(shè)計(jì) 常見(jiàn)微服務(wù)分層架構(gòu)的區(qū)別和落地實(shí)踐
![<b class='flag-5'>架構(gòu)</b>與設(shè)計(jì) 常見(jiàn)<b class='flag-5'>微服務(wù)</b>分層<b class='flag-5'>架構(gòu)</b>的區(qū)別和落地實(shí)踐](https://file1.elecfans.com//web1/M00/F3/6F/wKgaoWcXVYOABfykAACXUPb6uWA473.png)
微服務(wù)架構(gòu)與容器云的關(guān)系與區(qū)別
入門(mén)級(jí)攻略:如何容器化部署微服務(wù)?
Proxyless的多活流量和微服務(wù)治理
![Proxyless的多活流量和<b class='flag-5'>微服務(wù)</b>治理](https://file1.elecfans.com//web2/M00/04/79/wKgZombO5bOALV66AABWmg83ey8199.jpg)
服務(wù)器集群中 IP 地址管理混亂
采用OpenUSD和NVIDIA NIM微服務(wù)創(chuàng)建精準(zhǔn)品牌視覺(jué)
K8S學(xué)習(xí)教程(二):在 PetaExpress KubeSphere容器平臺(tái)部署高可用 Redis 集群
![K8S學(xué)習(xí)教程(二):在 PetaExpress KubeSphere容器平臺(tái)部署<b class='flag-5'>高</b><b class='flag-5'>可用</b> Redis <b class='flag-5'>集群</b>](https://file1.elecfans.com/web2/M00/F7/94/wKgZomaE_LWAIzZtAACo5pTAtaY093.png)
評(píng)論