漫谈微服务架构：什么是Spring Cloud，为什么要选择Spring Cloud
Spring Cloud是基于Spring Boot的，所以还在使用SpringMVC的同窗要先了解Spring Boot。先上一段官话，Spring Cloud是一个基于Spring Boot实现的云应用开发工具，它为基于JVM的云应用开发中涉及的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操做提供了一种简单的开发框架。前端
Spring Cloud并无重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，经过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。数据库
Spring Cloud全家桶
上面的图是Spring Cloud的全家桶，一应俱全，犹如水电，涉及到开发的方方页面。后端
Spring Cloud从设计之初就考虑了绝大多数互联网公司架构演化所需的功能，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。缓存
首先是核心服务治理的组件（服务注册与发现）Spring Cloud Eureka
Eureka是Netflix开源的一款提供服务注册和发现的产品，Eureka就是一个服务中心，将全部的能够提供的服务都注册到它这里来管理，其它各调用者须要的时候去注册中心获取，而后再进行调用，避免了服务之间的直接调用，方便后续的水平扩展、故障转移等。以下图：安全
固然服务中心这么重要的组件一但挂掉将会影响所有服务，所以须要搭建Eureka集群来保持高可用性，生产中建议最少两台。随着系统的流量不断增长，须要根据状况来扩展某个服务，Eureka内部已经提供均衡负载的功能，只须要增长相应的服务端实例既可。那么在系统的运行期间某个实例挂了怎么办？Eureka内容有一个心跳检测机制，若是某个实例在规定的时间内没有进行通信则会自动被剔除掉，避免了某个实例挂掉而影响服务。性能优化
所以使用了Eureka就自动具备了注册中心、负载均衡、故障转移的功能。架构
固然还有另一个实现组件Spring Cloud Consul，这里不作多介绍。并发
随着微服务不断的增多，每一个微服务都有本身对应的配置文件。在研发过程当中有测试环境、UAT环境、生产环境，所以每一个微服务又对应至少三个不一样环境的配置文件。这么多的配置文件，若是须要修改某个公共服务的配置信息，如：缓存、数据库等，不免会产生混乱，这个时候就须要引入Spring Cloud另一个组件：Spring Cloud Config。负载均衡
Spring Cloud Config
Spring Cloud Config是一个解决分布式系统的配置管理方案。它包含了Client和Server两个部分，其实就是Server端将全部的配置文件服务化，须要配置文件的服务实例去Config Server获取对应的数据。将全部的配置文件统一整理，避免了配置文件碎片化。框架
若是服务运行期间改变配置文件，服务是不会获得最新的配置信息，须要解决这个问题就须要引入Refresh。能够在服务的运行期间从新加载配置文件，当全部的配置文件都存储在配置中心的时候，配置中心就成为了一个很是重要的组件。若是配置中心出现问题将会致使灾难性的后果，所以在生产中建议对配置中心作集群，来支持配置中心高可用性。
Hystrix
在微服务架构中一般会有多个服务层调用，基础服务的故障可能会致使级联故障，进而形成整个系统不可用的状况，这种现象被称为服务雪崩效应。
以下图所示：A做为服务提供者，B为A的服务消费者，C和D是B的服务消费者。A不可用引发了B的不可用，并将不可用像滚雪球同样放大到C和D时，雪崩效应就造成了。
在这种状况下就须要整个服务机构具备故障隔离的功能，避免某一个服务挂掉影响全局。在Spring Cloud 中Hystrix组件就扮演这个角色。
Hystrix会在某个服务连续调用N次不响应的状况下，当即通知调用端调用失败，避免调用端持续等待而影响了总体服务。Hystrix间隔时间会再次检查此服务，若是服务恢复将继续提供服务。
Hystrix Dashboard和Turbine
当熔断发生的时候须要迅速的响应来解决问题，避免故障进一步扩散，那么对熔断的监控就变得很是重要。熔断的监控如今有两款工具：Hystrix-dashboard和Turbine。
Hystrix-dashboard是一款针对Hystrix进行实时监控的工具，经过Hystrix Dashboard咱们能够直观地看到各Hystrix Command的请求响应时间, 请求成功率等数据。可是只使用Hystrix Dashboard的话, 你只能看到单个应用内的服务信息, 这明显不够. 咱们须要一个工具能让咱们汇总系统内多个服务的数据并显示到Hystrix Dashboard上, 这个工具就是Turbine. 监控的效果图以下：
Spring Cloud Bus消息总线
Refresh方案虽然能够解决单个微服务运行期间重载配置信息的问题，可是在真正的实践生产中，可能会有N多的服务须要更新配置，若是每次依靠手动Refresh将是一个巨大的工做量，这时候Spring Cloud提出了另一个解决方案：Spring Cloud Bus
Spring Cloud Bus经过轻量消息代理链接各个分布的节点。这会用在广播状态的变化（例如配置变化）或者其它的消息指令中。Spring Cloud Bus的一个核心思想是经过分布式的启动器对Spring Boot应用进行扩展，也能够用来创建一个或多个应用之间的通讯频道。目前惟一实现的方式是用AMQP消息代理做为通道。
Spring Cloud Bus是轻量级的通信组件，也能够用在其它相似的场景中。有了Spring Cloud Bus以后，当咱们改变配置文件提交到版本库中时，会自动的触发对应实例的Refresh，具体的工做流程以下：
服务网关
在微服务架构模式下，后端服务的实例数通常是动态的，对于客户端而言很难发现动态改变的服务实例的访问地址信息。所以在基于微服务的项目中为了简化前端的调用逻辑，一般会引入API Gateway做为轻量级网关，同时API Gateway中也会实现相关的认证逻辑从而简化内部服务之间相互调用的复杂度。
Spring Cloud体系中支持API Gateway落地的技术就是Zuul。Spring Cloud Zuul路由是微服务架构中不可或缺的一部分，提供动态路由，监控，弹性，安全等的边缘服务。Zuul是Netflix出品的一个基于JVM路由和服务端的负载均衡器。它的具体做用就是服务转发，接收并转发全部内外部的客户端调用。使用Zuul能够做为资源的统一访问入口，同时也能够在网关作一些权限校验等相似的功能。
链路跟踪
随着服务的愈来愈多，对调用链的分析会愈来愈复杂，如服务之间的调用关系、某个请求对应的调用链、调用之间消费的时间等，对这些信息进行监控就成为一个问题。在实际的使用中咱们须要监控服务和服务之间通信的各项指标，这些数据将是咱们改进系统架构的主要依据。所以分布式的链路跟踪就变的很是重要，Spring Cloud也给出了具体的解决方案：Spring Cloud Sleuth和Zipkin
Spring Cloud Sleuth为服务之间调用提供链路追踪。经过Sleuth能够很清楚的了解到一个服务请求通过了哪些服务，每一个服务处理花费了多长时间。从而让咱们能够很方便的理清各微服务间的调用关系。分布式链路跟踪须要Sleuth+Zipkin结合来实现，固然实现链路追踪的还有三方开源方案，若是zipkin实现的功能很是简单，图形化能力也不强，因此能够试试其它的方案，如pinpoint较成熟的框架等。说到这里顺便给你们推荐一个架构学习交流圈。交流学习企鹅圈号：519-752-913 里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多
Feign
声明式远程调度组件。
Ribbon
负载均衡组件
Spring Cloud Data Flow
大数据操做组件，它是Spring XD的替代品，也是一个混合计算模型，能够经过命令行的方式操做数据流
Spring Cloud Task
组件基于Spring Tsak，提供任务调度和任务管理的功能
以上只介绍常常用到很是重要的内容，通常的技术栈为 SpringCloud +GitLab+Jinkins进行普通服务的开发持续集成部署CI，后面可升级用SpingCloud +GitLab+Jinkins+Docker容器化布署，进一步升级到用 SpingCloud +GitLab+Jinkins+Docker+k8s自动化容器编排内容，这里的难度等级就彻底不同了，并且每个组件都涉及到不少内容，传统业务如何进行微服务的拆分下次再进行讨论。