服务拆分

对单体架构项目来说：简单方便，高度耦合，扩展性差，适合小型项目。

而对于分布式架构来说：低耦合，扩展性好，但架构复杂，难度大。

微服务就是一种良好的分布式架构方案：

①优点：拆分粒度更小、服务更独立、耦合度更低

②缺点：架构非常复杂，运维、监控、部署难度提高

SpringCloud是微服务架构的一站式解决方案，集成了各种优秀微服务功能组件。

微服务拆分时的几个原则：

不同微服务，不要重复开发相同业务

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

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

拆分案列：

cloud-demo是父工程，是用来管理依赖的。

order-service：订单微服务，负责订单相关业务

user-service：用户微服务，负责用户相关业务

要求：

• 订单微服务和用户微服务都必须有各自的数据库，相互独立

• 订单服务和用户服务都对外暴露Restful的接口

• 订单服务如果需要查询用户信息，只能调用用户服务的Restful接口，不能查询用户数据库

实现远程调用

在order-service服务中，有一个根据id查询订单的接口，根据id查询订单，返回值是Order对象，如图，其中的user为null。

在user-service中有一个根据id查询用户的接口：

查询结果：

现在通过实现远程调用，在查询订单的同时，根据订单中包含的userId查询出用户信息，一起返回。

因此，我们需要在order-service中 向user-service发起一个http的请求，调用http://localhost:8081/user/{userId}这个接口。

大概的步骤是这样的：

• 注册一个RestTemplate的实例到Spring容器

• 修改order-service服务中的OrderService类中的queryOrderById方法，根据Order对象中的userId查询User

• 将查询的User填充到Order对象，一起返回

注册RestTemplate

在order-service服务中的OrderApplication启动类中，注册RestTemplate实例：

修改order-service服务中的cn.itcast.order.service包下的OrderService类中的queryOrderById方法：

查询结果：

假如我们的服务提供者user-service部署了多个实例，那么

order-service在发起远程调用的时候，该如何得知user-service实例的ip地址和端口？

有多个user-service实例地址，order-service调用时该如何选择？

order-service如何得知某个user-service实例是否依然健康，是不是已经宕机？

上述问题将在注册中心中可以得到解决，接下来还会继续介绍关于Eureka注册中心和Nacos注册中心。