现在很多大型互联网项目都倾向于使用微服务的架构，因为业务模块太多，就比如一个电商项目，包含商品模块，订单模块，支付模块，会员模块等等，若是用传统的单体应用，甚至是SOA，也会出现后台服务压力太大，一个数据库，或者一个服务调用后台，往往不能支持日益增长的业务量，并且最主要的是所有模块耦合在一个应用里，后续想要对会员模块开发一些比如会员积分的功能，都有可能会影响其他模块。
但是如果我们用微服务的架构来的话，将每个模块都独立部署，独立的数据库，模块之间的调用用服务(http)调用的方式来，这样的话将压力分散，每个模块只需要考虑自己的性能提高即可，维护也不会影响其他模块的代码。而SpringCloud微服务框架的出现对微服务技术提供了非常大的帮助，因为SpringCloud 提供了一套完整的微服务解决方案，不像其他框架只是解决了微服务中某个问题。
一、选择SpringCloud的原因
我们如果按微服务的架构来架构项目，将会面对很多微服务架构所必须面对的问题，并且一个框架的出现肯定是为了解决某些问题才会出现的，就算以后我们学习任何技术都是这样，不可能平白无故的出现，肯定是有原因的，下面我们就大概说明下微服务架构所面对的问题，而SpringCloud框架又有什么好的解决方案，先上SpringCloud组件架构图：
1、服务治理
就比如电商项目，如果拆分为微服务的架构，那么如果订单服务要调用会员服务，那么走的肯定是http的方式吗，此时我们需要指定每个服务的ip地址，那么假如我们的会员服务地址改变了的话也，订单服务是找不到对应的ip的了，也需要相应去改。如果服务少的话还好，要是有几百上千个服务，那么一个关键服务的ip改变，此时可能要去修改几百个服务的ip，这样还容易充错。因此需要服务治理技术，管理服务与服务之间依赖关系，可以实现服务调用、负载均衡、容错等，实现服务发现与注册。因为每个服务都统一向一个注册中心注册ip地址，服务之间的调用是通过别名，而不是ip来调用，只要别名不变，那么注册中心会自动的根据服务请求的别名来找到对应的ip。服务去注册中心通过别名找到真正的ip地址后，再在本地通过rpc调用远程。我们的SpringCloud框架就提供了Eureka技术来解决上面遇到的问题，来治理服务。当然这里要说一下，除了Eureka，还有阿里巴巴开源的Dubbo和当当网在其基础上扩展的Dubbox、Apache 的Consul等以及Zookeeper都可以用来当做服务治理。但是我学习的话就是以Eureka为例子，因为其他的框架原理都差不多，都是为了解决微服务之间的调用问题而产生的对应的技术。
2、服务保护机制
大型复杂的分布式系统中，高可用相关的技术架构非常重要。高可用架构非常重要的一个环节，就是如何将分布式系统中的各个服务打造成高可用的服务，从而足以应对分布式系统环境中的各种各样的问题，，避免整个分布式系统被某个服务的故障给拖垮。比如服务间的调用超时、服务间的调用失败要解决这些棘手的分布式系统可用性问题，就涉及到了高可用分布式系统中的很多重要的技术，主要是用服务降级，服务熔断，服务隔离，服务限流的技术来解决服务调用的过程中所面对的服务雪崩效应。服务雪崩效应产生与服务堆积在同一个线程池中，因为所有的请求都是同一个线程池进行处理，这时候如果在高并发情况下，所有的请求全部访问同一个接口，这时候可能会导致其他服务没有线程进行接受请求，这就是服务雪崩效应效应。解决的办法如下：
a、服务降级
在高并发情况下，防止用户一直等待，使用服务降级方式(直接返回一个友好的提示给客户端，调用fallBack方法
b、服务熔断
熔断机制目的为了保护服务，在高并发的情况下，如果请求达到一定极限(可以自己设置阔值)如果流量超出了设置阈值，然后直接拒绝访问，保护当前服务。使用服务降级方式返回一个友好提示，服务熔断和服务降级一起使用。
c、服务隔离
因为默认情况下，只有一个线程池会维护所有的服务接口，如果大量的请求访问同一个接口，达到tomcat 线程池默认极限，可能会导致其他服务无法访问。此时可以使用服务隔离机制来解决这个问题。
d、服务限流
服务限流就是对接口访问进行限制，常用服务限流算法令牌桶、漏桶。计数器也可以进行粗暴限流实现。我们的SpringCloud只需要用Hystrix服务保护框架就解决了上面的众多问题。
3、配置管理
每个服务都有自己的配置，但是如果有时候我们要去修改配置文件的话，就要将服务重新发布，此时如果服务达到上千个的话，每台服务器都要去打开来修改，基本上是不科学的。此时我们的SpringCloud提供了分布式配置中心技术：config分布式配置中心，来解决这个问题，当然因为config组件需要借助git来，比较麻烦，我们可以用携程的阿波罗技术来实现。
4、客户端负载均衡
在我们服务调用其他服务的时候，可能其他服务为了提高自己的效率使用了集群，此时我们的SpringCloud提供了Ribbon客户端负载均衡器来实现本地负载均衡。这里我们要跟nginx负载均衡区分开来，nginx是服务端的负载均衡。其实ribbon的负载均衡原理很简单，就是从Eureka注册中心将服务的ip拿下来后，本地实现轮询调用或者其他的一系诶算法调用。
5、服务调用方式
服务提供的接口是http，此时服务之间的调用方式用的是http请求，当然我们可以用RestTemplate方式调用，但是这样的调用的话还是不是很方便，每次都RestTemplate(也使用了ribbon技术)注入进来，不过生成bean的时候需要加上@LoadBalanced注解，才能开启ribbon.
@Bean@LoadBalanced //就能让这个RestTemplate在请求时拥有客户端负载均衡的能力 轮询的方式,需要开启这个才可以使用serverid的方式调用public RestTemplate restTemplate() { return new RestTemplate();}使用的时候调用它提供的一些方法，话说这个也是SpringCloud提供的，但是SpringCloud还提供了一个更厉害的基于ribbon和hystrix的声明式服务调用组件Feign，这个的话基本上不用我们怎么写调用的代码，超级方便。
6、服务统一拦截过滤
比如我们很多服务都是需要验证用户身份，或者拦截特殊字符，如果我们每个服务里面自己代码里加上过滤器去实现，也可以，不过这样太多重复代码了，SpringCloud提供了网关组件Zuul，提供智能路由、访问过滤等功能，zull还可以实现负载均衡功能。
7、服务跟踪
当我们服务之间调用如果连续调用了四五个服务，然后调用失败，此时想要定位问题所在，有比较大的难度，但是SringCloud提供了分布式服务跟踪框架sleuth。Spring Cloud Sleuth 主要功能就是在分布式系统中提供追踪解决方案，并且兼容支持了 zipkin，你只需要在pom文件中引入相应的依赖即可。
8、接口管理
当我们服务多了，每个服务中有很多接口，此时我们需要统一的管理各个接口，SpringCloud提供了Swagger技术来很好的管理我们的接口。
9、消息总线
在微服务架构中，通常会使用轻量级的消息代理来构建一个共用的消息主题来连接各个微服务实例，它广播的消息会被所有在注册中心的微服务实例监听和消费，也称消息总线。SpringCloud中也有对应的解决方案，SpringCloud Bus 将分布式的节点用轻量的消息代理连接起来，可以很容易搭建消息总线，配合SpringCloud config 实现微服务应用配置信息的动态更新。消息代理属于中间件。设计代理的目的就是为了能够从应用程序中传入消息，并执行一些特别的操作。开源产品很多如ActiveMQ、Kafka、RabbitMQ、RocketMQ等目前springCloud仅支持RabbitMQ和Kafka。本文采用RabbitMQ实现这一功能。
10、小结
我们学习SpringCloud就是学会上面所提供的对各种微服务问题的解决方案，这些框架不一定都用的到，但是我们的需要了解，这样等什么时候遇到这种问题要很快的知道解决方案与技术，这是架构师必备的技能。下面总结一下学习Spring技术需要弄懂和了解的技术：Eureka、Hystrix、Config、Ribbon、Zuul、Sleuth、Swagger、Bus。
结语
这里是SpringCloud学习开启的第二篇，主要了解了接下来要学习的技术，以及学习这门技术的原因，解决微服务使用过程中遇到的各种问题。
