柳伟卫（英文名Way Lau），关注编程、系统架构、性能优化。在大型IT公司担任过项目经理、架构师、高级开发顾问等职位，具有多年软件开发管理及系统架构经验。负责过多个省级、国家大型分布式系统的设计与研发，参与了多个大型项目的微服务架构的技术改造，在实际工作中积累了大量的微服务架构经验。是CSDN、开源中国、云栖社区等技术社区专家。已出版专著《 Spring Boot企业级应用开发实战》。

　　众所周知，Spring Cloud 是开发微服务架构系统的利器，企业对 Spring Cloud 方面的开发需求也非常旺盛。然而，虽然市面上介绍 Spring Cloud 的概念及基础入门的书籍较多，但这些书籍中的案例往往只是停留在简单的“Hello World”级别，缺乏可真正用于实战落地的指导。
　　本书与其他书籍不同，特色是真正从实战角度出发，运用 Spring Cloud 技术来构建一个完整的微服务架构的系统。本书全面介绍 Spring Cloud 的概念、产生的背景，以及围绕 Spring Cloud 在开发微服务架构系统过程中所面临的问题时应当考虑的设计原则和解决方案。特别是在设计微服务架构系统时所面临的系统分层、服务测试、服务拆分、服务通信、服务注册、服务发现、服务消费、集中配置、日志管理、容器部署、安全防护、自动扩展等方面，给出了作者自己独特的见解。本书不仅介绍了微服务架构系统的原理、基础理论，还以一个真实的天气预报系统实例为主线，集成市面上主流的新的实现技术框架，手把手地教读者如何来应用这些技术，创建一个完整的微服务架构系统。这样读者可以理论联系实践，从而让 Spring Cloud 真正地落地。
　　此外，本书不仅可以令读者了解微服务架构系统开发的完整流程，而且通过实战结合技术点的归纳，令读者知其然且知其所以然。本书所涉及的技术符合当前主流，并富有一定的前瞻性，可以有效提高读者在市场中的核心竞争力。
　　本书主要面向以 Spring 为核心的 Java EE 开发者，以及对 Spring Cloud 和微服务开发感兴趣的读者。

1.2 常见分布式系统架构
复杂的大型软件系统，倾向于使用分布式系统架构。就像 Warren Buffett 有个关于投资的名言，就是“不要把鸡蛋放在一个篮子里”。对于系统而言也是如此。厂商的机器不可能保证永远不坏，也无法保证黑客不会来对系统搞破坏，最为关键的是，我们无法保证自己的程序不会出现Bug。问题无法避免，错误也不可避免。我们只能把鸡蛋分散到不同的篮子里，来减少“一锅端”的风险。这就是需要分布式系统的一个重要原因。使用分布式系统的另外一个理由是可扩展性。毕竟任何主机（哪怕是小型机、超级计算机）都会有性能的极限。而分布式系统可以通过不断扩张主机的数量以实现横向水平性能的扩展。本章将会介绍市面上常见的分布式系统架构，并对这些架构做优缺点的比较。本章大部分内容源自笔者的另一本书《分布式系统常用技术及案例分析》1，有兴趣的读者也可以作为参考。
1.2.1 分布式对象体系
在基于对象的分布式系统中，对象的概念在分布式实现中起着极其关键的作用。从原理上来讲，所有的一切都被作为对象抽象出来，而客户端将以调用对象的方式来获得服务和资源。分布式对象之所以成为重要的范型，是因为它相对比较容易地把分布的特性隐藏在对象接口后面。此外，因为对象实际上可以是任何事务，所以它也是构建系统的强大范型。面向对象技术于20 世纪80 年代开始用于开发分布式系统。同样，在达到高度分布式透明性的同时，通过远程服务器宿主独立对象的理念构成了开发新一代分布式系统的稳固的基础。在分布式对象体系架构中，比较有代表性的技术有 DCOM、CORBA 及 RMI。
1. DCOM（COM+）
1992 年4 月，微软发布 Windows 3.1 ，包括一种被称为 OLE（Object Linking and Embedding）的机制。这允许一个程序动态链接其他库来支持其他功能，如将一个电子表格嵌入 Word 文档。OLE演变成了 COM （Component Object Model）。一个 COM 对象是一个二进制文件。使用 COM 服务的程序来访问标准化接口的 COM 对象，而不是其内部结构。COM 对象用全局唯一标识符（GUID）来命名，用类的 ID 来识别对象的类。可以有多种方法来创建一个 COM 对象，如 CoGetInstance-FromFile。COM 库在系统注册表中查找相应的二进制代码（一个 DLL 或可执行文件）来创建对象，并给调用者返回一个接口指针。COM 的着眼点是在同一台计算机上不同应用程序之间的通信需求。
DCOM（Distributed Component Object Model）是 COM 的扩展，它支持不同的两台机器上组件间的通信，而且无论它们是运行在局域网、广域网，还是 Internet 上。借助 DCOM 的应用程序将能够进行任意空间分布。DCOM 于1996 年在 Windows NT 4.0 中引入，后来更名为 COM+。由于DCOM 是为了支持访问远程 COM 对象，需要创建一个对象的过程，此时需要提供服务器的网络名及类 ID。微软提供了一些机制来实现这一点。最透明的方式是远程计算机的名称固定在注册表（或DCOM 类存储）里，与特定类 ID 相关联。采用这种方式之后，应用程序便不知道它正在访问一个远程对象，并且可以使用与访问本地 COM 对象相同的接口指针。另外，应用程序也可指定一个机器名作为参数。
由于 DCOM 是 COM 这个组件技术的无缝升级，所以能够从现有的有关 COM 的知识中获益，以前在 COM 中开发的应用程序、组件、工具都可以移入分布式的环境中。DCOM 将屏蔽底层网络协议的细节，你只需要集中精力于应用。
DCOM 最大的缺点是，这是微软独家的解决办法，但在跨防火墙方面的工作做得不是很好（大多数RPC 系统也有类似的问题），因为防火墙必须允许某些端口来让 ORPC 和 DCOM 通过。

目录
第1章 微服务概述
1.1 传统软件行业面临的挑战
1.2 常见分布式系统架构
1.3 单块架构如何进化为微服务架构
1.4 微服务架构的设计原则
1.5 如何设计微服务系统
第2章 微服务的基石——Spring Boot
2.1 Spring Boot简介
2.2 开启第一个Spring Boot项目
2.3 Hello World
2.4 如何搭建开发环境
2.5 Gradle与Maven的抉择
第3章 Spring Boot 的高级主题
3.1 构建RESTful服务
3.2 Spring Boot的配置详解
3.3 内嵌Servlet容器
3.4 实现安全机制
3.5 允许跨域访问
3.6 消息通信
3.7 数据持久化
3.8 实现热插拔
第4章 微服务的测试
4.1 测试概述
4.2 测试的类型和范围
4.3 如何进行微服务的测试
第5章 微服务的协调者——Spring Cloud
5.1 Spring Cloud简介
5.2 Spring Cloud入门配置
5.3 Spring Cloud的子项目介绍
第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 如何集成Eureka Server
8.3 如何集成Eureka Client
8.4 实现服务的注册与发现
第9章 微服务的消费
9.1 微服务的消费模式
9.2 常见微服务的消费者
9.3 使用Feign实现服务的消费者
9.4 实现服务的负载均衡及高可用
第10章 API 网关
10.1 API网关的意义
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.4 Elastic Stack实现日志集中化
第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.2 Spring Cloud Bus设计原理
16.3 如何集成Bus
16.4 实现配置信息的自动更新

附录A：本书所涉及的技术及相关版本
参考文献