系統進化理論概述
在系統架構與設計的實踐中,經歷了兩個階段,一個階段是早些年常見的集中式系統,一個階段是近年來流行的分布式系統;
集中式系統也叫單體應用,就是把所有的程序、功能、模塊都集中到一個項目中,部署在一臺服務器上,從而對外提供服務;
分布式系統就是把所有的程序、功能拆分成不同的子系統,部署在多臺不同的服務器上,這些子系統相互協作共同對外提供服務,而對用戶而言他并不知道后臺是多個子系統和多臺服務器在提供服務,在使用上和集中式系統一樣;
集中式系統跟分布式系統是相反的兩個概念,他們的區別體現在“合”與“分”。
系統進化的背景與中國互聯網用戶規模龐大有巨大關系,中國互聯網用戶規模有7.7億,龐大的用戶訪問量對系統的架構設計是巨大的挑戰;
產品或者網站初期,通常功能較少,用戶量也不多,所以一般按照單體應用進行設計和開發,按照經典的MVC三層架構設計;
隨著業務的發展,應用功能的增加,訪問用戶的增多,傳統的采用集中式系統進行開發的方式就不再適用了,因為在這種情況下,集中式系統就會逐步變得非常龐大,很多人維護這么一個系統,開發、測試、上線都會造成很大問題,比如代碼沖突,代碼重復,邏輯錯綜混亂,代碼邏輯復雜度增加,響應新需求的速度降低,隱藏的風險增大;
所以需要按照業務維度進行應用拆分,采用分布式開發,每個應用專職于做某一些方面的事情,比如將一個集中式系統拆分為用戶服務、訂單服務、產品服務、交易服務等,各個應用服務之間通過相互調用完成某一項業務功能。
分布式強調系統的拆分,微服務也是強調系統的拆分,微服務架構屬于分布式架構的范疇;
并且到目前為止,微服務并沒有一個統一的標準的定義,那么微服務究竟是什么?
微服務一詞源于Martin Fowler(馬丁.福勒)的名為 Microservices 的博文, 可以在他的官方博客上找到這篇文章:
http://martinfowler.com/articles/microservices.html
中文翻譯版本:
https://www.martinfowler.cn/articles/microservices.html
簡單地說, 微服務是系統架構上的一種設計風格, 它的主旨是將一個原本獨立的系統拆分成多個小型服務,這些小型服務都在各自獨立的進程中運行,服務之間通過基于HTTP的RESTful API進行通信協作;
被拆分后的每一個小型服務都圍繞著系統中的某一項業務功能進行構建, 并且每個服務都是一個獨立的項目,可以進行獨立的測試、開發和部署等;
由于各個獨立的服務之間使用的是基于HTTP的JSON作為數據通信協作的基礎,所以這些微服務可以使用不同的語言來開發;
1、我們知道微服務架構是將系統中的不同功能模塊拆分成多個不同的服務,這些服務進行獨立地開發和部署,每個服務都運行在自己的進程內,這樣每個服務的更新都不會影響其他服務的運行;
2、由于每個服務是獨立部署的,所以我們可以更準確地監控每個服務的資源消耗情況,進行性能容量的評估,通過壓力測試,也很容易發現各個服務間的性能瓶頸所在;
3、由于每個服務都是獨立開發,項目的開發也比較方便,減少代碼的沖突、代碼的重復,邏輯處理流程也更加清晰,讓后續的維護與擴展更加容易;
4、微服務可以使用不同的編程語言進行開發;
但是在系統架構領域關于微服務架構也有一些爭論,有人傾向于在系統設計與開發中采用微服務架構實現軟件系統的低耦合,被認為是系統架構的未來方向,Martin Fowler(馬丁.福勒)也給微服務架構很高的評價;
同時,對微服務架構也有人持反對觀點,他們表示:
1、微服務架構增加了系統維護、部署的難度,導致一些功能模塊或代碼無法復用;
2、隨著系統規模的日漸增長,微服務在一定程度上也會導致系統變得越來越復雜,增加了集成測試的復雜度;
3、隨著微服務的增多,數據的一致性問題,服務之間的通信成本等都凸顯了出來;
所以在系統架構時也要提醒自己:不要為了微服務而微服務。
微服務一詞是Martin Fowler(馬丁.福勒)于2014年提出來的,近幾年微服務架構的討論非常火熱,無數的架構師和開發者在實際項目中實踐著微服務架構的設計理念,他們在微服務架構中針對不同應用場景出現的各種問題,也推出了很多解決方案和開源框架,其中我們國內的互聯網企業也有一些著名的框架和方案;
整個微服務架構是由大量的技術框架和方案構成,比如:
服務基礎開發 | Spring MVC、Spring、SpringBoot |
服務注冊與發現 | Netflix的Eureka、Apache的ZooKeeper等 |
服務調用 |
RPC調用有阿里巴巴的Dubbo,Rest方式調用有當當網Dubbo基礎上擴展的Dubbox、 |
分布式配置管理 | 百度的Disconf、360的QConf、淘寶的Diamond、Netflix的Archaius等 |
負載均衡 | Ribbon |
服務熔斷 | Hystrix |
API網關 | Zuul |
批量任務 | 當當網的Elastic-Job、Linkedln的Azkaban |
服務跟蹤 | 京東的Hydra、Twitter的Zipkin等 |
但是在微服務架構上,幾乎大部分的開源組件都只能解決某一個場景下的問題,所以這些實施微服務架構的公司也是整合來自不同公司或組織的諸多開源框架,并加入針對自身業務的一些改進,沒有一個統一的架構方案;
所以當我們準備實施微服務架構時,我們要整合各個公司或組織的開源軟件,而且某些開源軟件又有多種選擇,這導致在做技術選型的初期,需要花費大量的時間進行預備研、分析和實驗,這些方案的整合沒有得到充分的測試,可能在實踐中會遇到各種各樣的問題;
Spring Cloud的出現,可以說是為微服務架構迎來一縷曙光,有SpringCloud社區的巨大支持和技術保障,讓我們實施微服務架構變得異常簡單了起來,它不像我們之前所列舉的框架那樣,只是解決微服務中的某一個問題,而是一個解決微服務架構實施的綜合性解決框架,它整合了諸多被廣泛實踐和證明有效的框架作為實施的基礎組件,又在該體系基礎上創建了一些非常優秀的邊緣組件將它們很好地整合起來。
加之Spring Cloud 有其Spring 的強大技術背景,極高的社區活躍度,也許未來Spring Cloud會成為微服務的標準技術解決方案;