這一兩年因為工作需要接觸了基於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開發可能更為簡單方便。
(圖與排版後續補上)
沒有留言:
張貼留言