转载：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中文社区对四个基础关键组件的描述：
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就担任了这样的一个角色，为微服务架构提供了前门保护的作用，同时将权限控制这些较重的非业务逻辑内容迁移到服务路由层面，使得服务集群主体能够具备更高的可复用性和可测试性。
