一、微服務
1. 什麼是微服務
官網：https://martinfowler.com/articles/microservices.html
起源于： 25 March(3月) 2014 作者：James Lewis & Martin Fowler
[摘自官網] 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.
- - a suite of small services：一系列微小服務
- - running in its own process：運作在自己的程序裡
- - built around business capabilities：圍繞自己的業務開發
- - independently deployable：獨立部署
- - bare minimum of centralized management of these services：基于分布式管理
官方定義：微服務就是由一系列圍繞自己業務開發的微小服務構成，他們獨立運作在自己的程序裡，基于分布式管理。
通俗定義：微服務是一種架構，這種架構是将單個的整體應用程式分割成更小的項目互相關聯的獨立的服務。一個服務通常實作一組獨立的特性或功能，包含自己的業務邏輯和擴充卡。各個微服務之間的關聯通過api來實作。這些獨立的微服務不需要部署在同一台
虛拟機，同一個系統和同一個應用伺服器中。
叢集（cluster）：同一種軟體服務的多個服務節點共同為系統服務過程，稱之為軟體服務叢集。
分布式（distribute）：不同的軟體叢集共同為一個系統提供服務，這個系統稱之為分布式系統。
2. 為什麼微服務？
單體應用
# 優點：
- 單一架構模式在項目初期很小的時候開發友善，測試友善，部署友善，運作良好。
# 缺點：
- 應用随着時間的推進，加入的功能越來越多，業務功能逐漸龐大，一個項目中很有可能數百萬行的代碼，互相之間繁瑣的jar包。
- 久而久之，開發效率低，代碼維護困難。
- 項目整體技術疊代，采用新的技術，新的架構或者語言，是不可能的。
- 任意子產品的漏洞或者錯誤都會影響這個應用，降低系統的可靠性。
微服務架構應用
# 優點：
- 将每個服務拆分成單一職責的小服務，進行獨立部署，服務之間統過網絡進行通訊。
- 每個服務單獨管理，高度自治，可自行選用開發技術。
- 各服務有自己單獨的職責，服務之間松耦合，避免因一個子產品的問題導緻服務崩潰。
# 缺點：
- 開發人員要處理分布式系統的複雜性。
- 多服務運作難度，随着服務的增加，運維的壓力也在增大。
- 服務治理 和 服務監控 是關鍵。
二、架構的演變
1. 架構的演變過程
[單一應用架構] --> [垂直應用架構] --> [分布式服務架構] --> [流動計算架構]||[微服務架構] --> [未知]
摘自dubbo官網：https://dubbo.apache.org/zh/docs/v2.7/user/preface/background/
# All in One 單一架構
- 當網站流量很小時，隻需一個應用，将所有功能都部署在一起，以減少部署節點和成本。此時，
用于簡化增删改查工作量的資料通路架構(ORM)是關鍵。
（JSP + MySQL + Tomcat）
# Vertical Application 垂直架構
- 當通路量逐漸增大，單一應用增加機器帶來的加速度越來越小，提升效率的方法之一是将應用拆
成互不相幹的幾個應用，以提升效率。此時，用于加速前端頁面開發的Web架構(MVC)是關鍵。
（struts struts2 spring springmvc springboot）
# Distribute Service 分布式服務架構
- 當垂直應用越來越多，應用之間互動不可避免，将核心業務抽取出來，作為獨立的服務，逐漸形
成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。此時，用于提高業務複用及整合
的分布式服務架構(RPC)是關鍵。
（tomcat叢集、MySQL叢集、redis叢集）
OSI七層：實體層 資料鍊路層 網絡層 傳輸層(rpc) 會話層 表示層 應用層(http)
# Elastic Computiing 流動計算架構即微服務架構
- 當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個排程中心基
于通路壓力實時管理叢集容量，提高叢集使用率。此時，用于提高機器使用率的資源排程和治理中
心(SOA)是關鍵。
^--^ 好的架構并不是設計出來的，一定是不斷發展進化出來的！！！
2. 微服務架構解決方案
Dubbo阿裡系
最早期 dubbo(spring、springboot(相容問題)) + zookeeper
- 初出茅廬：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年更新過兩次對dubbo2.4的維護版本，然後停止了所有維護工作。dubbo對spring的支援也停留在spirng2.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版本正在動工的修奧西。dubbo3.0核心與dubbo2.0完全不同，但相容dubbo2.0。dubbo3.0将以Streaming為核心，不再是dubbo時代的rpc，但是rpc會在dubbo3.0中變成遠端streaming對
接的一種可選形态。從dubbo新版本的路線規劃來看，新版本的dubbo在原有的服務治理的功能基礎上，将全面擁抱微服務解決方案。
- 結論：目前由于rpc協定、注冊中心資料不比對等問題，在面臨微服務基礎架構選型時dubbo與springcloud隻能二選一，這也是為什麼大家總是拿dubbo和springcloud做對比的原因之一。dubbo之後回積極尋求适配到springcloud生态，比如作為spirngcloud的二進制
通信方案來發揮dubbo的性能優勢，或者dubbo通過子產品化以及對http的支援适配到springcloud。
springcloud技術棧
spring cloud netflix 最早(16-17年)
- 基于美國Netflix公司開源的元件進行封裝，提供了微服務一站式的解決方案
spring cloud alibaba 阿裡巴巴的解決方案
- 在spring cloud netflix的基礎上封裝了阿裡巴巴的微服務解決方案
spring cloud spring 自己封裝微服務解決方案
- 目前spring官方趨勢正在吸收Netflix元件的精華，并在此基礎上進行二次封裝優化，打造spring專
有的解決方案。
三、SpringCloud
1. 定義
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, one-time tokens, global locks,
leadership election, distributed sessions, cluster state). 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. They will work well in
any distributed environment, including the developer’s own laptop, bare metal data centres, and managed platforms such as Cloud Foundry.
譯：Spring Cloud 為開發者提供了快速建構分布式系統中一些常見模式的工具（例如配置管理、服務發現、斷路器、智能路由、微代理、控制總線、一次性令牌、全局鎖、上司選舉、分布式會話、叢集狀态）。分布式系統的協調導緻了樣闆模式，使用 Spring
Cloud 開發人員可以快速建立實作這些模式的服務和應用程式。
# 通俗了解：
- spirngcloud是一個涵蓋多個子項目的開發工具集，集合了衆多開源架構，它利用了spinrgboot開發的便利性實作了很多功能，如服務注冊、負載均衡等。springcloud在整合過程中主要是針對Netflix開源元件的封裝，springcloud的出現真正的簡化了分布式架構的開
發。
Netflix 是美國的一個線上視訊網站，微服務界的翹楚，他是公認的大規模生産微服務的傑出實踐者，Netflix的開源元件已經在他大規模分布式微服務環境中經過多年的生産實戰驗證，是以springcloud中很多元件都是基于Netflix。
2. 核心架構及其元件
# 核心元件說明
- eurekaserver、consul、nacos 服務注冊元件
- rabbion & openfeign 負載均衡 和 服務調用元件
- hystrix & hystrix dashboard 服務熔斷器 和 服務監控元件
- zuul、gateway 服務網管元件
- config 統一配置中心元件
- bus 消息總線元件
......
3. spirngcloud版本命名
spirngcloud是一個由衆多子項目組成的大型綜合項目，原則上每個子項目上有不同的釋出節奏，都維護自己的釋出版本号。為了更好的管理springcloud的版本，通過一個資源清單BOM(Bill Of Materials)，為避免與子版本号的釋出号混淆，是以沒有采用版本号的方
式，而是通過命名的方式。這些字母都是按照字母順序排列的。如倫敦的地鐵站的名稱（“天使”是第一個版本，“布裡斯頓”是第二個版本，“卡姆敦”是第三個版本）。當單個項目的點釋出累計到一個臨界量，或者其中一個項目中有一個關鍵缺陷需要每個人都可以使
用時，釋出序列将推出名稱以“.SRX”結尾的“服務釋出”，其中“X”是一個數字。
# 倫敦地鐵站名稱
- Angel、Brixton、Camden、Dalston、Edgware、Finchley、Greenwich、Hoxton
4. springcloud與spirngboot的版本對應關系
Spring Cloud Dalston, Edgware, Finchley, and Greenwich have all reached end of life status
and are no longer supported.
- Brixton 2017年Brixton and Angel release 官方宣布報廢
- Camden 2018年Camden release 官方宣布報廢
- Dalston 2018年12月官方宣布報廢
- Edgware 将遵循springboot1.5.x的生命周期結束