In short, the microservice architectural style is an approach to developing a single application as a suite of small services
, each running in its own process
and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities
and independently deployable
by fully automated deployment machinery. There is a bare minimum of centralized management of these services
, which may be written in different programming languages and use different data storage technologies. -----[摘自官網]html
- a suite of small services --一系列微小服務 - running in its own process --運行在本身的進程裏 - built around business capabilities --圍繞本身的業務開發 - independently deployable --獨立部署 - bare minimum of centralized management of these services --基於分佈式管理
官方定義:微服務就是由一系列圍繞本身業務開發的微小服務構成,他們獨立部署運行在本身的進程裏,基於分佈式的管理前端
App 應學項目 分類模塊 視頻模塊 評論模塊 用戶模塊 統計模塊... 單體應用java
分類服務 獨立應用 ---> 計算進程裏面 ---> 獨立部署web
視頻服務 基於分佈式服務管理spring
評論服務apache
用戶服務api
....服務springboot
通俗定義:微服務是一種架構,這種架構是將單個的總體應用程序分割成更小的項目關聯的獨立的服務。一個服務一般實現一組獨立的特性或功能,包含本身的業務邏輯和適配器。各個微服務之間的關聯經過暴露api來實現。這些獨立的微服務不須要部署在同一個虛擬機,同一個系統和同一個應用服務器中。服務器
# 1.優勢 - 單一架構模式在項目初期很小的時候開發方便,測試方便,部署方便,運行良好。 # 2.缺點 - 應用隨着時間的推動,加入的功能愈來愈多,最終會變得巨大,一個項目中頗有可能數百萬行的代碼,互相之間繁瑣的jar包。 - 長此以往,開發效率低,代碼維護困難 - 還有一個若是想總體應用採用新的技術,新的框架或者語言,那是不可能的。 - 任意模塊的漏洞或者錯誤都會影響這個應用,下降系統的可靠性
# 1.優勢 - 將服務拆分紅多個單一職責的小的服務,進行單獨部署,服務之間經過網絡進行通訊 - 每一個服務應該有本身單獨的管理團隊,高度自治 - 服務各自有本身單獨的職責,服務之間鬆耦合,避免因一個模塊的問題致使服務崩潰 # 2.缺點 - 開發人員要處理分佈式系統的複雜性 - 多服務運維難度,隨着服務的增長,運維的壓力也在增大 - 服務治理 和 服務監控 關鍵
# 1.架構的演變過程 - [單一應用架構] `===>` [垂直應用架構] `===>` [分佈式服務架構] `===>` [流動計算架構]||[微服務架構] `===>` [未知]
# 1. All in One Application 單一架構 - 起初當網站流量很小時,將全部功能都寫在一個應用裏面,對整個應用進行部署,以減小部署節點和成本。對於這個架構簡化增刪改查的工做量的數據訪問框架(ORM)是關鍵。 # 2. Vertical Application 垂直架構 - 當訪問量逐漸增大,單一應用增長機器帶來的加速度愈來愈小,提高效率的方法之一是將應用拆成互不相干的幾個應用,以提高效率。此時,用於加速前端頁面開發的Web框架(MVC)是關鍵。 # 3. Distributed Service 分佈式服務架構 - 當垂直應用愈來愈多,應用之間交互不可避免,將核心業務抽取出來,做爲獨立的服務,逐漸造成穩定的服務中心,使前端應用能更快速的響應多變的市場需求。此時,用於提升業務複用及整合的分佈式服務框架(RPC)是關鍵。 # 4. Elastic Computing 流動計算架構即微服務架構 - 當服務愈來愈多,容量的評估,小服務資源的浪費等問題逐漸顯現,此時需增長一個調度中心基於訪問壓力實時管理集羣容量,提升集羣利用率。此時,用於提升機器利用率的資源調度和治理中心(SOA)是關鍵
# 1.Dubbo (阿里系) - 初出茅廬:2011年底,阿里巴巴在GitHub上開源了基於Java的分佈式服務治理框架Dubbo,以後它成爲了國內該類開源項目的佼佼者,許多開發者對其表示青睞。同時,前後有很多公司在實踐中基於Dubbo進行分佈式系統架構,目前在GitHub上,它的fork、star數均已破萬。Dubbo致力於提供高性能和透明化的RPC遠程服務調用方案,以及SOA服務治理方案,使得應用可經過高性能RPC實現服務的輸出、輸入功能和Spring框架無縫集成。Dubbo包含遠程通信、集羣容錯和自動發現三個核心部分。 - 中止維護:從2012年10月23日Dubbo 2.5.3發佈後,在Dubbo開源將滿一週年之際,阿里基本中止了對Dubbo的主要升級。只在以後的2013年和2014年更新過2次對Dubbo 2.4的維護版本,而後中止了全部維護工做。Dubbo對Srping的支持也停留在了Spring 2.5.6版本上。 - 死而復生:多年漫長的等待,隨着微服務的火熱興起,在國內外開發者對阿里再也不升級維護Dubbo的吐槽聲中,阿里終於開始從新對Dubbo的升級和維護工做。在2017年9月7日,阿里發佈了Dubbo的2.5.4版本,距離上一個版本2.5.3發佈已經接近快5年時間了。在隨後的幾個月中,阿里Dubbo開發團隊以差很少每個月一版本的速度開始快速升級迭代,修補了Dubbo老版本多年來存在的諸多bug,並對Spring等組件的支持進行了全面升級。 - 2018年1月8日,Dubbo創始人之一梁飛在Dubbo交流羣裏透露了Dubbo 3.0正在動工的消息。Dubbo 3.0內核與Dubbo 2.0徹底不一樣,但兼容Dubbo 2.0。Dubbo 3.0將以Streaming爲內核,再也不是Dubbo 時代的RPC,可是RPC會在Dubbo 3.0中變成遠程Streaming對接的一種可選形態。從Dubbo新版本的路線規劃上能夠看出,新版本的Dubbo在原有服務治理的功能基礎上,將全面擁抱微服務解決方案。 - 結論:當前因爲RPC協議、註冊中心元數據不匹配等問題,在面臨微服務基礎框架選型時Dubbo與Spring Cloud是隻能二選一,這也是爲何你們老是拿Dubbo和Spring Cloud作對比的緣由之一。Dubbo以後會積極尋求適配到Spring Cloud生態,好比做爲Spring Cloud的二進制通訊方案來發揮Dubbo的性能優點,或者Dubbo經過模塊化以及對http的支持適配到Spring Cloud。
# Spring Cloud: - Spring Cloud NetFlix(美國 在線視頻網站) 基於美國Netflix公司開源的組件進行封裝,提供了微服務一棧式的解決方案。 G版本 - Spring Cloud alibaba 在Spring cloud netflix基礎上封裝了阿里巴巴的微服務解決方案。 - Spring Cloud 目前spring官方趨勢正在逐漸吸取Netflix組件的精華,並在此基礎進行二次封裝優化,打造spring專有的解決方案
Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management
, service discovery
, circuit breakers, intelligent routing, micro-proxy, control bus
). Coordination of distributed systems leads to boiler plate patterns, and using Spring Cloud developers can quickly stand up services and applications that implement those patterns. -------[摘自官網]markdown
# 1.翻譯 - springcloud爲開發人員提供了在分佈式系統中快速構建一些通用模式的工具(例如配置管理、服務發現、斷路器、智能路由、微代理、控制總線)。分佈式系統的協調致使了鍋爐板模式,使用springcloud開發人員能夠快速地創建實現這些模式的服務和應用程序。 # 2.通俗理解 - springcloud是一個含概多個子項目的開發工具集,集合了衆多的開源框架,他利用了Spring Boot開發的便利性實現了不少功能,如服務註冊,服務註冊發現,負載均衡等.SpringCloud在整合過程當中主要是針對Netflix(耐非)開源組件的封裝.SpringCloud的出現真正的簡化了分佈式架構的開發。 - NetFlix 是美國的一個在線視頻網站,微服務業的翹楚,他是公認的大規模生產級微服務的傑出實踐者,NetFlix的開源組件已經在他大規模分佈式微服務環境中通過多年的生產實戰驗證,所以Spring Cloud中不少組件都是基於NetFlix組件的封裝。 # 3.微服務架構下所存在問題? - 基於獨立業務拆分紅一個微小的服務 每一個服務獨立部署 運行在本身的進程裏面 服務之間使用http rest的方式進行通訊 - 單體應用 分類模塊 視頻模塊 用戶模塊 產生 測試 前端 pc app 統一入口 localhost:8989 - 微服務架構應用 分類服務 8080 視頻服務 8081 用戶服務 8082 8083 ..... - 問題 1.要有個組件幫助咱們記錄服務,監控服務,服務發現 服務註冊和發現組件 註冊中心 2.服務調用問題http rest方式調用 --- 如何調用? 服務調用時如何實現服務負載均衡 ? 3.服務雪崩效應? 4.服務配置文件管理? 5.網關組件?
# 1.核心組件說明 - eurekaserver、consul、nacos 服務註冊中心組件 - rabbion & openfeign 服務負載均衡 和 服務調用組件 - hystrix & hystrix dashboard 服務斷路器 和 服務監控組件 - zuul、gateway 服務網關組件 - config 統一配置中心組件 - bus 消息總線組件 ......
Spring Cloud is an umbrella(傘) project consisting of independent projects with, in principle, different release cadences. To manage the portfolio a BOM (Bill of Materials) is published with a curated set of dependencies on the individual project (see below). The release trains have names, not versions, to avoid confusion with the sub-projects. The names are an alphabetic sequence (so you can sort them chronologically) with names of London Tube stations ("Angel" is the first release, "Brixton" is the second). When point releases of the individual projects accumulate to a critical mass, or if there is a critical bug in one of them that needs to be available to everyone, the release train will push out "service releases" with names ending ".SRX", where "X" is a number. ---[摘自官網]
# 1.翻譯 - springcloud 版本管理方式: 命名方式 Angel.SR1~6 Brixton.SR1~6 Camden.SR1~6 - springcloud是一個由衆多獨立子項目組成的大型綜合項目,原則每一個子項目上有不一樣的發佈節奏,都維護本身發佈版本號。爲了更好的管理springcloud的版本,經過一個資源清單BOM(Bill of Materials),爲避免與子項目的發佈號混淆,因此沒有采用版本號的方式,而是經過命名的方式。這些名字是按字母順序排列的。如倫敦地鐵站的名稱(「天使」是第一個版本,「布里斯頓」是第二個版本,"卡姆登"是第三個版本)。當單個項目的點發布累積到一個臨界量,或者其中一個項目中有一個關鍵缺陷須要每一個人均可以使用時,發佈序列將推出名稱以「.SRX」結尾的「服務發佈」,其中「X」是一個數字。 # 2.倫敦地鐵站名稱 [瞭解] - Angel、Brixton、Camden、Dalston、Edgware、Finchley、Greenwich、Hoxton、
# 1.版本選擇官方建議 https://spring.io/projects/spring-cloud - Angel 版本基於springboot1.2.x版本構建與1.3版本不兼容 - Brixton 版本基於springboot1.3.x版本構建與1.2版本不兼容 `2017年Brixton and Angel release官方宣佈報廢 - Camden 版本基於springboot1.4.x版本構建並在1.5版本經過測試 `2018年Camden release官方宣佈報廢 - Dalston、Edgware 版本基於springboot1.5.x版本構建目前不能再springboot2.0.x版本中使用 `Dalston(達爾斯頓)將於2018年12月官方宣佈報廢。Edgware將遵循Spring Boot 1.5.x的生命週期結束。 - Finchley 版本基於springboot2.0.x版本進行構建,不能兼容1.x版本 - Greenwich 版本基於springboot2.1.x版本進行構建,不能兼容1.x版本 - Hoxton 版本基於springboot2.2.x版本進行構建
仍是建立springboot的方式
# 0.說明 - springboot 2.2.x.RELEASE+ - springcloud Hoxton SR1~6 - java8+ - maven 3.3.6+ - idea 2018.3.5+ # 1.建立springboot項目 指定版本爲 2.2.5版本
# 2.引入springcloud的版本管理
<!--定義springcloud使用版本號--> <properties> <java.version>1.8</java.version> <spring-cloud.version>Hoxton.SR6</spring-cloud.version> </properties> <!--全局管理springcloud版本,並不會引入具體依賴--> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>${spring-cloud.version}</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement>
# 3.完成上述操做springboot與springcloud環境搭建完成 - 接下來就是使用到具體的springcloud組件,在項目中引入具體的組件便可
<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.2.5.RELEASE</version> <relativePath/> <!-- lookup parent from repository --> </parent> <groupId>com.md</groupId> <artifactId>01-hello</artifactId> <version>0.0.1-SNAPSHOT</version> <name>01-hello</name> <description>Demo project for Spring Boot</description> <properties> <java.version>1.8</java.version> <!--定義springcloud使用版本號--> <spring-cloud.version>Hoxton.SR6</spring-cloud.version> </properties> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> </dependencies> <!--全局管理springcloud版本,並不會引入具體依賴--> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>${spring-cloud.version}</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build> </project>