Spring Cloud微服务架构开发实战 - (EPUB全文下载)

文件大小：0.48 mb。
文件格式：epub 格式。
书籍内容：

Spring Cloud微服务架构开发实战
第1篇 微服务开发基础——Spring Boot框架及使用
第1章 微服务架构开发
1.1 单体架构应用的困境
1.2 微服务架构
1.3 微服务架构设计
1.4 不应使用微服务架构的情形
第2章 微服务基础——Spring Boot
2.1 Spring与Spring Boot
2.2 快速启动Spring Boot
2.3 使用Spring Boot构建示例项目
2.4 Spring Boot特性
2.5 关于敏捷开发
2.6 关于RESTful API设计
第2篇 Spring Cloud组件实战
第3章 Spring Cloud简介
3.1 微服务架构的核心关键点
3.2 Spring Cloud技术概览
3.3 Spring Cloud版Hello World示例
第4章 服务治理与负载均衡
4.1 什么是服务治理
4.2 构建服务治理——Eureka
4.3 使用客户端负载均衡——Ribbon
4.4 使用Feign简化微服务调用
4.5 深入Eureka
4.6 深入Ribbon
4.7 深入Feign
4.8 微服务健康监控
4.9 异构服务解决方案——Sidecar
第5章 微服务容错保护——Hystrix
5.1 什么是微服务容错保护
5.2 快速启动Hystrix
5.3 Hystrix容错机制分析
5.4 服务隔离
5.5 服务降级模式
5.6 请求缓存
5.7 请求合并
5.8 Hystrix监控
第6章 API服务网关——Zuul
6.1 API服务网关
6.2 Spring Cloud与Netflix Zuul
6.3 启用Zuul路由服务
6.4 路由配置规则
6.5 Zuul路由其他设置
6.6 Zuul容错与回退
6.7 Zuul过滤器
6.8 @EnableZuulServer与@EnableZuulProxy比较
第7章 统一配置中心——Config
7.1 Spring Cloud Config简介
7.2 快速启动
7.3 配置资源库
7.4 配置的加密与解密
7.5 配置服务器访问安全
7.6 配置服务器的高可用
第8章 分布式服务跟踪——Sleuth
8.1 Spring Cloud Sleuth简介
8.2 Sleuth与ELK整合
8.3 整合Zipkin服务
8.4 Sleuth抽样采集与采样率
第9章 消息驱动——Stream
9.1 什么是消息驱动开发
9.2 Spring Cloud Stream简介
9.3 Kafka使用指南
9.4 使用消息对应用重构
9.5 Spring Cloud Stream高级主题
9.6 消息总线——Spring Cloud Bus
第10章 微服务应用安全——Security
10.1 Spring Boot的应用安全
10.2 微服务安全
10.3 基于OAuth 2.0的认证
10.4 基于JWT的认证
第3篇 微服务与Docker容器技术
第11章 微服务与Docker
11.1 Docker简介
11.2 Docker的使用
11.3 Docker与Spring Cloud微服务
11.4 微服务与Jenkins
11.5 微服务编排
第1篇　微服务开发基础——Spring Boot框架及使用
第1章　微服务架构开发
第2章　微服务基础——Spring Boot
第1章　微服务架构开发
从软件开发诞生之初，业界一直致力于寻找大型分布式应用系统开发的“银弹”，从结构化编程、面向对象，到COBRA、EJB、ESB、SOA等。Fred Brooks在《没有银弹：软件工程的本质性与附属性工作》一文中提出：大型分布式系统具有复杂性、隐匿性、配合性和易变性四大难题，不会存在任何单一软件工程上的突破，能够让开发生产力得到一个数量级上的提升。而微服务的出现虽然不是一颗“银弹”，但是它给出了四大难题的对策，解决了以往单体架构系统构建的困境。
1.1　单体架构应用的困境
在Java开发中，一个典型的单体架构应用就是将一个应用中所有的功能都打包在一个WAR文件中，并部署在应用服务器（如Tomcat）中运行，如图1-1所示。
图1-1　典型单体架构应用结构图
对于单体架构应用来说，随着业务的扩张，其开发、部署和运维都会越来越慢，越来越复杂，甚至在单体架构应用开发中敏捷模式都无法施展开。这是因为，在单体架构应用中，一个应用中承载的职责太多，其开发、部署和运维复杂度在后期几乎会呈几何性增长，应用的每次编译和启动都需要更长的时间，每次需要修改、增加新的功能时都需要更多的协调和测试。而对于新增的功能，每次修正Bug都会使系统的代码更加复杂，使开发-编译-启动-测试进入了一种恶性循环，大大降低了开发效率。
单体架构应用会逐渐变得不稳定，一方面是系统不断增长的复杂性造成的，另一方面是由于系统本身牵一发而动全身的特性造成的，可能一不注意，不常用的模块因为存在内存泄漏而造成整个服务无法正常提供服务，甚至引起服务崩溃。
在数据管理上单体架构应用容易产生漏洞，最常见的就是数据管理。单体架构应用往往要管理的数据类型／表都非常多，而且分布在不同团队之间，如果沟通不好可能某些团队的开发会直接操纵数据库表，最常见的方式就是在数据层通过写SQL语句操纵数据库表。这种做法相当于埋下不定时炸弹。当数据相关团队修改了数据库结构，由于之前的团队之间使用SQL语句进行处理，在系统编译、打包和测试时都有可能通过，但当在真实的生产环境使用时就有可能造成服务的崩溃。
单体架构的应用在开发时要求我们必须使用同一个技术栈，使得单体架构的应用很难接受或切换到其他框架、语言。因为重写一个应用的风险实在太大，即使有更合适的应用开发框架或语言，甚至应用所使用的框架有了新的版本，也很难进行升级。因此，开发者会发现因为这个限制很多应用还在使用着非常古老的技术和框架。
单体架构应用开发对于开发者来说，需要了解更多的东西，如系统架构、统一的开发模式、与 ............

以上为书籍内容预览，如需阅读全文内容请下载EPUB源文件，祝您阅读愉快。