2023年2月20日

BladeX(SpringCloud)介紹

前言

這一兩年因為工作需要接觸了基於BladeX的Spring Cloud,深刻體會到Spring Cloud的博大精深,因為這是中國公司以Spring Cloud集成的微服務架構系統,台灣知道的人比較少,這邊就介紹下這個大傢伙。
另外,前一篇介紹了我對JavaScript和NodeJS的看法,這篇也會帶入,既然NodeJS這麼好,BladeX適用情境在哪?

BladeX介紹
BladeX是由上海布雷德科技有限公司集成的Spring Cloud解決方案,產品稱為BladeX
BladeX包括開源版和商業版,不用懷疑,大家都用商業版,開源版基本上只用做入門,事實上以商業版而言,它的價格不算貴,商業版授權大概台幣30,000左右,無使用限制、無授權期限制、無升級版本限制,基本上就是買一次,無限使用。
BladeX有2個版本,BladeX和BladeX Boot,兩個版本分別對應Spring Cloud和Spring Boot。
使用上,大部分使用者都使用BladeX,BladeX Boot版本用的人很少很少。

BladeX系統需求
BladeX的架構是所謂的微服務2.0。
BladeX要佈署和運行,至少需要 MySQL、Nacos、Redis,其系統需求,除去MySQL、Redis、Nacos這3台伺服器外,通常還需要3台每台至少8GB(建議16GB)記憶體的伺服器。

上述意思是,BladeX的運作環境,伺服器需求6台起跳。

Spring Cloud與BladeX架構介紹
以Web Service觀點看Spring Cloud,Spring Cloud是目前Web後端微服務2.0架構的主流。
以前以SOAP Protocol為基礎的Java 2 Enterprise Edition (J2EE),目前都改以Spring架構實做。
單從Protocol觀點而言,J2EE使用SOAP為基礎,SOAP以RPC + HTTP + XML組成,Spring則以(WebSocket) + REST API + HTTP + json組成。
既然對比的是J2EE,Spring Cloud的特點是在高穩定、模塊化、大架構、分散式的企業級應用情境。
Spring Cloud由許多輕量級組件組合而成,我們從下面這個架構圖看起:











這張架構圖算是比較簡潔的圖,先以這張圖描述服務註冊(Service Register)和服務發現(Service Discovery)。

Spring Cloud的架構中,以服務註冊(Service Register)和服務發現(Service Discovery)為基礎,在Spring Cloud中,一般用Eureka (BladeX中是Nacos)。
所謂的服務註冊(Service Register),是系統中所有要運行的微服務,在加入系統時,都要先透過Eureka進行註冊(Service Register),服務註冊後,系統內要呼叫和使用服務時,都可以透過Eureka的服務發現(Service Discovery),自動的找出相對應服務的微服務。
例如:
上圖中右側有個Auth Service,是使用者認證用的,要在上圖系統中使用Auth Service
首先,要先在Eureka (BladeX是Nacos)中先註冊Auth Service
使用時,要使用的程式要先詢問Eureka (BladeX是Nacos),Auth Service是誰?Eureka (BladeX是Nacos)會將Auth Service的IP和Port回傳給要使用的程式。
這個註冊和使用過程看起來有點複雜,在Spring Cloud中,呼叫、查詢和使用封裝在Feign Client API當中,透過呼叫和使用Feign Client API,它底層直接將上述行為處理完成。

在寫程式時,我們會需要全域變數紀錄和處理環境變數,並讓系統內所有程式都能存取,同樣的,Spring Cloud的微服務也需要存取共用的變數資料,在Spring Cloud中,並不將它稱為變數,而將它稱為Config或設置參數。
因為這些Config需要能夠共用,因此這些Config需要特定一個服務儲存和管理,它就是上述架構途中的Spring Cloud Config(BladeX中是Nacos)。
系統內所有的微服務,都能夠透過存取Spring Cloud Config(BladeX是Nacos),儲存和讀取Config。
例如:
微服務要能存取MySQL,通常會將MySQL的JDBC URL存放在Spring Cloud Config(BladeX是Nacos),使用時取出。

前面提到過,BladeX是Spring Cloud集成的解決方案,在BladeX當中,上述的服務註冊(Service Register)、服務發現(Service Discovery)和Config參數管理,都是透過Nacos管理的,而Nacos是阿里巴巴針對Spring Cloud開發的輕量級服務。

Spring Cloud中包含很多微服務,實際使用時,Client端通常不會直接存取微服務,Client端一般會透過Spring Cloud的API Gateway存取,在Spring Cloud中是ZUUL,而在BladeX中,它包含了一個稱為bladex gateway的微服務。
架構圖如下:

BladeX的bladex gateway和ZUUL作用相同。
所有Client都存取API Gateway,ZUUL和其他微服務的需求,則透過Feign Client API互相存取,中間存取的API,都是REST API,資料格式都是json。

BladeX(Spring Cloud)與php/express/django比較
典型的Web應用,通常由SQL(常見MySQL)、Apache、Web Backend、Web Frontend組成。
通常SQL一台,Apache和Web Backend一台,其他Client端都在系統外部。
這樣的應用,一般使用php/nodejs express/python django都能方便開發,經典的CRUD這類都足夠並方便使用,我自己估計,大概9成的應用都屬於此。
BladeX與Spring Cloud適用在企業的大型Web應用,它最基本需要穩定,還需要模組化,能夠以模組形式開發新服務,還需要具備分散式系統的橫向擴充性。
例如:
當希望有多個Client入口分散系統負載時,直接開多個API Gateway即可,只要確定Nacos內API Gateway有多個Instance,就能橫向擴展服務。

上述這些需求,會讓系統架構的複雜度變高,比較不適合直接用php/express/django開發,底層需要的API和SDK太多太雜。
舉個例子:
Nacos有NodeJS的API,透過呼叫Nacos API,NodeJS也能做到服務發現、服務註冊、Config存取,但這個只是Nacos API,並不是Feign Client API,實際在開發微服務時,需要大量使用Feign Client API存取其他微服務,光是要把NodeJS Nacos API包裝成Feign Client API,就要花費很多時間成本,而在BladeX中,Feign Client API只是其中一組常用的API,其他像是資料庫ORM的MyBatis API、加解密API...等,大概有10幾組API,不大可能全部用NodeJS重造輪子。

結論
BladeX是博大精深的微服務Web Framework,它集成了認證、會員管理、後台管理界面...等功能,它的系統集成了以Nacos為基礎的許多輕量級Spring Cloud組件服務,且能夠擴展支援包括Prometheus...等監控系統服務,承襲Spring Cloud的架構、模組化設計、橫向擴充能力、服務管理...等特點,讓大型Web應用的開發變得容易。
同時,BladeX與Spring Cloud這類Web Framework的設計目標,並不是使用在常見的小型Web應用,如果開發的目標項目是一般會員網站或功能網站,系統需求鎖定在2台以下的Web Server時,以express/django開發可能更為簡單方便。
(圖與排版後續補上)

沒有留言: