SpringBoot揭秘 快速构建微服务体系pdf

SpringBoot揭秘 快速构建微服务体系 作者：王福强

SpringBoot揭秘 快速构建微服务体系 出版社：机械工业出版社

SpringBoot揭秘 快速构建微服务体系 内容简介

本书以微服务的基本概念介绍性开篇， 逐步引出Java平台下打造微服务的利器SpringBoot微框架， 从SpringBoot微框架的出身和源头， 循序渐进，一步步为大家剖析了SpringBoot微框架的设计理念和原理，并对框架的重点功能和模块进行了逐一讲解。

“框架，体系，生态”， 三者循序渐进，相辅相成，本书*精彩的部分在于， 在大家对SpringBoot微框架已经有了基本的认识之后， 我们将一起探索如何基于SpringBoot微框架打造一套完备的微服务体系。

SpringBoot微框架依托Java平台和Spring框架，拥有良好的可扩展性和可定制性，为了说明这一点，我们单独开辟了一章内容，为大家介绍如何使用Scala和SpringBoot微框架来开发和交付相应的微服务，并且围绕着Scala和SpringBoot如何打造相应的工具， 技术产品等支持来提高相应微服务的交付效率。

SpringBoot揭秘 快速构建微服务体系 目录

序言

前言

第1章 了解微服务

1.1 什么是微服务

1.2 微服务因何而生

1.3 微服务会带来哪些好处

1.4 微服务会带来哪些挑战

1.5 本章小结

第2章 饮水思源：回顾与探索Spring框架的本质

2.1 Spring框架的起源

2.2 Spring IoC其实很简单

2.3 了解一点儿JavaConfig

2.4 本章小结

第3章 SpringBoot的工作机制

3.1 SpringBoot初体验

3.2 @SpringBootApplication背后的秘密

3.3 SpringApplication：SpringBoot程序启动的一站式解决方案

3.4 再谈自动配置

3.5 本章小结

第4章 了解纷杂的spring-boot-starter

4.1 应用日志和spring-boot-starter-logging

4.2 快速Web应用开发与spring-boot-starter-web

4.3 数据访问与spring-boot-starter-jdbc

4.4 spring-boot-starter-aop及其使用场景说明

4.5 应用安全与spring-boot-starter-security

4.6 应用监控与spring-boot-starter-actuator

4.7 本章小结

第5章 SpringBoot微服务实践探索

5.1 使用SpringBoot构建微服务

5.2 SpringBoot微服务的发布与部署

5.3 SpringBoot微服务的注册与发现

5.4 SpringBoot微服务的监控与运维

5.5 SpringBoot微服务的安全与防护

5.6 SpringBoot微服务体系的脊梁：发布与部署平台

5.7 本章小结

第6章 SpringBoot与Scala

6.1 使用Maven构建和发布基于SpringBoot的Scala应用

6.2 使用SBT构建和发布基于SpringBoot的Scala应用

6.3 本章小结

第7章 SpringBoot总结与展望

SpringBoot揭秘 快速构建微服务体系 精彩文摘

SpringBoot是一个可使用Java构建微服务的微框架，所以在了解SpringBoot之前，我们需要先了解什么是微服务。

微服务（Microservice）虽然是当下刚兴起的比较流行的新名词，但本质上来说，微服务并非什么新的概念。实际上，很多SOA实施成熟度比较好的企业，已经在使用和实施微服务了。只不过，它们只是在闷声发大财，并不介意是否有一个比较时髦的名词来明确表述SOA的这个发展演化趋势罢了。

微服务其实就是服务化思路的一种最佳实践方向，遵循SOA的思路，各个企业在服务化治理的道路上走的时间长了，踩的坑多了，整个软件交付链路上各个环节的基础设施逐渐成熟了，微服务自然而然就诞生了。

当然，之所以叫微服务，是与之前的服务化思路和实践相比较而来的。早些年的服务实现和实施思路是将很多功能从开发到交付都打包成一个很大的服务单元（一般称为Monolith），而微服务实现和实施思路则更强调功能趋向单一，服务单元小型化和微型化。如果用“茶壶煮饺子”来打比方的话，原来我们是在一个茶壶里煮很多个饺子，现在（微服务化之后）则基本上是在一个茶壶煮一个饺子，而这些饺子就是服务的功能，茶壶则是将这些服务功能打包交付的服务单元，如图1-1所示。

所以，从思路和理念上来讲，微服务就是要倡导大家尽量将功能进行拆分，将服务粒度做小，使之可以独立承担对外服务的职责，沿着这个思路开发和交付的软件服务实体就叫作“微服务”，而围绕着这个思路和理念构建的一系列基础设施和指导思想，笔者将它称为“微服务体系”。

微服务的概念我们应该大体了解了，那么微服务又是怎么来的？原来将很多功能打包为一个很大的服务单元进行交付的做法不能满足需求吗？

实际上，并非原来“大一统”（Monolith）的服务化实践不能满足要求，也不是不好，只是，它有自己存在的合理场景。对于Monolith服务来说，如果团队不大，软件复杂度不高，那么，使用Monolith的形式进行服务化治理是比较合适的，而且，这种方式对运维和各种基础设施的要求也不高。

但是，随着软件系统的复杂度持续飙升，软件交付的效率要求更高，投入的人力以及各项资源越来越多，基于Monolith的服务化思路就开始“捉襟见肘”。

在开发阶段，如果我们遵循Monolith的服务化理念，通常会将所有功能的实现都统一归到一个开发项目下，但随着功能的膨胀，这些功能一定会分发给不同的研发人员进行开发，造成的后果就是，大家在提交代码的时候频繁冲突并需要解决这些冲突，单一的开发项目成为了开发期间所有人的工作瓶颈。

为了减轻这种苦恼，我们自然会将项目按照要开发的功能拆分为不同的项目，从而负责不同功能的研发人员就可以在自己的代码项目上进行开发，从而解决了大家无法在开发阶段并行开发的苦恼。