当前位置： 首页 > news >正文

微服务基础1-微服务拆分与服务调用

news 2025/9/22 11:51:49

1.微服务概念

1.1 单体架构

单体架构（monolithic structure）：顾名思义，整个项目中所有功能模块都在一个工程中开发；项目部署时需要对所有模块一起编译、打包；项目的架构设计、开发模式都非常简单。当项目规模较小时，这种模式上手快，部署、运维也都很方便，因此早期很多小型项目都采用这种模式。

但随着项目的业务规模越来越大，团队开发人员也不断增加，单体架构就呈现出越来越多的问题：

  • 团队协作成本高：试想一下，你们团队数十个人同时协作开发同一个项目，由于所有模块都在一个项目中，不同模块的代码之间物理边界越来越模糊。最终要把功能合并到一个分支，你绝对会陷入到解决冲突的泥潭之中。

  • 系统发布效率低：任何模块变更都需要发布整个系统，而系统发布过程中需要多个模块之间制约较多，需要对比各种文件，任何一处出现问题都会导致发布失败，往往一次发布需要数十分钟甚至数小时。

  • 系统可用性差：单体架构各个功能模块是作为一个服务部署，相互之间会互相影响，一些热点功能会耗尽系统资源，导致其它服务低可用。

1.2 微服务架构

微服务架构，首先是服务化，就是将单体架构中的功能模块从单体应用中拆分出来，独立部署为多个服务。同时要满足下面的一些特点：

  • 单一职责：一个微服务负责一部分业务功能，并且其核心数据不依赖于其它模块。

  • 团队自治：每个微服务都有自己独立的开发、测试、发布、运维人员，团队人员规模不超过10人（2张披萨能喂饱）

  • 服务自治：每个微服务都独立打包部署，访问自己独立的数据库。并且要做好服务隔离，避免对其它服务产生影响

那么，单体架构存在的问题有没有解决呢？

  • 团队协作成本高？

    • 由于服务拆分，每个服务代码量大大减少，参与开发的后台人员在1~3名，协作成本大大降低

  • 系统发布效率低？

    • 每个服务都是独立部署，当有某个服务有代码变更时，只需要打包部署该服务即可

  • 系统可用性差？

    • 每个服务独立部署，并且做好服务隔离，使用自己的服务器资源，不会影响到其它服务。

综上所述，微服务架构解决了单体架构存在的问题，特别适合大型互联网项目的开发，因此被各大互联网公司普遍采用。大家以前可能听说过分布式架构，分布式就是服务拆分的过程，其实微服务架构正式分布式架构的一种最佳实践的方案。

1.3 SpringCloud

微服务拆分以后碰到的各种问题都有对应的解决方案和微服务组件，而SpringCloud框架可以说是目前Java领域最全面的微服务组件的集合了。

而且SpringCloud依托于SpringBoot的自动装配能力，大大降低了其项目搭建、组件使用的成本。对于没有自研微服务组件能力的中小型企业，使用SpringCloud全家桶来实现微服务开发可以说是最合适的选择了，另外，Alibaba的微服务产品SpringCloudAlibaba目前也成为了SpringCloud组件中的一员。

https://spring.io/projects/spring-cloud#overview

2.微服务拆分

2.1 什么时候拆

一般情况下，对于一个初创的项目，首先要做的是验证项目的可行性。因此这一阶段的首要任务是敏捷开发，快速产出生产可用的产品，投入市场做验证。为了达成这一目的，该阶段项目架构往往会比较简单，很多情况下会直接采用单体架构，这样开发成本比较低，可以快速产出结果，一旦发现项目不符合市场，损失较小。

如果这一阶段采用复杂的微服务架构，投入大量的人力和时间成本用于架构设计，最终发现产品不符合市场需求，等于全部做了无用功。

所以，对于大多数小型项目来说，一般是先采用单体架构，随着用户规模扩大、业务复杂后再逐渐拆分为微服务架构。这样初期成本会比较低，可以快速试错。但是，这么做的问题就在于后期做服务拆分时，可能会遇到很多代码耦合带来的问题，拆分比较困难（前易后难）。

而对于一些大型项目，在立项之初目的就很明确，为了长远考虑，在架构设计时就直接选择微服务架构。虽然前期投入较多，但后期就少了拆分服务的烦恼（前难后易）。

2.2 如何拆

之前我们说过，微服务拆分时粒度要小，这其实是拆分的目标。具体可以从两个角度来分析：

  • 高内聚：每个微服务的职责要尽量单一，包含的业务相互关联度高、完整度高。

  • 低耦合：每个微服务的功能要相对独立，尽量减少对其它微服务的依赖，或者依赖接口的稳定性要强。

高内聚首先是单一职责，但不能说一个微服务就一个接口，而是要保证微服务内部业务的完整性为前提。目标是当我们要修改某个业务时，最好就只修改当前微服务，这样变更的成本更低。

一旦微服务做到了高内聚，那么服务之间的耦合度自然就降低了。

当然，微服务之间不可避免的会有或多或少的业务交互，比如下单时需要查询商品数据。这个时候我们不能在订单服务直接查询商品数据库，否则就导致了数据耦合。而应该由商品服务对应暴露接口，并且一定要保证微服务对外接口的稳定性（即：尽量保证接口外观不变）。虽然出现了服务间调用，但此时无论你如何在商品服务做内部修改，都不会影响到订单微服务，服务间的耦合度就降低了。

明确了拆分目标，接下来就是拆分方式了。我们在做服务拆分时一般有两种方式：

  • 纵向拆分

  • 横向拆分

所谓纵向拆分，就是按照项目的功能模块来拆分。例如在某项目中，就有用户管理功能、订单管理功能、购物车功能、商品管理功能、支付功能等。那么按照功能模块将他们拆分为一个个服务，就属于纵向拆分。这种拆分模式可以尽可能提高服务的内聚性。

而横向拆分，是看各个功能模块之间有没有公共的业务部分，如果有将其抽取出来作为通用服务。例如用户登录是需要发送消息通知，记录风控数据，下单时也要发送短信，记录风控数据。因此消息发送、风控数据记录就是通用的业务功能，因此可以将他们分别抽取为公共服务：消息中心服务、风控管理服务。这样可以提高业务的复用性，避免重复开发。同时通用业务一般接口稳定性较强，也不会使服务之间过分耦合。

一般微服务项目有两种不同的工程结构：

  • 完全解耦：每一个微服务都创建为一个独立的工程，甚至可以使用不同的开发语言来开发，项目完全解耦。

    • 优点：服务之间耦合度低

    • 缺点：每个项目都有自己的独立仓库，管理起来比较麻烦

  • Maven聚合：整个项目为一个Project，然后每个微服务是其中的一个Module

    • 优点：项目代码集中，管理和运维方便（授课也方便）

    • 缺点：服务之间耦合，编译时间较长

2.3 服务调用

在某一个微服务中我们想调用另一个微服务的业务逻辑，需要用到跨微服务的远程调用（RPC，即Remote Produce Call）。

下面是一个远程调用的例子：

最直接的调用方式就是调用方给被调用方发送HTTP请求，Spring给我们提供了一个RestTemplate的API，可以方便的实现Http请求的发送。

先将RestTemplate注册为一个Bean：

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.client.RestTemplate;@Configuration
public class RemoteCallConfig {@Beanpublic RestTemplate restTemplate() {return new RestTemplate();}
}

利用RestTemplate发送http请求与前端ajax发送请求非常相似，都包含四部分信息：

  • ① 请求方式

  • ② 请求路径

  • ③ 请求参数

  • ④ 返回值类型

发起远程调用：

   // 2.查询商品// List<ItemDTO> items = itemService.queryItemByIds(itemIds);// 2.1.利用RestTemplate发起http请求，得到http的响应ResponseEntity<List<ItemDTO>> response = restTemplate.exchange("http://localhost:8081/items?ids={ids}",HttpMethod.GET,null,new ParameterizedTypeReference<List<ItemDTO>>() {},Map.of("ids", CollUtil.join(itemIds, ",")));

2.4 总结：

什么时候需要拆分微服务？

  • 如果是创业型公司，最好先用单体架构快速迭代开发，验证市场运作模型，快速试错。当业务跑通以后，随着业务规模扩大、人员规模增加，再考虑拆分微服务。

  • 如果是大型企业，有充足的资源，可以在项目开始之初就搭建微服务架构。

如何拆分？

  • 首先要做到高内聚、低耦合

  • 从拆分方式来说，有横向拆分和纵向拆分两种。纵向就是按照业务功能模块，横向则是拆分通用性业务，提高复用性

服务拆分之后，不可避免的会出现跨微服务的业务，此时微服务之间就需要进行远程调用。微服务之间的远程调用被称为RPC，即远程过程调用。RPC的实现方式有很多，比如：

  • 基于Http协议

  • 基于Dubbo协议

我们课堂中使用的是Http方式，这种方式不关心服务提供者的具体技术实现，只要对外暴露Http接口即可，更符合微服务的需要。

Java发送http请求可以使用Spring提供的RestTemplate，使用的基本步骤如下：

  • 注册RestTemplate到Spring容器

  • 调用RestTemplate的API发送请求，常见方法有：

    • getForObject：发送Get请求并返回指定类型对象

    • PostForObject：发送Post请求并返回指定类型对象

    • put：发送PUT请求

    • delete：发送Delete请求

    • exchange：发送任意类型请求，返回ResponseEntity

3.服务注册与发现

基于手动发送HTTP请求实现远程调用的方式存在很多问题，如果需要调用的微服务越来越多，我们需要实时知道每一个微服务的地址以及调用所需的参数，如果微服务节点实时变化，我们无法实时感知到。因此我们引入注册中心的概念。

3.1 注册中心原理

在微服务远程调用的过程中，包括两个角色：

  • 服务提供者：提供接口供其它微服务访问，比如item-service

  • 服务消费者：调用其它微服务提供的接口，比如cart-service

在大型微服务项目中，服务提供者的数量会非常多，为了管理这些服务就引入了注册中心的概念。注册中心、服务提供者、服务消费者三者间关系如下：

流程如下：

  • 服务启动时就会注册自己的服务信息（服务名、IP、端口）到注册中心

  • 调用者可以从注册中心订阅想要的服务，获取服务对应的实例列表（1个服务可能多实例部署）

  • 调用者自己对实例列表负载均衡，挑选一个实例

  • 调用者向该实例发起远程调用

当服务提供者的实例宕机或者启动新实例时，调用者如何得知呢？

  • 服务提供者会定期向注册中心发送请求，报告自己的健康状态（心跳请求）

  • 当注册中心长时间收不到提供者的心跳时，会认为该实例宕机，将其从服务的实例列表中剔除

  • 当服务有新实例启动时，会发送注册服务请求，其信息会被记录在注册中心的服务实例列表

  • 当注册中心服务列表变更时，会主动通知微服务，更新本地服务列表

3.2 Nacos注册中心

目前开源的注册中心框架有很多，国内比较常见的有：

  • Eureka：Netflix公司出品，目前被集成在SpringCloud当中，一般用于Java应用

  • Nacos：Alibaba公司出品，目前被集成在SpringCloudAlibaba中，一般用于Java应用

  • Consul：HashiCorp公司出品，目前集成在SpringCloud中，不限制微服务语言

以上几种注册中心都遵循SpringCloud中的API规范，因此在业务开发使用上没有太大差异。由于Nacos是国内产品，中文文档比较丰富，而且同时具备配置管理功能（后面会学习），因此在国内使用较多。

基于Docker起Nacos服务：

docker run -d \
--name nacos \
--env-file ./nacos/custom.env \
-p 8848:8848 \
-p 9848:9848 \
-p 9849:9849 \
--restart=always \
nacos/nacos-server:v2.1.0-slim

启动完成后，访问下面地址：http://yourIP:8848/nacos/

首次访问会跳转到登录页，账号密码都是nacos

3.3.服务注册

我们把item-service注册到Nacos，步骤如下：

  • 引入依赖

  • 配置Nacos地址

  • 重启

在item-service的pom.xml中添加依赖：

<!--nacos 服务注册发现-->
<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

在item-service的application.yml中添加nacos地址配置：

spring:application:name: item-service # 服务名称cloud:nacos:server-addr: 192.168.150.101:8848 # nacos地址

启动服务实例：

访问nacos控制台，可以发现服务注册成功：

3.4.服务发现

服务的消费者要去nacos订阅服务，这个过程就是服务发现，步骤如下：

  • 引入依赖

  • 配置Nacos地址

  • 发现并调用服务

在cart-service中的pom.xml中添加下面的依赖：

<!--nacos 服务注册发现-->
<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

服务发现除了要引入nacos依赖以外，由于还需要负载均衡，因此要引入SpringCloud提供的LoadBalancer依赖。可以发现，这里Nacos的依赖于服务注册时一致，这个依赖中同时包含了服务注册和发现的功能。因为任何一个微服务都可以调用别人，也可以被别人调用，即可以是调用者，也可以是提供者。

配置Nacos地址：

spring:cloud:nacos:server-addr: 192.168.150.101:8848

3.5 发现并调用服务

接下来，服务调用者cart-service就可以去订阅item-service服务了。不过item-service有多个实例，而真正发起调用时只需要知道一个实例的地址。

因此，服务调用者必须利用负载均衡的算法，从多个实例中挑选一个去访问。常见的负载均衡算法有：

  • 随机

  • 轮询

  • IP的hash

  • 最近最少访问

这里我们可以选择最简单的随机负载均衡。

另外，服务发现需要用到一个工具，DiscoveryClient，SpringCloud已经帮我们自动装配，我们可以直接注入使用：

接下来，我们就可以对原来的远程调用做修改了，之前调用时我们需要写死服务提供者的IP和端口：

但现在不需要了，我们通过DiscoveryClient发现服务实例列表，然后通过负载均衡算法，选择一个实例去调用：

4.OpenFeign

我们利用Nacos实现了服务的治理，利用RestTemplate实现了服务的远程调用。但是远程调用的代码太复杂了,而且这种调用方式，与原本的本地方法调用差异太大，编程时的体验也不统一，一会儿远程调用，一会儿本地调用。因此，我们必须想办法改变远程调用的开发模式，让远程调用像本地方法调用一样简单。而这就要用到OpenFeign组件了。

其实远程调用的关键点就在于四个：

  • 请求方式

  • 请求路径

  • 请求参数

  • 返回值类型

所以，OpenFeign就利用SpringMVC的相关注解来声明上述4个参数，然后基于动态代理帮我们生成远程调用的代码，而无需我们手动再编写，非常方便。

4.1 入门案例

我们还是以cart-service中的查询我的购物车为例。因此下面的操作都是在cart-service中进行。

在cart-service服务的pom.xml中引入OpenFeign的依赖和loadBalancer依赖：

  <!--openFeign--><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-openfeign</artifactId></dependency><!--负载均衡器--><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-loadbalancer</artifactId></dependency>

启用OpenFeign:

接下来，我们在cart-service的CartApplication启动类上添加注解，启动OpenFeign功能：

@MapperScan("com.hmall.cart.mapper")
@SpringBootApplication
@EnableFeignClients
public class CartApplication {public static void main(String[] args) {SpringApplication.run(CartApplication.class, args);}
}

编写OpenFeign客户端：

在cart-service中，定义一个新的接口，编写Feign客户端：

package com.hmall.cart.client;import com.hmall.cart.domain.dto.ItemDTO;
import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;import java.util.List;@FeignClient("item-service")
public interface ItemClient {@GetMapping("/items")List<ItemDTO> queryItemByIds(@RequestParam("ids") Collection<Long> ids);
}

这里只需要声明接口，无需实现方法。接口中的几个关键信息：

  • @FeignClient("item-service") ：声明服务名称

  • @GetMapping ：声明请求方式

  • @GetMapping("/items") ：声明请求路径

  • @RequestParam("ids") Collection<Long> ids ：声明请求参数

  • List<ItemDTO> ：返回值类型

有了上述信息，OpenFeign就可以利用动态代理帮我们实现这个方法，并且向http://item-service/items发送一个GET请求，携带ids为请求参数，并自动将返回值处理为List<ItemDTO>。

我们只需要直接调用这个方法，即可实现远程调用了。

使用FeignClient:
最后，我们在cart-service的com.hmall.cart.service.impl.CartServiceImpl中改造代码，直接调用ItemClient的方法：

feign替我们完成了服务拉取、负载均衡、发送http请求的所有工作，是不是看起来优雅多了。

而且，这里我们不再需要RestTemplate了，还省去了RestTemplate的注册。

4.2.连接池

Feign底层发起http请求，依赖于其它的框架。其底层支持的http客户端实现包括：

  • HttpURLConnection：默认实现，不支持连接池

  • Apache HttpClient ：支持连接池

  • OKHttp：支持连接池

因此我们通常会使用带有连接池的客户端来代替默认的HttpURLConnection。比如，我们使用OK Http。

在cart-service的pom.xml中引入依赖：

<!--OK http 的依赖 -->
<dependency><groupId>io.github.openfeign</groupId><artifactId>feign-okhttp</artifactId>
</dependency>

在cart-service的application.yml配置文件中开启Feign的连接池功能：

feign:okhttp:enabled: true # 开启OKHttp功能

重启服务，连接池就生效了。

4.4 日志配置

OpenFeign只会在FeignClient所在包的日志级别为DEBUG时，才会输出日志。而且其日志级别有4级：

  • NONE：不记录任何日志信息，这是默认值。

  • BASIC：仅记录请求的方法，URL以及响应状态码和执行时间

  • HEADERS：在BASIC的基础上，额外记录了请求和响应的头信息

  • FULL：记录所有请求和响应的明细，包括头信息、请求体、元数据。

Feign默认的日志级别就是NONE，所以默认我们看不到请求日志。

4.4.1.定义日志级别

在hm-api模块下新建一个配置类，定义Feign的日志级别：

package com.hmall.api.config;import feign.Logger;
import org.springframework.context.annotation.Bean;public class DefaultFeignConfig {@Beanpublic Logger.Level feignLogLevel(){return Logger.Level.FULL;}
}

4.4.2.配置

接下来，要让日志级别生效，还需要配置这个类。有两种方式：

  • 局部生效：在某个FeignClient中配置，只对当前FeignClient生效

@FeignClient(value = "item-service", configuration = DefaultFeignConfig.class)

  • 全局生效：在@EnableFeignClients中配置，针对所有FeignClient生效。

    @EnableFeignClients(defaultConfiguration = DefaultFeignConfig.class)

日志格式：

17:35:32:148 DEBUG 18620 --- [nio-8082-exec-1] com.hmall.api.client.ItemClient          : [ItemClient#queryItemByIds] ---> GET http://item-service/items?ids=100000006163 HTTP/1.1
17:35:32:148 DEBUG 18620 --- [nio-8082-exec-1] com.hmall.api.client.ItemClient          : [ItemClient#queryItemByIds] ---> END HTTP (0-byte body)
17:35:32:278 DEBUG 18620 --- [nio-8082-exec-1] com.hmall.api.client.ItemClient          : [ItemClient#queryItemByIds] <--- HTTP/1.1 200  (127ms)
17:35:32:279 DEBUG 18620 --- [nio-8082-exec-1] com.hmall.api.client.ItemClient          : [ItemClient#queryItemByIds] connection: keep-alive
17:35:32:279 DEBUG 18620 --- [nio-8082-exec-1] com.hmall.api.client.ItemClient          : [ItemClient#queryItemByIds] content-type: application/json
17:35:32:279 DEBUG 18620 --- [nio-8082-exec-1] com.hmall.api.client.ItemClient          : [ItemClient#queryItemByIds] date: Fri, 26 May 2023 09:35:32 GMT
17:35:32:279 DEBUG 18620 --- [nio-8082-exec-1] com.hmall.api.client.ItemClient          : [ItemClient#queryItemByIds] keep-alive: timeout=60
17:35:32:279 DEBUG 18620 --- [nio-8082-exec-1] com.hmall.api.client.ItemClient          : [ItemClient#queryItemByIds] transfer-encoding: chunked
17:35:32:279 DEBUG 18620 --- [nio-8082-exec-1] com.hmall.api.client.ItemClient          : [ItemClient#queryItemByIds] 
17:35:32:280 DEBUG 18620 --- [nio-8082-exec-1] com.hmall.api.client.ItemClient          : [ItemClient#queryItemByIds] [{"id":100000006163,"name":"巴布豆(BOBDOG)柔薄悦动婴儿拉拉裤XXL码80片(15kg以上)","price":67100,"stock":10000,"image":"https://m.360buyimg.com/mobilecms/s720x720_jfs/t23998/350/2363990466/222391/a6e9581d/5b7cba5bN0c18fb4f.jpg!q70.jpg.webp","category":"拉拉裤","brand":"巴布豆","spec":"{}","sold":11,"commentCount":33343434,"isAD":false,"status":2}]
17:35:32:281 DEBUG 18620 --- [nio-8082-exec-1] com.hmall.api.client.ItemClient          : [ItemClient#queryItemByIds] <--- END HTTP (369-byte body)

http://www.dtcms.com/a/394389.html

相关文章：

  • http、UDP协议
  • 微服务基础3-服务保护与分布式事务
  • C++红黑树详解
  • 【不背八股】15.kmp算法/ Dijkstra算法/二叉树遍历
  • 【ES】ElasticSearch 数据库之查询操作 从入门＞实践＞精通 一篇文章包含ES的所有查询语法
  • huggingface-cli修改模型下载路径
  • 计算机视觉——灰度分布
  • OpenFeature 标准在 ABP vNext 的落地
  • Agentic AI 多智能体协作：开发实战、框架选型与踩坑指南
  • [优选算法专题三二分查找——NO.17二分查找]
  • 一文学会c++哈希
  • 【06】EPGF 架构搭建教程之 本地环境管理工具的本地化
  • 【开发实践】DNS 报文分析与 CDN 架构可视化方案
  • Ubuntu 系统下 Nginx + PHP 环境搭建教程
  • AI 如何改变日常生活
  • 字典树 Trie 介绍、实现、封装与模拟 C++STL 设计
  • 第一性原理（First Principles Thinking）
  • 1.UE-准备环境（一）-账号注册和打开虚幻引擎源码页面
  • javascript `AbortController`
  • 时间复杂度与空间复杂度
  • rocketmq队列和消费者关系
  • RAG评估指南：从核心指标到开源框架，打造高效检索生成系统
  • xtuoj 0x05-A 前缀和
  • 防误删 (实时) 文件备份系统 (btrfs 快照 + rsync)
  • 【FreeRTOS】第七课（1）：任务间通信（使用队列）
  • OD C卷 - 二叉树计算
  • DiffDock 环境安装和使用教程
  • NVIC中的不可屏蔽中断NMI（Non-Maskable Interrupt）是什么？
  • TypeORM 浅析
  • 2.4 死锁 (答案见原书 P165)