一、微服务架构#
1、微服务架构简介#
1.1、分布式：不同的功能模块部署在不同的服务器上，减轻网站高并发带来的压力。
1.2、集群：多台服务器上部署相同应用构成一个集群，通过负载均衡共同向外提供服务。
1.3、微服务：微服务架构模式就是将web应用拆分为一系列小的服务模块，这些模块可以独立地编译、部署，并通过各自暴露的API接口通讯，共同组成一个web应用。
1.4、SpringCloud是基于SpringBoot的一整套微服务框架，提供了一系列可配置的组件，如配置管理、服务发现、负载均衡、熔断器、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等。
2、微服务的特点#
- 单一职责：每一个服务模块都对应单一的业务实现
- 微：服务拆分的颗粒度很小
- 面向服务：每个服务对外仅暴露服务接口API即可，不关心服务的技术实现，与技术、语言和平台无关
- 自治：服务间互相独立、互不干扰
- 团队独立
- 技术独立：提供Rest接口，面向服务即可
- 前后端分离
- 数据库分离：每个服务使用自己的数据源
- 部署独立：每个服务都是独立的组件，可复用，可替换，降低服务间的耦合
3、三者的关系#
微服务是一种结构理念，设计原则，提供理论指导；
Spring Boot专注于快速、方便集成的单个微服务个体，可以基于Spring Boot快速开发单个微服务；
Spring Cloud是一个基于Spring Boot实现的服务工具治理包，专注于全局的服务治理框架。
二、Spring Cloud#
1、Spring Cloud组件架构#
上图中各组件的组件和运行流程如下：
-
- 所有请求都通过API网关来访问内部服务；
- 网关接受请求后，从注册中心获取可用服务模块；
- 由Ribbon进行负载均衡后，分发到后台的具体实例；
- 各个服务模块之间通过Feign进行通信处理业务；
- Hystrix负责处理服务超时熔断；
- Turbine监控服务间的调用和熔断相关指标。
再来看一个具体实例上的Spring Cloud服务流程：
2、Spring Cloud组件简介#
2.1、主要组件简介#
- Eureka，服务注册中心
- Zuul，API服务网关
- Config，分布式配置中心，支持本地仓库、SVN、Git、Jar包内配置等模式
- Dashboard，Hystrix仪表盘，监控集群模式和单点模式，其中集群模式需要收集器Turbine配合
- Ribbon，客户端负载均衡
- Feign，声明式服务调用
- Bus，消息总线
2.2、组件主要功能#
Eureka和Ribbon，一个注册服务，一个消费服务。
Hystrix，为了优化Ribbon，防止整个微服务架构因为某个服务节点的问题导致崩溃，起到保险丝的作用。
Dashboard，给Hystrix统计和展示用，而且监控服务节点的整体压力和健康情况。
Turbine，集群收集器，服务于Dashboard。
Zuul，加在整个微服务最前沿的防火墙和代理器，隐藏微服务结点IP端口信息，加强安全保护。
Config，为了解决所有微服务各自维护各自的配置，设置一个统一的配置中心，方便修改配置。
Bus是因为config修改完配置后各个结点都要refresh才能生效实在太麻烦，所以交给bus来通知服务节点刷新配置的。
3、SpringCloud全家桶#
- 首先为了提供微服务之间的发现和注册，需要服务注册中心提供注册与发现功能，采用Eureka组件。
- 消费者从注册中心拿到服务提供者的注册地址信息列表，为了从中选择一个提供方，避免流量集中在某台机，需要客户端负载均衡组件Ribbon。
- 消费者得到具体提供方的地址信息后，发起远程调用，通过声明式调用组件Feign，将远程RestFul调用封装成接口调用。
- 在微服务架构中，为了避免某个服务挂掉后引起服务雪崩，以及做到服务端失败后快速响应，提供了服务熔断以及降级机制Hystrix组件。
- 为了对外屏蔽内部服务调用细节，在最前沿加入网关组件，提供流量控制、身份鉴别、负载均衡等安全防护功能，采用API网关Zuul组件。
- 随着系统访问量的增加，为避免单点的注册中心成为系统性能瓶颈，注册中心采用Eureka集群方式部署。
- 随着系统扩大，Eureka集群的部署以及服务模块的增多，每个模块维护各自的配置信息，复杂且容易出错，引入配置中心SpringCloud Config组件，提供统一的配置信息管理。
- 为了避免每次配置信息的变更都需要重启服务才能生效，引入消息总线Bus组件，提供无需重启、实时刷新配置信息等功能。
后续也会按照这个顺序逐个介绍各组件，以及各组件demo的开发搭建，最终完成一个SpringCloud全家桶demo......