多种网盘链接检测插件 购买前，请先检测网盘链接是否有效
《微服务架构实战基于SpringBootSpringCloudDocker》_郑天民_018-12-01_1
《微服务架构实战基于SpringBootSpringCloudDocker》_郑天民_018-12-01_2
《微服务架构实战基于SpringBootSpringCloudDocker》_郑天民_018-12-01_3
内容简介：
2@微服务架构实战—基于 Spring Boot、 Spring Cloud、 Docker
422使用 Discovery Client查找服务72
62.1构建Zuu服.务.器
42.3通过 RestTemplate调用服务74
.2.2配置Zu服务路由
4.3 Ribbon
43.1 Ribbon核心机制
63.1 ZuulFilter组件架构
3.2 Ribbon负载均衡策略
8四8
6.3,2使用Zu过滤器
43.3@ LoadBalanced注解与
64本章小结
82第7章 Spring Cloud Config
434@ Ribbon Client注解与自定义
与配置中心
负载均衡策略
83
7.1分布式配置中心方案
44本章小结
分布式配置模型
第5章 Spring Cloud
7.1.2配置中心实现工具
Hystrⅸ与服务容错
7.2构建配置中心服.务.器
5.1服务消费者容错思想和模式
721引人 Spring Cloud Config
5.1.1服务消费者容错的需求
722实现基于本地文件系统的
51.2服务隔离
13服务熔断
72.3实现基于Git的配置方案139
5.14服务回退
52使用 Hystriⅸx实现服务容错
7.3.1访问配置项
7.3.2配置数据.An.全.性
522使用 Hystrix实现服务隔离9374 Spring Cloud Config特性
523使用 Hystrix实现服务熔断96
74.1 Spring Cloud Config对比
524使用 Hystrix实现服务回退99
Zookeeper
53 Hystrix基本原理
742 Spring Cloud Config高可用149
务隔离
7.5本章小结
3.2服务熔断
03第8章 Spring Cloud Stream与
53,3 Hystrix配置项
事件驱动
54本章小结
8.1事件驱动架构与模
62 Spring Cloud Netflix Zuul
81.1基本事件驱动架构与实现
与AP|网关
机制
6.1服务网关的设计理念
8.12事件驱动与领域模型
61.1服务网关的作用
82引人 Spring Cloud Stream
612服务网关的结构和功能12
821 Spring Cloud Stream基本
6.2使用Zul构建服务网关
8.2.2 Spring Cloud Stream Spring
10.2.1 Zipkin基本结构
Integration
82.3 Spring Cloud Stream与消息
10.2.3使用 Zipkin跟踪服务调用
中间件
83实现消息发布者
10.24使用 Zipkin实现自定义
831消息发送场景与实现流程
8.32在服务中添加消息发布者
.3本章小结
84实现消息消费者
Spring Test与服务测试
84.1消息消费场景与实现流程
111微服务测试的方法
4.2在服务中添加消息消费者
111.1单元测试
本章小结
第9章 Spring Cloud Security与
端到端测试
服务.An.全.
112测试 Spring Boot应用程序
9.1服务访问.An.全.性与 OAuth协议178
112.1初始化测试环境
9.1.1微服务架构中的.An.全.性设计179
112.2执行单元测试
.2 OAuth协议
113使用Mock和注解实施集成
92构建 OAuth认证服.务.器
测试
921引人 Spring Cloud Security185
113.1使用@ BJsonTest注解测试
922初始化用户与客.户.端
JSON数据
923生成 Token
113.2使用@ MataPa Test注解测试
9.3使用OAuh保护服务访问
层
931集成OAuh认证服务195
113.3使用Mock测试 Service层248
9.3.2创建服务访问策略
1134使用Mock和@ WebMyc Test
93,3使用 OAuth2 Rest'Template
注解测试 Controller层
传播 Toker
114消费者驱
94本章小结
114.1向契约的端对端测试
第10章 Spring Cloud Sleuth与
114.2实现面向契约的端对端
服务监控
01服务监控与 Spring Cloud Sleuth207
115本章小
10..1服务监控基本原理
207第12章 Docker与服务部署
10.12引人 Spring Cloud Sleuth209
2.1 Docker与微服务架构
102整合 Spring Cloud Sleuth与
12.1.1 Docker的优势
Zipkin
12..2 Docker组件与命令
268
4@微服务架构实战—基于 Spring Boot、 Spring Cloud、 Docker
12.2使用 Dockerfile构建服务镜像272
123.1 Docker Compose组件与
12.2.1 Dockerfile命令
命令
22.2使用 Dockerfile命令构建
123.2使用 Docker Compose
123.3 Docker Compose案例分析281
123使用 Docker Compose编排
24本章小结
276参考文献
第1章
微服务架构设计
近年来,微服务架构( Micros
Architecture)已经成为一种主流的软件开发方法
论,它把一种特定的软件应用设计方法描述为能够独立部署的服务套件。所谓微服务
Microservices),就是一些具有足够小的粒度、能够相互协作且自治的服务体系。每个微服务
注于完成一个功能并能很好地完成该功能,而这里的功能代表的是一种业务
能力。构建微服务体系需要一套完整的方法论和工程实践,而微服务架构的提出代表的就是实
现微服务体系的架构模式,即为我们提供了这些方法论和工程实践。从这个角度讲,微服务架
构需要我们理解、学习并应用到ri常开发过程中去
微服务架构基于分布式系统,同时借助了面向服务架构和企业服务总线的设计理念并做了
另一方面也在技术架构和研发过程中存在巨大挑战。微服务架构的实施需要具备一定的前提,
而构建微服务架构是一项系统工程,涉及服务建模、实现技术、基础设施和硏发过程等各个维
在实施过程中,也需要根据现有系统的具体情况采用合适的实施模
本章作为全书的开篇,对微服务设计原理与架构做了全面介绍。本书的关注点是微服务架
构的实现技术,本章也会梳理目前市面上主流的微服务技术体系并完成技术选型。在本章的最
后,我们还会给出全书的组织架构
11直面微服务架构
顾名思义,微服务区别与其他服务体系的关键在于它的“微”特性。“微”是小的同义词
所以容易让人联想到微服务都是小型的服务,这是微服务的第一个特性。微服务之间只有通过
相互的协作和交互才能构成完整的服务体系,而这种协作和交互机制也是微服务区别其他服务
体系的另一个主要方面
11.1分布式系统与微服务架构
所谓分布式系统( Distributed System)是指硬件或软件组件分布在不同的网络计算机上,
2@微服务架构实战——基于 Spring Boot、 Spring Cloud、 Docker
彼此之间仅仅通过消息传递进行通信和协调的系统。从这个定义中可以看出,分布式系统包含
两个区别于单块系统( Monolith System)的本质性特征:一个是网络,分布式系统的所有组
件都位于网络之中,对于互联网应用而言,则位于更为复杂的互联网环境中;另一个是通信和
协调,与单块系统不同,位于分布式系统中的各个组件只有通过约定、高效且可靠的通信机制
进行相关协作,才能完成某一项业务功能。这些特征是我们在设计和实现分布式系统时首先需
要考虑
分布式系统相较于单块系统在具备一定优势的同时,也存在一些我们不得不考虑的特性
包括但不限于网络传输的三态性、系统之间的异构性、数据一致性、服务的可用性等。以上问
题是分布式系统的基本特性,我们无法避免,只能想办法进行利用和管理,这就给我们设计和
实现分布式系统提出了挑战。微服务架构本质上也是一种分布式系统,但在遵循通用分布式特
性的基础上,微服务架构还表现出一定的特殊特性。下面将围绕微服务架构的这些特殊特性展
Martin fowler指出,微服务架构具有以下特点
所谓组件( Component)是一种可独立替换和升级的软件单元。在我们ri常开发过程中
能会设计和使用很多组件,这些组件可能服务于系统内部,也可能存在于系统所运行的_进.程_
之外。而服务就是一种_进.程_外组件,服务之间利用诸如.R.P.C.( Remote Procedur
过程调用)等通信机制完成交互。服务组件化的主要目的是服务可以独立部署。如果某个应用
程序是由一个运行在独立_进.程_中的很多组件组成,那么对任何一个组件的改变都将导致整个应
用程序必须重新部署。但是如果把应用程序拆分成很多服务,通常情况下,只需要重新部署那
个改变的服务即可。在微服务架构中,每个服务运行在其独立的_进.程_中,服务与服务之间采用
轻量级通信机制互相沟通。
(2)按业务能力组织服务
在寻找把一个大的应用程序进行拆分的方法时,研发过程一般都会围绕产品团队、UED团
队、APP前端团队和服.务.器端团队而展开,这些团队也就是通常所说的职能团队( Function
Team)。当使用这种模式对团队进行划分时,任何一个需求变更,无论大小,都将导致跨团队
协作,从而增加构通和协作成本。而微服务架构下的划分方法则有所不同,它倾向于围绕业务
功能的组织来分割服务。这些服务面向的是具体业务结构,而不是面向某项技术能力。因此
团队是跨职能的( Cross-- Functional)特征团队( Feature Team),包含用户体验、项目管理
和技术研发等开发过程所要求的所有技能。每个服务都围绕着业务进行构建,并且能够被独立
地部署到生产或类生产环境
(3)去中心化
服务集中治理的一种好处是在单一平台上进行标准化,而采用微服务的团队更喜欢不同的
标准。把集中式系统中的组件拆分成不同的服务,我们在构建这些服务时就会有更多的选择
|
|
