个人主页: 叶落闲庭
我的专栏:
c语言
数据结构
javaEE
操作系统
Redis
石可破也,而不可夺坚;丹可磨也,而不可夺赤。
分布式架构是将一个项目中的不同的需求拆分成了多个模块,每个模块都可以独立开发,互不影响,各个模块最终一起部署,降低了代码的耦合度,但如果项目的需求有很多个,就需要大量的模块,模块数量变多,最终部署的时候就会变得很复杂,再拆分的过程中也会有很多问题,由于拆分好的服务为了保证高可用,还需要集群,与单体架构相比,分布式架构中的某个模块需要另一个模块的提供的信息时不能像单体架构那样直接调用。
此外,采用分布式架构还要考虑很多问题:服务拆分粒度如何(就是指哪些功能可以单独拆分出来)、服务集群地址如何维护(每个拆分的模块都有自己的地址,在部署的时候如何获取这些地址,当地址发生变化该怎么办)、服务之间如何实现远程调用、服务的健康状态如何感知(模块1发生问题挂掉了,模块2去调用模块1也会出现问题)
微服务的分布式架构方案将每个小的服务都拆分成单独的模块,使每个模块的功能更少,在开发时不会那么繁琐,每个模块对外都提供访问接口,可以实现对某个模块功能的调用,模块都是独立开发的,相当于一个完整的小的项目,有自己独立的数据库,有自己独立的数据,模块之间不能访问对方的数据,实现了数据解耦,避免了数据污染,模块之间进行调用时,当一个模块发生问题挂掉了,另一个模块需要调用,此时会有一个隔离性的措施,避免模块调用时出现问题
不管是哪种微服务,他们都需要去做微服务的拆分,形成微服务集群,集群中的每个服务都需要遵循单一职责的原则,,并且由于要面向服务,所以每个服务都要对外暴露接口,用于服务之间的调用,不同技术去实现这些接口的方式可能会有所不同,由于这些接口之间的调用关系需要维护,并且这些调用关系错综复杂,而且量也是非常大,所以在微服务中都会有一个注册中心,用来维护微服务里面每个节点的信息,并且监控这些节点的状态,随着微服务越来越多,里面要是有一些配置需要去修改,此时会有一个配置中心,用来统一管理整个微服务群的配置,微服务部署完成后,为服务群会有一个统一的服务网关,用户访问这个网关,由网关把请求路由到微服务群,在路由过程中还可以做负载均衡。
微服务技术对比:
Dubbo | SpringCloud | SpringCloudAlibaba | |
---|---|---|---|
注册中心 | zookeeper、redis | Eureka、Consul | Nacos、Eureka |
服务远程调用 | Dobbo协议 | Feign(http协议) | Dubbo、Feign |
配置中心 | 无 | SpringCloudConfig | SpringCloudConfig、Nacos |
服务网关 | 无 | SpringCloudGetway、Zuul | SpringCloudGetway、Zuul |
服务监控和保护 | dubbo-admin,功能弱 | Hystrix | Sentinel |
服务拆分就是一个单体架构按照功能模块进行拆分,变成多个服务
在进行微服务拆分时要注意不同的微服务,不要重复开发相同的业务,避免重复开发,要保证微服务数据的独立,不同的微服务不能访问彼此的数据库,如果一个微服务需要另一个微服务的数据,可以通过接口调用,因为每个微服务都要将自己的部分业务暴露作为接口供其它微服务调用
@MapperScan("order.mapper")
@SpringBootApplication
public class OrderApplication {
public static void main(String[] args) {
SpringApplication.run(OrderApplication.class,args);
}
@Bean
public RestTemplate restTemplate() {
return new RestTemplate();
}
}
@Service
public class OrderService {
@Autowired
private RestTemplate restTemplate;
public Order queryOrderById(Long orderId) {
//查询订单
Order order = orderMapper.findById(orderId);
//查询用户
String url = "http://localhost:8081/user/" + order.getUserId();
User user = restTemplate.getForObject(url,User.class);
//封装user信息
order.setUser(user);
//返回
return order;
}
}