微服務(wù)架構(gòu)演變過程
傳統(tǒng)單體架構(gòu) =》 分布式架構(gòu) =》 soa面向服務(wù)架構(gòu) =》 微服務(wù)架構(gòu)
傳統(tǒng)單體架構(gòu)
傳統(tǒng)單體架構(gòu)就是單點(diǎn)應(yīng)用室囊，也就是在早期開發(fā)學(xué)習(xí)的ssm或ssh整合項目采用分層架構(gòu)模式、數(shù)據(jù)庫訪問層秘噪、業(yè)務(wù)邏輯層狸吞、控制層，從前端到后端所有代碼都是一個人寫的
cn.itycu.controler ---springmvc 視圖層 jsp/ftl
cn.itycu.service ---業(yè)務(wù)邏輯層
cn.itycu.dao ---數(shù)據(jù)庫訪問層
將所有的代碼都放入到同一個項目中指煎，部署在同一個tomcat中
- 該架構(gòu)模式存在的優(yōu)缺點(diǎn)
- 優(yōu)點(diǎn)：開發(fā)簡單蹋偏、運(yùn)維簡單
- 缺點(diǎn)：該架構(gòu)模式?jīng)]有對業(yè)務(wù)邏輯進(jìn)行拆分威始，這樣子耦合度非常高黎棠，只適合小團(tuán)隊或者個人形式開發(fā)镰绎，不適合團(tuán)隊模式協(xié)同工作開發(fā)畴栖，維護(hù)性很難，如果系統(tǒng)中某個模塊出現(xiàn)問題挪挤，會導(dǎo)致整個系統(tǒng)無法使用扛门。
- 應(yīng)用場景：政府項目论寨、管理系統(tǒng)爽茴、crm室奏、oa，適合于小團(tuán)隊或個人進(jìn)行開發(fā)
分布式架構(gòu)
分布式架構(gòu)模式基于傳統(tǒng)的架構(gòu)模式演變過來昌简，將我們傳統(tǒng)的單點(diǎn)系統(tǒng)實(shí)現(xiàn)根據(jù)業(yè)務(wù)拆分。會拆分為會員系統(tǒng)谦疾、訂單系統(tǒng)念恍、支付系統(tǒng)峰伙、秒殺系統(tǒng)等该默。從而降低整個項目的耦合度权均，這種架構(gòu)模式開始慢慢適合于互聯(lián)網(wǎng)公司開發(fā)。
會員系統(tǒng) memner.itycu.cn
支付系統(tǒng) pay.itycu.cn
項目命名為系統(tǒng)意味：包含視圖層和服務(wù)層
soa面向服務(wù)架構(gòu)
sso單點(diǎn)登錄系統(tǒng)恋沃，抽離出通用服務(wù)
soa面向服務(wù)架構(gòu)基于分布式架構(gòu)模式演變過來囊咏，俗稱服務(wù)化梅割，也就是面向于服務(wù)與接口開發(fā)（服務(wù)開發(fā)）户辞，將共同存在的業(yè)務(wù)邏輯抽取成一個公共服務(wù)癞谒，提供給其他接口實(shí)現(xiàn)調(diào)用弹砚，服務(wù)與服務(wù)之間采用rpc遠(yuǎn)程調(diào)用技術(shù)。
- 服務(wù)：只是有接口朱沃、沒有視圖層
cn.itycu.service
cn.itycu.dao
能夠解決我們的代碼冗余性問題
-
soa架構(gòu)模式特點(diǎn)
- soa架構(gòu)模式傳輸協(xié)議采用soap協(xié)議（HTTP/https+xml）實(shí)現(xiàn)傳輸逗物，在高并發(fā)情況下實(shí)現(xiàn)通訊協(xié)議存在大量的冗余性傳輸敬察，而且非常占用帶寬莲祸。所以后來微服務(wù)架構(gòu)中使用json替代了xml锐帜。
- soa架構(gòu)模式實(shí)現(xiàn)方案webservice或者esb企業(yè)服務(wù)總線畜号，底層采用soap傳輸協(xié)議。
- 傳統(tǒng)政府蛮拔、銀行項目還是保留的在使用webservice
- webservice架構(gòu)模式
- wsdl組件表示接口信息建炫、方法疼蛾、調(diào)用地址、參數(shù)
-
soa架構(gòu)模式存在缺點(diǎn)
- 采用soap協(xié)議實(shí)現(xiàn)通訊衍慎，xml傳輸非常重稳捆，效率比較低麦轰。
- 服務(wù)化管理和治理設(shè)施不夠完善
- 依賴于中心服務(wù)發(fā)現(xiàn)機(jī)制
- 不適合前后端分離架構(gòu)模式
- 前后端分離就是對我們控制層和業(yè)務(wù)邏輯實(shí)現(xiàn)區(qū)分，前端控制可以采用vue調(diào)用我們后端接口（http+json）
微服務(wù)架構(gòu)
微服務(wù)架構(gòu)模式基于soa架構(gòu)模式演變過來的驯嘱，比soa架構(gòu)迷失對服務(wù)拆分力度會更加精細(xì)鞠评，采用前后端分離模式讓專業(yè)的人做專業(yè)的事（專注）剃幌，目的可以實(shí)現(xiàn)高效率開發(fā)。微服務(wù)架構(gòu)中负乡，每個服務(wù)之間都是互補(bǔ)影響抖棘，每個服務(wù)必須要獨(dú)立部署、運(yùn)維最岗、互不影響朝捆，微服務(wù)架構(gòu)模式非常輕巧芙盘，輕量級儒老、適合于互聯(lián)網(wǎng)公司開發(fā)模式。
服務(wù)與服務(wù)之間通訊的協(xié)議采用restful形式淘这，數(shù)據(jù)交換格式采用http+json格式實(shí)現(xiàn)傳輸
整個過程中巩剖，采用二進(jìn)制佳魔，所以http協(xié)議可以實(shí)現(xiàn)跨語言的平臺，并且和其他語言實(shí)現(xiàn)通訊宁脊，所以為什么開放都是采用http+json格式傳輸
-
SOA架構(gòu)與微服務(wù)架構(gòu)有哪些區(qū)別
- 通訊協(xié)議
- 微服務(wù)架構(gòu)基于soa架構(gòu)模式演變過來榆苞，繼承了soa架構(gòu)的優(yōu)點(diǎn)坐漏，在微服務(wù)架構(gòu)中去除soa架構(gòu)中soap協(xié)議和esp企業(yè)服務(wù)總線赊琳。改為http+json形式傳輸我們的數(shù)據(jù)。
- esb企業(yè)服務(wù)總線解決多系統(tǒng)間跨語言無法實(shí)現(xiàn)通訊的問題板丽，對我們的數(shù)據(jù)實(shí)現(xiàn)轉(zhuǎn)換埃碱，可以提供可靠的消息傳輸。一般情況我們采用http+json傳輸數(shù)據(jù)，不需要esb對數(shù)據(jù)進(jìn)行轉(zhuǎn)換婶博。
- 微服務(wù)架構(gòu)基于soa架構(gòu)模式演變過來榆苞，繼承了soa架構(gòu)的優(yōu)點(diǎn)坐漏，在微服務(wù)架構(gòu)中去除soa架構(gòu)中soap協(xié)議和esp企業(yè)服務(wù)總線赊琳。改為http+json形式傳輸我們的數(shù)據(jù)。
- 服務(wù)拆分力度
- 微服務(wù)架構(gòu)模式比soa架構(gòu)模式拆分力度更加精細(xì)凡人，提倡讓專業(yè)的人做專業(yè)的事叹阔，目的是實(shí)現(xiàn)高效的開發(fā)，每個服務(wù)與服務(wù)之間互不影響岸晦，每個服務(wù)都是單獨(dú)獨(dú)立數(shù)據(jù)庫睛藻、redis連接、MQ等冈在。并且都是實(shí)現(xiàn)獨(dú)立部署包券，整個微服務(wù)架構(gòu)更加輕量級炫贤。
- 在soa架構(gòu)中兰珍，有可能純在多個服務(wù)共享同一個數(shù)據(jù)庫，但是微服務(wù)架構(gòu)必須強(qiáng)調(diào)每個都是獨(dú)立數(shù)據(jù)庫部署汰寓，互補(bǔ)影響有滑。
- 迭代
- 微服務(wù)架構(gòu)模式比soa架構(gòu)模式毛好，更加適合于互聯(lián)網(wǎng)公司敏捷苛秕、高效、快速迭代版本開發(fā)吼驶，因為力度非常精細(xì)蟹演。
- 通訊協(xié)議
-
微服務(wù)架構(gòu)中可能會存在哪些問題
- 分布式事務(wù)解決方案（rabbitmq酒请、rocketmq事務(wù)消息羞反、lcn（淘汰）苟弛、setata）最終一級概念
- 分布式任務(wù)調(diào)度平臺（xxl-job阁将、alibabacloud scheduler做盅、elastic-job）
- 分布式服務(wù)注冊與發(fā)現(xiàn)（eureka、consul亭敢、zookeeper帅刀、nacos）
- 分布式日志采集系統(tǒng)elk+kafka
- 分布式服務(wù)最綜與調(diào)用鏈系統(tǒng)zipkin
- 分布式服務(wù)配置中心（spring cloud config/攜程阿波羅/nacos/disconfig）
微服務(wù)架構(gòu)中有個非常重要的概念：獨(dú)立部署扣溺、可配置锥余、動態(tài)化驱犹。
為什么要使用到spring cloud
-
spring cloud 并不是一個rpc遠(yuǎn)程調(diào)用框架雄驹，而是一個微服務(wù)全家桶的解決方案的框架。理念就是一條龍服務(wù)解決我們在微服務(wù)架構(gòu)中遇到的問題俘侠。
- 服務(wù)治理：eureka
- 分布式配置：config
- 客戶端調(diào)用工具：rest/feign客戶 rpc遠(yuǎn)程調(diào)用
說明：阿里巴巴兼贡、騰訊娃胆、百度
注意：大家如果去一些比較大型的互聯(lián)網(wǎng)公司中，整個公司內(nèi)部實(shí)現(xiàn)rpc通訊的框架禁谦、服務(wù)幫助治理都是內(nèi)部自己研發(fā)。
rpc遠(yuǎn)程調(diào)用框架：HTTPclent丧蘸、dubbo、feign演训、grpc弟孟、基于netty手寫rpc
spring cloud一代和二代的區(qū)別
- spring cloud第一代實(shí)際上采用Netflix開源的組件整合微服務(wù)解決方案。
- spring cloud第二代實(shí)際上就是自己研發(fā)和國內(nèi)的優(yōu)秀的服務(wù)解決微服務(wù)框架進(jìn)行組合样悟。比如spring cloudali baba
- spring cloud Alibaba實(shí)際上是為了推廣阿里云的產(chǎn)品對我們目前的spring cloud2.x版本實(shí)現(xiàn)擴(kuò)展功能拂募。
nacos實(shí)現(xiàn)服務(wù)注冊于發(fā)現(xiàn)
spring cloud與spring cloud Alibaba的區(qū)別
- spring cloud Alibaba實(shí)際上是為了推廣阿里云的產(chǎn)品對我們目前的spring cloud2.x版本和spring cloud1.x版本實(shí)現(xiàn)組件擴(kuò)展功能庭猩，能夠完美整合到spring cloud開發(fā)的組件。
- nacos分布式注冊中心陈症、分布式配置中心spring cloudEureka+config組合蔼水。
- 如果使用spring cloud Alibaba 建議使用Alibaba整個體系的產(chǎn)品。
微服務(wù)服務(wù)治理核心概念
- Nacos產(chǎn)生背景
- nacos分布式注冊與發(fā)現(xiàn)功能 | 分布式配置中心
- 產(chǎn)生于rpc遠(yuǎn)程調(diào)用中爬凑，服務(wù)的url的治理
- rpc遠(yuǎn)程調(diào)用框架：HTTP client徙缴、grpc、dubbo嘁信、rest于样、openfeign等。
- 傳統(tǒng)rpc遠(yuǎn)程調(diào)用中存在哪些問題？
- 超時贬芥、安全、服務(wù)與服務(wù)之間的url地址管理
- 在我們的微服務(wù)架構(gòu)通訊中，服務(wù)間依賴非常大，如果使用傳統(tǒng)方式管理我們的服務(wù)，非常麻煩雾袱，所以采用url治理技術(shù)妻枕，可以實(shí)現(xiàn)我們整個實(shí)現(xiàn)動態(tài)服務(wù)注冊與發(fā)現(xiàn)蝌数、本地負(fù)載均衡剑梳、容錯等
傳統(tǒng)服務(wù)注冊中心的實(shí)現(xiàn)方式
- 把每個服務(wù)器的地址信息和端口號人工存放到數(shù)據(jù)庫表中
Id service IP 端口號 1 itycu.cn 192.168.1.1 8080 2 itycu.cn 192.168.1.1 8000 - 基于數(shù)據(jù)庫形式實(shí)現(xiàn)服務(wù)url治理的缺點(diǎn)
- 維護(hù)成本高
- 沒有實(shí)現(xiàn)動態(tài)自動化
- 基于數(shù)據(jù)庫形式實(shí)現(xiàn)服務(wù)url治理的缺點(diǎn)
分布式注冊中心實(shí)現(xiàn)原理
-
注冊中心的作用
- 管理整個微服務(wù)url地址
- 可以實(shí)現(xiàn)動態(tài)感知
注冊中心：duboo依賴zookeeper、eureka骂倘、consul情妖、nacos、redis、數(shù)據(jù)庫
nacos與eureka的區(qū)別
eureka與zookeeper的區(qū)別
-
注冊中心的原理
- 服務(wù)注冊：提供服務(wù)接口地址信息存放
key IP 端口號 服務(wù)名稱 192.168.1.1 8080 生產(chǎn)者啟動時，根據(jù)這種存儲方式注冊到微服務(wù)注冊中心
- 生產(chǎn)者：提供我們接口被其他服務(wù)調(diào)用
- 消費(fèi)者：調(diào)用接口實(shí)現(xiàn)服務(wù)
根據(jù)以上存儲方式的服務(wù)名稱獲取到IP地址和端口號
獲取到地址后在本地實(shí)現(xiàn)rpc遠(yuǎn)程調(diào)用
Naxos基本介紹
- 實(shí)現(xiàn)注冊中心和分布式配置中心
- 默認(rèn)賬號密碼：nacos
