SpringCloud微服務之宏觀了解

@

目錄

• 宏觀了解
• 微服務架構
• 微服務概述
• 微服務優缺點
• 微服務目前技術棧
• SpringCloud和Dubbo的對比

學了也用了這麼久SpringBoot,你有沒有思考過SpringBoot和SpringCloud 的關系呢？SpringCloud這麼火的原因究竟有哪些呢？SpringCloud解決了哪些問題呢？Dubbo 和 SpringCloud 對比有什麼不同呢？接下來我們就來帶着問題，捋一捋。

MVC架構（三層架構）:結構清晰，友善開發人員協調分工，簡化開發；

Spring(IOC、AOP): Spring是一個輕量級的JAVA架構，或者我們可以把它叫做一個IOC容器。它的誕生解決了企業級的開發複雜性問題，但是随着時間推移，越來越多的東西內建到Spring中，Spring也變得越來越複雜了；這似乎已經背離了Spring的初衷，再也不是簡單易用的程式員的春天了！

那麼SpringBoot應勢頭而生，它簡化了Sprig的開發，我們可以了解為是Spring的更新版，是Spring的一個腳手架，提供了很多自動化配置的元件（約定大于配置)!于是乎，慢慢演進到現在成為了新一代的JavaEE的開發标準；

那麼基于SpringBoot我們就可以快速開發一個企業級應用，企業級的單體應用因為SpringBoot的出現，又可以拆分成一個個的微服務應用。對比于以前的單體應用，業務邏輯沒有發生任何改變，變的隻是服務的架構，也叫微服務架構；

微服務架構解決的根本問題是解藕，本質就是子產品化開發。那麼這就帶來了一個問題，服務多了後管理不是很友善啊，大大增加了運維及排錯成本。相比單體的架構，它主要帶來了以下四個問題：

• 這麼多服務，用戶端怎麼通路服務端？
• 這麼多服務，服務之間如何通信？
• 這麼多服務，如何管理呢（又叫服務治理）？
• 這麼多服務，服務挂了這麼辦？（運維成本大增）

那麼SpringCloud也就為了這些問題應運而生，注意SpringCloud并不是一個技術，它是微服務架構的一站式解決方案，是基于SpringBoot的一個微服務生态圈！

那麼解決上面問題，目前有哪些解決方案呢？

SpringCloud Netflix:
    api網關 -- zuul
    服務間通信 -- Feign (HttpClient-ribbon-feign)
    服務治理(服務注冊與發現) -- Eureka
    服務熔斷 -- Hystrix

Apache Dubbo + Zookeeper:
    api網關 -- 很遺憾，dubbo并沒有開發自己的網關元件，目前使用了第三方提供的（例如:Zuul,Soul,Gateway...)
    服務間通信 -- 一個基于Java的Rpc通信架構
    服務治理(服務注冊與發現) -- Zookeeper(多用于大資料相關，Hadoop、hive...)
    服務熔斷 -- 也沒有，用的是Hystrix

SpringCloud Alibaba:
    api網關 -- 也是用的zuul或Gateway
    服務間通信 -- 預設使用的也是Feign (HttpClient-ribbon-feign)
    服務治理(服務注冊與發現) -- Nacos
    服務熔斷 -- 也沒有，預設使用的是Hystrix（可惜的是Hystrix也宣布不再維護了，官方推薦的替換版本是resilience4）
           

springCloud 官網：https://spring.io/projects/spring-cloud

SpringCloud 中文網：https://www.springcloud.cc/

Dubbo 官網：http://dubbo.apache.org/en-us/

Dubbo 中文手冊：https://dubbo.gitbooks.io/dubbo-user-book/content/quick-start.html

SpringCloud Alibaba Wiki：https://github.com/alibaba/spring-cloud-alibaba/wiki

就目前而言，對于微服務，業界并沒有一個統一的，标準的定義。

但通常而言，微服務架構是一種架構模式，或者說是一種架構風格，它提倡将單一的應用程式劃分成一組小的服務，每個服務運作在其獨立的自己的程序内，服務之間互相協調，互相配置，為使用者提供最終價值。服務之間采用輕量級的通信機制互相溝通，每個服務都圍繞着具體的業務進行建構，并且能夠被獨立的部署到生産環境中，另外，應盡量避免統一的，集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合适的語言，工具對其進行建構，可以有一個非常輕量級的集中式管理來協調這些服務，可以使用不同的語言來編寫服務，也可以使用不同的資料存儲；

可能有的人覺得官方的話太過生澀，我們從技術次元來了解下：

微服務化的核心就是将傳統的一站式應用，根據業務拆分成一個一個的服務，徹底地去耦合，每一個微服務提供單個業務功能的服務，一個服務做一件事情，從技術角度看就是一種小而獨立的處理過程，類似程序的概念，能夠自行單獨啟動或銷毀，擁有自己獨立的資料庫。

關于微服務的詳細了解，推薦部落格: 微服務（Microservices）——Martin Flower

優點

• 每個服務足夠内聚，足夠小，代碼容易了解，這樣能聚焦一個指定的業務功能或業務需求；
• 開發簡單，開發效率提高，一個服務可能就是專一的隻幹一件事；
• 微服務能夠被小團隊單獨開發，這個小團隊是2~5人的開發人員組成； 最少3個人！
• 微服務是松耦合的，是有功能意義的服務，無論是在開發階段或部署階段都是獨立的。
• 微服務能使用不同的語言開發。
• 易于和第三方內建，微服務允許容易且靈活的方式內建自動部署，通過持續內建工具，如jenkins，Hudson，bamboo
• 微服務易于被一個開發人員了解，修改和維護，這樣小團隊能夠更關注自己的工作成果。無需通過合作才能展現價值。
• 微服務允許你利用融合最新技術。
• 微服務隻是業務邏輯的代碼，不會和 HTML ， CSS 或其他界面混合
• 每個微服務都有自己的存儲能力，可以有自己的資料庫，也可以有統一資料庫

缺點

• 開發人員要處理分布式系統的複雜性
• 多服務運維難度，随着服務的增加，運維的壓力也在增大
• 系統部署間依賴增加
• 服務間通信成本增加
• 資料一緻性問題
• 系統內建測試問題
• 性能監控問題

微服務條目	落地技術
服務開發	SpringBoot,Spring,SpringMVC
服務配置與管理	Netflix公司的Archaius、阿裡的Diamond等
服務注冊與發現	Eureka、Consul、Zookeeper等
服務調用	Rest、RPC、gRPC
服務熔斷器	Hystrix、Envoy等
負載均衡	Ribbon、Nginx等
服務接口調用（用戶端調用服務的簡｜化工具）	Feign等
消息隊列	Kafka、RabbitMQ、ActiveMQ等｜
服務配置中心管理	SpringCloudConfig、Chef等
服務路由（API網關）	Zuul等
服務監控	Zabbix、Nagios、Metrics、Specatator等
服務部署	Docker、OpenStack、Kubernetes等
資料流操作開發包	SpringCloud Stream(封裝與Redis，Rabbit，Kafka等發送接收消息)
事件消息總線	SpringCloud Bus

其實，它們注重的領域不一樣，按理說沒有太多的可比性.Dubbo的定位是一款RPC架構，Spring Cloud的目标是微服務架構下的一站式解決方案

-	Dubbo	Spring
服務注冊中心	Zookeeper	Spring Cloud Netfilx Eureka
服務調用方式	RPC	REST API
	Dubbo-monitor	Spring Boot Admin
斷路器	不完善	Spring Cloud Netflix Hystrix
服務網關	無	Spring Cloud Netflix Zuul
分布式配置		Spring Cloud Config
服務跟蹤		Spring Cloud Sleuth
消息總線		Spring Cloud Bus
資料流		Spring Cloud Stream
批量任務		Spring Cloud Task

最大差別：SpringCloud抛棄了Dubbo的RPC通信，采用的是基于HTTP的REST方式。

嚴格來說，這兩種方式各有優劣。雖然從一定程度上來說，後者犧牲了服務調用的性能，但也避免了上

面提到的原生RPC帶來的問題。而且REST相比RPC更為靈活，服務提供方和調用方的依賴隻依靠一紙契

約，不存在代碼級别的強依賴，這在強調快速演化的微服務環境下，顯得更加合适。

品牌機與組裝機的差別:

很明顯，Spring Cloud的功能比DUBBO更加強大，涵蓋面更廣，而且作為Spring的拳頭項目，它也能夠

與Spring Framework、Spring Boot、Spring Data、Spring Batch等其他Spring項目完美融合，這些對于微服務而言是至關重要的。

使用Dubbo建構的微服務架構就像組裝電腦，各環節我們的選擇自由度很高，但是最終結果很有可能因為一條記憶體品質不行就點不亮了，總是讓人不怎麼放心，但是如果你是一名高手，那這些都不是問題；

而Spring Cloud就像品牌機，在Spring Source的整合下，做了大量的相容性測試，保證了機器擁有更高的穩定性，但是如果要在使用非原裝元件外的東西，就需要對其基礎有足夠的了解。

社群支援與更新力度

最為重要的是，DUBBO停止了5年左右的更新，雖然2017.7重新開機了。對于技術發展的新需求，需要由開發者自行拓展更新（比如當當網弄出了DubboX），這對于很多想要采用微服務架構的中小軟體組織，顯然是不太合适的，中小公司沒有這麼強大的技術能力去修改Dubbo源碼+周邊的一整套解決方案，并不是每一個公司都有阿裡的大牛+真實的線上生産環境測試過。

是以基于以上的了解，SpringCloud 這個品牌機還是閱聽人廣大，作為優選方案沒問題！

好了，關于微服務的宏觀了解及擴充就總結到這裡；其實不要輕視這些思想層面的東西，因為這就是你面試時候的談資；會做不代表會說，會說健談也是一種能力的展現，做程式員這一行還是不能沉迷于閉門造車，交流總結很重要！後面就去開撸SpringCloud相關的東西了，奧利給！

餘路那麼長，還是得帶着虔誠上路...