Spring Boot 核心技术（一）

整个十六章学完，整个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，无代码生成，开箱即用
• 准生产环境的运行时应用监控
• 与云计算的天然集成

缺点：

1. 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可以快速的构建一个微服务单元。