微服务核心模块
这是微服务的基本架构图，不同终端可以通过网关调用我们的核心服务，每个服务可以独立水平扩展，它们各自管辖自己的数据库。下面是SpringCloud相关常见技术栈（模块），我们将通过一个简化后的真实案例来串联起它们：
Eureka/Nacos：服务注册中心,后者由阿里巴巴开源
Ribbon：负载均衡组件
Hystrix：熔断器组件
Feign：请求客户端组件
SpringCloud GateWay：网关组件，提供路由、过滤等功能
1. 准备工作
下面我们通过一个案例来整体介绍这些组件。案例背景：B2C商城里，用户在购物时会生成订单，除了支付业务本身的订单状态处理之外，系统还会围绕这些订单分别给商家、用户端做些处理。最典型的比如，商家端要做订单统计、用户端要做订单查询、积分计算等等。为了将不同端的订单处理分层解耦，通常会划分多个服务，最简单的方案是分为商家服务和用户服务，商家服务管理商家订单、用户服务管理用户订单。
当用户下单后，前端通过调用平台聚合层来分别调用商家、用户服务。
所以，我们可以新建三个服务项目，PlatformDemo、MerchantDemo、UserDemo。按照微服务的理论，每个服务管控自己的数据库，所以可以新建两个单独的库，分别是merchantdb、userdb,然后分别新建各自的订单表merchantorder、userorder。（其实就是垂直分库）
编译相关命令
clean compile package -Dmaven.test.skip=true
PlatformDemo怎么调用MerchantDemo和UserDemo呢？两种方式：
- platform直接通过http调用merchant和user，优点是：简单，缺点是：假如merchant和user是多实例的，那么platform需要手动维护每个实例的地址；
- 将merchant、user注册到一个服务注册中心，然后platform仅通过单一的【服务名称】来路由到不同的merchnt、user服务实例。优点是：服务实例水平扩展很方便，不需要在platform维护实例地址。缺点是：要安装单独的服务注册中心。
在实际场景中，肯定会选2，原因就在于，微服务的意义就是让服务实例更方便的水平扩展，假如每次还得在调用层手动维护实例地址，会非常麻烦。另外，注册中心只需要安装一次，也不存在其他太复杂的操作。
2. Nacos基本介绍
微服务比较常见的注册中心有Eureka、ZK、Consul、Nacos等。Nacos由阿里巴巴开源，它提供了服务注册、配置管理等功能。其简单易用的风格，越来越受到大家的关注，我们的生产级项目都已采用，目前运行良好。
实际上Nacos思路非常简单，它提供中心服务器（可集群扩展，消除单点）及控制台，服务提供者（比如Merchant服务）首先主动注册到中心服务，中心服务轮询其存活状态。服务消费者（比如Platform）根据固定的服务名从中心服务器调用目标服务。这种架构的优点是：服务提供者的水平扩展可以对服务消费者完全透明，后者不需要手动维护前者服务列表。
下面我们以Nacos为例，来对注册中心做个演示。
Nacos服务安装
安装过程可以看这里：
https://nacos.io/zh-cn/docs/quick-start.html我这里是按照源码方式安装，相关nacos命令在 distribution/target/nacos-server-$version/nacos/bin目录下。
启动命令：
sh startup.sh -m standalone 关停命令：
sh shutdown.sh
控制台页面：
http://localhost:8848/nacos/ 默认密码：nacos/nacos
使用Nacos进行服务注册
首先引入nacos依赖：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
<version>>0.2.1.RELEASE</version>
</dependency> 这里我们采用生产验证过的0.2.1版本
代码及配置方面的变动：
在主类上加上@EnableDiscoveryClient注解
在配置文件中新增如下内容：
server.port=0
spring.application.name=merchant-service
spring.cloud.nacos.discovery.server-addr=localhost:8848 这里将port设置为0，意味着每次启动都会使用随机端口号，这主要是因为同一类的微服务实例通常会有多个，使用同样的固定端口会造成端口占用的问题。
Nacos控制台初探
启动主类后，即可在控制台的【服务列表】中看到merchant-service 服务：
这里我们启动了3个实例，点击详情后，我们可以看到实例的权重及运行情况：
在这里，我们可以直接编辑实例的权重，也可以直接上下线实例，后面我们会对此进行演示。
借助Nacos进行微服务调用
如之前所说，我们需要在Platform中调用Merchant服务，完成订单入库的操作。由于Merchant已经注册在了Nacos，所以Platform必须借助Nacos来完成服务的调用。
Platform项目的配置和前面类似，这里不再赘述，我们直接看怎么轮询调用Merchant服务。为了更清楚的演示轮询过程，我们直接采用LoadBalancerClient+RestTemplate的方案手动调用服务。LoadBalancerClient用于通过服务名选取服务信息（ip地址、端口号），RestTemplate用于做Http请求。
下面首先配置RestTemplate：
@Configuration
public class RestTemplateConfig {
@Bean
public RestTemplate restTemplate(ClientHttpRequestFactory factory){
return new RestTemplate(factory);
}
@Bean
public ClientHttpRequestFactory simpleClientHttpRequestFactory(){
SimpleClientHttpRequestFactory factory = new SimpleClientHttpRequestFactory();
factory.setReadTimeout(3000);//单位为ms
factory.setConnectTimeout(3000);//单位为ms
return factory;
}
} 然后新建测试类，核心测试代码如下：
ServiceInstance serviceInstance = loadBalancerClient.choose("merchant-service");
String url = String.format("http://%s:%s/merchant/saveOrder",serviceInstance.getHost(),serviceInstance.getPort());
System.out.println("request url:"+url);
Object value=restTemplate.postForObject(url,null,String.class); 代码解释：首先通过ServiceInstance根据权重获取服务信息，该信息包括ip+端口，然后拼接服务地址信息，最后通过RestTemplate进行Http请求。
注意：在test之前，先启动多个merchant服务实例。大家不妨测试一下，假如请求多次，是能看到均衡负载的效果的。
上面这种方式比较手工一点，实际上，我们可以直接让RestTemplate集成Ribbon，实现LoadBalance的效果，做法很简单：
- 在构建RestTemplate时加上@LoadBalanced注解：
@LoadBalanced
@Bean
public RestTemplate restTemplate(ClientHttpRequestFactory factory){
return new RestTemplate(factory);
} - 请求服务时，直接使用服务名而非IP+端口：
restTemplate.postForObject("http://merchant-service/merchant/saveOrder",null,String.class); 3. 微服务调用之Feign
Feign是SpringCloud中非常常用的一个HTTP客户端组件，它提供了接口式的微服务调用API。
首先确保项目中已经导入了Feign依赖：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-openfeign</artifactId>
<version>2.0.0.RELEASE</version>
</dependency> 然后创建目标服务的接口，比如我们这里需要调用Merchant服务，那么可以新建MerchantService接口专门来处理与之相关的服务调用：
@FeignClient(value="merchant-service")
public interface MerchantService {
@PostMapping("/merchant/saveOrder")
public String saveMerchantOrder();
} 这个接口非常容易理解：使用@FeignClient将接口定义为服务接口，使用SpringMVC的@PostMapping、@GetMapping注解将接口方法定义为服务映射方法。就这样，调用微服务的方式就和普通方法调用的方式没太大区别（至少感觉上是这样）。
有时候，我们需要在发起Feign请求时，可以做一些统一的处理，比如：header设置、请求监控等。此时我们可以配置Feign拦截器来实现。
Feign拦截器的实现方式非常简单，主要分为两步：
- 实现feign.RequestInterceptor接口，重写其apply方法，如下：
public class FeignRequestInterceptor implements RequestInterceptor {
@Override
public void apply(RequestTemplate requestTemplate) {
requestTemplate.header("token","123");
}
} - 将其配置在@FeignClient(configuration)中：
@FeignClient(value="merchant-service",configuration = FeignRequestInterceptor.class)
public interface MerchantService {
@PostMapping("/merchant/saveOrder")
public String saveMerchantOrder();
} 此时我们可以先调整下Merchant服务的接口，使用@RequestHeader("token")来接收token参数。
Feign超时及重试机制
微服务之间调用最大的一个问题就是超时问题（没有之一）。比如说，当Platform调用Merchant时，由于网络不通或者Merchant服务响应缓慢，那么Platform是不能一直等待下去的，这样资源会一致被占用，前端也得不到快速响应。此时一般会设置超时时间。
大家可以测试一下，当连接不上服务端时，会报connect timeout，当服务端响应时间过长，会报read timeout。默认情况下，Feign是不会重试的，即重试逻辑为Retryer.NEVER_RETRY。我们可以根据实际情况作如下配置：
@Configuration
public class FeignConfigure {
@Bean
Request.Options feignOptions() {
return new Request.Options(
/**connectTimeoutMillis**/
1 * 1000,
/** readTimeoutMillis **/
1 * 5000);
}
@Bean
public Retryer feignRetryer() {
return new Retryer.Default();
}
} 该配置类里面，我们设置了连接超时未1秒、读取超时未5秒，然后默认重试机制会重试5次。测试方式比较简单，比如我们可以把Merchant服务从Nacos上摘除下来，或者在接口中手动设置sleep，这里不再给出。
调用方在收到超时异常时，很可能服务方会继续执行（比如执行过长导致de 超时）,所以重试的前提是：【一定要保证服务方的幂等性】，即重复多次不会影响业务逻辑。
4. 微服务间的数据传输
在实际开发中，有一个很现实的问题是数据传输格式的约定问题。在微服务架构中，实现一个完整的功能需要涉及到多个服务的调用，每个服务都有与自己领域相关的数据封装，微服务之间的调用需要遵循对方的数据格式要求。以前面的订单为例，Platform在调用Merchant时，应该传入商户订单对象，然后被返回Merchant服务的响应对象。听起来很简单对吧？但是Platform和Merchant是不同项目，后者约定好的对象类在前者是不存在的，前者工程师需要手动新建匹配的类才行。在服务接口非常繁多的情况下，这种手工处理会占用工程师很多时间。为了让他们过的爽一点，我们应该让这些类/对象共享才对。
所以，笔者建议针对每个服务都新建一个DTO项目，专门用于定义数据传输对象。比如我们可以新建MerchantDTO，专门定义该服务对应的输入、输出对象，每次更新升级时，可以将其打入公司的私有仓库中。为了自动化这一过程，可以使用CI/CD工具（比如jenkins）自动拉取git代码并install/deploy到私有仓库。在需要调用Merchant服务时，在pom中加入依赖就可以了。在项目规模较小时，可以暂时只做一个DTO项目，涵盖所有服务，以后再拆也是OK的。
在DTO中，我们会约定两种类型的数据：请求参数值、响应返回值。请求参数与业务域相关。比如保存商户订单，那么请求参数就是商户订单数据，比如：
@ApiModel("商户订单实体")
@Setter
@Getter
public class MerchantOrderRequest {
@ApiModelProperty(name = "ordername",value = "订单名称")
private String ordername;
@ApiModelProperty(name="price",value = "价格")
private double price;
} 通常来说，响应返回值都会有些公共的字段，比如code、message等，一般来说会设计响应对象的基类，这样便于后面做统一的code处理:
@ApiModel(value = "默认响应实体")
@Setter
@Getter
public class DefaultResponseData {
@ApiModelProperty(name = "code",value = "返回码，默认1000是成功、5000是失败")
private String code;
@ApiModelProperty(name = "message",value = "返回信息")
private String message;
/**
* 额外数据
*/
@ApiModelProperty(name = "extra",value = "额外数据")
private String extra;
} 这里用到了swagger注解，这样在接口文档中就会有明确说明，方便调试。@Setter、@Getter主要用于生产Setter/Getter代码，有助于解放大家的双手，具体安装及依赖过程可以看这篇文章：
如何使用Lombok简化你的代码?我们改造一下之前的saveMerchantOrder方法，让其传入MerchantOrderRequest、返回DefaultResponseData。
public DefaultResponseData saveMerchantOrder(
@RequestBody MerchantOrderRequest merchantOrderRequest,
@RequestHeader("token") String token){
...
}
重新启动Merchant服务，打开swagger，可以看到请求和响应参数的描述：
User服务可以完全按照同样的处理策略，这里不再赘述。
5. 使用Hystrix进行熔断保护（降级）
在分布式/微服务环境中往往会出现各种各样的问题，比如网络异常，超时等，而这些问题可能会导致系统的级联失败，即使不断重试，也可能无法解决的，还会耗费更多的资源。比如说我们Platform在调用Merchant时，后者的数据库突然挂了，然后系统卡顿或者不停报错，用户此时可能会不断刷新，做更多的请求。这最终会让应用程序由于资源耗尽而导致雪崩。遇到这种情况，更好的做法是在调用阶段进行熔断保护并做降级处理。
熔断保护类似于电路中的保险丝，当电流异常升高时会自动切断电流，以保护电路安全。在开发中，熔断器通常有三个状态，即Closed、Open、Half-Open，如下图：
默认情况下，熔断器是关闭（Closed）的，一旦在某个时间窗口T（默认10秒）内发生异常或者超时的次数在N以上，那么熔断器就会开启（Open），然后在时间窗口S之后，熔断器会进入半开状态（Half-Open），此时假如新请求成功执行，那么会进入关闭状态（Closed），否则继续开启（Open）。为了让熔断后能快速降级，我们通常需要指定相应的fallback处理逻辑。
在SpringCloud中，我们主要使用Hystrix组件来完成熔断降级，下面看看怎么实现。
首先，我们得引入依赖：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency> 在启动类上加@EnableHystrix注解，开启Hystrix。
在API层，我们只需要加@HystrixCommand注解即可。如前面所说，当接口熔断后，我们需要指定降级逻辑，即指定fallback方法：
@GetMapping("/simpleHystrix")
@HystrixCommand(fallbackMethod = "fallbackHandler"
})
public String simpleHystrix(@RequestParam("count") Integer count){
System.out.println("执行.................");
int i=10/count;
return "success";
}
public String fallbackHandler(Integer count){
System.out.println("count="+count);
return "fail";
} 这里我们定义了一个简单的接口，当count=0时，很明显会发生异常，在某段时间内出现异常的次数达到阈值，新请求就会进入fallbackHandler进行处理，不会继续调用simpleHystrix的逻辑。我们可以通过commandProperties/@HystrixProperty指定一些基本的参数，比如：
commandProperties = {
@HystrixProperty(name=HystrixPropertiesManager.CIRCUIT_BREAKER_REQUEST_VOLUME_THRESHOLD,value = "3"),
@HystrixProperty(name =HystrixPropertiesManager.CIRCUIT_BREAKER_SLEEP_WINDOW_IN_MILLISECONDS,value = "20000") 这里我们指定了10秒内出现3次异常，就会进入Open状态，然后再20秒之后，会进入Half-Open状态。
Feign整合Hystrix
在实际场景中，熔断器解决的大部分是微服务调用的问题，所以这里我们看看怎样让Feign整合Hystrix。
前面提到过的@FeignClient，其实直接支持配置Hystrix。它支持的方式有两种：fallback、fallbackFactory。前者比较简单，仅需要配置当前接口实现类作为降级函数，后者功能丰富一点，可以获取触发降级的原因。我们这里先用前者快速实现一下。
首先定义fallback类，该类实现服务接口及其所有方法，以MerchantService为例：
public class MerchantServiceFallBack implements MerchantService {
@Override
public DefaultResponseData saveMerchantOrder(MerchantOrderRequest merchantOrderRequest) {
DefaultResponseData responseData=new DefaultResponseData();
responseData.setCode("1001");
responseData.setMessage("fallback");
return responseData;
}
} 然后在@FeignClient中加上：
fallback = MerchantServiceFallBack.class 最后，别忘记在配置文件中开启feign-hystrix:
feign.hystrix.enabled=true 当调用MerchantService接口服务时，一旦出现异常情况，会转入MerchantServiceFallBack的逻辑。
6. API网关之Spring Cloud Gateway
API网关主要解决的问题有：API鉴权、流量控制、请求过滤、聚合服务等。它并非微服务的必需品，具体怎么用得看实际场景。目前比较流行的网关有Zuul、Spring Cloud GateWay等。前者比较老牌了，网上资料也较多，而后者是新贵，算是SpringCloud的亲儿子，个人感觉也更好用，我们以它为例来讲解API网关的常见用法。
Spring Cloud Gateway基于Spring5、Reactor以及SpringBoot2构建，提供路由（断言、过滤器）、熔断集成、请求限流、URL重写等功能。
SpringBoot/SpringCloud系列的组件太多，经常会出现版本不对应，以下是经过测试无误的搭配：
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.0.4.RELEASE</version>
</parent>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>Finchley.RELEASE</version>
<type>pom</type>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-gateway</artifactId>
<version>2.0.4.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-webflux</artifactId>
</dependency>
</dependencies> 最重要的一步是定义路由：
@Bean
public RouteLocator myRoutes(RouteLocatorBuilder builder) {
return builder.routes()
.route(p -> p
.path("/api/order/gateWay")
.uri("http://localhost:8889"))
.build();
} 代码解释：当访问本服务的/api/order/gateWay时，会将请求转发到
:8889/api/order/gateWay。然后我们也可以在转发请求前进行过滤处理，比如新增header参数、请求参数等，大家可以自行测试：
filters(f -> f.addRequestHeader("token", "123")) 在实际项目中，网关所调用的目标服务都注册在注册中心里面，所以一般来说，会让网关访问注册中心地址。假如用的是Nacos，可以将uri中的http换成lb：
lb://platform-service