整个十六章学完,整个Spring Boot 就算是收官了。但是,即使再来二十六章Spring Boot也不能面面俱到。这十六章总结了Spring Boot 的内功心法,希望通过这十六章以不变应万变。通过这个章节内容,也可以发现Spring Boot 不是一个框架的内容,它着眼于 J2EE 整个解决方案。
一、Sring Boot 入门
Spring Boot来简化Spring应用开发,约定大于配置,去繁从简,just run就能创建一个独立的,产品级别的应用。
首先会对Sring Boot以及为服务相关的概念做一个简介;接下来编写一个Spring Boot的 HelloWord程序;通过分析Hello World 了解Spring Boot的内部原理。
先来说下什么是Spring Boot呢,Spring Boot是Spring团队在2014年的时候,伴随Spring 4.0版本开发出的框架。进入Spring官网,在它的项目列表里面,第一个是Spring IO平台,也就是Spring开发平台;第二个就是Spring Boot,他已经成为spring非常重要的一个项目。
点击Spring Boot进入页面,他的作用呢,帮我们快捷简单的创建一个独立的产品级别的spring应用。
以前要做一个spring应用,比如要做一个三大框架(SSM)的整合。创建一个应用,导一大堆的jar包或者用maven导一大堆的依赖,接下来呢,写一大堆的配置文件,写完以后测试、开发业务逻辑;部署的时候呢,要将项目测试、打war包等等;打包以后,在服务器上部署,还有配置服务器环境;然后把这个项目放上去来运行。
在以前,J2EE的开发,都是一个繁琐的过程,Spring Boot意识到这一点,就来简化Spring应用开发,包括简化整个J2EE的开发。
由于Spring Boot底层就是使用的Spring技术栈 。Spring Boot通过整合Spring整个系列技术栈,来完成和简化企业级开发的。以前如果要面向spring开发,那么spring需要掌握的所有内容,可能都需要清楚,这样太麻烦了。有了Spring Boot,不需要懂得这么多的东西了,Spring Boot自动配置好spring的相关环境,面对有用户来说呢,只是一些少量的配置,基本上零配置。用户从一个非常微小的少量入口,就可以打开整个J2EE开发的企业级大门。
背景:
- J2EE笨重的开发、繁多的配置、低下的开发效率、
- 复杂的部署流程、第三方技术集成难度大。
解决:
- “Spring全家桶”时代。
- Spring Boot → J2EE一站式解决方案
- Spring Cloud → 分布式整体解决方案
优点:
- 快速创建独立运行的Spring项目以及与主流框架集成
以前要创建一个spring应用项目要配置一大堆,导包一大堆挺麻烦的;用来Spring Boot一步就完成了。 - 默认使用嵌入式的Servlet容器,应用无需打成WAR包
它的好处,就是如果来开发一个web应用,无需把这个web应用打成war包,然后放在服务器上;有可能服务器上没有装相应的环境,只有配置了相应的环境才能吧这个war包部署上去。有了Spring Boot,应用开发完,可以直接打成一个jar包,用java jar的命令就可以直接运行 - starters自动依赖与版本控制
starters也称为启动器,自动进行依赖管理和版本管理,如果想要用某一块的功能,会有相应的starters启动器。 - 大量的自动配置,简化开发,也可修改默认值
- 无需配置XML,无代码生成,开箱即用
- 准生产环境的运行时应用监控
- 与云计算的天然集成
缺点:
- Spring Boot最大的一个缺点,入门容易精通难Spring Boot是基于spring框架的一个再封装;如果对整个spring框架不是很了解,那么Spring Boot整个封装机制也不会很了解。
2、微服务
早在2014年的时候,martin fowler(不是微服务的创始人)发表了一篇关于微服务的博客,非常生动形象的介绍了一些微服务的设计思想以及一些理念,然后微服务才慢慢的被人所熟知。 博客地址
微服务:是一种架构风格
一个应用是一组小型服务;可以通过HTTP的方式进行互通;
之前的一种架构:单体应用(simple todevelop、test、deploy、scale)
单体应用:ALL IN ONE(所有的东西都写在一个应用里面);
开发测试简单,不牵扯到各个系统指间的互联互调;部署也简单,想要部署应用,将所有打包成一个war包,然后把这个war放置tomcat服务器上;扩展,当负载不行的时候,把相同的应用复制,放在几个服务器上,服务器都在跑这个应用,负载均衡机制就可以来提高并发能力。
牵一发而动全身,因为一个小小的修改,整个应用都需要重新部署或者重新运行;最大的挑战是日益增长的软件需求,随便一个应用都有可能成为一个大型应用,而大型应用不可能就一个应用;这些应用该多大,该怎么分工合作,这都是问题?
微服务就是打破传统方式,以前将所有的功能单元放在一个应用里边,然后把整个应用部署到服务器上,如果负载不行,通过应用的水平复制扩展,进行访问。
微服务提倡的是,把每一个功能元素独立出来,独立出来可以通过元素的动态组合(比如这个功能元素需要多一点的,在这个服务器多放一点;包括某一些功能在有需要的时候才进行复制),是功能元素级别的复制,没有复制到整个应用。这样的话,一也是节省了整个项目资源;第二个把服务规划起来呢,每一个服务都应该是一个可替换的、可独立升级的软件单元。
每一个功能元素都是一个可独立替换和独立升级的软件单元。
服务到底有多微,要怎么规划他们
martin fowler 文章中也有谈及,与 SOA 进行了一些对比。整篇文字从微服务的起源介绍一直到 SOA 的整个对比(以及与其他方式的一些对比),包括服务要规划成什么样子;都有提及。
服务规划一直是业内有争论的一个问题。
微服务最终架构起来的应用应该像这个样子
Microservices 之间的组建该怎么工作呢?
将每一个功能单元都独立出来,独立出来以后,单元跟单元之间的互调通过HTTP的方式互联互调(轻量级通信),整个功能单元不断的规划,就形成了整个应用网。
如果是这样大的一张功能单元连接网,那后来可能会有些问题。部署和运维是相当不容易的,这其实就是一个大型的分布式应用。更重要的是,每一个功能单元都是一个完整的。
每个功能单元,都让我们去规划,创建这么些项目,规划这些服务的时候,每一个项目可能都是要整合各种场景,按照以前的方式构建应用,那这么多模块,创建项目、搭建环境可能一个月都做不完。
那怎么办呢?
Spring Boot 官网有一个经典的图
面对这么大型分布式的应用,怎么样构建出一个应用。用Spring Boot 可以快速的帮我们来构建一个应用;然后整个应用这么大型的分布式 网之间应该怎么互调呢,用Spring Cloud,进行网状互联互调,把整个应用分布式做出来。包括在分布式之间,要进行一些流式数据计算、批处理,使用Spring Cloud Data Flow。Spring 官方为我们想清楚了应用的整个出路,从开始构建,到大型分布式应用;包括在Spring Cloud里边也有一些应用架构都考虑好了。
用Spring Boot可以快速的构建一个微服务单元。