微服务架构的演变过程
目录
1. 架构的演变过程
1.1 单体架构
1.2 集群
1.3 垂直化
1.4 服务化（SOA）
1.5 微服务化
2. SpringCloud
1. 架构的演变过程
1.1 单体架构
1.2 集群
（水平伸缩，负载均衡分发请求数量，实现高可用）
1.3 垂直化
业务复杂度越来越高，不同人群对产品的体验方式不一样，需要做业务解耦。垂直拆分：将业务拆分为多个系统，如电商网站分为用户系统、订单系统、商品系统，每个系统都对应其子域名，有其独立的数据库。按照子域名去访问不同的子系统。
如此一来，会有对应的问题：数据库是按业务拆分的，如果业务A需要查询B的数据库，实际业务B也会有查询B的代码，容易存在大量的冗余代码。如果B数据库发生变更，所有设计的业务代码都需要变更。因此引入了服务化SOA的概念。
1.4 服务化（SOA）
SOA，解决冗余和信息孤岛问题，用特定的规范去定义一个服务。
中间加一个服务层，服务层专门处理共享服务。
比如，用户服务、订单服务、商品服务，只提供公共服务的接口，接口必须满足某种契约。系统调用对应的服务去完成业务。
核心目标：把一些通用的，会被多个上层业务调用的模块拆分出来，形成一个共享的基础服务。这些拆分出来的服务相对来说是独立的，可重用的，从而实现业务的灵活性。
SOA的作用：数据的互联互通、业务的重用，
1.5 微服务化
SOA到微服务没有太大的变化，微服务实际上强调的是SOA的更细粒度化的拆分。（递进的关系）
比如，用户服务进一步可以拆分为用户服务、账户服务、积分服务等。
微服务下会带来的问题：底层基础运维的资源是否成熟设施是否完善。（原来十个服务、现在一百个服务）
如果一定要回答SOA和微服务的区别？
- 微服务是在SOA思想上进一步提炼的产物，SOA思想的成熟和基础设施的成熟形成了微服务。
- 微服务的主要目的是实现解耦，降低业务之间的耦合度，更关注服务之间的粒度。而SOA主要是为了解决数据互联互通、数据孤岛问题和业务单元的共享性，更关注服务之间的重用。
- 微服务会使用一些轻量级的协议，比如REST风格的API，轻量级协议能更好支持跨语言，所以微服务生态更完善。服务粒度更小了，也更注重运维和连通性。
微服务时代的到来，分布式架构下要着重考虑网络不可靠性下如何保持服务可用。会产生对应的需求 ，对应着微服务结构中的各个组件：
- 服务之间的远程通信——RPC通信
采用专线通信，提高通信性能。因此产生了 RPC通信。
比如用户服务调用订单服务去查询用户的订单数据，就需要用户服务通过远程通信调用订单服务。
- 服务注册中心
分布式架构下服务的集群解决单点故障问题，客户端在发起通信时，要通过负载均衡来实现分发。负载均衡的前提是服务调用者要清楚服务提供者的地址。即，用户服务需要知道所有提供订单服务的地址。
要实现该功能，可以将服务提供者的地址全部静态写在客户端的配置文件中。但是，这种方式无法实现 ①服务的动态感知（上线（恢复、扩容）、下线）。② 当微服务数量很多，每个节点都要维护对应的地址信息，造成维护工作量很大。
因此，引入注册中心 → 满足 服务动态感知 和 高效管理地址。
有了注册中心后，服务调用者（客户端）先通过注册中心拿到服务提供者的地址，然后缓存到本地。负载均衡的算法集成在客户端，再实现目标地址的均衡路由。
注册中心的实现：Nacos / consul / Eureka / zookeeper ...
- 负载均衡的实现
常用组件：Ribbon（Spring），
负载均衡算法：轮询、哈希、随机、根据响应时间来计算权重的轮询。
- 统一配置中心
通过application.yaml配置文件来配置，有以下缺点：
1. 更改配置后要重启服务
2. 服务很多的情况下很难实现配置管理
3. 配置信息不安全
因此，引入统一配置中心
在服务启动时，服务到配置中心加载相关的配置，缓存到本地。相关人员访问配置中心进行配置，当配置中心的配置发生变更后，配置中心会告知服务对配置缓存进行更新，实现动态配置管理。
通常，可以将以下配置到统一配置中心实现动态配置：阈值（如限流阈值、线程池的阈值、降级开关、第三方服务密钥等）
常用组件：apollo / Nacos / zookeeper / disconf / SpringCloud Config / diamond ...
- 网关
网关主要功能：统一授权、日志记录、限流熔断也可以在网关做。
客户在发起请求时，先经过网关进行路由转发，得到返回值通过网关返回给客户。
网关本质上是一个路由（route）和过滤器（prefilter和postfilter）。
常用网关：SpringCloud gateway、SpringCloud zuul...
为了实现网关的高可用，通常会在客户和网关之间再加一个 nginx， nginx可以基于keepalived做主从。
- 限流、降级、容错、缓存
当请求流量超出系统吞吐量时，需要进行限流，降低一部分用户的可用性，满足大部分用户的体验。
常见限流算法：令牌桶、计数器（滑动窗口）、漏桶、ratelimiter
常见限流组件：sentinel、hystrix；
服务主动降级：比如618大促时把订单评论、广告等关闭，保证核心服务可用。
服务被动降级：限流后降级，返回友好提示；
容错：当下游服务宕机时，上游服务通过容错机制（重试、failover、记录日志再异步处理）根据不同的业务处理场景来处理。
异步通信机制：Spring中提供了 SpringCloudBus 通信总线，通信总线的本质对接的是 kafka/ rabbitMQ，实现异步通信的传递。
服务和服务本身之间是可以实现异步通信的，消息队列中的消息
- 监控
SpringCloud 提供 sleuth+aipkin 链路追踪，对于每个请求会生成对应的一个 tranceId、spanId，tranceId是唯一的，spanId表示经过的第几个节点。
Zipkin dashboard：每个节点会上报其请求耗时和数量等信息，人员可以通过看板实时查看。
通过追踪每个节点花费的时间可以找到费时节点。
常见监控组件：cat 、jaeger、skywalking、pinpoint...
2. SpringCloud
SpringCloud之前，对于微服务中涉及的组件，开发人员自己组合，会存在版本兼容等问题。
SpringCloud 生态：提供了快速构建微服务的技术组件，包含：
SpringCloud 版本号是根据伦敦的街区命名的，从A-K，比如Hoxton、Greenwish...，对于某版本(Greenwish)下的所有组件的版本号(nacos的版本、sentinel的版本...)，保存在Greenwish版本的bom文件清单中。
SR：发行版；GA：稳定版
SpringBoot 和 SpringCloud 有很大关系：SpringCloud中的服务是在SpringBoot上构建的，组件的版本需要与springboot也兼容。