本文是Spring Cloud專欄的第一篇文章，了解本篇文章內容有助於更好的理解后面文章
一、網站架構演變過程
1-1、傳統架構
傳統的SSH架構，分為三層架構 web控制層、業務邏輯層、數據庫訪問層。
傳統架構也就是單點應用，就是大家在剛開始初學JavaEE技術的時候SSH架構或者SSM架構，業務沒有進行拆分，都寫同一個項目工程里面，一般是適合於個人或者是小團隊開發。
這種架構模式，一旦有一個模塊導致服務不可用，可能會影響整個項目。
1-2、分布式架構
分布式架構基於傳統架構演變過來，將傳統的單體項目以項目模塊進行拆分，拆分為會員項目、訂單項目、支付項目、優惠券項目等，從而降低耦合度，這種項目架構模式慢慢開始適合於互聯網公司規模人數開發。
1-3、SOA架構
SOA架構代表面向與服務架構，俗稱服務化，通俗的理解為面向與業務邏輯層開發，將共同的業務邏輯抽取出來形成一個服務，提供給其他服務接口進行調用，服務與服務之間調用使用rpc遠程技術。
1、SOA架構特點:
SOA架構中通常使用XML方式實現通訊，在高並發情況下XML比較冗余會帶來極大的影響，所以最后微服務架構中采用JSON替代xml方式。
SOA架構的底層實現通過WebService和ESB（xml與中間件混合物），Web Service技術是SOA服務化的一種實現方式，WebService底層采用soap協議進行通訊，soap協議就是Http或者是Https通道傳輸XML數據實現的協議。
1-4、微服務架構
1、微服務架構產生的原因
微服務架構基於SOA架構演變過來的，在傳統的WebService架構中有如下問題：
1、依賴中心化服務發現機制
2、使用Soap通訊協議，通常使用XML格式來序列化通訊數據，xml格式非常喜歡重，比較占寬帶傳輸。
3、服務化管理和治理設施不完善
1-5、漫談微服務架構
1、什么是微服務
微服務架是從SOA架構演變過來，比SOA架構粒度會更加精細，讓專業的人去做專業的事情（專注），目的提高效率，每個服務於服務之間互不影響，微服務架構中，每個服務必須獨立部署，互不影響，微服務架構更加體現輕巧、輕量級，是適合於互聯網公司敏捷開發。
2、微服務架構特征
微服務架構倡導應用程序設計程多個獨立、可配置、可運行和可微服務的子服務。
服務與服務通訊協議采用Http協議，使用restful風格API形式來進行通訊，數據交換格式輕量級json格式通訊，整個傳輸過程中，采用二進制，所以http協議可以跨語言平台，並且可以和其他不同的語言進行相互的通訊，所以很多開放平台都采用http協議接口。
3、微服務架構如何拆分
1、微服務把每一個職責單一功能存放在獨立的服務中
2、每個服務運行在單獨的進程中
3、每個服務有自己獨立數據庫存儲、實際上有自己獨立的緩存、數據庫、消息隊列等資源。
4、微服務架構與SOA架構區別
1、微服務架構基於 SOA架構 演變過來，繼承 SOA架構的優點，在微服務架構中去除 SOA 架構中的 ESB 消息總線，采用 http+json（restful）進行傳輸。
2、微服務架構比 SOA 架構粒度會更加精細，讓專業的人去做專業的事情（專注），目的提高效率，每個服務於服務之間互不影響，微服務架構中，每個服務必須獨立部署，微服務架構更加輕巧，輕量級。
3、SOA 架構中可能數據庫存儲會發生共享，微服務強調獨每個服務都是單獨數據庫，保證每個服務於服務之間互不影響。
4、項目體現特征微服務架構比 SOA 架構更加適合與互聯網公司敏捷開發、快速迭代版本，因為粒度非常精細。
二、SpringCloud微服務框架
2-1、為什么選擇SpringCloud
因為SpringCloud出現,對微服務技術提供了非常大的幫助，因為SpringCloud 提供了一套完整的微服務解決方案，不像其他框架只是解決了微服務中某個問題。
服務治理：阿里巴巴開源的Dubbo和當當網在其基礎上擴展的Dubbox、Eureka、Apache 的Consul等。
分布式配置中心：百度的disconf、Netfix的Archaius、360的QConf、SpringCloud Config、攜程的阿波羅等。
分布式任務：xxl-job、elastic-job、springcloud的task等。
服務跟蹤：京東的hyra、springcloud的sleuth等。
2-2、SpringCloud介紹
Spring Cloud為開發人員提供了快速構建分布式系統中一些常見模式的工具（例如配置管理，服務發現，斷路器，智能路由，微代理，控制總線，一次性令牌，全局鎖定，領導選舉，分布式會話，集群狀態）。分布式系統的協調導致了樣板模式，使用Spring Cloud開發人員可以快速站起來實現這些模式的服務和應用程序。它們適用於任何分布式環境，包括開發人員自己的筆記本電腦，裸機數據中心和Cloud Foundry等托管平台。
三、Spring Cloud組件
Spring Cloud構建微服務是基於SpringBoot開發的，服務之間通過基於HTTP的RESTFUL API進行通信協作的。所以本專欄以后所以案例均采用SpringBoot 2.0.5.RELEASE，Spring Cloud Finchley.SR4版本
Spring Cloud組件由20多個組件組成的，常用的組件有如下：
主要：
Eureka：服務注冊中心，特性有失效剔除、服務保護
Dashboard，Hystrix儀表盤：監控集群模式和單點模式，其中集群模式需要收集器Turbine配合
Zuul：API服務網關，功能有路由分發和過濾
Config：分布式配置中心，支持本地倉庫、SVN、Git、Jar包內配置等模式
融合：
融合在每個微服務中、依賴其它組件並為其提供服務
Ribbon：客戶端負載均衡，特性有區域親和、重試機制
Hystrix：客戶端容錯保護，特性有服務降級、服務熔斷、請求緩存、請求合並、依賴隔離
Feign：聲明式服務調用，本質上就是Ribbon+Hystrix，類似於Dubbo的調用
Stream：消息驅動，有Sink、Source、Processor三種通道，特性有訂閱發布、消費組、消息分區
Bus：消息總線，配合Config倉庫修改的一種Stream實現
Sleuth：分布式服務追蹤，需要搞清楚TraceID和SpanID以及抽樣，並且與ZipKin整合
在此還會涉及到SpringBoot的SpringBoot Admin（一個管理和監控 Spring Boot 應用程序的開源項目）
作用：
每個組件都不是平白無故的產生的，是為了解決某一特定的問題而存在
Eureka：分為客戶端和服務端，客戶端是一個java客戶端，用來連接Eureka服務端(說白了服務端就是Eureka注冊中心)，與服務端進行交互，負載均衡，服務的故障切換等。。。作用類似於zookeeper
Ribbon：是一個基於HTTP和TCP的客戶端負載均衡器，當使用Ribbon對服務進行訪問的時候，他會擴展Eureka客戶端的服務發現功能，實現從Eureka注冊中心獲取服務端列表，並通過Eureka客戶端來確定服務端是否已經啟動。Ribbon在Eureka客戶端服務發現的基礎上，實現對服務實例的選擇策略，從而實現對服務的負載均衡消費。
總結：Eureka和Ribbon，是最基礎的組件，一個注冊服務，一個負載均衡消費服務。
Hystrix(斷路器/熔斷器)：為了優化Ribbon、防止整個微服務架構因為某個服務節點的問題導致崩潰，是個保險絲的作用，防止服務雪崩。
Dashboard：給Hystrix統計和展示用的，而且監控服務節點的整體壓力和健康情況。
Turbine：是集群收集器，服務於Dashboard的。
Feign：是Netflix公司開發的一個聲明式的REST調用客戶端，Ribbon負載均衡，Hystrix服務熔斷是Spring Cloud中進行微服務開發的最基礎的組件，在使用過程中我一般發現他們都是一起存在的，而且配置也相似，每次開發都有相同的代碼，因此Spring Cloud基於Netflix Feign整合了Ribbon和Hystrix兩個組件，讓開發更簡單
Zuul：是加在整個微服務最前沿的防火牆和代理器，隱藏微服務結點IP端口信息，加強安全保護的。
Config：是為了解決所有微服務各自維護各自的配置，設置一個統一的配置中心，方便修改配置的。
Bus：是因為config修改完配置后各個結點都要refresh才能生效實在太麻煩，所以交給bus來通知服務節點刷新配置的。
Stream：是為了簡化研發人員對MQ使用的復雜度，弱化MQ的差異性，達到程序和MQ松耦合。目前只支持RabbitMQ和Kafka
Sleuth：是因為單次請求在微服務節點中跳轉無法追溯，解決任務鏈日志追蹤問題的
案例源碼地址：https://gitee.com/coding-farmer/springcloud-learn
Spring Cloud專欄文章學習參考資源來源於如下，排名不分先后：
官網：https://spring.io/projects/spring-cloud
方志朋：https://blog.csdn.net/forezp
螞蟻課堂：http://www.mayikt.com
翟永超：《Spring Cloud微服務實戰》
