Spring Cloud微服务实战(txt+pdf+epub+mobi电子书下载)

作者：翟永超

出版社：电子工业出版社

格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT

Spring Cloud微服务实战试读：

前言

从接触Spring Cloud开始，我除了被其庞大的项目结构震撼之外，还被其所要完成的远大目标所吸引。该项目不同于其他Spring的优秀项目，它不再是一个基础框架类，而是一个更高层次的、架构视角的综合性大型项目，其目标旨在构建一套标准化的微服务解决方案，让架构师、开发者在使用微服务理念构建应用系统的时候，面对各个环节的问题都可以找到相应的组件来处理。引用网友戏称的一个比喻：Spring Cloud可以说是Spring社区为微服务架构提供的一个“全家桶”套餐。由于“套餐”中的组件通过一个社区进行包装与整合，使得“套餐”中各个组件之间的配合变得更加和谐，这可以有效减少我们在组件的选型和整合上花费的精力，所以它可以帮助我们快速构建起基础的微服务架构系统。

虽然，Spring Cloud提供了很多我们期待的内容，但是因其涵盖的内容非常广泛，并且知识跨度较大，因此对于很多初学者来说就像被专业名词轰炸了一样，入门的难度也就大大提高了。同时，中文文档与资料的匮乏，以及官方文档的内容对于使用描述并不够细致等问题，也直接提升了使用者的学习门槛。这些看似都不是什么大问题，但是却在一定程度上阻碍了Spring Cloud在国内的推广与发展，毕竟任何一项优秀技术都需要有大批的实践者才能得到不断优化、完善和发扬光大。作为一名Spring社区的忠实粉丝和长期实践者，自然希望可以有更多的开发者可以参与到Spring Cloud的使用和贡献中来，笔者也就萌生了想要编写一些入门文章的念头，一方面对自身知识的掌握做一些整理，另一方面也希望这些内容可以成为后来者的学习资料。于是就开始坚持着写了一些基础的入门文章和示例，没有想到会受到不少Spring爱好者的持续关注，在创建了相关的QQ交流群之后，短短一个月的时间，交流群的人数就突破了1000人。由于在交流过程中发现很多问题重复出现，而这些问题并没有得到很好的整理，也没有办法被搜索引擎收录，于是就创建了 Spring Cloud 中文社区论坛，以帮助收集交流过程中提出和解决的各种问题，方便将来学习者可以搜索到这些前人踩过的坑。

之后，有幸在电子工业出版社计算机出版分社的张春雨先生的邀请下，开始编写这本关于Spring Cloud的入门书籍。在这本书的编写期间，由于工作、家庭等因素，使得与大家交流的时间变得越来越少，但好在有诸多网友和热心爱好者帮忙一起维护着交流群与论坛，为大家提供了很多宝贵的学习资源，我也从中得到了不少启发和收获。同时，感谢后来建议并牵头整合目前国内Spring Cloud学习资源的许进，他在此期间承担了很多沟通和网站维护工作，为Spring Cloud中国社区付出了不少精力，后续我也会重新加入进来，继续编写在线免费入门教程，以帮助更多的爱好者快速入门Spring Cloud。我们也欢迎更多的爱好者参与进来，一起为社区贡献力量，以帮助Spring Cloud在国内被更好地应用与成长。

轻松注册成为博文视点社区用户（www.broadview.com.cn），即可享受以下服务：

下载资源：本书所提供的示例代码及资源文件均可在“下载资源”处下载。

提交勘误：您对书中内容的修改意见可在“提交勘误”处提交，若被采纳，将获赠博文视点社区积分（在您购买电子书时，积分可用来抵扣相应金额）。

与作者交流：在页面下方“读者评论”处留下您的疑问或观点，与作者和其他读者一同学习交流。

页面入口：http://www.broadview.com.cn/31301

二维码：第1章基础知识在进行Spring Cloud的具体内容介绍之前，我们先通过本章学习一些关于微服务架构以及Spring Cloud的基础知识。对Spring Cloud能够解决的具体问题有一个大致的了解，以帮助我们更好地理解后续章节对各个组件的介绍。什么是微服务架构“微服务”一词源于Martin Fowler的名为Microservices的博文，可以在他的官方博客上找到：http://martinfowler.com/articles/microservices.html。

简单地说，微服务是系统架构上的一种设计风格，它的主旨是将一个原本独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于HTTP的RESTful API进行通信协作。被拆分成的每一个小型服务都围绕着系统中的某一项或一些耦合度较高的业务功能进行构建，并且每个服务都维护着自身的数据存储、业务开发、自动化测试案例以及独立部署机制。由于有了轻量级的通信协作基础，所以这些微服务可以使用不同的语言来编写。与单体系统的区别

在以往传统的企业系统架构中，我们针对一个复杂的业务需求通常使用对象或业务类型来构建一个单体项目。在项目中我们通常将需求分为三个主要部分：数据库、服务端处理、前端展现。在业务发展初期，由于所有的业务逻辑在一个应用中，开发、测试、部署都还比较容易且方便。但是，随着企业的发展，系统为了应对不同的业务需求会不断为该单体项目增加不同的业务模块；同时随着移动端设备的进步，前端展现模块已经不仅仅局限于Web的形式，这对于系统后端向前端的支持需要更多的接口模块。单体应用由于面对的业务需求更为宽泛，不断扩大的需求会使得单体应用变得越来越臃肿。单体应用的问题就逐渐凸显出来，由于单体系统部署在一个进程内，往往我们修改了一个很小的功能，为了部署上线会影响其他功能的运行。并且，单体应用中的这些功能模块的使用场景、并发量、消耗的资源类型都各有不同，对于资源的利用又互相影响，这样使得我们对各个业务模块的系统容量很难给出较为准确的评估。所以，单体系统在初期虽然可以非常方便地进行开发和使用，但是随着系统的发展，维护成本会变得越来越大，且难以控制。

为了解决单体系统变得庞大臃肿之后产生的难以维护的问题，微服务架构诞生了并被大家所关注。我们将系统中的不同功能模块拆分成多个不同的服务，这些服务都能够独立部署和扩展。由于每个服务都运行在自己的进程内，在部署上有稳固的边界，这样每个服务的更新都不会影响其他服务的运行。同时，由于是独立部署的，我们可以更准确地为每个服务评估性能容量，通过配合服务间的协作流程也可以更容易地发现系统的瓶颈位置，以及给出较为准确的系统级性能容量评估。如何实施微服务

在实施微服务之前，我们必须要知道，微服务虽然有非常多吸引人的优点，但是也因为服务的拆分引发了诸多原本在单体应用中没有的问题。

●运维的新挑战：在微服务架构中，运维人员需要维护的进程数量会大大增加。有条不紊地将这些进程编排和组织起来不是一件容易的事，传统的运维人员往往很难适应这样的改变。我们需要运维人员有更多的技能来应对这样的挑战，运维过程需要更多的自动化，这就要求运维人员具备一定的开发能力来编排运维过程并让它们能自动运行起来。

●接口的一致性：虽然我们拆分了服务，但是业务逻辑上的依赖并不会消除，只是从单体应用中的代码依赖变为了服务间的通信依赖。而当我们对原有接口进行了一些修改，那么交互方也需要协调这样的改变来进行发布，以保证接口的正确调用。我们需要更完善的接口和版本管理，或是严格地遵循开闭原则。

●分布式的复杂性：由于拆分后的各个微服务都是独立部署并运行在各自的进程内，它们只能通过通信来进行协作，所以分布式环境的问题都将是微服务架构系统设计时需要考虑的重要因素，比如网络延迟、分布式事务、异步消息等。

尽管微服务架构有很多缺点和问题，但是其实现的敏捷开发和自动化部署等优点依然被广大优秀架构师和开发者所青睐，所以解决这些问题就是这几年诸多架构大师努力的目标。

在架构师对于一个大型系统架构的设计与实施的过程中，面对环境、资源、团队等各种因素的影响，几乎不会出现完全相同的架构设计。对于微服务架构而言更是如此，由于并没有一个标准或正式的定义，每位架构师都根据自身理解与实际情况来进行设计，并在发展的过程中不断演化与完善。经过多年的发展，Martin Fowler在Microservices一文中，提炼出了微服务架构的九大特性，用于指导大家设计架构。

服务组件化

组件，是一个可以独立更换和升级的单元。就像PC中的CPU、内存、显卡、硬盘一样，独立且可以更换升级而不影响其他单元。

在微服务架构中，需要我们对服务进行组件化分解。服务，是一种进程外的组件，它通过HTTP等通信协议进行协作，而不是像传统组件那样以嵌入的方式协同工作。每一个服务都独立开发、部署，可以有效避免一个服务的修改引起整个系统的重新部署。

打一个不恰当的比喻，如果我们的 PC 组件以服务的方式构建，那么只维护主板和一些必要外设之后，计算能力通过一组外部服务实现，我们只需要告诉 PC 从哪个地址来获得计算能力，通过服务定义的计算接口来实现我们使用过程中的计算需求，从而实现CPU组件的服务化。这样原本复杂的 PC 服务得到了轻量化的实现，我们甚至只需要更换服务地址就能升级PC的计算能力。

按业务组织团队

当决定如何划分微服务时，通常也意味着我们要开始对团队进行重新规划与组织。按以往的方式，我们往往会从技术的层面将团队划分为多个，比如DBA团队、运维团队、后端团队、前端团队、设计师团队等。若我们继续按这种方式组织团队来实施微服务架构开发，当有一个服务出现问题需要更改时，可能是一个非常简单的变动，比如对人物描述增加一个字段，这需要从数据存储开始考虑一直到设计和前端，虽然大家的修改都非常小，但这会引起跨团队的时间耗费和预算审批。

在实施微服务架构时，需要采用不同的团队分割方法。由于每一个微服务都是针对特定业务的宽栈或是全栈实现，既要负责数据的持久化存储，又要负责用户的接口定义等各种跨专业领域的职能。因此，面对大型项目的时候，对于微服务团队的拆分更加建议按业务线的方式进行拆分，一方面可以有效减少服务内部修改所产生的内耗；另一方面，团队边界可以变得更为清晰。

做“产品”的态度

在实施微服务架构的团队中，每个小团队都应该以做产品的方式，对其产品的整个生命周期负责。而不是以项目的模式，以完成开发与交付并将成果交接给维护者为最终目标。

开发团队通过了解服务在具体生产环境中的情况，可以增加他们对具体业务的理解，比如，很多时候，一些业务中发生的特殊或异常情况，很可能产品经理都并不知晓，但细心的开发者很容易通过生产环境发现这些特殊的潜在问题或需求。

所以，我们需要用做“产品”的态度来对待每一个微服务，持续关注服务的运作情况，并不断分析以帮助用户来改善业务功能。

智能端点与哑管道

在单体应用中，组件间直接通过函数调用的方式进行交互协作。而在微服务架构中，由于服务不在一个进程中，组件间的通信模式发生了改变，若仅仅将原本在进程内的方法调用改成RPC方式的调用，会导致微服务之间产生烦琐的通信，使得系统表现更为糟糕，所以，我们需要更粗粒度的通信协议。

在微服务架构中，通常会使用以下两种服务调用方式：

●第一种，使用HTTP的RESTful API或轻量级的消息发送协议，实现信息传递与服务调用的触发。

●第二种，通过在轻量级消息总线上传递消息，类似 RabbitMQ 等一些提供可靠异步交换的中间件。

在极度强调性能的情况下，有些团队会使用二进制的消息发送协议，例如protobuf。即使是这样，这些系统仍然会呈现出“智能端点和哑管道”的特点，这是为了在易读性与高效性之间取得平衡。当然大多数Web应用或企业系统并不需要在这两者间做出选择，能够获得易读性已经是一个极大的胜利了。——Martin Fowler

去中心化治理

当我们采用集中化的架构治理方案时，通常在技术平台上都会制定统一的标准，但是每一种技术平台都有其短板，这会导致在碰到短板时，不得不花费大力气去解决，并且可能因为其底层原因解决得不是很好，最终成为系统的瓶颈。

在实施微服务架构时，通过采用轻量级的契约定义接口，使得我们对于服务本身的具体技术平台不再那么敏感，这样整个微服务架构系统中的各个组件就能针对其不同的业务特点选择不同的技术平台，终于不会出现杀鸡用牛刀或是杀牛用指甲钳的尴尬处境了。

不是每一个问题都是钉子，不是每一个解决方案都是锤子。

去中心化管理数据

我们在实施微服务架构时，都希望让每一个服务来管理其自有的数据库，这就是数据管理的去中心化。

在去中心化过程中，我们除了将原数据库中的存储内容拆分到新的同平台的其他数据库实例中之外（如把原本存储在MySQL中的表拆分后，存储到多个不同的MySQL实例中），也可以将一些具有特殊结构或业务特性的数据存储到一些其他技术的数据库实例中（如把日志信息存储到MongoDB中或把用户登录信息存储到Redis中）。

虽然数据管理的去中心化可以让数据管理更加细致化，通过采用更合适的技术可让数据存储和性能达到最优。但是，由于数据存储于不同的数据库实例中后，数据一致性也成为微服务架构中亟待解决的问题之一。分布式事务本身的实现难度就非常大，所以在微服务架构中，我们更强调在各服务之间进行“无事务”的调用，而对于数据一致性，只要求数据在最后的处理状态是一致的即可；若在过程中发现错误，通过补偿机制来进行处理，使得错误数据能够达到最终的一致性。

基础设施自动化

近年来云计算服务与容器化技术的不断成熟，运维基础设施的工作变得越来越容易。但是，当我们实施微服务架构时，数据库、应用程序的个头虽然都变小了，但是因为拆分的原因，数量成倍增长。这使得运维人员需要关注的内容也成倍增长，并且操作性任务也会成倍增长，这些问题若没有得到妥善解决，必将成为运维人员的噩梦。

所以，在微服务架构中，务必从一开始就构建起“持续交付”平台来支撑整个实施过程，该平台需要两大内容，缺一不可。

●自动化测试：每次部署前的强心剂，尽可能地获得对正在运行的软件的信心。

●自动化部署：解放烦琐枯燥的重复操作以及对多环境的配置管理。

容错设计

在单体应用中，一般不存在单个组件故障而其他部件还在运行的情况，通常是一挂全挂。而在微服务架构中，由于服务都运行在独立的进程中，所以存在部分服务出现故障，而其他服务正常运行的情况。比如，当正常运作的服务B调用到故障服务A时，因故障服务A没有返回，线程挂起开始等待，直到超时才能释放，而此时若触发服务B调用服务A的请求来自服务C，而服务C频繁调用服务B时，由于其依赖服务A，大量线程被挂起等待，最后导致服务A也不能正常服务，这时就会出现故障的蔓延。

所以，在微服务架构中，快速检测出故障源并尽可能地自动恢复服务是必须被设计和考虑的。通常，我们都希望在每个服务中实现监控和日志记录的组件，比如服务状态、断路器状态、吞吐量、网络延迟等关键数据的仪表盘等。

演进式设计

通过上面的几点特征，我们已经能够体会到，要实施一个完美的微服务架构，需要考虑的设计与成本并不小，对于没有足够经验的团队来说，甚至要比单体应用付出更多的代价。

所以，在很多情况下，架构师都会以演进的方式进行系统的构建。在初期，以单体系统的方式来设计和实施，一方面系统体量初期并不会很大，构建和维护成本都不高。另一方面，初期的核心业务在后期通常也不会发生巨大的改变。随着系统的发展或者业务的需要，架构师会将一些经常变动或是有一定时间效应的内容进行微服务处理，并逐渐将原来在单体系统中多变的模块逐步拆分出来，而稳定不太变化的模块就形成一个核心微服务存在于整个架构之中。为什么选择Spring Cloud

近几年很多人对于微服务架构的热情非常高，但是回头看“微服务”被提及也有很多年了。无数的架构师和开发者在实际项目中实践该设计理念并为此付出了诸多努力，同时也分享了他们在微服务架构中针对不同应用场景出现的各种问题的各种解决方案和开源框架，其中也不乏国内互联网企业的杰出贡献。

●服务治理：阿里巴巴开源的Dubbo和当当网在其基础上扩展的DubboX、Netflix的Eureka、Apache的Consul等。

●分布式配置管理：百度的Disconf、Netflix的Archaius、360的QConf、Spring Cloud的Config、淘宝的Diamond等。

●批量任务：当当网的Elastic-Job、LinkedIn的Azkaban、Spring Cloud的Task等。

●服务跟踪：京东的Hydra、Spring Cloud的Sleuth、Twitter的Zipkin等。

●……

上面列举了一些在实施微服务架构初期，就需要被我们考虑进去的问题，以及针对这些问题的开源解决方案。可以看到国内、国外的技术公司都在贡献着他们的智慧。我们搜索微服务架构的实施方案时会发现，几乎大部分的分享主要以理论或是一个粗轮廓框架为主，整合了来自不同公司或组织的诸多开源框架，并加入针对自身业务的一些优化，所以找不到一个完全相同的架构方案。

前面我们介绍了一些关于微服务的理念以及特性，分析了实施微服务的优点和缺点，而这些缺点通常就是这些框架出现的源头，大家都是为了解决或弥补业务拆分后所引出的诸多问题来设计出这些解决方案。而当我们作为一个新手，准备实施微服务架构时，为了避免踩前辈们踩过的坑，我们不得不在这些核心问题上做出选择，而选择又是如此之多，这必然会导致在做技术选型的初期，需要花费巨大的调研、分析与实验精力。

Spring Cloud的出现，可以说是对微服务架构的巨大支持和强有力的技术后盾。它不像我们之前所列举的框架那样，只是解决微服务中的某一个问题，而是一个解决微服务架构实施的综合性解决框架，它整合了诸多被广泛实践和证明过的框架作为实施的基础部件，又在该体系基础上创建了一些非常优秀的边缘组件。

打个不太恰当的比喻：我们自己对各个问题选择框架来实施微服务架构就像在DIY电脑一样，我们对各环节的选择自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了，总是让人不怎么放心。当然，如果你是一名高手，这些自然都不是问题，然而千军易得、良将难求。而使用Spring Cloud来实施就像直接购买品牌机一样，在Spring社区的整合之下，做了大量的兼容性测试，保证了其拥有更好的稳定性，如果要在 Spring Cloud架构下使用非原装组件时，就需要对其基础有足够的了解。

Spring Cloud也许对很多已经实施微服务并自成体系的团队不具备足够的吸引力，但是对于还未实施微服务或是未成体系的团队，这必将是一个非常有吸引力的框架选择。不论其项目的发展目标，还是Spring的强大背景，亦或其极高的社区活跃度，都是未来企业架构师必须了解和接触的重要框架，有一天成为微服务架构的标准解决方案也并非不可能。Spring Cloud简介

Spring Cloud是一个基于Spring Boot实现的微服务架构开发工具。它为微服务架构中涉及的配置管理、服务治理、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。

Spring Cloud包含了多个子项目（针对分布式系统中涉及的多个不同开源产品，还可能会新增），如下所述。

●Spring Cloud Config：配置管理工具，支持使用Git存储配置内容，可以使用它实现应用配置的外部化存储，并支持客户端配置信息刷新、加密/解密配置内容等。

●Spring Cloud Netflix：核心组件，对多个Netflix OSS开源套件进行整合。

■Eureka：服务治理组件，包含服务注册中心、服务注册与发现机制的实现。

■Hystrix：容错管理组件，实现断路器模式，帮助服务依赖中出现的延迟和为故障提供强大的容错能力。

■Ribbon：客户端负载均衡的服务调用组件。

■Feign：基于Ribbon和Hystrix的声明式服务调用组件。

■Zuul：网关组件，提供智能路由、访问过滤等功能。

■Archaius：外部化配置组件。

●Spring Cloud Bus：事件、消息总线，用于传播集群中的状态变化或事件，以触发后续的处理，比如用来动态刷新配置等。

●Spring Cloud Cluster：针对ZooKeeper、Redis、Hazelcast、Consul的选举算法和通用状态模式的实现。

●Spring Cloud Cloudfoundry：与Pivotal Cloudfoundry的整合支持。

●Spring Cloud Consul：服务发现与配置管理工具。

●Spring Cloud Stream：通过Redis、Rabbit或者Kafka实现的消费微服务，可以通过简单的声明式模型来发送和接收消息。

●Spring Cloud AWS：用于简化整合Amazon Web Service的组件。

●Spring Cloud Security：安全工具包，提供在Zuul代理中对OAuth2客户端请求的中继器。

●Spring Cloud Sleuth:Spring Cloud应用的分布式跟踪实现，可以完美整合Zipkin。

●Spring Cloud ZooKeeper：基于ZooKeeper的服务发现与配置管理组件。

●Spring Cloud Starters:Spring Cloud的基础组件，它是基于Spring Boot风格项目的基础依赖模块。

●Spring Cloud CLI：用于在Groovy中快速创建Spring Cloud应用的Spring Boot CLI插件。

●……

本书将对其中一些较为常用的组件进行介绍、分析，并演示其使用方法。版本说明

当我们通过搜索引擎查找一些Spring Cloud的文章或示例时，往往可以在依赖中看到很多不同的版本名字，比如Angel.SR6、Brixton.SR5等，为什么Spring Cloud没有像其他Spring的项目使用类似1.x.x的版本命名规则呢？这些版本之间又有什么区别呢？在学习之初，非常有必要弄清楚这些版本的意义和内容，这样才能在我们使用Spring Cloud时，指导我们选择更为合适的版本进行架构与开发。

版本名与版本号

由于Spring Cloud不像Spring社区其他一些项目那样相对独立，它是一个拥有诸多子项目的大型综合项目，可以说是对微服务架构解决方案的综合套件组合，其包含的各个子项目也都独立进行着内容更新与迭代，各自都维护着自己的发布版本号。因此每一个Spring Cloud 的版本都会包含多个不同版本的子项目，为了管理每个版本的子项目清单，避免Spring Cloud的版本号与其子项目的版本号相混淆，没有采用版本号的方式，而是通过命名的方式。

这些版本的名字采用了伦敦地铁站的名字，根据字母表的顺序来对应版本时间顺序，比如最早的Release版本为Angel，第二个Release版本为Brixton……

经过上面的解释，不难猜出，之前所提到的 Angel.SR6、Brixton.SR5中的 SR6、SR5就是版本号了。

当一个版本的Spring Cloud项目的发布内容积累到临界点或者一个严重bug解决可用后，就会发布一个“service releases”版本，简称SRX版本，其中X是一个递增的数字，所以Brixton.SR5就是Brixton的第5个Release版本。

版本区别

下面列出的是开始编写此书时各版本的版本构成表，我们可以快速查阅当前各版本所包含的子项目，以及各子项目的版本号，以此来决定需要选择哪个版本。

Component　　　　　 Angel.SR6　　 Brixton.SR5　　Camden.M1　　Camden.BUILD-SNAPSHOT

spring-cloud-aws　　　　1.0.4.RELEASE　1.1.1.RELEASE　1.1.1.RELEASE　1.1.2.BUILD-SNAPSHOT

spring-cloud-bus　　　　 1.0.3.RELEASE　1.1.1.RELEASE　1.2.0.M1　　　 1.2.0.BUILD-SNAPSHOT

spring-cloud-cli　　　　 1.0.6.RELEASE　1.1.5.RELEASE　1.2.0.M1　　　 1.2.0.BUILD-SNAPSHOT

spring-cloud-commons　　1.0.5.RELEASE　1.1.1.RELEASE　1.1.1.RELEASE　1.1.2.BUILD-SNAPSHOT

spring-cloud-contract　　　　　　　　　　　　　　　 1.0.0.M2　　　 1.0.0.BUILD-SNAPSHOT

spring-cloud-config　　　 1.0.4.RELEASE　1.1.3.RELEASE　1.2.0.M1　　　 1.2.0.BUILD-SNAPSHOT

spring-cloud-netflix　　　 1.0.7.RELEASE　1.1.5.RELEASE　1.2.0.M1　　　 1.2.0.BUILD-SNAPSHOT

spring-cloud-security　　　1.0.3.RELEASE　1.1.2.RELEASE　1.1.2.RELEASE　1.1.3.BUILD-SNAPSHOT

spring-cloud-starters　　　1.0.6.RELEASE

spring-cloud-cloudfoundry　　　　　　　 1.0.0.RELEASE　1.0.0.RELEASE　1.0.1.BUILD-SNAPSHOT

spring-cloud-cluster　　　　　　　　　 1.0.1.RELEASE

spring-cloud-consul　　　　　　　　　　1.0.2.RELEASE　1.1.0.M1　　　 1.1.0.BUILD-SNAPSHOT

spring-cloud-sleuth　　　　　　　　　　1.0.6.RELEASE　1.0.6.RELEASE　1.0.7.BUILD-SNAPSHOT

spring-cloud-stream　　　　　　　　　 1.0.2.RELEASE　Brooklyn.M1　　Brooklyn.BUILD-SNAPSHOT

spring-cloud-zookeeper　　　　　　　　 1.0.2.RELEASE　1.0.2.RELEASE　1.0.3.BUILD-SNAPSHOT

spring-boot　　　　　　1.2.8.RELEASE　1.3.7.RELEASE　1.4.0.RELEASE　1.4.0.RELEASE

spring-cloud-task　　　　　　　　　　 1.0.2.RELEASE　1.0.2.RELEASE　1.0.3.BUILD-SNAPSHOT

不难看出，最初的Angel版本相对来说拥有的子项目较少，Brixton、Camden则拥有更全的子项目，所以能提供更多的组件支持。Brixton 的发布子项目更为稳定，Camden 则更为前瞻。

由于Brixton版本包含了大部分的Spring Cloud子项目，并且均为Release版本，所以本文所有示例以及讲解内容的编写均采用Brixton.SR5版本，基于Spring Boot 1.3.7版本。

注意：在本书完成时，Brixton版本已经升级到SR7，本书中的示例均可直接使用Brixton.SR7来完成，但是在使用Brixton版本的时候需要注意Spring Boot的版本，必须使用1.3.x版本，而不能使用1.4.x版本，否则会出现各种问题。若一定要使用Spring 1.4.x版本的话，必须将Spring Cloud版本升级到Camden版本，目前Camden 已经发布 Release版本，所以可以放心使用，最新版本为Camden.SR3。另外，Camden版本虽然可以兼容Brixton版本中的各种实现方法，但是在升级后读者会发现有一些方法已经被标注为过期，对于这些过期的使用方法，笔者后续会在博客中逐个编写博文来说明这些更新内容。所以，有兴趣的读者可以关注我的博客（http://blog.didispace.com），来持续获取Spring Cloud的一些最新动态。第2章微服务构建：Spring Boot在展开Spring Cloud的微服务架构部署之前，我们先通过本章的内容来了解一下用于构建微服务的基础框架—Spring Boot。对于Spring Boot已经有深入了解的读者可以直接跳过本章，进入后续章节学习Spring Cloud各个组件的使用。如果对于 Spring Boot 还不了解的话，建议先读完本章内容之后再继续学习后续关于Spring Cloud的内容。由于Spring Cloud的构建基于Spring Boot实现，在后续的示例中我们将大量使用Spring Boot来构建微服务架构中的基础设施以及一些试验中使用的微服务。为了能够辅助后续内容的介绍，确保读者有一定的Spring Boot基础，在这里先对Spring Boot做一个简单的介绍，以保证读者能够有一定的基础去理解后续介绍的内容并顺利完成后续的一些示例试验。在这里介绍Spring Boot的目的除了它是Spring Cloud的基础之外，也由于其自身的各项优点，如自动化配置、快速开发、轻松部署等，非常适合用作微服务架构中各项具体微服务的开发框架。所以我们强烈推荐使用Spring Boot来构建微服务，它不仅可以帮助我们快速地构建微服务，还可以轻松简单地整合Spring Cloud实现系统服务化，而如果使用了传统的Spring构建方式的话，在整合过程中我们还需要做更多的依赖管理工作才能让它们完好地运行起来。在本章中我们将介绍下面这些与后续介绍有密切联系的内容：●如何构建Spring Boot项目●如何实现RESTful API接口●如何实现多环境的Spring Boot应用配置●深入理解Spring Boot配置的启动机制●Spring Boot应用的监控与管理更多关于Spring Boot的使用细节，读者可以参阅Spring Boot的官方文档或是其他资料来进一步学习。框架简介

对于很多Spring框架的初学者来说，经常会因为其繁杂的配置文件而却步。而对于很多老手来说，每次新构建项目总是会重复复制粘贴一些差不多的配置文件这样枯燥乏味的事。作为一名优秀的程序员或架构师，我们总会想尽办法来避免这样的重复劳动，比如，通过Maven等构建工具来创建针对不同场景的脚手架工程，在需要新建项目时通过这些脚手架来初始化我们自定义的标准工程，并根据需要做一些简单修改以达到简化原有配置过程的效果。这样的做法虽然减少了工作量，但是这些配置依然大量散布在我们的工程中，大部分情况下我们并不会去修改这些内容，但为什么还要反复出现在我们的工程中呢？实在有些碍眼！

Spring Boot的出现可以有效改善这类问题，Spring Boot的宗旨并非要重写Spring或是替代Spring，而是希望通过设计大量的自动化配置等方式来简化Spring原有样板化的配置，使得开发者可以快速构建应用。

除了解决配置问题之外，Spring Boot还通过一系列Starter POMs的定义，让我们整合各项功能的时候，不需要在Maven的pom.xml中维护那些错综复杂的依赖关系，而是通过类似模块化的Starter模块定义来引用，使得依赖管理工作变得更为简单。

在如今容器化大行其道的时代，Spring Boot除了可以很好融入Docker之外，其自身就支持嵌入式的 Tomcat、Jetty 等容器。所以，通过 Spring Boot 构建的应用不再需要安装Tomcat，将应用打包成war，再部署到Tomcat这样复杂的构建与部署动作，只需将Spring Boot应用打成jar包，并通过java-jar命令直接运行就能启动一个标准化的Web应用，这使得Spring Boot应用变得非常轻便。

Spring Boot对于构建、部署等做了这么多的优化，自然不能少了对开发环节的优化。整个Spring Boot的生态系统都使用到了Groovy，很自然的，我们完全可以通过使用Gradle和Groovy来开发Spring Boot应用，比如下面短短的不足100个字符的代码，通过编译打包，使用java –jar命令就能启动一个返回“hello”的RESTful API。@RestControllerclass App {@RequestMapping（"/"）String home（）{"hello"}}

说了这么多Spring Boot带来的颠覆性框架特性，下面我们就通过后续内容来体验一下使用Spring Boot构建微服务的过程，以对Spring Boot有一个直观的感受。快速入门

在本节中，我们将逐步指引读者创建一个Spring Boot的基础项目，并且实现一个简单的RESTful API，通过这个例子对Spring Boot有一个初步的了解，并体验其结构简单、开发迅速的特性。项目构建与解析

系统及工具版本要求

●Java 7及以上版本

●Spring Framework 4.2.7及以上版本

●Maven 3.2及以上版本 /Gradle 1.12及以上版本

本书内容均采用Java 1.8.0_73、Spring Boot 1.3.7调试通过。

构建Maven项目

1.通过官方的Spring Initializr工具来产生基础项目。

2.访问http://start.spring.io/，如下图所示，该页面提供了以 Maven 或Gradle构建Spring Boot项目的功能。

3.选择构建工具 Maven Project、Spring Boot 版本选择1.3.7，填写 Group 和Artifact信息，在Search for dependencies中可以搜索需要的其他依赖包，这里我们要实现RESTful API，所以可以添加Web依赖。

4.单击Generate Project按钮下载项目压缩包。

5.解压项目包，并用IDE以Maven项目导入，以IntelliJ IDEA 14为例。

6.从菜单中选择File-->New-->Project from Existing Sources...。

7.选择解压后的项目文件夹，单击OK按钮。

8.单击Import project from external model并选择Maven，一直单击Next按钮。

9.若你的环境中有多个版本的JDK，选择Java SDK的时候请选择Java 7以上的版本。

工程结构解析

在完成了上面的步骤之后，我们就创建了一个最基础的Spring Boot工程。

如上图所示，Spring Boot的基础结构有三大块（具体路径根据用户生成项目时填写的Group和Artifact有所差异）。

●src/main/java：主程序入口 HelloApplication，可以通过直接运行该类来启动Spring Boot应用。

●src/main/resources：配置目录，该目录用来存放应用的一些配置信息，比如应用名、服务端口、数据库链接等。由于我们引入了Web模块，因此产生了static目录与templates目录，前者用于存放静态资源，如图片、CSS、JavaScript等；后者用于存放Web页面的模板文件，这里我们主要演示提供RESTful API，所以这两个目录并不会用到。

●src/test/：单元测试目录，生成的HelloApplicationTests通过JUnit 4实现，可以直接用运行Spring Boot应用的测试。后文中，我们会演示如何在该类中测试RESTful API。

Maven配置分析

打开当前工程下的 pom.xml 文件，看看生成的项目都引入了哪些依赖来构建 Spring Boot工程，内容大致如下所示。4.0.0com.didispacespring-boot-hello0.0.1-SNAPSHOTjarspring-boot-helloDemo project for Spring Bootorg.springframework.bootspring-boot-starter-parent1.3.7.RELEASE UTF-8UTF-8

试读结束[说明：试读内容隐藏了图片]

下载完整电子书