现在微服务架构可以说是风靡全球，微服务架构是一种抽象的概念，具体落地的框架有很多种，而当前在java界最流行的要数dubbo和SpringCloud了，那么咱们自己的项目中是选择dubbo还是SpringCloud呢？这个需要先弄清楚微服务架构中需要解决哪些问题。微服务架构本身是解决了单体架构的很多问题，比如单体架构中某一个服务出问题了，那就得连带所有功能都不能用了。但是不代表微服务架构就没有问题，微服务架构也有自己的很多问题需要解决，比如如何实现服务注册与发现、服务之间如何通信、如何防止服务雪崩、如何实现链路追踪等。下表是两者在解决问题层面的支持对比：
但是不知道老铁们有没有发现，对于SpringCloud这个微服务框架，有用SpringCloudNetfix的，也有用SpringCloudAlibaba的，既然SpringCloud是微服务框架，为什么还有Netfix和Alibaba之分呢？其实SpringCloud是Spring这个大家族下，基于SpringBoot的一整套实现微服务的方案，或者说它是一套微服务规范更为贴切，它包括了一堆的组件，每个组件完成上述表格中独立的任务，而且在开始之初这些组件大部分都是Netfix提供，后来Alibaba也基于SpringCloud这套微服务规范提供了具体的实现。
这次系列文章，笔者就先把SpringCloudNetfix这套具体实现讲清楚，后续在讲SpringCloudAlibaba，当然这里也是讲主要的组件，因为SpringCloud设计的组件实在太多，如果各位老铁想学习全部的可以去Spring的官网瞅瞅。
对于SpringCloud，笔者将从应用和底层源码两个层面来写，先知其然，然后知其所以然。
本次笔者主要分析以下几大组件，现在将组件名称和它的主要作用罗列出来，后续针对每个组件徐徐展开：
- Eureka：注册中心，实现服务治理，它是Spring Cloud Netflix项目下的服务治理模块，由两个组件组成：Eureka服务端和Eureka客户端。
Eureka服务端用作服务注册中心。支持集群部署；
Eureka客户端是一个java客户端，用来处理服务注册与发现。
- Ribbon：负载均衡，主要提供客户侧的软件负载均衡算法。根据服务名到Eureka服务中获取服务地址列表， 再根据或利用Ribbon负载均衡算法从地址列表中获取一个服务地址并访问。
- Feign：服务调用，让服务调用像使用本地类一样简单。
- Hystrix：熔断器，熔断本身的作用类似保险丝，也就是当出现异常（比如访问超时，服务不可用抛出异常）情况时，保证整个服务的正常运行，其实可以在服务端和客户端起作用，服务端说的是在被调服务端主动触发，而客户端说的是调用发主动降级，此时不会进入到服务端。可以通过Hystrix Dashboard这个监控面板，通过界面监控各个服务上的服务调用所消耗的时间等。
- Zuul：负责网络的路由，可以做统一的降级、限流、认证授权、安全。
- Config：分布式配置，包括服务器端和客户端。服务器存储后端的默认实现使用git，动态的需要配合Spring Cloud Bus实现动态的配置更新。
- Sleuth：Spring Cloud应用程序的分布式请求链路跟踪，支持使用Zipkin、HTrace和基于日志（例如ELK）的跟踪。