微服务可以认为是一种分布式架构的解决方案,提供服务的独立性和完整性,做到服务的高内聚、低耦合。
目前服务架构主要包含:单体架构和分布式架构。
单体架构:把所有业务功能模块都放在一个项目中进行开发,打成一个包部署。
优点:架构简单、易部署
缺点:功能模块耦合度高,升级维护困难
分布式架构:将系统中每个业务功能模块作为独立项目进行开发,分开进行部署,每个项目称为一个服务。
优点:耦合度低、有利于功能模块升级与维护
缺点:架构复杂、部署有一定难度
全球各地的互联网公司都在寻求可以落地的微服务方案,目前国内使用最广泛的微服务框架还是SpringCloud,官网地址:https://spring.io/projects/spring-cloud。SpringCloud集成了各种微服务功能组件,并基于SpringBoot实现了这些组件的自动装配,从而提供了良好的开箱即用体验。
注:SpringCloud底层是依赖于SpringBoot的,并且有版本的兼容关系
任何分布式架构方案都需要考虑服务拆分的问题:
微服务进行服务拆分的原则:
例:现在要开发两个微服务:支付微服务和订单微服务,支付微服务中需要用到订单微服务中的数据
支付微服务和订单微服务是两个完全不同的业务,不能包含相同的业务
支付微服务和订单微服务都需要有自己的数据库,支付微服务不能访问订单微服务的数据库
支付微服务和订单微服务都可以暴露自己的Restful接口供其它微服务使用,支付微服务可以通过访问订单微服务暴露的接口去获得数据
在服务的调用关系中,有两个不同的角色:
服务调用者:业务中访问其它微服务的服务称为服务调用者,就是一个服务去访问其它微服务暴露的业务接口
服务提供者:业务中被其它微服务访问的服务称为服务提供者,就是一个服务暴露业务接口供其它微服务访问
服务调用者和服务提供者的角色并不是绝对的,是相对与业务而言的,一个微服务既可以是服务调用者也可以是服务提供者
实现微服务之间的调用,最开始的方式可以使用注册RestTemplate实例的方式,RestTemplate是用于服务之间远程通信的一个类,以上文提到的支付微服务和订单微服务为例,支付微服务中需要用到订单微服务中的数据。步骤如下:
注册RestTemplate到容器到支付微服务的Spring中
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;
import org.springframework.web.client.RestTemplate;
@SpringBootApplication
public class PayApplication {
public static void main(String[] args) {
SpringApplication.run(PayApplication.class, args);
}
@Bean
public RestTemplate restTemplate() {
return new RestTemplate();
}
}
在支付微服务的业务方法中使用RestTemplate向订单微服务发起请求
一般是在支付微服务的service层代码中,步骤如下:
@Autowired
private RestTemplate restTemplate;
String url = "http://127.0.0.1:8080/order/"+id;
Order order = restTemplate.getForObject(url, Order.class);
String url = "http://127.0.0.1:8080/order/"+id;
Order order = restTemplate.getForObject(url, Order.class);