SpringCloud接入EDAS——服務發現篇
旁白
很久沒有寫技術文章了,最近不是寫水文就是寫小說。說到底,還是最近很少研究技術的緣故,已經到了江郎才盡的地步了。
不過,LZ無意間看到自己團隊的小夥伴寫的一些文章,覺得還是不錯的,於是便動了心思,準備把這些文章拿來,也算填補一下最近技術文章缺乏的空白。
而這些文章,不光涉及到一些技術幹貨,也算是變相的給自己團隊的產品做了宣傳,這也算是一石倆鳥了吧。
引言
好了,接下來咱們進入正題。可以看到,本篇文章的標題裏有三個關鍵字,SpringCloud、EDAS以及服務發現。關於SpringCloud和EDAS咱們接下來再說,LZ想首先簡單介紹一下“服務發現”這個概念。
說到服務發現,就不得不提到很火的一個概念“微服務”,究竟什麽是“微服務”?
微服務是一個新興的軟件架構,就是把一個大型的單個應用程序和服務拆分為數十個的支持微服務。一個微服務的策略可以讓工作變得更為簡便,它可擴展單個組件而不是整個的應用程序堆棧,從而滿足服務等級協議。
以上是從百度上抄來的解釋,從字面上粗暴的理解,微服務其實就是把一個大的應用拆分成很多的小應用,而這每一個所謂的小應用,就是所謂的微服務了。
拆分成一個個微服務以後,可以得到不小的好處,最顯而易見的就是,可以節省掉很多計算資源,因為你可以針對其中某一個模塊進行擴縮容,而不再是只能對整個應用。
舉個例子,就拿淘寶來說,雙11大促的時候,每個模塊的壓力都是不同的,比如訂單系統、商品搜索、評價系統等等,其中顯而易見的是,訂單系統這部分的壓力肯定很大,但是評價系統的壓力就不會那麽大。
所以,大促期間,就可以把更多的計算資源往訂單系統傾斜,而如果這些還都是集中在一個應用中的話,那就無法做到這樣把資源充分利用了。
不過,微服務雖然有諸多好處,但也會同樣引入一些問題。
最典型的問題,就是所謂的“服務發現”,那究竟什麽叫服務發現?
簡單地說,一個應用改成微服務以後,大家都在這個池子裏,誰發布了什麽服務,這個事情是需要讓池子裏的各個微服務知道的,否則的話,服務之間調用就不知道該找誰了。
所以,一個服務發布了以後,怎麽“發現”它,就成了微服務體系中一個重要的事情。
那麽怎麽解決這個事情,思路也很簡單,拿淘寶來舉例,我現在要買一個娃娃,怎麽才能買到呢?
首先第一件事是,賣娃娃的商家要把自己的店開到淘寶上,然後我去淘寶上搜索“娃娃”這個關鍵字,然後淘寶就告訴我一堆賣娃娃的商家,我再從這些商家裏選出來一家,最終就可以買到我想要的娃娃了。
那麽結合以上買娃娃的過程,放到微服務這個“市場”裏,也是類似的。首先得現有一個淘寶這樣的平臺,一般我們叫它“服務註冊中心”,然後,每一個微服務模塊發布了一個服務的時候,都需要到這個“服務註冊中心”去註冊一下,類似於賣家去淘寶上開店的操作。
接下來,調用者一方在調用的時候,就先去“服務註冊中心”查詢一下,這個就相當於去淘寶上搜索“娃娃”的操作,最終,調用者從“服務註冊中心”返回的服務提供者列表裏選取一個,最終調用成功。
當然了,在調用者選取服務提供者的時候,“服務註冊中心”又或者是調用者自己,也可以有一定的排序算法,比如同機房的優先調用,或者壓力小的優先調用等等。
這其實在淘寶那個例子中也同樣適用,比如你搜索“娃娃”,淘寶也會給你按銷量或者是按評價,對賣娃娃的商家進行綜合排序,以便給你篩選出最適合你的娃娃。
SpringCloud的服務發現
好了,LZ先簡單介紹了一下微服務和服務發現的概念,那麽接下來,就來談談SpringCloud吧。
SpringCloud是什麽玩意呢?
Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems.
上面這一段英文,是SpringCloud官網的解釋,翻譯過來的意思就是SpringCloud提供了一堆工具給開發者,讓開發者可以很快的,構建一套通用模式的分布式系統。
而這些SpringCloud提供的工具中,其中有一個,就是“服務發現”。
在SpringCloud的支持體系中,有Eureka、Consul、Zookeeper等幾種服務發現的支持,但是目前使用最廣的,無疑就是Eureka了。接下來咱們就通過一個demo,來看看Eureka怎麽使用的。
1. 啟動一個服務註冊中心(相當於上面例子中的淘寶網站)
創建一個基礎的 Spring Cloud 工程,命名為 eureka-server,並在 pom.xml 中引入需要的依賴內容:
<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>1.5.8.RELEASE</version> <relativePath/> </parent> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-eureka-server</artifactId> </dependency> </dependencies> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>Dalston.SR4</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement>
通過 @EnableEurekaServer 註解來啟動一個服務註冊中心。只需要在一個普通的 Spring Boot 應用中添加這個註解就能開啟此功能,代碼如下:
@SpringBootApplication @EnableEurekaServer public class EurekaServerApplication { public static void main(String[] args) { SpringApplication.run(EurekaServerApplication.class, args); } }
這樣啟動時,應用將完全只用默認配置,如果想給服務命名,或者是修改監聽端口,可以在 resource/application.properties 中進行如下配置。由於此工程就是唯一的一個 EurekaServer ,這裏就不向自己註冊自己了,將 register-with-eureka 設置成 false。
spring.application.name=eureka-server server.port=8761 eureka.client.register-with-eureka=false
只需要直接運行 EurekaServerApplication 的 main 函數,eureka server 即可啟動成功。啟動成功以後,可以查看 http://localhost:8761 查看eureka server的詳情。
當然,頁面打開成功,只是表明服務已經啟動,目前 instances 為空,表明還沒有服務註冊上來。
2.創建服務提供者(相當於上面例子中的賣家)
創建一個 Spring Cloud 工程,命名為 service-provider。同樣,首先在 pom.xml 中引入需要的依賴內容。
<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>1.5.8.RELEASE</version> <relativePath/> </parent> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-eureka</artifactId> </dependency> </dependencies> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>Dalston.SR4</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement>
接著是服務提供端的代碼,其中 @EnableDiscoveryClient 註解表明此應用需開啟服務註冊與發現功能。
@SpringBootApplication @EnableDiscoveryClient public class ServerApplication { public static void main(String[] args) { SpringApplication.run(ServerApplication.class, args); } }
既然是服務提供者,所以我們還需要提供一個簡單的服務。
@RestController public class EchoController { @RequestMapping(value = "/echo/{string}", method = RequestMethod.GET) public String echo(@PathVariable String string) { return string; } }
最後同樣是配置,除去配置應用名與監聽端口外,還需要配置一下 Eureka Server 的地址。
spring.application.name=service-provider server.port=18081 eureka.client.serviceUrl.defaultZone=http://localhost:8761/eureka/
啟動 service-provider 服務,在 Eureka 頁面查看服務是否已經註冊成功,可以看到 instances 中已經存在的實例 service-provider,端口是 18081。
3.創建服務消費者(相當於上面例子中的買家)
這個例子中,我們將不僅僅是演示服務發現的功能,同時還將演示 Eureka 服務發現 與 RestTemplate、AsyncRestTemplate、FeignClient這三個客戶端是如何結合的。因為實際使用中,我們更多使用的是用這三個客戶端進行服務調用。
創建一個 Spring Cloud 工程,命名為 service-consumer。同樣,首先在 pom.xml 中引入需要的依賴內容:
<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>1.5.8.RELEASE</version> <relativePath/> </parent> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-eureka</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-feign</artifactId> </dependency> </dependencies> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>Dalston.SR4</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement>
因為在這裏我們要演示 FeignClient 的使用,所以與 service-provider 相比,pom.xml文件中的依賴增加了一個 spring-cloud-starter-feign。
配置好依賴後,在啟動函數裏添加三個註解,使用 @EnableDiscoveryClient 註解啟用服務註冊與發現,使用 @EnableFeignClients 註解激活 FeignClients,添加 @LoadBalanced 註解將 RestTemplate 與 AsyncRestTemplate 與服務發現結合。
@SpringBootApplication @EnableDiscoveryClient @EnableFeignClients public class ConsumerApplication { @LoadBalanced @Bean public RestTemplate restTemplate() { return new RestTemplate(); } @LoadBalanced @Bean public AsyncRestTemplate asyncRestTemplate(){ return new AsyncRestTemplate(); } public static void main(String[] args) { SpringApplication.run(ConsumerApplication.class, args); } }
在使用 FeignClient 之前,我們還需要完善它的配置,配置服務名以及方法對應的HTTP請求,其中代碼如下:
@FeignClient(name = "service-provider") public interface EchoService { @RequestMapping(value = "/echo/{str}", method = RequestMethod.GET) String echo(@PathVariable("str") String str); }
然後,我們就可以在 Controller 中直接使用他們。
@RestController public class Controller { @Autowired private RestTemplate restTemplate; @Autowired private AsyncRestTemplate asyncRestTemplate; @Autowired private EchoService echoService; @RequestMapping(value = "/echo-rest/{str}", method = RequestMethod.GET) public String rest(@PathVariable String str) { return restTemplate.getForObject("http://service-provider/echo/" + str, String.class); } @RequestMapping(value = "/echo-async-rest/{str}", method = RequestMethod.GET) public String asyncRest(@PathVariable String str) throws Exception{ ListenableFuture<ResponseEntity<String>> future = asyncRestTemplate. getForEntity("http://service-provider/echo/"+str, String.class); return future.get().getBody(); } @RequestMapping(value = "/echo-feign/{str}", method = RequestMethod.GET) public String feign(@PathVariable String str) { return echoService.echo(str); } }
最後,還是不能忘了配置,特別是服務註冊中心的地址。
spring.application.name=service-consumer server.port=18082 eureka.client.serviceUrl.defaultZone=http://localhost:8761/eureka/
啟動服務,分別進行調用,可以看到調用都成功了。不過需要註意,AsyncRestTemplate 接入服務發現的時間比較晚,需要在 Dalston 之後的版本才能使用,具體詳情參見此 pull request
Eureka 的煩惱
前面的例子在本機工作起來是很方便的,但是很遺憾,這只是一個 demo ,實際部署中我們可能都踩過坑或者有這麽一些不爽。
- 只有一個服務註冊中心,顯然這不符合高可用的原則,高可用就得增加
eureka server 的數量,維護成本太高了。 - 實際生產中,不會將服務註冊中心與業務服務部署在同一臺機器上。實際部署中,當 eureka server 的地址發生變化時,還得修改配置文件裏 eureka server的地址,太麻煩了。
- 實際使用中,服務註冊發現中心的安全性也是需要考慮的,應該對服務註冊和發現的請求進行鑒權,來確保服務的安全性,安全也是急需解決的問題。
- eureka 使用過程中,有可能出現註冊上去的服務地址不是一個 ip ,而是一個 hostname 的情況,事實上又無法通過 hostname 進行服務調用。其實只是因為沒有增加 eureka.instance.prefer-ip-address=true這個配置,依舊需要添加配置。
- eureka 因為緩存設計的原因,使得服務註冊上去之後,最遲需要兩分鐘後才能發現。
或許你希望有人提供一個安全、穩定、高可用、高性能、簡單易用的服務註冊中心。它的配置更加簡單,而且又與原來寫好的eureka代碼完全兼容。
這個怎麽辦呢?
重點來了,LZ要插廣告了,註意!
EDAS就是你理想中的選擇,你只需要簡單修改幾行代碼,即可得到以下好處。
- 穩定高可用的服務註冊中心
- 安全的服務註冊、服務發現
- 秒級的服務發現機制
- 無需再關心服務註冊中心的地址
EDAS 服務註冊中心
1.安裝輕量版配置中心(相當於Eureka的服務註冊中心)
這個安裝過程很簡單,這裏就不再贅述了,詳情可以參考 輕量級配置中心 。唯一需要註意的是,最後在應用啟動時,需要配置一個 JVM 參數,配置如下。
//windows中修改startup.bat如下這一行 %_EXECJAVA% -Daddress.server.ip=%SERVER_IP% -Dvipserver.server.port=8080 -jar edas-config-center.jar //linux中修改startup.sh如下這一行 nohup $JAVA -Daddress.server.ip=$SERVER_IP -Dvipserver.server.port=8080 -jar edas-config-center.jar >/dev/null 2>&1 &
然後按照文檔所描述,windows下直接執行startup.bat,linux下執行startup.sh即可。
最終,你也會看到一個和Eureka類似的頁面,當然,現在這個頁面當中是沒有服務的。
另外,EDAS的輕量版配置中心啟動以後,不光內嵌了一個簡單的開發版服務註冊中心,還包含了一個簡單的分布式配置服務,以下這個頁面可以進行配置的維護操作。
這個分布式配置服務相當於SpringCloud體系中的Spring Cloud Config,不過這個和本文主線沒有什麽關系,這裏就暫且不詳談了。
2.服務提供者和消費者代碼修改
關於Java源碼的修改,只有兩行,需要在 main 函數中添加兩行,修改之後的 service-provider 的 main 函數如下。
public static void main(String[] args) { PandoraBootstrap.run(args);//引入Pandora SpringApplication.run(ServerApplication.class, args); PandoraBootstrap.markStartupAndWait();//引入Pandora }
pom.xml 的修改有兩點,一個是將原來的 eureka 的 starter 替換成 EDAS 服務註冊中心的starter,並加入 pandora 的依賴。修改之後的service-provider 的pom文件如下:
<dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-vipclient</artifactId> <version>1.1</version> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-pandora</artifactId> <version>1.2</version> </dependency> </dependencies>
另外一個則是在 build 的 plugins 中,也需要修改成 EDAS 的方式,修改後的內容如下,版本號後續可能會升級。
<build> <plugins> <plugin> <groupId>com.taobao.pandora</groupId> <artifactId>pandora-boot-maven-plugin</artifactId> <version>2.1.7.8</version> <executions> <execution> <phase>package</phase> <goals> <goal>repackage</goal> </goals> </execution> </executions> </plugin> </plugins> </build>
最後一步,由於目前以上jar包尚未進入中央倉庫,所以還需要配置下 maven 的私服地址,修改settings.xml配置如下。
<settings> <localRepository>/Users/../.m2/repository</localRepository> <profiles> <profile> <id>nexus</id> <repositories> <repository> <id>central</id> <url>http://repo1.maven.org/maven2</url> <releases> <enabled>true</enabled> </releases> <snapshots> <enabled>true</enabled> </snapshots> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>central</id> <url>http://repo1.maven.org/maven2</url> <releases> <enabled>true</enabled> </releases> <snapshots> <enabled>true</enabled> </snapshots> </pluginRepository> </pluginRepositories> </profile> <profile> <id>edas.oss.repo</id> <repositories> <repository> <id>edas-oss-central</id> <name>taobao mirror central</name> <url> http://edas-public.oss-cn-hangzhou.aliyuncs.com/repository </url> <snapshots> <enabled>true</enabled> </snapshots> <releases> <enabled>true</enabled> </releases> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>edas-oss-plugin-central</id> <url> http://edas-public.oss-cn-hangzhou.aliyuncs.com/repository </url> <snapshots> <enabled>true</enabled> </snapshots> <releases> <enabled>true</enabled> </releases> </pluginRepository> </pluginRepositories> </profile> </profiles> <activeProfiles> <activeProfile>nexus</activeProfile> <activeProfile>edas.oss.repo</activeProfile> </activeProfiles> </settings>
OK,到這裏所有的都已經修改好了,service-consumer 的修改方式與 service-provider 的修改方式完全一樣,這裏就不再贅述了。
當你將service-provider和service-consumer啟動以後,便可以在輕量版配置中心的頁面當中看到對應的服務提供者和調用者。
當然,你也可以直接從官網上直接下載寫好的demo。
server-demo
client-demo
EDAS輕量版配置中心原理簡介
換了一個pom依賴,加了兩行代碼就把 Eureka 替換成了 EDAS 服務註冊中心,雖然方便,但是這對於你來說也許相當於是一個黑盒,黑盒總是讓人很沒有安全感。下面LZ將從服務註冊中心尋址、服務註冊和下線、客戶端結合、高可用和安全多個方面,來簡單介紹一下。
服務註冊中心尋址
既然不需要在配置文件裏配置服務註冊中心的地址了,那麽客戶端是如何找到服務中心的呢? 其實是通過一個http請求來實現的,地址為http://jmenv.tbsite.net/vipserver/serverlist。無論是服務端還是客戶端,都會利用這個地址來進行服務發現,這個地址就相當於在Eureka中的http://localhost:8761/eureka這個地址的作用。 唯一的區別就是,當你使用EDAS時,這個配置是默認自帶的,所以省去了這部分工作。
服務註冊與下線
服務註冊的通信協議是http協議,默認註冊的應用名是 spring.application.name 的value值,如果有需要將某個應用發布成多個服務名的話,也可以在application.properties文件裏添加以下配置,來把當前應用發布成多個服務名。
vipserver.register.doms=applicationServiceName1,applicationServiceName2
舉個實例的場景,比如有一個應用,集成了訂單、商品管理等功能,那可能你會希望給這個應用起兩個服務名,比如order和product,這個時候,這個應用就可以獨自提供兩個服務給外部使用。
關於服務下線,其實是利用的典型的心跳機制,由服務提供者向服務註冊中心發送心跳,當心跳超過一定時長不正常的情況下,服務註冊中心便會將該服務提供者從列表中移出,如果此時沒有其它服務提供者提供同樣的服務,那麽這個服務就會被下線掉。
EDAS服務發現客戶端原理簡介
上面更多的講的是服務註冊中心的原理解釋,接下來咱們來看看,客戶端這一塊,EDAS是如何與SpringCloud做兼容的。
簡單地說,EDAS其實對SpringCloud的三個http客戶端做了兼容,分別是FeignClient、RestTemplate、AsyncRestTemplate,那麽接下來,咱們就以RestTemplate、AsyncRestTemplate為例,簡單了解下EDAS如何做的兼容。
對於這兩個rest客戶端的Bean來說,只要加上@LoadBalanced 註解,就可以接入EDAS服務發現。
具體是怎麽實現的呢?
其實在SpringCloud當中,當給RestTemplate、AsyncRestTemplate添加了LoadBalanced註解以後,他們會被兩個攔截器所攔截,即LoadBalancerInterceptor 和 AsyncLoadBalancerInterceptor。
而這兩個攔截器其實是通過LoadBalancerClient這個對象是處理的,這個接口只有一個實現,叫做RibbonLoadBalancerClient。
我們分析一下這個類的代碼,不難發現,這個類在做負載均衡的時候,是依靠一個叫做ILoadBalancer的接口來處理的,代碼如下。
ILoadBalancer loadBalancer = getLoadBalancer(serviceId);
Server server = getServer(loadBalancer);
這個接口有幾個實現,DynamicServerListLoadBalancer、NoOpLoadBalancer、ZoneAwareLoadBalancer等。其中NoOpLoadBalancer這個實現只是一個空實現,而最主要的就是DynamicServerListLoadBalancer和ZoneAwareLoadBalancer。
而其中ZoneAwareLoadBalancer又是DynamicServerListLoadBalancer的子類,我們觀察DynamicServerListLoadBalancer這個類的邏輯可以發現,它的服務者列表其實是由一個叫做ServerList的接口所實現的。
這個接口只有兩個方法,一個是獲取初始列表,一個是更新服務者列表。
public interface ServerList<T extends Server> { public List<T> getInitialListOfServers(); /** * Return updated list of servers. This is called say every 30 secs * (configurable) by the Loadbalancer‘s Ping cycle * */ public List<T> getUpdatedListOfServers(); }
而EDAS所做的,就是實現了一個自己的ServerList,名為VipserverList,並且搶先把這個Bean給註入了進去,就像下面這樣。
@Bean @ConditionalOnMissingBean public ServerList<Server> ribbonServerList(IClientConfig config) { return new VipserverList(config.getClientName()); }
這個VipserverList,其實就是連接的輕量版配置中心,因此如此一來,客戶端所獲取的服務者列表將會由輕量版配置中心來維護,並根據負載均衡策略,提供給客戶端選擇。
EDAS服務發現高可用
服務端高可用:
- Eureka
Eureka的多個server 是對等的實體,在 CAP 中選擇了 AP。
節點間的數據使用的是最終一致性,eureka 會將註冊的信息同步到 peer 節點,但是 peer 節點不會二次傳播。
peer節點需要顯示地在配置中設置。如果 peer 節點配置的不全,那麽集群的概念也不存在了,節點之間的關系是通過 peer 節點的顯示配置來維護的。 - EDAS
EDAS 服務註冊中心的多個 server,存在主從,各節點之間使用 raft 協議保證一致性。
server 之間的互相感知是通過訪問 http://jmenv.tbsite.net/vipserver/serverlist 來獲取其他 peer 節點地址來實現的。
然後通過自定義的端口和協議來進行選舉和數據同步等操作,CAP 中選擇的是 CP。
客戶端高可用:
- Eureka
通過本地緩存來實現,當 server 連接不上時,直接使用本地緩存。每 30s 異步更新一次緩存,避免了每次請求都強依賴於服務註冊中心。 - EDAS
通過本地緩存來實現,當 server 連接不上時,直接使用本地緩存。異步更新緩存,避免了每次請求都強依賴於服務註冊中心。同時,還提供了通過 UDP 主動 push 的方式在新服務節點加入時及時通知。
EDAS服務發現安全
EDAS 服務註冊發現組件,結合 EDAS 已有的安全功能,在每次註冊、心跳和查詢請求中都添加了驗簽鑒權的操作,確保了服務的安全性。
小結
好了,本文主要就是簡單介紹下SpringCloud的服務發現,順便和EDAS的服務發現簡單對比下,還囫圇吞棗的介紹了下EDAS服務發現的部分實現原理。
當然,順便......真的是順便......再打上一波廣告。
現在微服務的概念基本已經普及到了大大小小的公司,很多公司,特別是一些笨重的傳統企業IT系統,都在往微服務的方向靠攏。
那麽靠攏的過程中,肯定要選擇一個合適的方案。
這其實就涉及到一個選擇問題,到底是選擇開源版產品,還是選擇商業版產品?
從LZ個人的感受來說,如果是五年前的LZ,一定會選擇開源,但現在的LZ,一定會選擇商業。
因為使用開源的過程往往是踩坑的過程,而對於五年前的LZ來說,踩坑可以很快的提高LZ的技術。但五年過去了,如果現在再讓LZ選擇,LZ更加看重的是高效的解決問題,而踩坑的代價往往是很大的。
不管怎麽說,這就是LZ的真實想法,這絕不是在誘導你掏腰包,相信LZ!
參考文章鏈接:https://yq.aliyun.com/articles/255160
EDAS產品主頁:https://www.aliyun.com/product/edas
SpringCloud接入EDAS——服務發現篇