编辑推荐
（1）新。《Spring Cloud 微服务架构开发实战（全新升级版）》案例基于全新的SpringBoot2.0及SpringCloudFinchley.M2，深入浅出地讲解了SpringCloud。
（2）实战。跳脱纯理论讲述，案例贯穿《Spring Cloud 微服务架构开发实战（全新升级版）》，从0到1搭建微服务系统，从1到0实现微服务拆分。读者不仅能全面学到软件开发技能，还能学到项目实战经验。
（3）全。弥补市面上有关SpringCloud学习资料的不足，重新编写整个教学案例，使读者轻松脱离“HelloWorld”阶段，实现对微服务的治理。
内容简介
众所周知，SpringCloud是开发微服务架构系统的利器，企业对SpringCloud方面的开发需求也非常旺盛。然而，虽然市面上介绍SpringCloud的概念及基础入门的书籍较多，但这些书籍中的案例往往只是停留在简单的“HelloWorld”级别，缺乏可真正用于实战落地的指导。
《Spring Cloud 微服务架构开发实战（全新升级版）》与其他书籍不同，特色是真正从实战角度出发，运用SpringCloud技术来构建一个完整的微服务架构的系统。《Spring Cloud 微服务架构开发实战（全新升级版）》全面介绍SpringCloud的概念、产生的背景，以及围绕SpringCloud在开发微服务架构系统过程中所面临的问题时应当考虑的设计原则和解决方案。特别是在设计微服务架构系统时所面临的系统分层、服务测试、服务拆分、服务通信、服务注册、服务发现、服务消费、集中配置、日志管理、容器部署、安全防护、自动扩展等方面，给出了作者自己独特的见解。《Spring Cloud 微服务架构开发实战（全新升级版）》不仅介绍了微服务架构系统的原理、基础理论，还以一个真实的天气预报系统实例为主线，集成市面上主流的新的实现技术框架，手把手地教读者如何来应用这些技术，创建一个完整的微服务架构系统。这样读者可以理论联系实践，从而让SpringCloud真正地落地。
此外，《Spring Cloud 微服务架构开发实战（全新升级版）》不仅可以令读者了解微服务架构系统开发的完整流程，而且通过实战结合技术点的归纳，令读者知其然且知其所以然。《Spring Cloud 微服务架构开发实战（全新升级版）》所涉及的技术符合当前主流，并富有一定的前瞻性，可以有效提高读者在市场中的核心竞争力。
《Spring Cloud 微服务架构开发实战（全新升级版）》主要面向以Spring为核心的JavaEE开发者，以及对SpringCloud和微服务开发感兴趣的读者。
作者简介
柳伟卫（英文名WayLau），关注编程、系统架构、性能优化。在大型IT公司担任过项目经理、架构师、高级开发顾问等职位，具有多年软件开发管理及系统架构经验。负责过多个省级、国家大型分布式系统的设计与研发，参与了多个大型项目的微服务架构的技术改造，在实际工作中积累了大量的微服务架构经验。是CSDN、开源中国、云栖社区等技术社区专家。已出版专著《SpringBoot企业级应用开发实战》。
目录
目录
第1章微服务概述
1.1传统软件行业面临的挑战
1.2常见分布式系统架构
1.3单块架构如何进化为微服务架构
1.4微服务架构的设计原则
1.5如何设计微服务系统
第2章微服务的基石——SpringBoot
2.1SpringBoot简介
2.2开启第一个SpringBoot项目
2.3HelloWorld
2.4如何搭建开发环境
2.5Gradle与Maven的抉择
第3章SpringBoot的高级主题
3.1构建RESTful服务
3.2SpringBoot的配置详解
3.3内嵌Servlet容器
3.4实现安全机制
3.5允许跨域访问
3.6消息通信
3.7数据持久化
3.8实现热插拔
第4章微服务的测试
4.1测试概述
4.2测试的类型和范围
4.3如何进行微服务的测试
第5章微服务的协调者——SpringCloud
5.1SpringCloud简介
5.2SpringCloud入门配置
5.3SpringCloud的子项目介绍
第6章服务拆分与业务建模
6.1从一个天气预报系统讲起
6.2使用Redis提升应用的并发访问能力
6.3实现天气数据的同步
6.4给天气预报一个“面子”
6.5如何进行微服务的拆分
6.6领域驱动设计与业务建模
第7章天气预报系统的微服务架构设计与实现
7.1天气预报系统的架构设计
7.2天气数据采集微服务的实现
7.3天气数据API微服务的实现
7.4天气预报微服务的实现
7.5城市数据API微服务的实现
第8章微服务的注册与发现
8.1服务发现的意义
8.2如何集成EurekaServer
8.3如何集成EurekaClient
8.4实现服务的注册与发现
第9章微服务的消费
9.1微服务的消费模式
9.2常见微服务的消费者
9.3使用Feign实现服务的消费者
9.4实现服务的负载均衡及高可用
第10章API网关
10.1API网关的意义
10.2常见API网关的实现方式
10.3如何集成Zuul
10.4实现API网关
第11章微服务的部署与发布
11.1部署微服务将面临的挑战
11.2持续交付与持续部署微服务
11.3基于容器的部署与发布微服务
11.4使用Docker来构建、运行、发布微服务
第12章微服务的日志与监控
12.1微服务日志管理将面临的挑战
12.2日志集中化的意义
12.3常见日志集中化的实现方式
12.4ElasticStack实现日志集中化
第13章微服务的集中化配置
13.1为什么需要集中化配置
13.2使用Config实现的配置中心
第14章微服务的高级主题——自动扩展
14.1自动扩展的定义
14.2自动扩展的意义
14.3自动扩展的常见模式
14.4如何实现微服务的自动扩展
第15章微服务的高级主题——熔断机制
15.1什么是服务的熔断机制
15.2熔断的意义
15.3熔断与降级的区别
15.4如何集成Hystrix
15.5实现微服务的熔断机制
第16章微服务的高级主题——分布式消息总线
16.1消息总线的定义
16.2SpringCloudBus设计原理
16.3如何集成Bus
16.4实现配置信息的自动更新
附录A：《Spring Cloud 微服务架构开发实战（全新升级版）》所涉及的技术及相关版本
参考文献
精彩书摘
1.2常见分布式系统架构
复杂的大型软件系统，倾向于使用分布式系统架构。就像WarrenBuffett有个关于投资的名言，就是“不要把鸡蛋放在一个篮子里”。对于系统而言也是如此。厂商的机器不可能保证永远不坏，也无法保证黑客不会来对系统搞破坏，最为关键的是，我们无法保证自己的程序不会出现Bug。问题无法避免，错误也不可避免。我们只能把鸡蛋分散到不同的篮子里，来减少“一锅端”的风险。这就是需要分布式系统的一个重要原因。使用分布式系统的另外一个理由是可扩展性。毕竟任何主机（哪怕是小型机、超级计算机）都会有性能的极限。而分布式系统可以通过不断扩张主机的数量以实现横向水平性能的扩展。本章将会介绍市面上常见的分布式系统架构，并对这些架构做优缺点的比较。本章大部分内容源自笔者的另一《Spring Cloud 微服务架构开发实战（全新升级版）》《分布式系统常用技术及案例分析》1，有兴趣的读者也可以作为参考。
1.2.1分布式对象体系
在基于对象的分布式系统中，对象的概念在分布式实现中起着极其关键的作用。从原理上来讲，所有的一切都被作为对象抽象出来，而客户端将以调用对象的方式来获得服务和资源。分布式对象之所以成为重要的范型，是因为它相对比较容易地把分布的特性隐藏在对象接口后面。此外，因为对象实际上可以是任何事务，所以它也是构建系统的强大范型。面向对象技术于20世纪80年代开始用于开发分布式系统。同样，在达到高度分布式透明性的同时，通过远程服务器宿主独立对象的理念构成了开发新一代分布式系统的稳固的基础。在分布式对象体系架构中，比较有代表性的技术有DCOM、CORBA及RMI。
1.DCOM（COM+）
1992年4月，微软发布Windows3.1，包括一种被称为OLE（ObjectLinkingandEmbedding）的机制。这允许一个程序动态链接其他库来支持其他功能，如将一个电子表格嵌入Word文档。OLE演变成了COM（ComponentObjectModel）。一个COM对象是一个二进制文件。使用COM服务的程序来访问标准化接口的COM对象，而不是其内部结构。COM对象用全局唯一标识符（GUID）来命名，用类的ID来识别对象的类。可以有多种方法来创建一个COM对象，如CoGetInstance-FromFile。COM库在系统注册表中查找相应的二进制代码（一个DLL或可执行文件）来创建对象，并给调用者返回一个接口指针。COM的着眼点是在同一台计算机上不同应用程序之间的通信需求。
DCOM（DistributedComponentObjectModel）是COM的扩展，它支持不同的两台机器上组件间的通信，而且无论它们是运行在局域网、广域网，还是Internet上。借助DCOM的应用程序将能够进行任意空间分布。DCOM于1996年在WindowsNT4.0中引入，后来更名为COM+。由于DCOM是为了支持访问远程COM对象，需要创建一个对象的过程，此时需要提供服务器的网络名及类ID。微软提供了一些机制来实现这一点。最透明的方式是远程计算机的名称固定在注册表（或DCOM类存储）里，与特定类ID相关联。采用这种方式之后，应用程序便不知道它正在访问一个远程对象，并且可以使用与访问本地COM对象相同的接口指针。另外，应用程序也可指定一个机器名作为参数。
由于DCOM是COM这个组件技术的无缝升级，所以能够从现有的有关COM的知识中获益，以前在COM中开发的应用程序、组件、工具都可以移入分布式的环境中。DCOM将屏蔽底层网络协议的细节，你只需要集中精力于应用。
DCOM最大的缺点是，这是微软独家的解决办法，但在跨防火墙方面的工作做得不是很好（大多数RPC系统也有类似的问题），因为防火墙必须允许某些端口来让ORPC和DCOM通过。
