目录
引入
单体架构
当我们刚开始学开发的时候，基本都是单体架构，就是把一个项目的所有业务的实现功能都打包在一个 war 包或者 Jar 包中。这种架构开发简单，部署简单，一个项目就包含了所有的功能，省去了多个项目之间的交互和调用消耗，直接部署在一个服务即可:
集群和分布式架构
但是随着网站的用户量越来越大，对应的需求也会越来越多，流量也会越来越大服务可能就会面临一些问题：
- 后端服务器的压力过大，导致负载变高，出现用户无法访问或者访问失败的情况；
- 业务场景逐渐复杂，为了满足用户需求，单体应用也会越来越大，各个业务代码之间的耦合度也会越来越高。任何一个问题，都需要项目的重新构建和发布，降低了应用的可用性；
- 一个微笑的问题，可能会导致整个服务都挂掉
那有问题出现我们肯定也要有对应的解决方案，可以从以下两个方面进行优化：
- 横向拓展：添加服务器，把单台机器变为多台机器的集群；（集群架构）
- 纵向拓展：把一个应用按照业务拆分为多个小项目，这个架构也叫垂直架构；（分布式架构）以单体结构规模的项目为单位进行垂直划分，也就是将一个大项目拆分为一个个单体结构项目，项目和项目之间相对比较独立，接口多为数据同步功能。
这两种方案也引出下面要说的集群和分布式：
- 集群（cluster）：将一个系统完整的部署到多个服务器上，每个服务器都能提供系统所有的服务，多个服务器之间通过负载均衡调度完成任务，每一个服务器称为集群节点（node）；
- 分布式（distributed）：将一个系统拆分为多个子系统，多个子系统部署在多个服务器上，多个服务器上的子系统协同合作完成一个特定任务；
区别和联系：
- 概念上：集群是多个计算机做同样的事情，分布式是多个计算机做不同的事情；
- 功能上：集群的每个结点功能是相同的，并且可以替代的，分布式也是多个结点组成的系统，但是每个节点完成的业务是不一样的，一个结点出现问题整改服务都会挂掉；
- 关系上：分布式和集群在实践中会配合使用，比如分布式的某个结点可能由一个集群来代替，分布式结构大多是建立在集群上的，所以实际的分布式架构设计中并不会把分布式和集群单独区分，统称：分布式架构；
微服务架构
虽然分布式架构已经按照业务拆分为一个个小的项目，但是还是会有一些重复功能的开发，比如订单系统，电商平台和支付系统都会涉及到；
在分布式架构下，当部署的服务越来越多的时候，重复的代码就会越来越多，服务之间的调用关系也越来越复杂。因此我们可以把一些通用的，会被多个上层服务调用的共享业务，提取成独立基础服务，组成一个个微小的服务，这就是微服务；可以把微服务理解为一个很小的服务，小到一个服务只对应一个单一的功能并且可以单独部署运行，服务之间通过 REST 和 RPC 协议通讯；
从这个角度来看的话，微服务架构就是分布式架构的一种拓展，这种架构模式下它拆分的粒度更小，服务更加独立，分布式就是微服务拆分的过程，微服务就是分布式架构的一种最佳实践方案：微服务是一种经过良好架构设计的分布式架构方案；
分布式架构侧重于压力的分散，强调的是服务的分散化。微服务侧重于能力的分散，更强调服务的专业化和精细分工，从实践的角度来看，微服务架构通常是分布式架构，反之则未必成立，所以选择微服务通常意味着需要解决分布式架构的各种难题。
微服务架构，首先是服务化，就是将单体架构中的功能模块从单体应用中拆分出来，独立部署多个服务。同时要满足以下特点：
- 单一职责：一个微服务负责一部分业务功能，并且其核心数据不依赖于其它模块；
- 团队治理：每一个微服务都有自己独立的开发，测试，发布，运维人员，团队规模适中；
- 服务自治：每个微服务都独立打包部署，访问自己独立的数据库，并做好服务隔离；
所以，微服务架构解决了单体架构存在的问题，特别适合大型项目的开发，因此被大家广泛采用。
挑战
虽然微服务具有很多优势，但是由于服务数量的增加，服务治理也是要面对的一个巨大挑战：
- 服务依赖：随着服务数量增多，服务之间的关系也变得更加复杂，一个服务的更改需要考虑其对其他服务的影响；
- 运维成本：一个业务流程会涉及到多个微服务共同完成，有更多的服务需要编译，部署，运行，甚至可能是不同的编程语言，不同的运行环境，当然也需要集群来处理故障转移；
- 开发和测试：服务之间调用引起网络延迟，不可靠网络，如何进行容错处理等问题，这对开发和测试而言，难度也很大；
- 服务监控：微服务架构下，不仅需要对整个链路进行监控，还需要对每个服务实现监控；
- 负载均衡：微服务架构中的服务实例数量可能会非常庞大，因此需要有效的服务发现和负载均衡机制来管理流量和保证高可用性；
并且我们在拆分服务的时候也会遇到很多问题，比如：
- 如果出现跨服务的业务该如何处理
- 页面请求到底该访问哪一个路径
- 如何实现各个服务之间的服务隔离
如果选择微服务架构的话，以上问题都需要我们自己解决，我们也可以拿市场上比较成熟的技术拿来用，在 Java 领域最被广泛使用的就是下面要讲的 Spring Cloud。
Spring Cloud
介绍
可以先进入 Spring Cloud 的官网看看：Spring Cloud 官网
微服务拆分以后碰到的各种问题都有对应的解决方案和微服务组件，而 Spring Cloud 框架可以说是目前 Java 领域最全面的微服务组件的集合了。它提供了一些可以让开发人员快速构建分布式服务的工具，比如配置管理，服务发现，熔断，智能路由等，它们可以在任何分布式的环境中很好的工作；
简单来说，Spring Cloud 就是分布式微服务架构的一站式解决方案，是微服务架构落地的多种技术的集合：
- Distributed/versioned configuration 分布式版本配置
- Service registration and discovery 服务注册和发现
- Routing 路由
- Service-to-service calls 服务调用
- Loading balancing 负载均衡
- Circuit Breakers 熔断器
- Distributed messageing 分布式消息
- ......
Spring Cloud 并不是 Spring 团队研发的框架，它只是把一些比较优秀的解决微服务架构中常见的问题的开源框架基于 Spring Cloud 规范进行了整合，并基于 Spring Boot 的风格，对这些组件进行封装，屏蔽掉了复杂的配置和实现原理，为开发者提供了开箱即用的微服务开发体验，这些开源技术的框架还是由各个公司来维护的，Spring Cloud 就是把这些管理起来的。
实现方案
在 Spring Cloud 规范下，最为出名的两种实现方案就是：
- Spring Cloud Netflix
- Spring Cloud Alibaba
之前 Spring Cloud 一度使用 Spring Cloud Netflix 最为默认解决方案，但是由于 Netflix 公司在2018年左右宣布核心组件 Hystrix，Ribbon，Zuul 等进入维护状态，所以 Spring Cloud 也被迫宣布删除这些维护模块。
spring-cloud-netflix 也并没有从 Spring Cloud 的依赖中全部删除，只是从2020.0版本开始只管理 Eureka 组件。
并且 Cloud 官方也提供了一些替换建议，有些还是自研的：
- Hystrix ---> Resilience4i
- Hystrix Dashboard/Turbine ---> Micrmeter + Monitoring System
- Ribbon ---> Spring Cloud Loadbalancer
- Zuul 1 ---> Spring Cloud Gateway
- Archaius ---> Spring Boot 外部配置 + Spring Cloud 配置
Spring Cloud Alibaba
Spring Cloud Alibaba 是阿里巴巴集团下的开源组件和云产品在 Spring Cloud 规范下实现。
如果说 Spring Cloud Netflix 是 Spring Cloud 的第一代实现，那么 Spring Cloud Alibaba 也可以看作是 Spring Cloud 的第二代实现，主要由 Nacos，Sentinel，Seate 等组件组成。
使用的 Spring Cloud 版本要与你的 Spring 项目的版本与官网保持一致，使用官网指定的版本，不然会出问题：
