【SpringCloud】服务拆分-案例demo

服务拆分和远程调用

任何分布式架构都离不开服务的拆分，微服务也是一样。

服务拆分原则

需求：查询订单，并且同时把订单关联的用户信息、商品信息都给他查出来。

以前的开发模式：肯定是写一个方法去查订单，订单查询的过程中得到了用户id，我再去数据库里把用户查出来；得到商品id再去数据库里把商品查出来。那么这些功能全部写到了订单的模块里，这种做法是完全违背了微服务原则的。微服务拆分的目的就是单一职责，一个服务只做与自己相关的事，订单模块当然是做订单业务，为什么要做用户查询和商品查询呢。

这里我总结了微服务拆分时的几个原则：

• 微服务需要根据业务模块拆分，做到单一职责，不要重复开发相同业务

  每个微服务都不能去开发重复的业务，如果在微服务拆分的过程中，出现了重复业务，这就证明我们某些地方做的有问题。

• 微服务数据独立，不要访问其它微服务的数据库

  直接从根源上杜绝这种耦合性的业务。

• 微服务可以将自己的业务暴露为接口，供其它微服务调用

服务拆分demo

以课前资料中的微服务cloud-demo为例，其结构如下：

可以看见已经拆分成了两个微服务。从业务角度可以看见，它们的业务是解除了耦合的。

cloud-demo：父工程，管理依赖

• order-service：订单微服务，负责订单相关业务
• user-service：用户微服务，负责用户相关业务

要求：

• 订单微服务和用户微服务都必须有各自的数据库，相互独立
• 订单服务和用户服务都对外暴露Restful的接口
• 订单服务如果需要查询用户信息，只能调用用户服务的Restful接口，不能查询用户数据库

导入Sql语句

首先，将课前资料提供的cloud-order.sql和cloud-user.sql导入到mysql中：

将来在做实际业务生产的时候一定会把它们部署到不同的数据库里，不过现在我们是自己做测试，准备两个不同的database去存储这些表。

提前准备好两个不同的database来模拟两个不同的数据库

cloud-user表中初始数据如下：

cloud-order表中初始数据如下：

cloud-order表中持有cloud-user表中的id字段。

导入demo工程

用IDEA导入课前资料提供的Demo：

项目结构如下：

导入后，会在IDEA右下角出现弹窗，点击使用服务

会出现这样的菜单：

配置下项目使用的JDK：

使用shift选中需要启动的微服务，然后点击调式将项目启动起来

然后通过访问接口获取到数据库信息