本篇文章主要介绍学习SpringCloud前提条件，以及介绍SpringCloud以及各个组件

前提条件

最近项目在使用微服务作为开发项目的一个架构，所以趁这个时间学习一下SpringCloud，学习SpringCloud的前提要有一定的Java基础，并且对Spring和SpringBoot有一定使用。如果不满足这些，最好先不要尝试去学习SpringCloud。SpringCloud是在Spring+SpringBoot的基础上搭建而成。

微服务

微服务出现原因

相信很多项目都是从单体应用开始的，所有的业务模块耦合在一起，这样的单体应用比较容易部署，测试，在项目初期确实可以很好的运行。然而随着需求的增加，越来越多人加入开发团队，代码库也在飞速膨胀，慢慢的单体应用变得越来越臃肿，可维护性，灵活性逐渐降低，维护成本 越来越高。下面列举一些单体应用的问题：

复杂性高：单体百万行代码的项目包含的模块非常多，模块边界模糊，依赖关系不明确，代码质量残次不齐，每次改代码都心惊胆战，添加一个简单的功能都会带来隐含的缺陷。

技术债务：随着时间的推移，需求和开发人员更迭，会逐渐形成应用程序的技术债务，不坏不修很常见，已使用的系统设计难以被修改

部署频率低：随着代码的增多，构建和部署时间也会增加，每次功能的变更或者修复都会导致重新部署整个应用。全量部署的方式耗时长，影响范围大，风险高，这使得单体应用部署上线频率降低，而部署频率的降低又会导致两次发布版本之间大量的功能变更和修改，出错概率比较高。

可靠性差：某个模块bug，死循环，oom导致整个应用的崩溃。

拓展能力受限：单体应用只能作为一个整体进行拓展，无法根据业务模块的需要进行伸缩，列如：应用中有的是计算密集型，他需要强筋的cpu，有的是io密集型，他需要更大的内存。全部部署在一起的话需要综合考虑。

什么是微服务

微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通讯采用轻量级通信机制（http）。这些服务公用一个最小型的集中式的管理，服务可用不同语言开发，使用不同数据存储技术。

例如有一个电商网站

1、    由于每个服务都是独立并且微小的，由单独的团队负责，仍然可以采用敏捷开发模式，自由的选择合适的技术，甚至可以重写老服务，当然都要遵守统一的API约定。

2、    每一个微服务都是独立部署的，可以进行快速迭代部署，根据各自服务需求选择合适的虚拟机和使用最匹配的服务资源要求的硬件。

3、    整体应用程序被分解成可管理的模块和服务，单个的服务可以更快的开发、更简单的理解和维护。

4、    一些需要进行负载均衡的服务可以部署在多个云虚拟机上，加入NGINX这样的负载均衡器在多个实例之间分发请求，这样不需要整个应用进行负载均衡了。

每个后端服务暴露一套REST API，大部分服务调用其他服务提供的API。每个服务都有自己的数据库模式，而不是共享单个数据库模式。尽管这会造成某些数据的冗余，但是对于微服务架构这个独立数据库模式是必要的，确保了独立服务之间的松散耦合。

微服务的不足

1、  微服务应用作为分布式系统带来了复杂性。当应用是整体应用程序时，模块之间调用都在应用之内，即使进行分布式部署，依然在应用内调用。可是微服务是多个独立的服务，当进行模块调用的时候，分布式将会麻烦。

2、  多个独立数据库，事务的实现更具挑战性。

3、  测试微服务变得复杂，当一个服务依赖另外一个服务时，测试时候需要另外一个服务的支持。

4、  部署基于微服务的应用也很复杂，整体应用程序部署只需要部署在一组相同的服务器上，在这些服务前面加入传统的负载均衡器即可。独立服务的不是讲变得复杂，需要更高的自动化形式。

SpringCloud

Spring Cloud是一系列框架的有序集合。它利用SpringBoot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

针对微服务的不足之处，SpringCloud结合许多开源技术，整合一套微服务开发的解决方案。SpringCloud依托各个组件来针对性的解决微服务遇到的各个不足之处

SpringCloud组件

Spring Cloud技术应用从场景上可以分为两大类：润物无声类和独挑大梁类。

润物无声，融合在每个微服务中、依赖其它组件并为其提供服务。

Ribbon，客户端负载均衡，特性有区域亲和、重试机制。

Hystrix，客户端容错保护，特性有服务降级、服务熔断、请求缓存、请求合并、依赖隔离。

Feign，声明式服务调用，本质上就是Ribbon+Hystrix

Stream，消息驱动，有Sink、Source、Processor三种通道，特性有订阅发布、消费组、消息分区。

Bus，消息总线，配合Config仓库修改的一种Stream实现，

Sleuth，分布式服务追踪，需要搞清楚TraceID和SpanID以及抽样，如何与ELK整合。

独挑大梁，独自启动不需要依赖其它组件。

Eureka，服务注册中心，特性有失效剔除、服务保护。

Dashboard，Hystrix仪表盘，监控集群模式和单点模式，其中集群模式需要收集器Turbine配合。

Zuul，API服务网关，功能有路由分发和过滤。

Config，分布式配置中心，支持本地仓库、SVN、Git、Jar包内配置等模式，

每个组件都不是平白无故的产生的，是为了解决某一特定的问题而存在。

Eureka和Ribbon，是最基础的组件，一个注册服务，一个消费服务。

Hystrix为了优化Ribbon、防止整个微服务架构因为某个服务节点的问题导致崩溃，是个保险丝的作用。

Dashboard给Hystrix统计和展示用的，而且监控服务节点的整体压力和健康情况。

Turbine是集群收集器，服务于Dashboard的。

Feign是方便我们程序员写更优美的代码的。

Zuul是加在整个微服务最前沿的防火墙和代理器，隐藏微服务结点IP端口信息，加强安全保护的。

Config是为了解决所有微服务各自维护各自的配置，设置一个统一的配置中心，方便修改配置的。

Bus是因为config修改完配置后各个结点都要refresh才能生效实在太麻烦，所以交给bus来通知服务节点刷新配置的。

Stream是为了简化研发人员对MQ使用的复杂度，弱化MQ的差异性，达到程序和MQ松耦合。

Sleuth是因为单次请求在微服务节点中跳转无法追溯，解决任务链日志追踪问题的。

------SpringCloud的组件部分转载 作者：https://blog.csdn.net/yejingtao703/article/details/78331442/