服务拆分:
1.单一职责原则:在一个微服务架构中,一个服务也应该只负责一个功能或业务领域,每个服务应该清晰的定义和边界,只关注自己的特定业务领域
2.服务自治:服务自治是指每个微服务都应该具备高度自治的能力,即每个服务要能做到独立开发,独立测试,独立构建,独立部署,独立运行
3.单向依赖
微服务之间要做到单向依赖,严禁循环依赖,双向依赖
循环依赖:A->B->C->A
双向依赖:A->B,B->A
实例:
1、订单列表
2、商品列表
订单服务:提供订单ID,获取订单详细信息
商品服务:根据商品ID,返回商品详细信息
根据订单查询订单信息时,根据订单里产品ID,获取产品详细信息
实现:
实现思路:order-service服务向product-service服务发送一个http请求,把得到的返回结果,和订单结果融合在一起,返回给调用方
实现方式:采用Spring提供的RestTemplate
1、定义RestTemplate
@Configuration
public class BeanConfig{
@Bean
public RestTemplate restTemplate{
return new RestTemplate();
}
}
2、在order-controller中使用restTemplate
RestTemplate:
Rest(Representational State Tranfer)表示层资源状态转移
资源:网络上的数据,比如图片,视频,文本等都是资源
表现层:资源的表现形式(比如 文本的表现形式是txt 图片的表现形式是jpg 还有一些资源是以json,xml,或者二进制等方式表现)
状态转移:我们通过网络访问资源,对资源进行(添加,修改,删除等),都会引起资源状态的变简单来说:REST描述的是在网络中Client和Server的一种交互形式 REST本身不实用,使用的是如何设计RESTful API (REST风格的网络接口)
Restful风格大致有几下几个特征:
1、资源
2、统一接口:对资源的操作,比如获取,创建,修改和删除,些窗口正好对应http协议提供的GET、POST、PUT和DELETE方法,换而言知,如果使用RESTful风格的接口,从接口上你可能只定位其资源,但是无法知晓它具体进行了什么操作,需要具体了解其发生了什么操作动作要从起http请求方法类型上进行判断 (比如:同一个url :GET/blog/{blogId}:查询博客 DELETE/blog/{blogId} 删除博客)
RESTful API缺点:
1. 操作⽅式繁琐, RESTful API通常根据GET, POST, PUT, DELETE 来区分对资源的操作动作. 但是
HTTP Method 并不可直接⻅到, 需要通过抓包等⼯具才能观察. 如果把动作放在URL上反⽽更加直
观, 更利于团队的理解和交流.
2. ⼀些浏览器对GET, POST之外的请求⽀持不太友好, 需要额外处理.
3. 过分强调资源. ⽽实际业务需求可能⽐较复杂, 并不能单纯使⽤增删改查就能满⾜需求, 强⾏使⽤
RESTful API会增加开发难度和成本.
项⽬存在问题
1、远程调⽤时, URL的IP和端⼝号是写死的(http://127.0.0.1:9090/product/), 如果更换IP, 需要修改代
码
2、调⽤⽅如何可以不依赖服务提供⽅的IP?
3、 多机部署, 如何分摊压⼒?
4、 远程调⽤时, URL⾮常容易写错, ⽽且复⽤性不⾼, 如何优雅的实现远程调⽤
5、所有的服务都可以调⽤该接⼝, 是否有⻛险?