电子书：《微服务架构实战基于springbootspringclouddocker》《微服务架构实战基于springbootspringclouddocker》郑天民0181201
111
内容简介：
2@微服务架构实战—基于 spring boot、 spring cloud、 docker422使用 discovery client查找服务7262.1构建zuu服.务.器42.3通过 resttemplate调用服务74.2.2配置zu服务路由4.3 ribbon43.1 ribbon核心机制63.1 zuulfilter组件架构3.2 ribbon负载均衡策略8四86.3.2使用zu过滤器43.3@ loadbalanced注解与64本章小结82第7章 spring cloud config434@ ribbon client注解与自定义与配置中心负载均衡策略837.1分布式配置中心方案44本章小结分布式配置模型第5章 spring cloud7.1.2配置中心实现工具hystrⅸ与服务容错7.2构建配置中心服.务.器5.1服务消费者容错思想和模式721引人 spring cloud config5.1.1服务消费者容错的需求722实现基于本地文件系统的51.2服务隔离13服务熔断72.3实现基于git的配置方案1395.14服务回退52使用 hystriⅸx实现服务容错7.3.1访问配置项7.3.2配置数据.安.全.性522使用 hystrix实现服务隔离9374 spring cloud config特性523使用 hystrix实现服务熔断9674.1 spring cloud config对比524使用 hystrix实现服务回退99zookeeper53 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 zuul81.1基本事件驱动架构与实现与ap|网关机制6.1服务网关的设计理念8.12事件驱动与领域模型61.1服务网关的作用82引人 spring cloud stream612服务网关的结构和功能12821 spring cloud stream基本6.2使用zul构建服务网关
8.2.2 spring cloud stream spring10.2.1 zipkin基本结构integration82.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与端到端测试服务.安.全.112测试 spring boot应用程序9.1服务访问.安.全.性与 oauth协议178112.1初始化测试环境9.1.1微服务架构中的.安.全.性设计179112.2执行单元测试.2 oauth协议113使用mock和注解实施集成92构建 oauth认证服.务.器测试921引人 spring cloud security185113.1使用@ bjsontest注解测试922初始化用户与客.户.端json数据923生成 token113.2使用@ matapa test注解测试9.3使用oauh保护服务访问层931集成oauh认证服务195113.3使用mock测试 service层2489.3.2创建服务访问策略1134使用mock和@ webmyc test93.3使用 oauth2 rest’template注解测试 controller层传播 toker114消费者驱94本章小结114.1向契约的端对端测试第10章 spring cloud sleuth与114.2实现面向契约的端对端服务监控01服务监控与 spring cloud sleuth207115本章小10..1服务监控基本原理207第12章 docker与服务部署10.12引人 spring cloud sleuth2092.1 docker与微服务架构102整合 spring cloud sleuth与12.1.1 docker的优势zipkin12..2 docker组件与命令268
4@微服务架构实战—基于 spring boot、 spring cloud、 docker12.2使用 dockerfile构建服务镜像272123.1 docker compose组件与12.2.1 dockerfile命令命令22.2使用 dockerfile命令构建123.2使用 docker compose123.3 docker compose案例分析281123使用 docker compose编排24本章小结276参考文献
第1章微服务架构设计近年来.微服务架构( microsarchitecture)已经成为一种主流的软件开发方法论.它把一种特定的软件应用设计方法描述为能够独立部署的服务套件。所谓微服务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前端团队和服.务.器端团队而展开.这些团队也就是通常所说的职能团队( functionteam)。当使用这种模式对团队进行划分时.任何一个需求变更.无论大小.都将导致跨团队协作.从而增加构通和协作成本。而微服务架构下的划分方法则有所不同.它倾向于围绕业务功能的组织来分割服务。这些服务面向的是具体业务结构.而不是面向某项技术能力。因此团队是跨职能的( cross– functional)特征团队( feature team).包含用户体验、项目管理和技术研发等开发过程所要求的所有技能。每个服务都围绕着业务进行构建.并且能够被独立地部署到生产或类生产环境(3)去中心化服务集中治理的一种好处是在单一平台上进行标准化.而采用微服务的团队更喜欢不同的标准。把集中式系统中的组件拆分成不同的服务.我们在构建这些服务时就会有更多的选择
