什么是微服务

单体架构

整个项目的所有功能模块都在一个工程中开发，项目部署时需要对所有模块一起编译、打包。如下图所示：

优点：当项目规模较小时，这种模式上手快，部署、运维都很方便。

缺点：

微服务架构是一种软件设计模式，通过将大型单体应用拆分成多个独立的小型服务，每个服务专注特定的业务功能。这种架构旨在提高系统的灵活性、可扩展性和可维护性。它满足以下核心要点：

例如，上面图中的4个功能模块，我们可以拆分成商品、用户、交易、购物车这几个模块，分别交给不同的团队去开发，并独立部署：

大家之前可能听说过分布式架构，分布式就是微服务的拆分过程，其实微服务架构正式分布式架构的一种最佳实践方案。

虽然微服务能解决单体架构的问题，但是在拆分的过程中，也会面临其他的问题：

SpringCloud 框架就能解决这种问题。SprigCloud 框架可以说是目前 Java 领域最全的微服务组件的集合了。

而 SpringCloud 是依托于 SpringBoot 的自动装配能力，两者版本有对应条件：

另外 Alibaba 的微服务产品 SpringCloudAlibaba 目前也成为了 SpringCloud 组件的一员。

我们要使用的话，在父工程 hmall 的 pom.xml 中引入依赖：

指定版本如下，这样后续使用的时候就无需指定版本了。

上一章我们实现了微服务的拆分，并且通过 Http 请求实现了跨微服务的远程调用。不过这种手动发送 Http 请求的方式存在几个问题。

试想一下，如果商品微服务调用过多，为了应对高并发我们进行了多实例部署，如下图：

此时，每个item-service的实例其IP或端口不同，问题来了：

为了解决上述问题，就必须引入注册中心的概念了。

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

而为了应对在大型微服务项目中服务提供者数量太多，微服务不好管理的问题，就引入了注册中心的概念。三者关系如下：