目录

一、概念

1、单体架构

2、微服务

3、springcloud

 二、微服务的拆分

1、微服务的拆分原则

1.1 什么时候拆

1.2 怎么拆

2、服务调用

2.1 resttemplate

2.2 远程调用

---

一、概念

1、单体架构

        单体架构（monolithic structure）：顾名思义，整个项目中所有功能模块都在一个工程中开发；项目部署时需要对所有模块一起编译、打包；项目的架构设计、开发模式都非常简单。

当项目规模较小时，这种模式上手快，部署、运维也都很方便，因此早期很多小型项目都采用这种模式。

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

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

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

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

2、微服务

        微服务（Microservices）是一种软件架构风格，它将一个大型应用程序拆分为一组小型、独立的服务，每个服务运行在自己的进程中，并通过轻量级的通信机制（如HTTP/REST或消息队列）进行通信。每个服务通常专注于完成一个特定的业务功能，并且可以独立部署、扩展和维护。

 

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

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

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

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

在微服务中可以将不同的模块交给不同的团队开发并且独立部署

 

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

• 团队协作成本高？

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

• 系统发布效率低？

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

• 系统可用性差？

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

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

        当然，微服务架构虽然能解决单体架构的各种问题，但在拆分的过程中，还会面临很多其它问题。比如：

• 如果出现跨服务的业务该如何处理？

• 页面请求到底该访问哪个服务？

• 如何实现各个服务之间的服务隔离？

3、springcloud

        Spring Cloud 是一个基于 Spring Boot 的微服务框架，它提供了一系列工具和库，帮助开发者快速构建和部署微服务架构的应用程序。Spring Cloud 提供了许多常见的微服务模式和组件，如服务发现、配置管理、负载均衡、断路器、API 网关等。

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

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

        目前SpringCloud最新版本为2022.0.x版本，对应的SpringBoot版本为3.x版本，但它们全部依赖于JDK17，目前在企业中使用相对较少。

SpringCloud版本	SpringBoot版本
2022.0.x aka Kilburn	3.0.x
2021.0.x aka Jubilee	2.6.x, 2.7.x (Starting with 2021.0.3)
2020.0.x aka Ilford	2.4.x, 2.5.x (Starting with 2020.0.3)
Hoxton	2.2.x, 2.3.x (Starting with SR5)
Greenwich	2.1.x
Finchley	2.0.x
Edgware	1.5.x
Dalston	1.5.x

 

 

二、微服务的拆分

1、微服务的拆分原则

服务拆分一定要考虑几个问题：

• 什么时候拆？

• 如何拆？

1.1 什么时候拆

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

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

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

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

1.2 怎么拆

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

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

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

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

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

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

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

• 纵向拆分

• 横向拆分

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

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

        然而当我们拆分完成到不同的模块之后我们又会遇到一个新的问题，那就是当拆分为不同的微服务之后我们如何跨服务调用其他服务的接口？

2、服务调用

        当我们将前端的nginx启动之后你就会惊讶的发现为什么获取不了后端的数据了，明明拆分之前还好好的，这是因为将单体项目拆分成了不同的服务了，然而不同的服务之间是不能直接调用其它服务的三层架构中的功能的。如果想要调用该如何实现呢？首先要明白服务之间调用也是要用HTTP请求或者REST，那么我们如何发送HTTP请求到其他服务呢？

2.1 resttemplate

        Spring给我们提供了一个RestTemplate的API，可以方便的实现Http请求的发送。其中提供了大量的方法，方便我们发送Http请求，例如：

可以看到常见的Get、Post、Put、Delete请求都支持，如果请求参数比较复杂，还可以使用exchange方法来构造请求。

在使用之前需要先将resttemplate注入到ioc容器中，做如下配置

package com.hmall.cart.config;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.client.RestTemplate;
@Configuration
public class RemoteCallConfig {
    @Bean
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}

2.2 远程调用

示例如下：

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

• 请求方式

• 请求路径

• 请求参数

• 返回值类型

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

• 注册RestTemplate到Spring容器

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

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

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

  • put：发送PUT请求

  • delete：发送Delete请求

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

        使用过之后我们会发现这种方法跨服务调用有很多的劣势，比如我们直接将url写死了，就不能灵活的调用其他的功能了、再者就是这种方法比较繁琐需要很多的参数。在下面我们会借助nacos服务注册中心实现服务之间的调用，这样实现会比较方便而且不会出现上述问题。