Spring Boot和Spring cloud

转载：https://blog.csdn.net/an341221/article/details/79068117

微服务框架SpringBoot简单验证

首先摘录部分IBM网站部份内容对框架作一个简单说明

http://www.ibm.com/developerworks/cn/java/j-lo-spring-boot/

Spring 框架对于不少 Java 开发人员来讲都不陌生。自从 2002 年发布以来，Spring 框架已经成为企业应用开发领域很是流行的基础框架。有大量的企业应用基于 Spring 框架来开发。Spring 框架包含几十个不一样的子项目，涵盖应用开发的不一样方面。

如此多的子项目和组件，一方面方便了开发人员的使用，另一个方面也带来了使用方面的问题。每一个子项目都有必定的学习曲线。开发人员须要了解这些子项目和组件的具体细节，才能知道如何把这些子项目整合起来造成一个完整的解决方案。在如何使用这些组件上，并无相关的最佳实践提供指导。

对于新接触 Spring 框架的开发人员来讲，并不知道如何更好的使用这些组件。Spring 框架的另一个常见问题是要快速建立一个能够运行的应用比较麻烦。Spring Boot 是 Spring 框架的一个新的子项目，用于建立 Spring 4.0 项目。它的开发始于 2013 年。2014 年 4 月发布 1.0.0 版本。它能够自动配置 Spring 的各类组件，并不依赖代码生成和 XML 配置文件。Spring Boot 也提供了对于常见场景的推荐组件配置。Spring Boot 能够大大提高使用 Spring 框架时的开发效率。本文将对 Spring Boot 进行详细的介绍。

SpringBoot框架简介

从 Spring Boot 项目名称中的 Boot 能够看出来，Spring Boot 的做用在于建立和启动新的基于 Spring 框架的项目。它的目的是帮助开发人员很容易的建立出独立运行和产品级别的基于 Spring 框架的应用。Spring Boot 会选择最适合的 Spring 子项目和第三方开源库进行整合。大部分 Spring Boot 应用只须要很是少的配置就能够快速运行起来。

Spring Boot 包含的特性

• 建立能够独立运行的 Spring 应用。
• 直接嵌入Tomcat 或 Jetty 服务器，不须要部署 WAR 文件。
• 支持一键启动，不须要预先部署应用服务器或Web容器，自己能够内嵌。
• 提供推荐的基础 POM 文件来简化 Apache Maven 配置。
• 尽量的根据项目依赖来自动配置 Spring 框架。
• 提供能够直接在生产环境中使用的功能，如性能指标、应用信息和应用健康检查。
• 没有代码生成，也没有 XML 配置文件。
• 可灵活的经过注解的方式将内部的API接口发布为http rest接口服务

而咱们看到一个框架要选择作为微服务模块开发用，其必需要具有的几个特色

1)足够轻：其中包括了编码，配置，部署，乃至后期的运维监控都足够轻量和独立。
2)接口开放容易：内部API方法应该可以很容易开放为Rest风格的API接口

从这两点来看Spring Boot彻底知足，并且支持的很好，虽然Spring Boot缺乏微服务网关的诸多能力（注册，安全，监控，日志审计，路由，流控）等，可是该框架仍然是一个微服务架构开发的可选入门框架。

经过 Spring Boot，建立新的 Spring 应用变得很是容易，并且建立出的 Spring 应用符合通用的最佳实践。只须要简单的几个步骤就能够建立出一个 Web 应用。下面在本机参考网上一篇文章进行简单验证

http://blog.csdn.net/lxhjh/article/details/51711148

整个验证过程至关简单，注意按文章要求创建好目录结构，同时手工新建三个文件放到指定目录，上述blog文章有详细描述，以下：

pom.xml
Application.java
Example.java

在经过Eclipse环境（实现已经安装了Maven插件）经过Import方式导入Maven项目。在导入的时候，因为须要远程下载Maven须要等待一段时间。下载完成后便可以进行编译和运行。

在select Java Aplication中选择“Application -com.example.myFirstProject”

运行起来后，打开浏览器输入打开浏览器，输入http://localhost:8080
可看到输出结果 helloworld 对应代码文件 home 方法

输入http://localhost:8080/hello/SpringBoot
可看到 hello SpringBoot输出，对应代码文件 index方法

能够看到整个过程至关简单，编码和配置，包括后续的部署启动都至关简单和容易。咱们没有写任何服务接口和发布的代码，而只是在Java方法上增长了注解，便可以将内部的方法很容易的发布为一个Http Rest服务，这就是SpringBoot框架很大的一个优点了。

任何开发的事情变简单了，就会致使服务发布的随意性和滥用，致使后续Rest接口暴增而没法管理，这也是在使用这些微服务框架时候必需要考虑的事情。简单来讲就是不能由于使用了简单易用的微服务框架而忽略了SOA治理的重要性。

另一个SpringBoot的在线课程可参考：http://www.roncoo.com/article/detail/124661

 

微服务框架-基础框架

上面一篇文章对SpringBoot框架作了一下简单验证，在文中也写到SpringBoot重点仍是在单个微服务模块的开发，已经对于微服务接口开放的便捷性上，而对于微服务基础架构和管控治理层面没有太多支持。

那什么叫微服务基础框架？

对于微服务基础框架能够看做是微服务治理架构的核心内容，包括了对微服务模块的全生命周期管理能力，这个能力包括了微服务网关APP，DevOps，Docker和云集成，安全，负载均衡，服务注册和发现等诸多能力。微服务基础框架确实不是简单的微服务网关，而是对整个微服务基础环境的支撑和管控。

对于微服务基础框架，建议参考InfoQ的一篇文章以下：

http://www.infoq.com/cn/articles/basis-frameworkto-implement-micro-service/

对于这篇文章的一些重点作以下一些说明：

1. 服务注册和发现

第一种方案为集中式LB方案，对刚开始实施微服务架构时候仍然建议采用该方案，特别是有负载均衡硬件设备如F5，Array等，在加上硬件自己的HA，不会在LB上出现任何性能问题和可靠性问题。

对于第二种进程内LB方案是趋势，当前微服务框架的主流方案，Netflix和Dubbo等均采用该方案，那这种时候服务注册库至关存粹，只是实时准确提供可用服务注册列表和地址信息便可，可是这种方案咱们可看到通常不会对调用的日志流进行审计和跟踪。

第三种方案其实是一种折中的方案，即在每一个微服务节点都须要部署相对比较重的独立进程外LB模块，这种方案最大的问题仍然是在于总体基础架构体系偏重同时后续维护工做量大。

2. 服务前端路由-微服务网关

此处核心能力即便微服务网关，不只仅是实现服务代理和前端路由，还须要实现安全，限流，监控等扩展能力。能够看到对整个微服务环境的治理管控，微服务网关会起到重要做用，具体摘录原文描述以下：

• 服务反向路由，网关要负责将外部请求反向路由到内部具体的微服务，这样虽然企业内部是复杂的分布式微服务结构，可是外部s系统从网关上看到的就像是一个统一的完整服务，网关屏蔽了后台服务的复杂性，同时也屏蔽了后台服务的升级和变化。
• 安全认证和防爬虫，全部外部请求必须通过网关，网关能够集中对访问进行安全控制，好比用户认证和受权，同时还能够分析访问模式实现防爬虫功能，网关是链接企业内外系统的安全之门。
• 限流和容错，在流量高峰期，网关能够限制流量，保护后台系统不被大流量冲垮，在内部系统出现故障时，网关能够集中作容错，保持外部良好的用户体验。
• 监控，网关能够集中监控访问量，调用延迟，错误计数和访问模式，为后端的性能优化或者扩容提供数据支持。日志，网关能够收集全部的访问日志，进入后台系统作进一步分析。
• 其它能力：实现线上引流，线上压测，线上调试(Surgical debugging)，金丝雀测试(Canary Testing)，数据中心双活(Active-Active HA)等高级功能。

要注意到在微服务架构里面的集群和负载功能其实有两层，第一层是在微服务网关上面的分布式集群部署，能够减轻单个API GateWay节点的并发访问压力；另一个是在微服务模块上层的负载均衡部署，重点是实如今同一个微服务模块集群部署后可以进行负载均衡。

在讲第一点服务注册和发现的时候能够看到，对于LB是能够下沉到服务消费端的，那么在LB下移后对于微服务网关层的能力是否也能够彻底下沉到微服务模块节点（无论是进程内部署仍是进程外部署），以实现彻底意义上的去中心化分布式架构？

我在下面这篇文章曾经谈到过去中心化的微服务网关构建思路，能够参考：

http://blog.sina.com.cn/s/blog_493a84550102wcmw.html

3. 服务容错

该部分主要仍是讲服务的限流和流量控制机制，而对于熔断只是在发现问题和异常后所采用的操做。对于服务容错功能自己功能的重要性就在于，在复杂的微服务架构环境下，服务关联和依赖至关多，当发生大量的服务异常调用的时候，极其容易引发雪崩效应，致使整个微服务环境彻底崩溃。

对于服务的容错，在考虑限流机制前，还能够考虑对服务进行分域，将不一样域的服务单独部署到不一样的JVM容器中，这样至少能够保证在A域的JVM彻底崩溃的时候，不会影响到B，C等其它服务部署域。这个有点相似文章最佳实践谈到的舱壁隔离模式(Bulkhead Isolation Pattern)。

要实现服务的容错管理i，首先要有实时的采集和统计服务运行数据，包括服务运行时间，次数等，这些是服务容错，限流或容错策略计算的基础。

对于服务容错须要分几个层面来谈：

首先来讲是服务限流，即当出现超出预设的大并发服务调用的时候，直接在网关处控制服务的流入速度，即让消费方调用在外面等待和排队，而后慢慢的放进来，固然若是调用再大则会引发服务调用超时。注意这是服务消费方调用超时，而不是原始服务提供方，这种超时网关是不清楚的。

其次即开始不限流，服务所有放进来，可是服务提供方可能处理不过来大并发，这种状况下会出现服务超时调用，服务响应时间超过预设值，那么在这种状况下就启动服务限流，控制流入速度。注意在服务限流后可能仍然没法解决服务超时或响应慢的问题。那么这个时候就必须进行服务熔断处理，即禁止对该服务全部访问。对于文中也谈到了熔断的弹性恢复机制，这也是一个至关关键的内容。

对于服务流量控制自己也有多个层级，能够针对全部服务，一个域的全部服务，单个服务均可以。即对服务调用总量或单个服务并发量都可以进行灵活的限流规则定义，以确保整个微服务架构基础环境的稳定性。

Netflix将上述容错模式和最佳实践集成到一个称为Hystrix的开源组件中，凡是须要容错的依赖点(服务，缓存，数据库访问等)，开发人员只须要将调用封装在Hystrix Command里头，则相关调用就自动置于Hystrix的弹性容错保护之下。Hystrix组件已经在Netflix通过多年运维验证，是Netflix微服务平台稳定性和弹性的基石，正逐渐被社区接受为标准容错组件。

4.Netflix的微服务框架

在原来谈SOA和ESB的时候，咱们通常会谈两个内容，即ESB服务总线和基于ESB总线的SOA管控和治理平台。而对应到微服务框架也同样的道理：

其一是：微服务网关(服务注册发现，代理路由，安全，限流，日志，监控）
其二是：基于微服务网关的完整微服务框架（客户端和服务端集成，DevOps，云集成）

注意在这里我仍是将服务注册发现，日志等能力统一划归到一个完整的微服务网关应该具有的能力，虽然在实现中可能会分为多个子系统或组件，可是自己是属于GateWay应该具有的能力。

Netflix是一家成功实践微服务架构的互联网公司，几年前，Netflix就把它的几乎整个微服务框架栈开源贡献给了社区，这些框架和组件包括：

• Eureka:　服务注册发现框架
• Zuul:　服务网关
• Karyon:　服务端框架
• Ribbon:　客户端框架
• Hystrix: 服务容错组件
• Archaius: 服务配置组件
• Servo: Metrics组件
• Blitz4j: 日志组件

下图Fig 11展现了基于这些组件构建的一个微服务框架体系，来自recipes-rss。



Netflix的开源框架组件已经在Netflix的大规模分布式微服务环境中通过多年的生产实战验证，正逐步被社区接受为构造微服务框架的标准组件。Pivotal去年推出的Spring Cloud开源产品，主要是基于对Netflix开源组件的进一步封装，方便Spring开发人员构建微服务基础框架。

对于一些打算构建微服务框架体系的公司来讲，充分利用或参考借鉴Netflix的开源微服务组件(或Spring Cloud)，在此基础上进行必要的企业定制，无疑是通向微服务架构的捷径。

另外推荐下做者的另一篇文章：每一个架构师都应该了解下康威定律
http://www.infoq.com/cn/articles/every-architect-should-study-conway-law

 

 

 

 

 

 

 

 

前面一篇文章谈到微服务基础框架，而Netflix的多个开源组件一块儿正好能够提供完整的分布式微服务基础架构环境，而对于Spring Cloud正是对Netflix的多个开源组件进一步的封装而成，同时又实现了和云端平台，和Spring Boot开发框架很好的集成。

Spring Cloud是一个相对比较新的微服务框架，今年(2016)才推出1.0的release版本. 虽然Spring Cloud时间最短, 可是相比Dubbo等RPC框架, Spring Cloud提供的全套的分布式系统解决方案。

Spring Cloud 为开发者提供了在分布式系统（配置管理，服务发现，熔断，路由，微代理，控制总线，一次性token，全居琐，leader选举，分布式session，集群状态）中快速构建的工具，使用SpringCloud的开发者能够快速的启动服务或构建应用、同时可以快速和云平台资源进行对接。

咱们先简单阐述下Spring Cloud中文社区对四个基础关键组件的描述：

社区地址：http://springcloud.cn/

Spring Cloud Config配置中心



Spring Cloud Config就是咱们一般意义上的配置中心。Spring Cloud Config-把应用本来放在本地文件的配置抽取出来放在中心服务器，本质是配置信息从本地迁移到云端。从而可以提供更好的管理、发布能力。

Spring Cloud Config分服务端和客户端，服务端负责将git（svn）中存储的配置文件发布成REST接口，客户端能够从服务端REST接口获取配置。但客户端并不能主动感知到配置的变化，从而主动去获取新的配置，这须要每一个客户端经过POST方法触发各自的/refresh。

Spring Cloud Netflix 服务发现


Spring Cloud Eureka提供在分布式环境下的服务发现，服务注册的功能。

Spring Cloud Netflix，该项目是Spring Cloud的子项目之一，主要内容是对Netflix公司一系列开源产品的包装，它为Spring Boot应用提供了自配置的Netflix OSS整合。

经过一些简单的注解，开发者就能够快速的在应用中配置一下经常使用模块并构建庞大的分布式系统。它主要提供的模块包括：服务发现（Eureka），断路器（Hystrix），智能路由（Zuul），客户端负载均衡（Ribbon）等。

Spring cloud Hystrix 熔断器



断路器(Cricuit Breaker)是一种可以在远程服务不可用时自动熔断(打开开关)，并在远程服务恢复时自动恢复(闭合开关)的设施。

断路器(Cricuit Breaker)是一种可以在远程服务不可用时自动熔断(打开开关)，并在远程服务恢复时自动恢复(闭合开关)的设施，Spring Cloud经过Netflix的Hystrix组件提供断路器、资源隔离与自我修复功能。

Spring Cloud Zuul 服务网关


Spring Cloud Eureka提供在分布式环境下的服务发现，服务注册的功能。

Spring Cloud Netflix，该项目是Spring Cloud的子项目之一，主要内容是对Netflix公司一系列开源产品的包装，它为Spring Boot应用提供了自配置的Netflix OSS整合。经过一些简单的注解，开发者就能够快速的在应用中配置一下经常使用模块并构建庞大的分布式系统。它主要提供的模块包括：服务发现（Eureka），断路器（Hystrix），智能路有（Zuul），客户端负载均衡（Ribbon）等。

固然Spring Cloud还有额外扩展的其它不少组件，包括了服务链路监控和跟踪（很关键的一个功能），消息总线，数据流处理，批量任务处理等。而对于整个Spring Cloud微服务框架简单来讲，便是：

你只要划分到你的微服务组件和模块，并定义好须要暴露的API接口，那么剩下的整个开发和传统方式没有太大的区别，你开发完成的组件集成起来就是一个分布式可扩展的微服务环境。里面设计到的接口发布，服务注册，服务调用和路由，服务监控，健康检测和流控等都会由微服务框架来帮你完成。

正是有了成熟的微服务框架，咱们才更应该将微服务架构设计重心从技术底层转移到组件划分和接口设计上。

SpringCloud和Dubbo的区别问题

对于二者的区别在以下文章有详细描述能够参考：

http://blog.didispace.com/microservice-framework/

能够看到SpringCLoud可以提供的基础能力要多于Dubbo，Dubbo能够看做是SpringCLoud简单实现。

Dubbo是RPC服务治理框架，和Spring Cloud同样具有服务注册、发现、路由、负载均衡等能力。可是没有配置中心，完整的好用全链路监控，须要采用开源的解决方案定制或者自研。Spring cloud的配置中心，全链路监控等组件。从目前来看，Spring Cloud国内中小型企业用的比较多，大型企业可能须要对其须要的组件进行定制化处理。

可是也须要看到Spring Cloud基于注解的服务发现，服务治理等功能具备代码侵入性，dubbo没有代码侵入性，业务开发人员不须要经过注解的方式去关注框架级别的处理。从中间件或者作基础架构的角度来看，其实服务治理等功能对普通的业务程序员应该是透明的，业务程序员不须要关注服务治理框架的使用，专一于业务代码便可。

基于SpringCLoud微服务框架的实践

对于基于SpringCLoud框架的具体实践，建议参考翟永超博客的系列文章，具体以下：

• 服务注册和发现：http://blog.didispace.com/springcloud1/
• 服务消费：http://blog.didispace.com/springcloud2/
• 服务熔断机制：http://blog.didispace.com/springcloud3/
• 服务配置中心：http://blog.didispace.com/springcloud4/
• 服务网关：http://blog.didispace.com/springcloud5/
• 高可用服务注册中心：http://blog.didispace.com/springcloud6/
• 消息总线：http://blog.didispace.com/springcloud7/

服务注册和发现

注意这里仍然使用的是SpringBoot框架，并和SpringBoot框架进行了集成，在pom.xml配置文件中增长了对SpringCLoud相关包和组件的依赖。在原有的接口API定义的基础上，咱们增长@EnableDiscoveryClient注解后，便可以让服务注册中心很轻松的发现服务提供方以及提供的服务。

服务消费

方式1 - Ribbon是一个基于HTTP和TCP客户端的负载均衡器。Ribbon能够在经过客户端中配置的ribbonServerList服务端列表去轮询访问以达到均衡负载的做用。当Ribbon与Eureka联合使用时，ribbonServerList会被DiscoveryEnabledNIWSServerList重写，扩展成从Eureka注册中心中获取服务端列表。

方式2 - Feign是一个声明式的Web Service客户端，它使得编写Web Serivce客户端变得更加简单。咱们只须要使用Feign来建立一个接口并用注解来配置它既可完成。它具有可插拔的注解支持，包括Feign注解和JAX-RS注解。Feign也支持可插拔的编码器和解码器。Spring Cloud为Feign增长了对Spring MVC注解的支持，还整合了Ribbon和Eureka来提供均衡负载的HTTP客户端实现。

断路器

首先在pom.xml文件中增长引入对hystrix依赖，同时在消费端Application主类上增长@EnableCircuitBreaker注解开启断路器功能。注意原有的服务消费方式也涉及到修改，增长了服务Callback的回调函数。

服务网关

服务网关是微服务架构中一个不可或缺的部分。经过服务网关统一贯外系统提供REST API的过程当中，除了具有服务路由、均衡负载功能以外，它还具有了权限控制等功能。Spring Cloud Netflix中的Zuul就担任了这样的一个角色，为微服务架构提供了前门保护的做用，同时将权限控制这些较重的非业务逻辑内容迁移到服务路由层面，使得服务集群主体可以具有更高的可复用性和可测试性。