spring cloud 2.0 概述

微服務架構演變過程

傳統單體架構 =》 分布式架構 =》 soa面向服務架構 =》 微服務架構

傳統單體架構

傳統單體架構就是單點應用，也就是在早期開發學習的ssm或ssh整合項目采用分層架構模式、數據庫訪問層、業務邏輯層、控制層，從前端到后端所有代碼都是一個人寫的

cn.itycu.controler?---springmvc?視圖層?jsp/ftl cn.itycu.service?---業務邏輯層 cn.itycu.dao?---數據庫訪問層 將所有的代碼都放入到同一個項目中，部署在同一個tomcat中

該架構模式存在的優缺點

優點：開發簡單、運維簡單

缺點：該架構模式沒有對業務邏輯進行拆分，這樣子耦合度非常高，只適合小團隊或者個人形式開發，不適合團隊模式協同工作開發，維護性很難，如果系統中某個模塊出現問題，會導致整個系統無法使用。

應用場景：政府項目、管理系統、crm、oa，適合于小團隊或個人進行開發

分布式架構

分布式架構模式基于傳統的架構模式演變過來，將我們傳統的單點系統實現根據業務拆分。會拆分為會員系統、訂單系統、支付系統、秒殺系統等。從而降低整個項目的耦合度，這種架構模式開始慢慢適合于互聯網公司開發。

會員系統?memner.itycu.cn 支付系統?pay.itycu.cn 項目命名為系統意味：包含視圖層和服務層

soa面向服務架構

sso單點登錄系統，抽離出通用服務

soa面向服務架構基于分布式架構模式演變過來，俗稱服務化，也就是面向于服務與接口開發（服務開發），將共同存在的業務邏輯抽取成一個公共服務，提供給其他接口實現調用，服務與服務之間采用rpc遠程調用技術。

服務：只是有接口、沒有視圖層

cn.itycu.service cn.itycu.dao

能夠解決我們的代碼冗余性問題

soa架構模式特點

傳統政府、銀行項目還是保留的在使用webservice

webservice架構模式

wsdl組件表示接口信息、方法、調用地址、參數

soa架構模式傳輸協議采用soap協議（HTTP/https+xml）實現傳輸，在高并發情況下實現通訊協議存在大量的冗余性傳輸，而且非常占用帶寬。所以后來微服務架構中使用json替代了xml。

soa架構模式實現方案webservice或者esb企業服務總線，底層采用soap傳輸協議。

soa架構模式存在缺點

前后端分離就是對我們控制層和業務邏輯實現區分，前端控制可以采用vue調用我們后端接口（http+json）

采用soap協議實現通訊，xml傳輸非常重，效率比較低。

服務化管理和治理設施不夠完善

依賴于中心服務發現機制

不適合前后端分離架構模式

微服務架構

微服務架構模式基于soa架構模式演變過來的，比soa架構迷失對服務拆分力度會更加精細，采用前后端分離模式讓專業的人做專業的事（專注），目的可以實現高效率開發。微服務架構中，每個服務之間都是互不影響，每個服務必須要獨立部署、運維、互不影響，微服務架構模式非常輕巧，輕量級、適合于互聯網公司開發模式。

服務與服務之間通訊的協議采用restful形式，數據交換格式采用http+json格式實現傳輸

整個過程中，采用二進制，所以http協議可以實現跨語言的平臺，并且和其他語言實現通訊，所以為什么開放都是采用http+json格式傳輸

SOA架構與微服務架構有哪些區別

微服務架構模式比soa架構模式，更加適合于互聯網公司敏捷、高效、快速迭代版本開發，因為力度非常精細。

微服務架構模式比soa架構模式拆分力度更加精細，提倡讓專業的人做專業的事，目的是實現高效的開發，每個服務與服務之間互不影響，每個服務都是單獨獨立數據庫、redis連接、MQ等。并且都是實現獨立部署，整個微服務架構更加輕量級。

在soa架構中，有可能純在多個服務共享同一個數據庫，但是微服務架構必須強調每個都是獨立數據庫部署，互不影響。

微服務架構基于soa架構模式演變過來，繼承了soa架構的優點，在微服務架構中去除soa架構中soap協議和esp企業服務總線。改為http+json形式傳輸我們的數據。

esb企業服務總線解決多系統間跨語言無法實現通訊的問題，對我們的數據實現轉換，可以提供可靠的消息傳輸。一般情況我們采用http+json傳輸數據，不需要esb對數據進行轉換。

通訊協議

服務拆分力度

迭代

微服務架構中可能會存在哪些問題

分布式事務解決方案（rabbitmq、rocketmq事務消息、lcn（淘汰）、setata）最終一級概念

分布式任務調度平臺（xxl-job、elastic-job）

分布式服務注冊與發現（eureka、consul、zookeeper、nacos）

分布式日志采集系統elk+kafka

分布式服務最綜與調用鏈系統zipkin

分布式服務配置中心（spring Cloud config/攜程阿波羅/nacos/disconfig）

微服務架構中有個非常重要的概念：獨立部署、可配置、動態化。

為什么要使用到spring Cloud

spring cloud 并不是一個rpc遠程調用框架，而是一個微服務全家桶的解決方案的框架。理念就是***服務解決我們在微服務架構中遇到的問題。

服務治理：eureka

分布式配置：config

客戶端調用工具：rest/feign客戶 rpc遠程調用

說明：阿里巴巴、騰訊、百度

注意：大家如果去一些比較大型的互聯網公司中，整個公司內部實現rpc通訊的框架、服務幫助治理都是內部自己研發。

rpc遠程調用框架：HTTPclent、dubbo、feign、grpc、基于netty手寫rpc

spring cloud一代和二代的區別

spring cloud第一代實際上采用Netflix開源的組件整合微服務解決方案。

spring cloud第二代實際上就是自己研發和國內的優秀的服務解決微服務框架進行組合。

nacos實現服務注冊于發現

微服務服務治理核心概念

Nacos產生背景

rpc遠程調用框架：HTTP client、grpc、dubbo、rest、openfeign等。

傳統rpc遠程調用中存在哪些問題？

超時、安全、服務與服務之間的url地址管理

在我們的微服務架構通訊中，服務間依賴非常大，如果使用傳統方式管理我們的服務，非常麻煩，所以采用url治理技術，可以實現我們整個實現動態服務注冊與發現、本地負載均衡、容錯等

nacos分布式注冊與發現功能 | 分布式配置中心

產生于rpc遠程調用中，服務的url的治理

傳統服務注冊中心的實現方式

把每個服務器的地址信息和端口號人工存放到數據庫表中

維護成本高

沒有實現動態自動化

基于數據庫形式實現服務url治理的缺點

分布式注冊中心實現原理

注冊中心的作用

管理整個微服務url地址

可以實現動態感知

注冊中心：duboo依賴zookeeper、eureka、consul、nacos、redis、數據庫

nacos與eureka的區別

eureka與zookeeper的區別

注冊中心的原理

生產者啟動時，根據這種存儲方式注冊到微服務注冊中心

根據以上存儲方式的服務名稱獲取到IP地址和端口號

獲取到地址后在本地實現rpc遠程調用

生產者：提供我們接口被其他服務調用

消費者：調用接口實現服務

服務注冊：提供服務接口地址信息存放

Naxos基本介紹

實現注冊中心和分布式配置中心

默認賬號密碼：nacos

使用命令模式實現對nacos的注冊

使用discovertyClient從注冊中心獲取接口地址

使用rest Template實現rpc遠程調用

純手寫本地負載均衡輪詢算法

實現線下服務動態感知

分布式 微服務 Spring Cloud

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。