作者：许进
出版社：机械工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
重新定义Spring Cloud实战试读：
前言
随着互联网的快速普及，云计算近年来得到蓬勃发展，企业的IT环境和架构体系也逐渐发生变革，其中最典型的就是由过去的单体应用架构发展为当今流行的微服务架构。微服务是一种架构风格，其优势是为软件应用开发带来很大的便利，让敏捷开发和复杂的企业应用快速持续交付成为可能。随着微服务架构的流行，很多企业纷纷使用微服务架构来搭建新的系统或者对历史系统进行重构，但是微服务架构的实施和落地会面临很大的挑战。虽然微服务架构的解决方案很多，但是对于如何真正落地微服务架构，目前还没有公认的技术标准和规范。幸运的是，业界已经有一些很有影响力的开源微服务解决方案，比如2015年年初，Spring团队推出的Spring Cloud，其目标是成为Java领域微服务架构落地的标准。Spring Cloud经过高速迭代和发展，至今已经成为Java领域落地微服务架构的推荐解决方案，为企业IT架构变革保驾护航。
Spring Cloud是一个优质的开源项目，它的稳健发展离不开众多开发人员的实践与反馈，开发人员通过一个社区化的平台去交流学习从而使Spring Cloud逐渐完善。Spring Cloud发展到2016年，得到国内越来越多的人的关注，但是相应的学习交流平台和材料比较分散，这阻碍了Spring Cloud在我国的普及和发展。因此Spring Cloud中国社区应运而生。Spring Cloud中国社区(http://springcloud.cn)是国内首个基于Spring Cloud微服务体系创建的非盈利技术社区，也是国内首个致力于Spring Cloud微服务架构开放交流的社区，是专为Spring Boot或Spring Cloud技术人员提供分享和交流服务的平台，目的是推动Spring Cloud在中国的普及和应用。为什么写这本书？
Spring Cloud中国社区自2016年创建以来，在北京、上海、深圳、成都等地举办了多次技术沙龙，帮助数万名开发者快速学习Spring Cloud并用于生产。为更好地推动Spring Cloud在中国的发展，让更多开发者受益，社区针对Spring Cloud在国内的使用情况，结合国内上百家企业使用Spring Cloud落地微服务架构时遇到的问题和相应的解决方案，特推出本书。你适合本书吗？
如果你没听说过微服务，也没有听说过Spring Cloud，或者你正在学习或尝试使用Spring Cloud去落地微服务架构，那么这本书会非常适合你。因为本书更加偏实战，书中所讲是一套可落地的解决方案。不管你是初学者、开发人员还是架构师，只要你想使用Spring Cloud去落地微服务架构，就可以阅读并学习本书。本书是如何组织的？
本书共25章，按照“核心组件→进阶实战→解决方案”的结构将内容从逻辑上划分为三个部分，具体如下：
第1～10章为核心组件部分，主要介绍Spring Cloud的核心组件。首先从应用架构的发展历程讲起，介绍了微服务出现的背景，并对微服务架构的落地提出了相应的解决方案。然后分别详细介绍了Spring Cloud微服务体系中的核心常用组件，如Eureka、Feign、Ribbon、Hystrix、Zuul等。最后通过一个综合案例将前面介绍的组件连接起来，帮助大家融会贯通。
第11～18章为进阶实战部分，在核心组件的基础上，对Config、Consul、认证和鉴权、全链路监控以及Spring Cloud生态圈中第二代网关Spring Cloud Gateway进行详细阐述，循序渐进、案例驱动，帮助读者加深对组件的理解，更好地掌握相关内容并运用于生产实践中。
第19～25章为解决方案部分，主要从解决方案着手，内容包括Spring Cloud与gRPC的整合方式、版本控制与灰度发布、Spring Cloud容器化、Dubbo向Spring Cloud的迁移、分布式事务、领域驱动等生产级实用解决方案，为企业IT架构微服务化和变革保驾护航。本书源码及勘误
本书案例源码使用Java 8版本编写，并使用Maven来构建管理。关于JDK的安装、Maven的安装，以及集成开发环境IDE的安装，在这里不再阐述，请读者自行安装。本书的源码托管在GitHub上，具体地址是https://github.com/springcloud/spring-cloud-code.git。可以使用Git客户端管理工具，比如通过SourceTree直接复制仓库到本地，然后通过IDE直接导入。代码模块根据章节内容进行编号，如ch2-1，其中ch是chapter的简称，ch2代表第2章，ch2-1代表第2章的第一个聚合案例工程。
由于能力有限，书中难免有不妥之处，如果在学习中遇到问题或者发现Bug，可以加QQ（2508203324）或者发邮件到Software_King@qq.com与我们交流沟通。致谢
我们代表Spring Cloud中国社区编写本书，我们想把本书送给每一位Spring Cloud技术爱好者，帮助大家快速掌握Spring Cloud的实战技巧并快速落地实践，为企业创造价值。
感谢与我一起写作的小伙伴们，大家能聚在一起写一本书也是一种缘分，大家的思维碰撞和交流，使本书变得更加完善，更加接地气，更具实战性。
感谢机械工业出版社华章公司的杨福川编辑与他的团队，他们在写作和审校过程中给予的帮助和支持，让我们能顺利地写完本书，跟大家见面。
感谢为本书评审的专家们，他们专业的态度和建议，为本书提供了宝贵的建议，尤其感谢Spring Cloud中国社区核心成员何鹰、刘石明、任浩军、任聪、李云龙等对Spring Cloud中国社区开源项目的贡献和支持。
感谢一直支持Spring Cloud中国社区发展的读者和亲朋好友们，感恩一路有你们，因为有你们的支持和陪伴，社区才能更好地发展，本书才能顺利完成。
最后我想说的是，我们7位作者并不是Spring Cloud微服务落地方面的架构专家，我们只是Spring Cloud微服务架构的实践者。我们只是想重新定义什么是真正意义上的Spring Cloud实战，并把我们自己的实践经验分享给大家，帮助大家解决学习和工作上遇到的问题。三人行，必有我师焉，由于我们学识有限，难免会有不足之处，还请读者不吝赐教，一起交流学习，共同进步。许进第1章微服务与Spring Cloud
随着互联网的快速发展，云计算近十年也得到蓬勃发展，企业的IT环境和IT架构也逐渐在发生变革，从过去的单体应用架构发展为至今广泛流行的微服务架构。微服务是一种架构风格，能给软件应用开发带来很大的便利，但是微服务的实施和落地会面临很大的挑战，因此需要一套完整的微服务解决方案。在Java领域，Spring框架的出现给Java企业级软件开发带来了福音，提高了开发效率。在2014年底，Spring团队推出Spring Cloud，目标使其成为Java领域微服务架构落地的标准，发展至今，Spring Cloud已经成为Java领域落地微服务架构的完整解决方案，为企业IT架构变革保驾护航。1.1 微服务架构概述1.1.1 应用架构的发展
应用是可独立运行的程序代码，提供相对完善的业务功能。目前软件架构有三种架构类型，分别是业务架构、应用架构、技术架构。它们之间的关系是业务架构决定应用架构，技术架构支撑应用架构。架构的发展历程是从单体架构、分布式架构、SOA架构再到微服务架构，如图1-1所示。图1-1 架构发展历程
1.单体应用架构
单体架构在Java领域可以理解为一个Java Web应用程序，包含表现层、业务层、数据访问层。从Controller到Service再到Dao层，“一杆子捅到底”，没有任何应用拆分，开发完毕之后变成一个超级大型的War部署。简单的单体架构水平分层逻辑如图1-2所示。图1-2 单体架构水平分层逻辑
单体架构的优点：
·易于开发：开发人员使用当前开发工具在短时间内就可以开发出单体应用。
·易于测试：因为不需要依赖其他接口，测试可以节约很多时间。
·易于部署：你只需要将目录部署在运行环境中即可。
单体架构的缺点：
·灵活度不够：如果程序有任何修改，修改的不只是一个点，而是自上而下地去修改，测试时必须等到整个程序部署完后才能看出效果。在开发过程可能需要等待其他开发人员开发完成后才能完成部署，降低了团队的灵活性。
·降低系统的性能：原本可以直接访问数据库但是现在多了一层。即使只包含一个功能点，也需要在各个层写上代码。
·系统启动慢：一个进程包含了所有业务逻辑，涉及的启动模块过多，导致系统的启动时间延长。
·系统扩展性比较差：增加新东西的时候不能针对单个点增加，要全局性地增加。牵一发而动全身。
2.分布式架构
什么是传统的分布式架构？简单来说，按照业务垂直切分，每个应用都是单体架构，通过API互相调用，如图1-3所示。
3.面向服务的SOA架构
面向服务的架构是一种软件体系结构，其应用程序的不同组件通过网络上的通信协议向其他组件提供服务或消费服务，所以也是一种分布式架构。简单来说，SOA是不同业务建立不同的服务，服务之间的数据交互粗粒度可以通过服务接口分级，这样松散耦合提高服务的可重用性，也让业务逻辑变得可组合，并且每个服务可以根据使用情况做出合理的分布式部署，从而让服务变得规范，高性能，高可用。图1-3 分布式架构
SOA架构中有两个主要角色：服务提供者（Provider）和服务消费者（Consumer）。阿里开源的Dubbo是SOA的典型实现。
SOA架构的优点：
·把模块拆分，使用接口通信，降低模块之间的耦合度。
·把项目拆分成若干个子项目，不同的团队负责不同的子项目。
·增加功能时只需要增加一个子项目，调用其他系统的接口即可。
·可以灵活地进行分布式部署。
SOA架构的缺点：系统之间的交互需要使用远程通信，接口开发增加工作量。1.1.2 微服务架构
微服务架构在某种程度上是SOA架构继续发展的下一步。微服务的概念最早源于Martin Fowler的一篇文章《Microservices》。总体来说，微服务是一种架构风格，对于一个大型复杂的业务系统，它的业务功能可以拆分为多个相互独立的微服务，各个微服务之间是松耦合的，通过各种远程协议进行同步/异步通信，各微服务均可以被独立部署、扩/缩容以及升/降级。这里对微服务技术选型做了对比，如表1-1所示。表1-1 微服务架构技术选型对比1.1.3 微服务解决方案
现如今微服务架构十分流行，而采用微服务构建系统也会带来更清晰的业务划分和可扩展性。同时支持微服务的技术栈也是多种多样的。下面介绍两种实现微服务的解决方案。
1.基于Spring Cloud的微服务解决方案
Spring Cloud的技术选型是中立的，因此可以随需更换搭配使用，基于Spring Cloud的微服务落地解决方案可以分为三种，如表1-2所示。表1-2 基于Spring Cloud的三种方案
2.基于Dubbo实现微服务解决方案
2012年，阿里巴巴在GitHub上开源了基于Java的分布式服务治理框架Dubbo，但是Dubbo未来的定位并不是要成为一个微服务的全面解决方案，而是专注于RPC领域，成为微服务生态体系中的一个重要组件。至于微服务化衍生出的服务治理需求，Dubbo正在积极适配开源解决方案，并且已经启动独立的开源项目予以支持，比如最近宣布的开源的Nacos。Nacos的定位是一个更易于帮助构建云原生应用的动态服务发现、配置和服务管理平台。因此基于Dubbo的微服务解决方案是：Dubbo+Nacos+其他。1.2 Spring Cloud与中间件1.2.1 中间件概述
中间件与操作系统、数据库并列为传统基础软件的三驾马车。其中，中间件也是难度极高的软件工程。传统中间件的概念，诞生于上一个“分布式”计算的年代，也就是小规模局域网中的服务器/客户端计算模式，在操作系统之上、应用软件之下的“中间层”软件。
随着互联网的快速发展，以及云计算的出现，企业的IT架构正在发生深刻的变革。在这个过程中，软件向大规模互联网云服务演化，无论是操作系统还是数据库都发生了深刻的变化，中间件也在这个过程不断演进和扩大自己的边界。中间件向下屏蔽异构的硬件、软件、网络等计算资源，向上提供应用开发、运行、维护等全生命周期的统一计算环境与管理，属于承上启下的中间连接层，对企业来说有着极其重要的价值。中间件本质上可以归属为技术架构，常见的中间件分别是服务治理中间件（例如：Dubbo等RPC框架）、配置中心、全链路监控、分布式事务、分布式定时任务、消息中间件、API网关、分布式缓存、数据库中间件等。1.2.2 什么是Spring Cloud
在前面的小节介绍了中间件，Spring Cloud也是一个中间件。它目前由Spring官方开发维护，基于Spring Boot开发，提供一套完整的微服务解决方案。包括服务注册与发现、配置中心、全链路监控、API网关、熔断器等选型中立的开源组件，可以随需扩展和替换组装。
Spring Cloud项目自从推出以来，到目前为止一直在高速迭代。Spring Cloud技术团队于2018年6月19日发布了Spring Cloud的重大里程碑Finchley版本。本书也是基于此版本编写，目前Spring Cloud在国内外得到广泛使用。Spring Cloud中国社区发起了Spring Cloud在中国的使用情况收集，具体可以参考如下统计链接：https://github.com/SpringCloud/spring-cloud-document/issues/1。1.2.3 Spring Cloud项目模块
Spring Cloud是一个开源项目集合，包括很多子项目。具体的项目地址可以参考GitHub组织：https://github.com/spring-cloud。Spring Cloud的主要组件汇总如表1-3所示，因为Spring Cloud的子项目居多，每个子项目有自己的版本号，为了对Spring Cloud整体进行版本编号，确定一个可用于生产上的版本标识。这些版本采用伦敦地铁站的名字，按名称首字母排序，比如Dalston版，Edgware版，Finchley。但是我们一般都会简称为D版、E版、F版等。表1-3 Spring Cloud组件列表1.2.4 Spring Cloud与服务治理中间件
服务治理中间件包含服务注册与发现、服务路由、负载均衡、自我保护、丰富的治理管理机制等功能。其中服务路由包含服务上下线、在线测试、机房就近选择、A/B测试、灰度发布等。负载均衡支持根据目标状态和目标权重进行负载均衡。自我保护包括服务降级、优雅降级和流量控制。
Spring Cloud作为一个服务治理中间件，它的服务治理体系做了高度的抽象，目前支持使用Eureka、Zookeeper、Consul作为注册中心，并且预留了扩展接口，而且由于选型是中立的，所以支持无缝替换。在Spring Cloud中可以通过Hystrix进行熔断自我保护Fallback，通过Ribbon进行负载均衡。本书围绕着Spring Cloud的服务治理体系介绍Eureka、Consul、Ribbon、Hystrix等实战用法。关于Spring Cloud注册中心的对比选型参考，如图1-4所示。1.2.5 Spring Cloud与配置中心中间件
在单体应用中，我们一般的做法是把属性配置和代码硬编码放在一起，这没有什么问题。但是在分布式系统中，由于存在多个服务实例，需要分别管理每个具体服务工程中的配置，上线需要准备Check List并逐个检查每个上线的服务是否正确。在系统上线之后一旦修改某个配置，就需要重启服务。这样开发管理相当麻烦。因此我们需要把分布式系统中的配置信息抽取出来统一管理，这个管理的中间件称为配置中心。配置中心应该具备的功能，分别是支持各种复杂的配置场景，与公司的运维体系和权限管理体系集成，各种配置兼容支持，如图1-5所示。图1-4 注册中心选型对比图1-5 配置中心的功能
Spring Cloud Config是Spring Cloud生态圈中的配置中心中间件，它把应用原本放在本地文件中的配置抽取出来放在中心服务器，从而能够提供更好的管理、发布能力。Spring Cloud Config基于应用、环境、版本三个维度管理，配置存储支持Git和其他扩展存储，且无缝支持Spring里Environment和PropertySource的接口。但是Spring Cloud Config的缺点是没有可视化的管控平台，因此会用其他的配置中心中间件取代它管理配置。在本书的第11章和第12章介绍了Spring Cloud Config和携程开源配置中心Apollo的实战用法。1.2.6 Spring Cloud与网关中间件
1.网关中间件概述
API Gateway（APIGW/API网关），顾名思义，是出现在系统边界上一个面向API的、串行集中式的强管控服务，这里的边界是企业IT系统的边界，可以理解为企业级应用防火墙，主要起到隔离外部访问与内部系统的作用。在微服务概念流行之前，API网关就已经诞生了，例如银行、证券等领域常见的前置系统，它的设计与出现主要是为了解决访问认证、报文转换、访问统计等问题。网关在微服务架构中所处的位置，如图1-6所示。图1-6 网关在微服务架构中所处的位置
随着微服务架构概念的提出，API网关成为微服务架构的一个标配组件。作为一个网关中间件，至少具备如下四大功能。（1）统一接入功能
为各种无线应用提供统一的接入服务，提供一个高性能、高并发、高可靠的网关服务。不仅如此，还要支持负载均衡、容灾切换和异地多活。（2）协议适配功能
网关对外的请求协议一般是HTTP或HTTP2协议，而后端提供访问的服务协议要么是REST协议要么是RPC协议。网关需要根据请求进来的协议进行协议适配，然后协议转发调用不同协议提供的服务。比如网关对外暴露是HTTP协议的请求，而网关后端服务可能是Dubbo提供的RPC服务，可能是Spring Cloud提供的REST服务，也可能是其他PHP编写的服务。当一个HTTP请求经过网关时，通过一系列不同功能的Filter处理完毕之后，此时就需要进行协议适配，判断应该协议转发调用RPC服务，调用REST服务，还是调用PHP提供的服务。（3）流量管控功能
网关作为所有请求流量的入口，当请求流量瞬间剧增，比如天猫双11、双12或者其他大促活动，流量会迅速剧增，此时需要进行流量管控、流量调拨。当后端服务出现异常，服务不可用时，需要网关进行熔断和服务降级。在异地多活场景中需要根据请求流量进行分片，路由到不同的机房。（4）安全防护功能
网关需要对所有请求进行安全防护过滤，保护后端服务。通过与安全风控部门合作，对IP黑名单和URL黑名单封禁控制，做风控防刷，防恶意攻击等。
2.Spring Cloud第一代网关Zuul
Spring Cloud生态圈的第一代网关是在Netflix公司开源的网关组件Zuul之上，它基于Spring Boot注解，采用Starter的方式进行二次封装，可以做到开箱即用。目前Zuul融合了Spring Cloud提供的服务治理体系，根据配置的路由规则或者默认的路由规则进行路由转发和负载均衡。它可以与Spring Cloud生态系统内其他组件集成使用，例如：集成Hystrix可以在网关层面实现降级的功能；集成Ribbon可以使得整个架构具备弹性伸缩能力；集成Archaius可以进行配置管理等。但是Spring Cloud Zuul如果需要做一些灰度、降级、标签路由、限流、WAF封禁，则需要自定义Filter做一些定制化实现。
3.Spring Cloud第二代网关Gateway
Spring Cloud Zuul处理每个请求的方式是分别对每个请求分配一个线程来处理。根据参考数据统计，目前Zuul最多能达到1000至2000 QPS。在高并发的场景下，不推荐使用Zuul作为网关。因此出现了Spring Cloud的第二代网关，即Spring Cloud Gateway。
Spring Cloud Gateway是Spring官方基于Spring 5.0、Spring Boot 2.0和Project Reactor等技术开发的网关，旨在为微服务架构提供一种简单、有效、统一的API路由管理方式。Spring Cloud Gateway底层基于Netty实现（Netty的线程模型是多线程reactor模型，使用boss线程和worker线程接收并异步处理请求，具有很强大的高并发处理能力），因此Spring Cloud Gateway出现的目的就是替代Netflix Zuul。其不仅提供统一的路由方式，并且基于Filter链的方式提供了网关基本的功能，例如，安全、监控/埋点、限流等。在本书的第17章和18章，详细地介绍了Spring Cloud Gateway的使用方法和实战技巧。1.2.7 Spring Cloud与全链路监控中间件
众所周知，中大型互联网公司的后台业务系统由众多的分布式应用组成。一个通过浏览器或移动客户端的前端请求到后端服务应用，会经过很多应用系统，并且留下足迹和相关日志信息。但这些分散在每个业务应用主机下的日志信息不利于问题排查和定位问题发生的根本原因。此时就需要利用全链路监控中间件收集、汇总并分析日志信息，进行可视化展示和监控告警。全链路监控中间件应该提供的主要功能包括：
·定位慢调用：包括慢Web服务（包括Restful Web服务）、慢REST或RPC服务、慢SQL。
·定位各种错误：包括4××、5××、Service Error。
·定位各种异常：包括Error Exception、Fatal Exception。
·展现依赖和拓扑：域拓扑、服务拓扑、trace拓扑。
·Trace调用链：将端到端的调用，以及附加在这次调用的上下文信息，异常日志信息，每一个调用点的耗时都呈现给用户进行展示。
·应用告警：根据运维设定的告警规则，扫描指标数据，如违反告警规则，则将告警信息上报到中央告警平台。
全链路监控中间件相关产品发展至今百花齐放，如京东Hydra，阿里Eagleye，这两个中间件都吸收了Dapper/Zipkin的设计思路，但是目前都未开源。近年，社区又发展出很多调用链监控产品，如国内开源爱好者吴晟（原OneAPM工程师，目前在华为）开源并提交到Apache孵化器的产品Skywalking，它同时吸收了Zipkin/Pinpoint/CAT的设计思路，支持非侵入式埋点。如果使用Java技术栈，希望采用非侵入式的监控，推荐使用Pinpoint或者Skywalking。
本书的相关章节介绍了Spring Cloud Sleuth的实战用法，以及如何借助Pinpoint或者Skywalking实现Spring Cloud体系下的全链路监控。1.3 Spring Cloud增强生态1.3.1 Spring Cloud分布式事务
微服务倡导将复杂的单体应用拆分为若干个功能简单、松耦合的服务，这样可以降低开发难度，增强扩展性，便于敏捷开发。当前微服务被越来越多的开发者推崇，很多互联网行业巨头、开源社区等都开始了微服务的讨论和实践。很多中小型互联网公司，由于经验、技术实力等问题，想要让微服务落地还比较困难。如著名架构师Chris Richardson所言，目前存在的主要困难有如下几方面：
1）单体应用拆分为分布式系统后，进程间的通信机制和故障处理措施变得更加复杂。
2）系统微服务化后，一个看似简单的功能，内部可能需要调用多个服务并操作多个数据库实现，服务调用的分布式事务问题变得非常突出。
3）微服务数量众多，其测试、部署、监控等都变得更加困难。
4）随着RPC框架的成熟，第一个问题已经逐渐得到解决。例如HSF、Dubbo可以支持多种通信协议，Spring Cloud可以非常好地支持RESTful调用。
对于第三个问题，随着Docker、Devops技术的发展以及各公有云PAAS平台自动化运维工具的推出，微服务的测试、部署与运维变得越来越容易。而对于第二个问题，现在还没有一个通用方案可以很好地解决微服务产生的事务问题。分布式事务问题已经成为微服务落地最大的阻碍，也是最具挑战性的一个技术难题。在本书的第24章，会通过案例介绍Spring Cloud与分布式事务的各种解决方案。1.3.2 Spring Cloud与领域驱动
Spring Cloud组件很多，更像是一套中间件体系，是实现微服务架构的基础实施。Spring Cloud作为微服务架构的基础设施，能够快速帮助企业开发者搭建微服务架构。Spring Cloud解决了框架层面的问题，但是对于业务怎么开发，业务架构怎么治理，架构怎么防腐，怎么解决应用架构的复杂性问题，还需要方法论去指导实践。所以在微服务架构落地的过程中，Spring Cloud和领域驱动相辅相成显得十分重要。Spring Cloud解决架构分布式等问题，领域驱动作为业务治理和架构防腐的方法论，两者并驾齐驱，为企业IT架构变革与微服务改造保驾护航。在本书的第25章将会详细介绍领域驱动Halo框架的设计。Halo框架无缝整合了Spring Cloud，目前支持Spring Cloud Finchley版本，通过案例的方式讲解如何运用Spring Cloud和领域驱动来进行业务架构治理和代码防腐。1.3.3 Spring Cloud与gRPC
通过Spring Cloud构建微服务应用，大多数开发者使用官方提供的服务调用组件Feign来进行内部服务调用通信，这种声明式的HTTP客户端使用起来极为简单、优雅、方便。然而Feign的底层调用实现走的还是HTTP协议，相对于Dubbo、gRPC等RPC框架走RPC协议来说，通过HTTP来进行服务之间的调用，性能相对低下。那么我们是否可以通过Spring Cloud集成其他RPC框架来实现服务之间的高性能调用，答案是肯定的。在本书的第19章至20章将为大家讲解如何在Spring Cloud中集成Google开源框架gRPC。1.3.4 Spring Cloud与Dubbo生态融合
在微服务架构的实施和落地过程中，我们通常会进行技术选型，做一些对比。很多人都会拿阿里开源的Dubbo和Spring Cloud进行对比，其本质对比的主要是REST和RPC。其实Dubbo和Spring Cloud并不在同一个领域，没有可比性。因为Spring Cloud是一个完整的微服务解决方案，提供分布式情况下的各种解决方案合集。而Dubbo是一款高性能Java RPC框架。Spring Cloud生态与Dubbo生态随着发展将会逐渐融合互补。
Spring Cloud的设计理念是Integrate Everything，即充分利用现有开源组件，在它们之上设计一套统一规范/接口使它们能够接入Spring Cloud体系并且能够无缝切换底层实现。最典型的例子就是DiscoveryClient，只要实现DiscoveryClient相关接口，Spring Cloud的底层注册中心就可以随意更换，Dubbo的注册中心也有SPI规范进行替换。
在2018年6月Spring Cloud中国社区开源了一个名为spring-cloud-dubbo项目，该项目的目标是将Dubbo融入Spring Cloud生态体系中，使微服务之间的调用同时具备RESTful和Dubbo调用的能力，做到对业务代码无侵入、无感知。若在使用过程中引入jar包则在微服务间调用时使用Dubbo，去掉jar包则使用默认的RESTful。在本书的第23章，将会详细讲解spring-cloud-dubbo的设计与使用，为Dubbo向Spring Cloud的无缝迁移提供统一的方法论并指导落地。1.4 本章小结
本章开始介绍了应用架构发展的历程，讲解了什么是微服务架构，然后针对微服务架构的落地提出了解决方案。接着介绍了什么是中间件，从中间件的角度介绍了Spring Cloud的主要组件和类似中间件的区别和联系。为了更好地通过Spring Cloud落地微服务架构，介绍了Spring Cloud的增强生态。第2章Spring Cloud Eureka上篇
Netflix Eureka（后文简称Eureka）是由Netflix开源的一款基于REST的服务发现组件，包括Eureka Server及Eureka Client。从2012年9月在GitHub上发布1.1.2版本以来，至今已经发布了231次，最新版本为2018年8月份发布的1.9.4版本。期间有进行2.x版本的开发，不过由于各种原因内部已经冻结开发，目前还是以1.x版本为主。Spring Cloud Netflix Eureka是Pivotal公司为了将Netflix Eureka整合于Spring Cloud生态系统提供的版本。
本章以Spring Cloud Finchley版本展开，对应Eureka的1.9.2版本，将系统全面地介绍服务发现的由来、Eureka的核心概念及其设计理念以及在实际企业级开发中的应用技巧。2.1 服务发现概述2.1.1 服务发现由来
服务发现及注册中心或是名字服务（后文统一简称服务发现），不是凭空出现的，其演进与软件开发的架构方式的演进有密切关联，大致如下：
1.单体架构时代
早期的互联网开发，多使用单体架构，服务自成一体，对于依赖的少数外部服务，会采用配置域名的方式访问，比如要使用外部短信供应商的短信发送接口，会使用appId和appKey，调用该供应商的域名接口即可。
2.SOA架构时代
随着SOA架构的流行，公司的内部服务开始从单体架构拆分为粒度较粗的服务化架构，这个时候，依赖的内部服务会比较多，那么内部的服务之间如何相互调用呢？以基于HTTP形式暴露服务为例，假设A服务部署在3台虚拟机上，这3个服务实例均有各自的独立内网ip，此时假设B服务要调用A服务的接口服务，有几种方式。
方式一：A服务把这3个服务实例的内网ip给到消费者B服务，这个时候B服务在没有Client端负载均衡技术的条件下，通常会在B服务自己的Nginx上配置A服务的upstream，即将A服务的3个服务实例配置进去，比如：upstream servicea_api_servers { server 192.168.99.100:80 weight=3 max_fails=3 fail_timeout=20s; server 192.168.99.101:80 weight=1 max_fails=3 fail_timeout=20s; server 192.168.99.102:80 weight=4 max_fails=3 fail_timeout=20s;}##......server { listen 80 default_server; server_name serviceb.com.cn; location /api/servicea/ { proxy_pass http://servicea_api_servers/api/ ; }}
通过B服务自己的Nginx来维护A服务的具体实例ip，这种方式缺点比较明显，那就是B服务耦合了A服务的实现细节，当A服务实例扩充或者ip地址变化的时候，其下游的消费者都需要去修改这些ip，非常费劲。
方式二：为了解耦合，采用服务提供方A服务自己维护ip实例的方式，暴露统一的内网域名给消费者去消费，这样B服务只需要配置一个内网域名即可，比如：server { listen 80 default_server; server_name serviceb.com.cn; location /api/servicea/ { proxy_pass http://servicea.com.cn/api/ ; }}
而A服务自己的Nginx则自己维护ip实例，比如：upstream servicea_api_servers { server 192.168.99.100:80 weight=3 max_fails=3 fail_timeout=20s; server 192.168.99.101:80 weight=1 max_fails=3 fail_timeout=20s; server 192.168.99.102:80 weight=4 max_fails=3 fail_timeout=20s;}##......server { listen 80 default_server; server_name servicea.com.cn; location /api/ { proxy_pass http://servicea_api_servers/api/ ; }}
这样即实现了服务提供方与消费者之间的解耦，若A服务要变更实例ip地址，自己更改自身的Nginx配置即可。
3.微服务时代
在微服务时代，底层运维方式发生了巨大的变化，随着Docker的流行，业务服务不再部署在固定的虚拟机上，其ip地址也不再固定，这个时候前面的解决方案就显得捉襟见肘了。针对合格问题，不同的思考方式提出了不同的解决方案，这里列举几个。
方案一：以Nginx为例，在没有引入服务注册中心的时候，那就是手工或是通过脚本的方式，在部署的时候去更新Nginx的配置文件，然后reload。抑或是使用ngx_http_dyups_module通过rest api来在运行时直接更新upstream而不需要reload。
方案二：将服务注册中心作为一个标配的分布式服务组件，网关等都从服务注册中心获取相关服务的实例信息，实现动态路由。比如consul-template+Nginx的方案，通过consul监听服务实例变化，然后更新Nginx的配置文件，通过reload实现服务列表更新。又拍云的slardar也是这个思路，不过不是通过reload的方式来，而是通过在运行时通过consul获取服务列表来实现动态upstream的路由。
由此可见，随着服务架构模式以及底层运维方式的变化，服务注册中心逐步在分布式系统架构中占据了一个重要的地位。2.1.2 Eureka简介
Eureka是Netflix公司开源的一款服务发现组件，该组件提供的服务发现可以为负载均衡、failover等提供支持，如图2-1所示。Eureka包括Eureka Server及Eureka Client。Eureka Server提供REST服务，而Eureka Client则是使用Java编写的客户端，用于简化与Eureka Server的交互。图2-1 Eureka简图
Eureka最初是针对AWS不提供中间服务层的负载均衡的限制而设计开发的。AWS Elastic Load Balancer用来对客户端或终端设备请求进行负载均衡，而Eureka则用来对中间层的服务做服务发现，配合其他组件提供负载均衡的能力。
Netflix为什么要设计Eureka，而不是直接利用AWS Elastic Load Balancer或者AWS Route 53呢？其官方文档说明简要如下：
理论上可以使用AWS Elastic Load Balancer对内部进行负载均衡，但是这样就会暴露到外网，存在安全性问题，另外AWS Elastic Load Balancer是传统的基于代理的负载均衡解决方案，无法直接基于服务元数据信息定制负载均衡算法。因此Netflix设计了Eureka，一方面给内部服务做服务发现，另一方面可以结合ribbon组件提供各种个性化的负载均衡算法。
而AWS Route 53是一款命名服务，可以给中间层的服务提供服务发现功能，但它是基于DNS的服务，传统的基于DNS的负载均衡技术存在缓存更新延时问题，另外主要是无法对服务健康状态进行检查，因此Netflix就自己设计了Eureka。2.1.3 服务发现技术选型
Jason Wilder在2014年2月的时候写了一篇博客《Open-Source Service Discovery》（http://jasonwilder.com/blog/2014/02/04/service-discovery-in-the-cloud/），总结了当时市面上的几类服务发现组件，这里补充上consul以及一致性算法，如表2-1所示。表2-1 服务发现组件对比
从列表看，有很多服务发现组件可以选择，针对AP及CP，本书主要选取了Eureka及Consul为代表来阐述。关于Eureka及Consul的区别，Consul的官方文档有一个很好的阐述（https://www.consul.io/intro/vs/eureka.html），具体如下：
Eureka Server端采用的是P2P的复制模式，但是它不保证复制操作一定能成功，因此它提供的是一个最终一致性的服务实例视图；Client端在Server端的注册信息有一个带期限的租约，一旦Server端在指定期间没有收到Client端发送的心跳，则Server端会认为Client端注册的服务是不健康的，定时任务会将其从注册表中删除。Consul与Eureka不同，Consul采用Raft算法，可以提供强一致性的保证，Consul的agent相当于Netflix Ribbon+Netflix Eureka Client，而且对应用来说相对透明，同时相对于Eureka这种集中式的心跳检测机制，Consul的agent可以参与到基于gossip协议的健康检查，分散了Server端的心跳检测压力。除此之外，Consul为多数据中心提供了开箱即用的原生支持等。
那么基于什么考虑因素可以选择Eureka呢，主要有如下几点：
·选择AP而不是CP，这一点在后面的章节会阐述。
·如果团队是Java语言体系的，则偏好Java语言开发的，技术体系上比较统一，出问题也好排查修复，对组件的掌控力较强，方便扩展维护。
·当然除此之外，更主要的是Eureka是Netflix开源套件的一部分，跟zuul，ribbon等整合的比较好。2.2 Spring Cloud Eureka入门案例
下面来让我们体验一下Eureka的Hello World工程，这里需要用到的组件是Spring Cloud Netflix Eureka。
1.创建Maven父级pom工程
在父工程里面配置好工程需要的父级依赖，目的是为了方便管理与简化配置，如代码清单2-1所示。
代码清单2-1 ch2-1\pom.xml
2.创建Eureka Server工程
为避免赘述，在本章中，Eureka组件配置只展示一次，后续实战演练配置中心皆基于此。
配置Eureka Server工程的pom.xml文件，只需要添加spring-cloud-starter-netflix-eureka-server即可，注意F版和之前的版本有些变化，如代码清单2-2所示。
代码清单2-2 ch2-1\ch2-1-eureka-server\pom.xml
试读结束[说明：试读内容隐藏了图片]