8月更文挑战第一天。本菜鸟决定本月学习Spring Cloud，并陆续发到8月更文中。
简介
当前单体架构存在诸多不足，随互联网技术的发展，微服务架构应运而生。 微服务架构一般来说就是讲一个系统的功能模块按照一定的粒度划分为不同的服务，其中粒度划分情况根据系统的实际情况而定，可以是一个模块，也可以是一个方法。此外，我们既可以将每个服务单独部署，也可以将多个服务部署到一台服务器上。各个服务之间是松耦合的，他们通过一定的方式进行通信，比如HTTP和RPC。
Spring Cloud 实现了微服务架构的方方面面。
优势
- 一个服务只做一件事，结构清晰；
- 一个应用由多个工程组成，每个服务启动周期短；
- 各服务之间是独立的，一个服务宕机不会影响全局；
- 低耦合，易于扩展，如果要加入一个新的需求，只要创建一个微服务，同一个系统下的其他微服务通过HTTP、RPC等方式就可以访问新服务的数据。
核心模块
| 核心模块 | Spring Cloud |
|---|---|
| 服务的注册与发现 | Eureka、Consul、ZooKeeper |
| 服务网关 | Gateway、Zuul |
| 服务间通信 | Ribbon、OpenFeign |
| 断路器 | Hystrix |
| 配置中心 | Spring Cloud Config |
| 日志追踪 | Spring Cloud Sleuth |
| 消息总线 | Spring Cloud Bus |
| 数据流 | Spring Cloud Stream |
| 任务调度 | Spring Cloud Task |
整体架构思路
通过架构图可知，所有的客户端请求都是通过服务网关来完成的，而服务网关通过注册中心才能找到具体的服务。因此我们的服务在启动后都必须注册到注册中心。在实际中，为了保证微服务的高可用性，一个服务往往会启动多个端口，甚至部署到不同的服务器上，这样，即使摸个端口宕机，也不会影响全局。这些，都需要注册中心来管理这些服务。
在解决了应用的并发瓶颈之后，数据库就成为了整个应用的瓶颈。因此，不同的微服务模块可能会连接不同的数据库，甚至每个服务对应的数据库都可能部署集群，服务间在保证低耦合的前提下也需要进行互相通信，它们通信的基础就是 HTTP。
