springboot实战章节小结
第一章小结
Spring Boot为Spring应用程序的开发提供了一种激动人心的新方式,框架本身带来的阻力很小。自动配置消除了传统Spring应用程序里的很多样板配置;Spring Boot起步依赖让你能通过库
所提供的功能而非名称与版本号来指定构建依赖;Spring Boot CLI将Spring Boot的无阻碍开发模型提升到了一个崭新的高度,在命令行里就能简单快速地用Groovy进行开发;Actuator让你能深入运行中的应用程序,了解Spring Boot做了什么,是怎么做的。本章大致概括了Spring Boot的功能。你大概已经跃跃欲试,想用Spring Boot来写个真实的应用程序了吧。这正是我们在下一章里要做的事情。有了Spring Boot提供的诸多功能,最困难的不
过是把书翻到第2章。
第二章小结
通过Spring Boot的起步依赖和自动配置,你可以更加快速、便捷地开发Spring应用程序。起步依赖帮助你专注于应用程序需要的功能类型,而非提供该功能的具体库和版本。与此同时,自动配置把你从样板式的配置中解放了出来。这些配置在没有Spring Boot的Spring应用程序里非常常见。虽然自动配置很方便,但在开发Spring应用程序时其中的一些用法也有点武断。要是你在配置Spring时希望或者需要有所不同,该怎么办?在第3章,我们将会看到如何覆盖Spring Boot自动
配置,借此达成应用程序的一些目标,还有如何运用类似的技术来配置自己的应用程序组件。
第三章小结
Spring Boot消除了Spring应用程序中经常要用到的很多样板式配置。让Spring Boot处理全部配置,你可以仰仗它来配置那些适合你的应用程序的组件。当自动配置无法满足需求时,SpringBoot允许你覆盖并微调它提供的配置。覆盖自动配置其实很简单,就是显式地编写那些没有Spring Boot时你要做的Spring配置。Spring Boot的自动配置被设计为优先使用应用程序提供的配置,然后才轮到自己的自动配置。即使自动配置合适,你仍然需要调整一些细节。Spring Boot会开启多个属性解析器,让你通过环境变量、属性文件、YAML文件等多种方式来设置属性,以此微调配置。这套基于属性的配置模型也能用于应用程序自己定义的组件,可以从外部配置源加载属性并注入到Bean里。Spring Boot还自动配置了一个简单的白标错误页,虽然它比异常跟踪信息友好一点,但在艺术性方面还有很大的提升空间。幸运的是,Spring Boot提供了好几种选项来自定义或完全替换这个白标错误页,以满足应用程序的特定风格。
现在我们已经用Spring Boot写了一个完整的应用程序,我们会验证它能否满足预期。除了自己在浏览器里手工点点之外,我们还应该要写一些自动化、可重复运行的测试来检查这个应用程序,证明它能正确运作。这也是我们在第4章里要做的事。
第四章小结
测试是开发高质量软件的重要一环。没有好的测试,你永远无法保证应用程序能像期望的那样运行。单元测试专注于单一组件或组件中的一个方法,此处并不一定要使用Spring。Spring提供了一些优势和技术——松耦合、依赖注入和接口驱动设计。这些都简化了单元测试的编写。但Spring不用直接涉足单元测试。集成测试会涉及众多组件,这时就需要Spring帮忙了。实际上,如果Spring在运行时负责拼装那些组件,那么Spring在集成测试里同样应该肩负这一职责。
Spring Framework以JUnit类运行器的方式提供了集成测试支持,JUnit类运行器会加载Spring
应用程序上下文,把上下文里的Bean注入测试。Spring Boot在Spring的集成测试之上又增加了配置加载器,以Spring Boot的方式加载应用程序上下文,包括了对外置属性的支持和Spring Boot日志。Spring Boot还支持容器内测试Web应用程序,让你能用和生产环境一样的容器启动应用程序。这样一来,测试在验证应用程序行为的时候,会更加接近真实的运行环境。此时我们已经构建了一个相当完整的应用程序(虽然有点简单),它利用Spring Boot的起步依赖和自动配置来处理低级工作,让我们专心开发应用程序。我们也看到了如何使用Spring Boot的支持来测试应用程序。在后续几章里,我们会看到一些不同的东西,了解让Spring Boot应用程序开发更加简单的Groovy。在第5章,我们会先了解Grails框架的一些特性,看看它们在Spring Boot中的用途。
第五章小结
Spring Boot CLI利用了Spring Boot自动配置和起步依赖的便利之处,并将其发扬光大。借由92 第 5 章 Groovy 与 Spring Boot CLIGroovy语言的优雅,CLI能让我们在最少的代码噪声下开发Spring应用程序。本章中我们彻底重写了第2章里的阅读列表应用程序,只是这次我们用Groovy把它写成了Spring Boot CLI应用程序。通过自动添加很多常用包和类的import语句,CLI让Groovy更优雅。它还可以自动解析很多依赖库。
对于CLI无法自动解析的库,基于CLI的应用程序可以利用Grape的@Grab注解,不用构建说
明也能显式地声明依赖。Spring Boot的CLI扩展了@Grab注解,针对很多常用库依赖,只需声明Module ID就可以了。最后,你还了解了如何用Spring Boot CLI来执行测试和构建可部署产物,这些通常都是由构建系统来负责的。
Spring Boot和Groovy结合得很好,两者的简洁性相辅相成。在第6章,我们还会看到SpringBoot和Groovy是如何协同的——Spring Boot是Grails最新版本的核心。
第六章小结
Grails和Spring Boot都旨在让开发者的生活更简单,大大简化基于Spring的开发模型,因此两者看起来是互相竞争的框架。但在本章中,我们看到了两者如何结合在一起,综合优势。我们了解了如何向典型的Spring Boot应用程序中添加GORM和GSP视图,这两个都是知名的Grails特性。GORM是Spring Boot里一个很受欢迎的特性,能让你直接针对领域模型执行持久化操作,消除了对模型仓库的需求。
随后我们认识了Grails 3,即Grails构建于Spring Boot之上的最新版本。在开发Grails 3应用程序时,你也在使用Spring Boot,可以使用Spring Boot的全部特性,包括自动配置。在本章和第5章里,我们看到了如何结合Groovy和Spring Boot,消除Java语言无法避免的那些代码噪声。在第7章,我们要将关注点从开发Spring Boot应用程序转移到Spring Boot Actuator上,看看它如何帮助我们了解应用程序的运行情况。
第七章小结
想弄清楚运行的应用程序里正在发生什么,这是件很困难的事。Spring Boot的Actuator为你打开了一扇大门,深入Spring Boot应用程序的内部细节。它发布的组件、度量和指标能帮你理解应用程序的运作情况。
在本章,我们先了解了Actuator的Web端点——通过HTTP发布运行时细节信息的REST端点。这些端点的功能包括查看Spring应用程序上下文里所有的Bean、查看自动配置决策、查看SpringMVC映射、查看线程活动、查看应用程序健康信息,还有多种度量、指标和计数器。除了Web端点,Actuator还提供了另外两种获取它所提供信息的途径。远程shell让你能在shell里安全地连上应用程序,发起指令,获得与Actuator端点相同的数据。与此同时,所有的Actuator端点也都发布成了MBean,可以通过JMX客户端进行监控和管理。
随后我们还了解了如何定制Actuator,包括如何通过端点的ID来修改Actuator端点的路径,如何启用和禁用端点,诸如此类。我们还插入了一些定制的度量信息,创建了定制的跟踪信息仓库,替换了默认的内存跟踪仓库。
最后,我们学习了如何保护Actuator的端点,只让经过授权的用户访问它们。接下来,在第8章里,我们将看到如何让应用程序从编码阶段过渡到生产阶段,了解SpringBoot如何协助我们在多种不同的平台上进行部署,包括传统的应用容器和云平台。
第八章小结
Spring Boot应用程序的部署方式有好几种,包括使用传统的应用服务器和云上的PaaS平台。在本章,我们了解了其中的一些部署方式,把阅读列表应用程序以WAR文件的方式部署到Tomcat和云上(Cloud Foundry和Heroku)。Spring Boot应用程序的构建说明经常会配置为生成可执行的JAR文件。我们也看到了如何对构建进行微调,如何编写一个SpringBootServletInitializer实现,生成WAR文件,以便部署到应用服务器上。
随后,我们进一步了解了如何将应用程序部署到Cloud Foundry上。Cloud Foundry非常灵活,能够接受各种形式的Spring Boot应用程序,包括可执行JAR文件、传统WAR文件,甚至还包括原始的Spring Boot CLI Groovy脚本。我们还了解了Cloud Foundry如何自动将内嵌式数据源替换为绑定到应用程序上的数据库服务。虽然Heroku不能像Cloud Foundry那样自动替换数据源的Bean,但在本章最后,我们还是看到了如何通过添加Spring Cloud Foundry库来实现一样的效果。这里使用绑定的数据库服务,而非内嵌式数据库。
在本章,我们还了解了如何在Spring Boot里使用Flyway和Liquibase这样的数据库迁移工具。在初次部署应用程序时,我们通过数据库迁移的方式完成了数据库的初始化,在后续的部署过程中,我们可以按需修改数据库。