微服务学习

1.单体架构

->将业务的所有功能集中在一个项目中开发,打成一个包部署

优点: 架构简单,部署成本低

缺点: 耦合度高

2.分布式架构

->根据业务功能进行系统的拆分,每隔业务模块作为独立项目开发,成为一个服务

优点:降低服务耦合,有利于升级拓展

服务拆分注意事项

1.不同的微服务,不要重复开发相同业务

2.微服务数据独立,不要访问其他微服务的数据库(一个微服务对应一个数据库)

3.微服务可以将自己的业务暴露为接口,供其他微服务调用

微服务调用方式

1.基于RestTemplate发起的http请求实现远程调用

2.http请求做远程调用是与语言无关的调用,只要直到对方的ip/端口/接口路径/请求参数就行

提供者与消费者

服务提供者 : 一次业务中,被其他微服务调用的服务。(提供接口给其他微服务)

服务消费者 : 一次业务中,调用其他微服务的服务。(调用其他微服务提供的接口)

思考

服务A调用服务B，服务B调用服务C，那么服务B是什么角色呢？

->如果是A调B这个业务，那么B就是提供者  B调用C，那么B就是消费者（一个业务既可以是提供者也可以是消费者，根据业务而定）

Eureka注册中心

eureka作用

消费者如何获取服务提供者具体信息？

1.服务提供者 启动时向eureka注册自己的信息

2.eureka保存这些信息

3.消费者根据服务名称向eureka拉去提供者信息

如果有多个服务提供者，消费者该如何选择呢？

服务消费者利用负载均衡算法，从服务列表中挑选一个

消费者如何感知服务提供者的健康状态？

1.服务提供者会每隔30秒向EurekaServer发送心跳请求，报告健康状态

2.eureka会更新记录服务列表信息，心跳不正常会被剔除

3.消费者就可以拉取到最新的信息

总结：

在Eureka架构中，微服务角色有两类

1.EurekaServer：服务端，注册中心

1）记录服务信息

2）心跳监控

2.EurekaClient：客户端  服务提供者

1）注册自己的信息到EurekaServer

2）每隔30秒向EnrekaServer发送心跳）

3.consumer： 服务消费者

1）根据服务名称从EurekaServer拉去服务列表

2）基于服务列表做负载均衡，选中一个微服务后发起远程调用