「这是我参与11月更文挑战的第7天，活动详情查看：2021最后一次更文挑战」
1. 系统架构的演变
互联网早期，网站的应用流量小，只需要一个单一应用架构就可以支撑服务的功能，减少开发、部署维护的成本。
随着智能设备的普及，手机电脑的广泛使用，互联网人群增大，网站的访问量也逐渐增大，但是可能只是单一的模块的访问量增大，例如电商项目的订单模块，这时的架构师希望将单个系统拆分成多个系统，给访问量大的系统增加节点，提高效率（垂直应用架构）。
随着垂直应用架构的使用，弊端显现，系统间独立运行，无法相互调用，系统间有重复的模块。之后便对服务继续拆分，拆分成业务层（业务的逻辑）和表现层（页面的交互），服务层抽取公共功能作为服务层。（分布式架构）
但是服务越来越多，便增加一个服务调度中心，对服务进行资源调度和治理(SOA Service Oriented Architecture，面向服务的架构)，这和现在的微服务架构相差无几了，但针对微服务的问题解决还差系统性的方案和处理。
微服务架构急需一系列针对微服务问题的系统性解决方案。
2. 微服务组件解决的四个问题
【微服务需要解决的问题】
-
这么多小服务，如何管理 - 服务治理 Eureka
-
服务间如何通信 - 服务调用 OpenFeign
-
客户端如何访问这些服务 - 服务网关 Zuul
-
服务出错如何处理、排查 - 服务容错 Hystrix
各大厂商针对这些问题，提出解决的方案，SpringCloud将他们整合，便有了现在的微服务架构。
SpringCloud就是单纯的对这些组件进行整合，对用 SpringBoot进行开发的微服务进行管理的系统性生态。
【组件的作用】
- Eureka：各个服务启动时，服务提供者都会将服务注册到Eureka Server，并且服务消费者还可以反过来从 Eureka Server拉取注册表，从而知道其他服务在哪里
- OpenFeign
-
- Ribbon：服务间发起请求的时候，基于 Ribbon做负载均衡，从一个服务的多台机器中选择一台
- Feign：基于 Feign的动态代理机制，根据注解和选择的机器，拼接请求URL地址，发起请求
- Hystrix：发起请求是通过Hystrix的线程池来走的，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题
- Zuul：如果前端、移动端要调用后端系统，统一从Zuul网关进入，由Zuul网关转发请求给对应的服务