一济瓢、概述
每個技術的產生沒有更好更壞之分,只是適用于不同的場景罷了棵帽。
二熄求、單體架構(單一應用架構)
2.1、單體架構概念
將所有的業(yè)務場景的表示層逗概,業(yè)務邏輯層和數據訪問層打包放在一個工程中弟晚,最終經過編譯打包,部署在一臺服務器上仗谆。例如:典型的J2EE工程指巡,把jsp,業(yè)務邏輯層的service,controller和數據訪問層的dao,打包成wa包,部署在Tomcat或者Jetty或者其他容器上運行隶垮。
問題:數據庫和應用程序部署到不同的服務器是單體架構嗎藻雪?
單體架構關心的是否是整個應用部署同一個包,如果是則為單體架構狸吞,否則就不是勉耀。
2.2、單體架構應用場景及特點
業(yè)務場景簡單,功能不復雜蹋偏,研發(fā)人員較少便斥。
公司處于創(chuàng)業(yè)初期:為了生存,需要的是快速開發(fā)出功能威始,然后到市場上試錯枢纠。
性能要求及其苛刻:一些對性能要求比較高的系統(tǒng),例如股票軟件黎棠。
需求比較穩(wěn)定的系統(tǒng)也不適合做成微服務晋渺,例如:公司內部OA镰绎,考勤系統(tǒng)等。
比如簡單的網上超市木西,網站 頁面包括 用戶注冊畴栖、登錄功能、商品展示八千、下單吗讶。管理后臺包括用戶管理、商品管理恋捆、訂單管理照皆。需要快速開發(fā)出功能,發(fā)布到市場上鸠信,這種就直接使用單體架構即可纵寝。
傳統(tǒng)架構其實就是SSH或者SSM,屬于單點應用星立,把整個業(yè)務模塊都在一個項目進行開發(fā)爽茴,分為MVC架構,會拆分成controller,service,dao層绰垂。
部署的時候首先所有功能集中在一個項目中打war包部署室奏,通過集群(session共享集群)來提高服務器的性能。war包劲装,圖片服務器整合到war包胧沫,放到同一臺服務器。
2.3占业、單體架構的優(yōu)缺點?
優(yōu)點:
部署簡單 :由于是完整的結構體绒怨,可以直接部署在一份服務器上即可;
技術單一 :項目不需要復雜的技術棧谦疾,往往一套熟悉的技術棧就可以完成開發(fā)南蹂,前期開發(fā)的成本低,周期短,小型企業(yè)首選;
用人成本低 :單個程序員可以完成業(yè)務接口到數據庫的整個流程念恍。
缺點:
業(yè)務越來越復雜六剥,單體架構擴展性不足,業(yè)務擴展帶來的代價越來越大峰伙;
用戶越來越多疗疟,程序承受的并發(fā)越來越高,單體應用的并發(fā)能力有限瞳氓;
單體應用的業(yè)務都在同一個程序中策彤,增刪改業(yè)務修改,也會影響其他代碼,給測試增加了難度店诗。
阻礙技術創(chuàng)新
單體應用往往使用統(tǒng)一的技術平臺或方案解決所有的問題叽赊,團隊中的每個成 員都必須使用相同的開發(fā)語言和框架,要想引人新框架或新技術平臺會非常 困難必搞。例如,一個使用 Struts 2構建的囊咏、有100萬行代碼的單體應用恕洲,如 果想要換用 Spring MVC ,毫無疑問切換的成本是非常高的梅割。
2.4霜第、單體架構的后階段
分層開發(fā)
分層的開發(fā)的目的:
為了解決容錯性差,比如用戶查詢數據導致sql異常户辞,會導致整個頁面無法訪問泌类,從而導致整個服務器的宕機,此時底燎,我們可以使用分層開發(fā)刃榨,每一個如果發(fā)生錯誤的話,在上一層可以進行異常捕獲双仍,這個錯誤就可以不讓用戶看到枢希。
分層的開發(fā)的好處:提高系統(tǒng)的維護性,解決容錯性問題朱沃,后面就總結出MVC設計模式(MVC架構解決方案)苞轿。分層開發(fā),還可以把服務器分離部署(把數據庫和應用程序分開部署)逗物。
特點和好處:
MVC分層開發(fā)能夠解決基本的容錯性問題搬卒,數據庫和項目部署分離。但是隨著互聯網的開發(fā)翎卓,網站的訪問量的持續(xù)增加契邀,單臺的應用服務器已經無法滿足用戶的需求。
2.5莲祸、單體架構提高并發(fā)訪問量
服務器集群:就是服務器集群就是指將很多服務器集中起來一起進行同一種服務蹂安,在客戶端看來就像是只有一個服務器。集群可以利用多個計算機進行并行計算從而獲得很高的計算速度锐帜,也可以用多個計算機做備份田盈,從而使得任何一個機器壞了整個系統(tǒng)還是能正常運行。
隨著業(yè)務的擴展缴阎,大部分公司會將單體應用進行集群式部署允瞧,并增加負載均衡器,還需要增加集群部署的緩存服務器和文件服務器,并將數據庫讀寫分離述暂,以應對用戶量的增加帶來的高并發(fā)訪問量痹升。
2.6、單體架構使用服務器集群及存在的不足
代碼可讀性畦韭,可維護性差疼蛾;
面對海量用戶,數據庫會成為瓶頸艺配,需要使用分庫分表察郁;
持續(xù)交付能力差,業(yè)務越復雜转唉,代碼越多熟悉成本高皮钠。
三、垂直架構
3.1赠法、垂直架構概念
訪問量逐漸增大麦轰,單體架構單加集群節(jié)點帶來服務器性能越來越小。比如有的模塊是計算密集型的砖织,它需要強勁的 CPU ;有的模塊則是 IO 密集型的款侵,需要更大的內存。由于這些模塊部署在一起侧纯,不得不在硬件 的選擇上做出妥協(xié)喳坠。因此我們通常需要將應用拆成互不相干的幾個應用,這就稱之為垂直架構?茂蚓。
3.2壕鹉、垂直架構的優(yōu)缺點
優(yōu)點:
系統(tǒng)拆分實現了流量分擔,解決了并發(fā)問題
可以針對不同模塊進行優(yōu)化
方便水平擴展聋涨,負載均衡晾浴,容錯率提高
系統(tǒng)間相互獨立
缺點:
服務之間相互調用,如果某個服務的端口或者ip地址發(fā)生改變牍白,調用的系統(tǒng)得手動改變
搭建集群之后脊凰,實現負載均衡比較復雜
會員項目、訂單項目茂腥、支付項目狸涌、優(yōu)惠券等。項目與項目之間進行webservice最岗、RPC遠程通信等帕胆。每個項目中都有自己獨立的數據庫(redis等),
分布式架構拆分
會員:登錄般渡、注冊懒豹、修改密碼芙盘。
訂單:下單,查詢訂單脸秽。
3.1儒老、分布式架構特點
以單體架構規(guī)模的項目為單位進行垂直劃分項目,即將一個大項目拆分成一個一個單體結構項目记餐。
項目與項目之間的存在數據冗余驮樊,耦合性較大,比如上圖中三個項目都存在客戶信息片酝。
項目之間的接口多為數據同步功能巩剖,如:數據庫之間的數據庫,通過網絡接口進行數據庫同步钠怯。
3.2、分布式架構優(yōu)缺點
優(yōu)點:
項目架構簡單曙聂,前期開發(fā)成本低晦炊,周期短,小型項目的首選宁脊。
通過垂直拆分断国,原來的單體項目不至于無限擴大。
不同的項目可采用不同的技術榆苞。
缺點:
復雜應用的開發(fā)維護成本變高稳衬,部署效率逐漸降低。因為隨著業(yè)務功能的不斷膨脹坐漏,代碼全量編譯和部署一次所需的時間非常長薄疚。
團隊協(xié)作效率差,部分公共功能重復開發(fā)赊琳,代碼重復率居高不下街夭。
系統(tǒng)可靠性變差。垂直架構將所有的應用模塊都部署到一個進程中躏筏,如果某個應用接口發(fā)生故障板丽,例如內存泄漏,會導致整個節(jié)點宕機趁尼。
四埃碱、SOA架構(面向服務架構)
HClient:將共同的業(yè)務邏輯進行拆分,拆分成獨立的項目進行部署酥泞。
服務化:面向業(yè)務邏輯層開發(fā)砚殿。
項目:包含業(yè)務邏輯層和視圖層。服務:只包含業(yè)務邏輯層芝囤,沒有視圖層瓮具。
重點術語剖析:
負載均衡器:分發(fā)高并發(fā)的網絡請求荧飞,用戶的訪問被分派到不同的應用服務器。用戶增加時名党,添加應用服務器即可叹阔。
緩存服務器:緩解數據庫的數據以及數據庫讀取的壓力。
五传睹、微服務架構
5.1耳幢、微服務架構概念
微服務架構:將單體應用拆分為多個高內聚低耦合的小型服務,每個小服務運行在獨立進程欧啤,由不同的團隊開發(fā)和維護睛藻,服務間采用輕量級通信機制,獨立自動部署邢隧,可以采用不同的語言及存儲店印。
單體架構整個團隊維護開發(fā)一個大工程及一個單庫,到了微服務架構倒慧,用戶請求經過API Gateway被路由到下游服務按摘,服務之間以輕量級通信協(xié)議進行通信,服務通過注冊中心發(fā)現彼此纫谅,每個服務都有專門的開發(fā)維護團隊炫贤,每個服務對應獨立的數據庫,服務獨立開發(fā)付秕,獨立部署和上線兰珍。
5.2、微服務架構的特點
將系統(tǒng)服務層完全獨立出來询吴,并將服務層抽取為一個一個的微服務掠河。
微服務遵循單一原則(一個服務做一件事)。
微服務之間采用RESTful等輕量協(xié)議傳輸猛计。
5.3口柳、微服務架構的優(yōu)缺點
優(yōu)點:
服務拆分粒度更細,有利于資源重復利用有滑,提高開發(fā)效率跃闹。
可以更加精準的制定每個服務的優(yōu)化方案,提高系統(tǒng)可維護性毛好。
微服務架構采用去中心化思想望艺,服務之間采用RESTful等輕量協(xié)議通信,相比ESB更輕量肌访。
適用于互聯網時代找默,產品迭代周期更短。
單個微服務啟動較快
技術棧不受限
缺點:
微服務過多吼驶,服務治理成本高惩激,不利于系統(tǒng)維護店煞。
分布式系統(tǒng)開發(fā)的技術成本高(容錯、分布式事務等)风钻,對團隊挑戰(zhàn)大顷蟀。