服务拆分：
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、所有的服务都可以调⽤该接⼝, 是否有⻛险?
