认识微服务与SpringCloud

目录

认识微服务

软件架构的演变

单体架构

垂直架构

分布式架构

微服务架构

服务拆分原则

认识SpringCloud

两者关系

认识微服务

微服务是一种软件设计架构，当前架构的演变过程主要是：单体架构->垂直架构->分布式架构->微服务架构。软件架构的演变始终围绕着业务复杂度提升、系统可扩展性需求、团队协作效率三大核心驱动力。从最初的单体架构到如今的微服务架构，每一次演进都是对前一种架构局限性的突破。

软件架构的演变

单体架构

单体架构指的是将一个软件的所有功能模块（如用户管理、订单管理、支付等）打包到一个整体应用中，作为一个完整的部署单元进行运行和管理。所有业务模块耦合在一起，共享同一个进程和数据库。

缺点

应用越来越大，代码复杂度提升，维护和升级难度大。

任何小变动都需要重新打包和发布整个应用，影响上线效率。

扩展性有限，无法针对热点模块单独扩展。

技术栈单一，限制了技术创新和灵活性。

垂直架构

垂直架构又称垂直拆分，是将单体应用按业务模块拆分成多个较大的服务，每个服务负责完整业务领域的一部分，垂直切分业务线。解决了单体应用中业务模块耦合过紧的问题。

缺点

服务数量较少，每个服务内部仍可能存在复杂度。

不同服务之间通信复杂度增加。

部署复杂度提升。

技术栈灵活性提高，但仍有限。

分布式架构

分布式架构是将系统的计算和数据拆分到不同的服务器或节点上，通过网络通信协同完成业务操作。它包括垂直拆分、水平拆分、缓存、消息队列等多种技术手段。物理上分布在不同机器或数据中心，提高系统可用性和扩展性。

缺点

系统复杂度大幅提升。

调试和运维难度增加。

数据一致性和事务处理变得复杂。

微服务架构

微服务架构是分布式架构的一种具体实现，将系统拆分成一组小而独立的服务，每个服务围绕具体业务能力构建，能够独立开发、测试、部署和扩展。服务粒度更细，每个服务只负责单一业务功能。独立部署：服务单独打包和发布，不影响其他服务。技术多样性：不同服务可以使用不同的语言、框架。

缺点

服务间通信和数据一致性复杂。

分布式事务实现复杂。

运维成本高。

团队要求高。

服务拆分原则

微服务到底多小才算"微"，这个在业界并没有明确的标准，微服务并不是越小越好，服务越小，微服务架构的优点和缺点都会越来越明显。服务越小，微服务的独立性就会越来越高，但同时，微服务的数量也会越多，管理这些微服务的难度也会提高，所以服务拆分也要考虑场景。

拆分原则一般遵循如下原则：

认识SpringCloud

微服务作为一种软件设计架构思想，而SpringCloud则是分布式微服务结构一站式解决方案。

Spring Cloud 是基于 Spring Boot 的微服务开发工具集，它整合了一系列组件，用于解决微服务架构落地时的共性问题（如服务注册发现、负载均衡、服务调用、熔断降级、集中配置管理、API网关等），简化了微服务系统的开发和运维。

服务注册与发现：服务动态注册，客户端自动发现服务地址。

负载均衡：自动分配请求到多个服务实例。

服务调用：简化服务间HTTP调用。

熔断降级：提高系统的稳定性和容错能力，防止服务故障扩散。

集中配置管理：统一管理分布式系统配置，避免每个服务单独维护配置文件。

API网关：统一对外接口，做安全、路由、限流等。

形象理解SpringCloud：

例如市面上存在不同品牌的家电，像电视、空调、洗衣机、冰箱等。

当我们首次装修房子时需要购买家电，此时存在一个企业推出装修有个套餐

套餐为：A牌电视机+C牌空调+B牌洗衣机+A牌冰箱

该企业的套餐就是在每个模块中都选取市面上比较好的品牌进行整合

SpringCloud也就类似于这个企业

两者关系

微服务是 “目标”：它定义了系统应该如何设计（拆分服务、独立运行、协作通信）。

Spring Cloud 是 “实现手段”：它提供了一套现成的工具，帮助开发者快速构建符合微服务架构的系统，解决微服务落地时的技术难题。

简单说：微服务告诉我们 “应该做什么架构”，Spring Cloud 告诉我们 “如何用技术实现这种架构”。