轉載自?干貨｜基于 Spring Cloud 的微服務落地

微服務架構模式的核心在于如何識別服務的邊界，設計出合理的微服務。但如果要將微服務架構運用到生產項目上，并且能夠發揮該架構模式的重要作用，則需要微服務框架的支持。

在Java生態圈，目前使用較多的微服務框架就是集成了包括Netfilix OSS以及Spring的Spring Cloud。它包括：

• Spring Cloud Config：配置管理工具，支持使用Git存儲配置內容，可以實現應用配置的外部化存儲，支持客戶端配置信息刷新、加密/解密配置內容等。

• Spring Cloud Netflix：對Netflix OSS進行了整合。其中又包括：

  • Eureka：服務治理組件，包含服務注冊中心、服務注冊與發現。

  • Hystrix：容器管理組件，實現斷路器模式，倘若依賴的服務出現延遲或故障，則提供強大的容錯功能。

  • Ribbon：客戶端負載均衡的服務調用組件。

  • Feign：基于Ribbon和Hystrix的聲明式服務調用組件。

  • Zuul：網關組件，提供智能路由、訪問過濾等功能。

  • Archaius：外部化配置組件。

• Spring Cloud Bus：事件、消息總線。

• Spring Cloud Cluster：針對ZooKeeper、Redis、Hazelcast、Consul的選舉算法和通用狀態模式的實現。

• Spring Cloud Cloudfoundry：與Pivotal Cloudfoundry的整合支持。

• Spring Cloud Consul：服務發現與配置管理工具。

• Spring Cloud Stream：通過Redis、Rabbit或者Kafka實現的消息驅動的微服務。

• Spirng Cloud AWS：簡化和整合Amazon Web Service。

• Spring Cloud Security：安全工具包，提供Zuul代理中對OAuth2客戶端請求的中繼器。

• Spring Cloud Sleuth：Spring Cloud應用的分布式跟蹤實現，可以整合Zipkin。

• Spring Cloud ZooKeeper：基于ZooKeeper的服務發現與配置管理組件。

• Spring Cloud Starters：Spring Cloud的基礎組件，是基于Spring Boot風格項目的基礎依賴模塊。

• Spring Cloud CLI：用于在Groovy中快速創建Spring Cloud應用的Spring Boot CLI插件。

服務治理

當一個系統的微服務數量越來越多的時候，我們就需要對服務進行治理，提供統一的服務注冊中心，然后在其框架下提供發現服務的功能。這樣就避免了對多個微服務的配置，以及微服務之間以及與客戶端之間的耦合。

Spring Cloud Eureka是對Netflix Eureka的包裝，用以實現服務注冊與發現。Eureka服務端即服務注冊中心，支持高可用配置。它依托于強一致性提供良好的服務實例可用性，并支持集群模式部署。Eureka客戶端則負責處理服務的注冊與發現。客戶端服務通過annotation與參數配置的方式，嵌入在客戶端應用程序代碼中。在運行應用程序時，Eureka客戶端向注冊中心注冊自身提供的服務，并周期性地發送心跳更新它的服務租約。

搭建服務注冊中心

服務注冊中心是一個獨立部署的服務（你可以認為它也是一個微服務），所以需要單獨為它創建一個項目，并在pom.xml中添加Eureka的依賴：

<dependency> ? ?<groupId>org.springframework.cloud</groupId> ? ?<artifactId>spring-cloud-starter-eureka-server</artifactId> </dependency>

創建Spring Boot Application：

@EnableEurekaServer @SpringBootApplication public class Application { ? ?public static void main(String[] args) { ? ? ? ?new SpringApplicationBuilder(Application.class).web(true).run(args); ? ?} }

注冊服務提供者

要讓自己編寫的微服務能夠注冊到Eureka服務器中，需要在服務的Spring Boot Application中添加@EnableDiscoveryClient注解，如此才能讓Eureka服務器發現該服務。當然，pom.xml文件中也需要添加相關依賴：

<dependency> ? ?<groupId>org.springframework.cloud</groupId> ? ?<artifactId>spring-cloud-starter-eureka</artifactId> </dependency>

同時，我們還需要為服務命名，并指定地址。這些信息都可以在application.properties配置文件中配置：

spring.application.name=demo-service eureka.client.serviceUrl.defaultZone=http://localhost:1111/eureka/

說明：Spring更推薦使用yml文件來維護系統的配置，yml文件可以體現出配置節的層次關系，表現力比單純的key-value形式更好。如果結合使用后面講到的Spring Cloud Config，則客戶端的配置文件必須命名為bootstrap.properties或者bootstrap.yml。與上述配置相同的yml文件配置為：

spring: ?application: ? ?name: demo-service eureka: ?client: ? ?serviceUrl: ? ? ?defaultZone: http://localhost:1111/eureka/

服務發現與消費

在微服務架構下，許多微服務可能會扮演雙重身份。一方面它是服務的提供者，另一方面它又可能是服務的消費者。注冊在Eureka Server中的微服務可能會被別的服務消費。此時，就相當于在服務中創建另一個服務的客戶端，并通過RestTemplate發起對服務的調用。為了更好地提高性能，可以在服務的客戶端引入Ribbon，作為客戶端負載均衡。

現在假定我們要為demo-service創建一個服務消費者demo-consumer。該消費者自身也是一個Spring Boot微服務，同時也能夠被Eureka服務器注冊。這時，就需要在該服務的pom.xml中添加eureka與ribbon的依賴：

<dependency> ? ?<groupId>org.springframework.cloud</groupId> ? ?<artifactId>spring-cloud-starter-eureka</artifactId> </dependency> <dependency> ? ?<groupId>org.springframework.cloud</groupId> ? ?<artifactId>spring-cloud-starter-ribbon</artifactId> </dependency>

然后在主應用類ConosumerApplication中注入RestTemplate，并引入@LoadBalanced注解開啟客戶端負載均衡：

@EnableDiscoveryClient @SpringBootApplication public class ConsumerApplication { ? ?@Bean ? ?@LoadBalanced ? ?RestTemplate restTemplate() { ? ? ? ?return new RestTemplate(); ? ?} ? ?public static void main(String[] args) { ? ? ? ?SpringApplication.run(ConsumerApplication.class, args) ? ?} }

假設消費demo-service的客戶端代碼寫在demo-consumer服務的其中一個Controller中：

@RestController public class ConsumerController { ? ?@Autowired ? ?RestTemplate restTemplate; ? ?@RequestMapping(value = "/demo-consumer", method = RequestMethod.Get) ? ?public String helloConsumer() { ? ? ? ?return restTemplate.getForEntity("http://demo-service/demo", String.class).getBody(); ? ?} }

通過RestTemplate就可以發起對demo-service的消費調用。

聲明式服務調用

通過Ribbon和Hystrix可以實現對微服務的調用以及容錯保護，但Spring Cloud還提供了另一種更簡單的聲明式服務調用方式，即Spring Cloud Feign。Feign實際上就是對Ribbon與Hystrix的進一步封裝。通過Feign，我們只需創建一個接口并用annotation的方式配置，就可以完成對服務供應方的接口（REST API）綁定。

假設我們有三個服務：

• Notification Service

• Account Service

• Statistics Service

  
  

服務之間的依賴關系如下圖所示：

要使用Feign來完成聲明式的服務調用，需要在作為調用者的服務中創建Client。Client通過Eureka Server調用注冊的對應服務，這樣可以解除服務之間的耦合。結構如下圖所示：

為了使用Feign，需要對應微服務的pom.xml文件中添加如下依賴：

<dependency> ? ?<groupId>org.springframework.cloud</groupId> ? ?<artifactId>spring-cloud-starter-feign</artifactId> </dependency>

同時，還需要在被消費的微服務Application中添加@EnableFeignClients注解。例如在Statistics服務的應用程序類中：

@SpringBootApplication @EnableDiscoveryClient @EnableFeignClients public class StatisticsApplication { ? ?public static void main(String[] args) { ? ? ? ?SpringApplication.run(StatisticsApplication.class, args); ? ?} }

由于Account服務需要調用Statistics服務，因此需要在Account服務項目中增加對應的client接口：

@FeignClient(name = "statistics-service") public interface StatisticsServiceClient { ? ?@RequestMapping(method = RequestMethod.PUT, value = "/statistics/{accountName}", consumes = MediaType.APPLICATION_JSON_UTF8_VALUE) ? ?void updateStatistics(@PathVariable("accountName") String accountName, Account account); }

StatisticsServiceClient接口的updateStatistics()方法會調用URI為/statistics/{accountName}的REST服務，且HTTP動詞為put。這個服務其實對應就是Statistics Service中StatisticsController類中的saveStatistics()方法：

@RestController public class StatisticsController { ? ?@Autowired ? ?private StatisticsService statisticsService; ? ?@RequestMapping(value = "/{accountName}", method = RequestMethod.PUT) ? ?public void saveStatistics(@PathVariable String accountName, @Valid @RequestBody Account account) { ? ? ? ?statisticsService.save(accountName, account); ? ?} }

在Account服務中，如果要調用Statistics服務，都應該通過StatisticsServiceClient接口進行調用。例如，Account服務中的AccountServiceImpl要調用updateStatistics()方法，就可以在該類的實現中通過@autowired注入StatisticsServiceClient接口：

@Service public class AccountServiceImpl implements AccountService { ? ?@Autowired ? ?private StatisticsServiceClient statisticsClient; ? ?@Autowired ? ?private AccountRepository repository; ? ?@Override ? ?public void saveChanges(String name, Account update) { ? ? ? ?//... ? ? ? ?statisticsClient.updateStatistics(name, account); ? ?} }

Notification服務對Account服務的調用如法炮制。

服務容錯保護

在微服務架構中，微服務之間可能存在依賴關系，例如Notification Service會調用Account Service，Account Service調用Statistics Service。真實產品中，微服務之間的調用會更加尋常。倘若上游服務出現了故障，就可能會因為依賴關系而導致故障的蔓延，最終導致整個系統的癱瘓。

Spring Cloud Hystrix通過實現斷路器（Circuit Breaker）模式以及線程隔離等功能，實現服務的容錯保護。

仍然參考前面的例子。現在系統的微服務包括：

• 上游服務：demo-service

• 下游服務：demo-consumer

• Eureka服務器：eureka-server

  
  

假設上游服務可能會出現故障，為保證系統的健壯性，需要在下游服務中加入容錯包含功能。首先需要在demo-consumer服務中添加對hystrix的依賴：

<dependency> ? ?<groupId>org.springframework.cloud</groupId> ? ?<artifactId>spring-cloud-starter-hystrix</artifactId> </dependency>

然后在demo-consumer的應用程序類中加入@EnableCircuitBreaker開啟斷路器功能：

@EnableCircuitBreaker @EnableDiscoveryClient @SpringBootApplication public class ConsumerApplication { ? ?@Bean ? ?@LoadBalanced ? ?RestTemplate restTemplate() { ? ? ? ?return new RestTemplate(); ? ?} ? ?public static void main(String[] args) { ? ? ? ?SpringApplication.run(ConsumerApplication.class, args) ? ?} }

注意：Spring Cloud提供了@SpringCloudApplication注解簡化如上代碼。該注解事實上已經包含了前面所述的三個注解。@SpringCloudApplication注解的定義如下所示：

@Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @Documented @Inherited @SpringBootApplication @EnableDiscoveryClient @EnableCircuitBreaker public @interface SpringCloudApplication {}

接下來，需要引入一個新的服務類來封裝hystrix提供的斷路器保護功能，主要是定義當故障發生時需要執行的回調邏輯，即代碼中指定的fallbackMethod：

@Service public class ConsumerService { ? ?@Autowired ? ?RestTemplate restTemplate; ? ?@HystrixCommand(fallbackMethod = "consumerFallback") ? ?public String consume() { ? ? ? ?return restTemplate.getForEntity("http://demo-service/demo", String.class).getBody(); ? ?} ? ?public String consumerFallback() { ? ? ? ?return "error"; ? ?} } @RestController public class ConsumerController { ? ?@Autowired ? ?ConsumerService consumerService; ? ?@RequestMapping(value = "/demo-consumer", method = RequestMethod.Get) ? ?public String helloConsumer() { ? ? ? ?return consumerService.consume(); ? ?} }

服務監控

微服務架構將服務的粒度分解的足夠細，這使得它在保證服務足夠靈活、足夠獨立的優勢下，也帶來了管理和監控上的挑戰，服務與服務之間的依賴也變得越來越復雜。因此，對服務健康度和運行指標的監控就變得非常重要。

Hystrix提供了Dashboard用以監控Hystrix的各項指標信息。為了監控整個系統的微服務，我們需要為Hystrix Dashboard建立一個Spring Boot微服務。在該服務項目的pom文件中，添加如下依賴：

<dependency> ? ?<groupId>org.springframework.cloud</groupId> ? ?<artifactId>spring-cloud-starter-hystrix</artifactId> </dependency> <dependency> ? ?<groupId>org.springframework.cloud</groupId> ? ?<artifactId>spring-cloud-starter-hystrix-dashboard</artifactId> </dependency> <dependency> ? ?<groupId>org.springframework.cloud</groupId> ? ?<artifactId>spring-cloud-starter-actuator</artifactId> </dependency>

服務的Application類需要添加@EnableHystrixDashboard，以啟用Hystrix Dashboard功能。同時，可能需要根據實際情況修改application.properties配置文件，例如選擇可用的端口號等。

如果要實現對集群的監控，則需要加入Turbine。

API網關

理論上，客戶端可以直接向每個微服務直接發送請求。但是這種方式是存在挑戰和限制的，調用者需要知道所有端點的地址，分別對每一段信息執行http請求，然后將結果合并到客戶端。

一般而言，針對微服務架構模式的系統，采用的都是前后端分離的架構。為了明顯地隔離開前端與后端的邊界，我們通常可以專門為前端的消費者定義更加粗粒度的Open Service。這些Open Service是對外的RESTful API服務，可以通過F5、Nginx等網絡設備或工具軟件實現對各個微服務的路由與負載均衡，并公開給外部的客戶端調用（注意，內部微服務之間的調用并不需要通過Open Service）。這種對外公開的Open Service通常又被稱為邊緣服務（edge service）。

如果這些Open Service需要我們自己去開發實現并進行服務的運維，在系統規模不斷增大的情況下，會變得越來越困難。例如，當增加了新的微服務又或者IP地址發生變動時，都需要運維人員手工維護這些路由規則與服務實例列表。又例如針對所有垂直分隔的微服務，不可避免存在重用的橫切關注點，例如用戶身份認證、授權或簽名校驗等機制。我們不能在所有微服務中都去添加這些相同的功能，因為這會造成橫切關注點的冗余。

解決的辦法是引入API網關（API Gateway）。它是系統的單個入口點，用于通過將請求路由到適當的后端服務或者通過調用多個后端服務并聚合結果來處理請求。此外，它還可以用于認證、insights、壓力測試、金絲雀測試（canary testing）、服務遷移、靜態響應處理和主動變換管理。Spring Cloud為API網關提供的解決方案就是Spring Cloud Zuul，它是對Netflix Zuul的包裝。

路由規則與服務實例維護

Zuul解決路由規則與服務實例維護的方法是通過Spring Cloud Eureka。API Gateway自身就是一個Spring Boot服務，該服務自身被注冊為Eureka服務治理下的應用，同時它會從Eureka中獲得所有其他微服務的實例信息。這樣的設計符合DRY原則，因為Eureka已經維護了一套服務實例信息，Zuul直接重用了這些信息，無需人工介入。

對于路由規則，Zuul默認會將服務名作為ContextPath創建路由映射，基本上這種路由映射機制就可以滿足微服務架構的路由需求。倘若需要一些特殊的配置，Zuul也允許我們自定義路由規則，可以通過在API網關的Application類中創建PatternServiceRouteMapper來定義自己的規則。

橫切關注點

諸如授權認證、簽名校驗等業務邏輯本身與微服務應用所要處理的業務邏輯沒有直接關系，我們將這些可能橫跨多個微服務的功能稱為“橫切關注點”。這些橫切關注點往往會作為“裝飾”功能在服務方法的前后被調用。Spring Cloud Zuul提供了一套過濾器機制，允許開發者創建各種過濾器，并指定哪些規則的請求需要執行哪個過濾器。

自定義的過濾器繼承自ZuulFilter類。例如我們要求客戶端發過來的請求在路由之前需要先驗證請求中是否包含accessToken參數，如果有就進行路由，否則就拒絕，并返回401 Unauthorized錯誤，則可以定義AccessFilter類：

public class AccessFilter extends ZuulFilter { ? ?private static Logger log = LoggerFactory.getLogger(AccessFilter.class); ? ?@Override ? ?public String filterType() { ? ? ? ?return "pre" ? ?} ? ?@Override ? ?public int filterOrder() { ? ? ? ?return 0; ? ?} ? ?@Override ? ?public boolean shouldFilter() { ? ? ? ?return true; ? ?} ? ? ? ?@Override ? ?public Object run() { ? ? ? ?RequestContext ctx = RequestContext.getCurrentContext(); ? ? ? ?HttpServletRequest request = ctx.getRequest(); ? ? ? ? ? ? ? ?log.info("send {} request to {}", request.getMethod(), request.getRequestURL().toString()); ? ? ? ?Object accessToken = request.getParameter("accessToken"); ? ? ? ?if (accessToken == null) { ? ? ? ? ? ?log.warn("access token is empty"); ? ? ? ? ? ?ctx.setSendZuulResponse(false); ? ? ? ? ? ?ctx.setResponseStatusCode(401); ? ? ? ? ? ?return null; ? ? ? ?} ? ? ? ?log.info("access token ok"); ? ? ? ?return null; ? ?} }

要讓該自定義過濾器生效，還需要在Zuul服務的Application中創建具體的Bean：

@EnableZuulProxy @SpringCloudApplication public class ZuulApplication { ? ?public static void main(String[] args) { ? ? ? ?new SpringApplicatonBuilder(ZuulApplication.class).web(true).run(args); ? ?} ? ?@Bean ? ?public AccessFilter accessFilter() { ? ? ? ?return new AccessFilter(); ? ?} }

Zuul一共提供了四種過濾器：

• pre filter

• routing filter

• post filter

• error filter

  
  

下圖來自官網，它展現了客戶端請求到達Zuul API網關的生命周期與過濾過程：

通過starter添加Zuul的依賴時，自身包含了spring-cloud-starter-hystrix與spring-cloud-starter-ribbon模塊的依賴，因此Zuul自身就擁有線程隔離與斷路器的服務容錯功能，以及客戶端負載均衡。但是，倘若我們使用path與url的映射關系來配置路由規則，則路由轉發的請求并不會采用HystrixCommand來包裝，因而這類路由是沒有服務容錯與客戶端負載均衡作用的。所以在使用Zuul時，應盡量使用path和serviceId的組合對路由進行配置。

分布式配置中心

為什么要引入一個分布式配置中心？一個微服務就需要至少一個配置文件，怎么管理分散在各個微服務中的配置文件呢？如果微服務采用的是不同的技術棧，如何來統一微服務的配置呢？微服務是部署在不同的節點中，顯然我們無法在單機中實現對分布式節點的配置管理。這就是引入Spring Cloud Config的目的。

Spring Cloud Config提供了服務端和客戶端支持。服務端是一個獨立的微服務，同樣可以注冊到Eureka服務器中。每個需要使用分布式配置中心的微服務都是Spring Cloud Config的客戶端。Spring Cloud Config默認實現基于Git倉庫，既可以進行版本管理，還可以通過本地Git庫起到緩存作用。Spring Cloud Config不限于基于Spring Cloud開發的系統，而是可以用于任何語言開發的程序，并支持自定義實現。

配置中心服務端

Spring Cloud Config Server作為配置中心服務端，提供如下功能：

• 拉取配置時更新git倉庫副本，保證是最新結果

• 支持數據結構豐富，yml, json, properties等

• 配合Eureke可實現服務發現，配合cloud bus可實現配置推送更新

• 配置存儲基于git倉庫，可進行版本管理

• 簡單可靠，有豐富的配套方案

  
  

建立一個Config服務，需要添加如下依賴：

<dependency> ? ?<groupId>org.springframework.cloud</groupId> ? ?<artifactId>spring-cloud-config-server</artifactId> </dependency>

服務的Application類需要添加@EnableConfigServer注解：

@SpringBootApplication @EnableConfigServer public class ConfigApplication { ? ?public static void main(String[] args) { ? ? ? ?SpringApplication.run(ConfigApplication.class, args); ? ?} }

配置服務的基本信息和Git倉庫的信息放在application.yml文件中：

spring: ?cloud: ? ?config: ? ? ?server: ? ? ? ?git: ? ? ? ? ? ?uri: http://localhost/workspace/springcloud-demo ? ? ? ? ? ?username: user ? ? ? ? ? ?password: password server: ?port: 8888 security: ?user: ? ?password: ${CONFIG_SERVICE_PASSWORD}

Git庫與配置服務

在Config服務中配置了Git服務器以及Git庫的信息后，我們就可以在git庫中提交配置文件。存儲在git庫中配置文件的名字以及分支名（默認為master分支）會組成訪問Config服務的URI。假設有一個服務為Notification服務，則它在配置中心服務端的配置文件為notification-dev.yml，內容如下：

devMode: ?true spring: ? ?application: ? ? ? ?name: notification ? ?jdbc: ? ? ? ?host: localhost ? ? ? ?port: 3306 ? ? ? ?user: root ? ? ? ?password: 123456 logging: ? ?file: demo

配置中心客戶端

需要讀取配置中心服務端信息的微服務都是配置中心的客戶端，為了能夠讀取配置服務端的信息，這些微服務需要：

• 在pom中添加對spring-cloud-starter-config的依賴

• 在bootstrap.properties或者bootstrap.yml中配置獲取配置的config-server位置

  
  

例如，Account服務的配置是由Spring Cloud Config進行管理的。在它的資源目錄下，提供了bootstrap.yml配置文件，內容如下所示：

spring: ?application: ? ?name: account-service ?cloud: ? ?config: ? ? ?uri: http://config:8888 ? ? ?fail-fast: true ? ? ?password: ${CONFIG_SERVICE_PASSWORD} ? ? ?username: user

注意，該配置文件除了配置了該Account服務應用的name之外，主要是支持該應用獲得配置服務端的信息。微服務自身的配置信息則統一放到配置中心服務端的文件中，并由Git庫進行管理。例如，Account服務的詳細配置在配置中心服務端的account-dev.yml文件中：

security: ?oauth2: ? ?client: ? ? ?clientId: account-service ? ? ?clientSecret: ${ACCOUNT_SERVICE_PASSWORD} ? ? ?accessTokenUri: http://auth-service:5000/uaa/oauth/token ? ? ?grant-type: client_credentials ? ? ?scope: server spring: ?data: ? ?mongodb: ? ? ?host: account-mongodb ? ? ?username: user ? ? ?password: ${MONGODB_PASSWORD} ? ? ?database: piggymetrics ? ? ?port: 27017 server: ?context-path: /accounts ?port: 6000

Spring Cloud Config通過Git實現分布式的配置管理。當配置中心服務端的配置信息發生變更時，各個作為配置客戶端的微服務會向Git庫提交pull更新，獲得最新的配置信息。

當然，Spring Cloud Config還可以使用SVN庫進行配置管理，也支持簡單的本地文件系統的存儲方式。此時需要將spring.profiles.active設置為native，并設置搜索配置文件的路徑。如果不配置路徑，默認在src/main/resources目錄下搜索。如下配置文件：

spring: ?cloud: ? ?config: ? ? ?server: ? ? ? ?native: ? ? ? ? ?search-locations: classpath:/shared ?profiles: ? ?active: native

搜索路徑放在classpath下的shared目錄下，那么在代碼中，目錄就是resources/shared。如果使用本地文件系統管理配置文件，則無法支持分布式配置管理以及版本管理，因此在生產系統下，還是推薦使用Git庫的方式。

總結

在實施微服務時，我們可以將微服務視為兩個不同的邊界。一個是與前端UI的通信，稱為Open Service（Edge Service），通過引入API Gateway來實現與前端UI的通信。另一個是在邊界內業務微服務之間的通信，通過Feign實現微服務之間的協作。所有的微服務都會通過Eureka來完成微服務的注冊與發現。一個典型的基于Spring Cloud的微服務架構如下所示：

微服務的集成可以通過Feign+Ribbon以RESTful方式實現通信，也可以基于RPC方式（可以結合Protocol Buffer）完成服務之間的通信，甚至可以通過發布事件與訂閱事件的機制。事件機制可以使微服務之間更加松散耦合。這時，我們可以引入RabbitMQ或Kafka來做到服務與服務之間的解耦。事件機制是異步和非阻塞的，在某些業務場景下，它的性能會更加的好。Spring Cloud也提供了相關的組件Spring Cloud Stream來支持這種事件機制。

對于微服務之間的協作，到底選擇Feign這種REST方式、事件機制或者RPC方式，取決于業務場景是否需要同步方式，還是異步方式；是高性能高并發，還是普通方式；是要求徹底解耦，還是做到一般的松散耦合。我們需要針對實際情況作出實際的判斷，作出正確的選擇。沒有誰壞誰好之分，而是看誰更加的適合。

本文部分內容來自PiggyMetrics，并參考了微服務與Spring Cloud相關文檔。

來源：http://zhangyi.xyz/micro-service-based-on-spring-cloud/

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的干货｜基于 Spring Cloud 的微服务落地的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。