SpringBoot-SpringBoot概述及入门

一、微服务（Microservices）

1.1 什么是微服务

早些年的服务实现和实施思路是将很多功能从开发到交付都打包成一个很大的服务单元（一般称为 Monolith），而微服务实现和实施思路则更强调功能趋向单一，服务单元小型化和微型化。

如果用“茶壶煮饺子”来打比方的话，原来我们是在一个茶壶里煮很多个饺子，现在（微服务化之后）则基本上是在一个茶壶煮一个饺子，而这些饺子就是服务的功能，茶壶则是将这些服务功能打包交付的服务单元，如图所示。

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

1.2 使用微服务的好处

首先，在开发层面，每个微服务基本上都是各自独立的项目（project），而对应各自独立项目的研发团队基本上也是独立对应，这样的结构保证了微服务的并行研发，并且各自快速迭代，不会因为所有研发都投入一个近乎单点的项目，从而造成开发阶段的瓶颈。开发阶段的独立，保证了微服务的研发可以高效进行。

在微服务治理体系下，各个微服务交付期间也是各自独立交付的，从而使得每个微服务从开发到交付整条链路上都是独立进行，这大大加快了微服务的迭代和交付效率。

服务交付之后需要部署运行，对微服务来说，它们运行期间也是各自独立的。

对于 Java 开发者来说，早些年（当然现在也依然存在），我们遵循 Java EE 规范开发的 Web 应用，都需要以 WAR 包的形式部署到 TOMCAT、Jetty、RESIN 等 Web 容器中运行，即使每个 WAR 包提供的都是独立的微服务，但因为它们都是统一部署运行在一个 Web 容器中，所以扩展能力受限于 Web 容器作为一个进程（process）的现状。无论如何调整 Web 容器内部实现的线程（thread）设置，还是会受限于 Web 容器整体的扩展能力。所以，现在很多情况下，大家都是一个 TOMCAT 只部署一个 WAR，然后通过复制和扩展多个 TOMCAT 实例来扩展整个应用服务集群。

微服务运行期间给我们带来的第二个好处，即隔离性。隔离性实际上是可扩展性的基础，当我们将每个微服务都隔离为独立的运行单元之后，任何一个或者多个微服务的失败都将只影响自己或者少量其他微服务，而不会大面积地波及整个服务运行体系。

1.3 微服务带来的挑战

服务“微”化之后，一个显著的特点就是服务的数量增多了。如果将软件开发和交付也作为一种生产模式看待，那么数量众多的微服务实际上就类似于传统生产线上的产品，而在传统生产模型下，为了能够高效地生产大量产品，通常采用的就是标准化生产。

比如在汽车产业，在福特 T 型车没有出来之前，大多汽车企业的生产效率都不高，而福特在引入标准化生产线之后，福特 T 型车得以大量生产并以低成本优势快速普及。在其他行业也是同样的道理，个性化生产虽然会深得个别用户的喜欢，但生产成本通常也会很高，生产效率因为受限于个性化需求，也无法从“熟能生巧”中获益，所以，最终用户需要为生产成本和效率付出更多的溢价才能获得最终产品。而相对于个性化生产来说，标准化生产走的是另一条路，通过生产标准产品，使得整条生产链路可重复，从而提升了生产效率，可以为更广层面的用户提供大量“物美价廉”的标准产品。

微服务的研发和交付其实就类似于产品的生产链路，而数量大这一特点则决定了，我们无法通过个性化的生产模式来支撑整个微服务的交付链路和研发体系。

虽然微服务化之后，我们可以投入相应的人力和团队对应各个微服务的开发和交付，可扩展性上绝对没有问题，但这不意味着现实情况下我们就能这样做，因为这些都涉及人力和资源成本，而这往往是受限的。所以，使用标准化的思路来开发和交付微服务就变成了自然而然的选择：

二、什么是SpringBoot

2.1 SpringBoot介绍

2.1.1 Spring Boot 核心功能

• 独立运行的 Spring 项目。SpringBoot 可以以 jar 包的形式独立运行，运行一个 SpringBoot 项目只需通过 java–jar xx.jar 来运行。
• 内嵌 Servlet 容器。SpringBoot可选择内嵌Tomcat、Jetty或者Undertow，这样我们无须以war包形式部署项目。
• 提供 starter 简化 Maven 配置。Spring 提供了一系列的 starter pom 来简化 Maven 的依赖加载。
• 自动配置 Spring。Spring Boot 会根据在类路径中的 jar 包、类，为 jar 包里的类自动配置 Bean，这样会极大地减少我们要使用的配置。当然，Spring Boot 只是考虑了大多数的开发场景，并不是所有的场景，若在实际开发中我们需要自动配置 Bean，而 Spring Boot 没有提供支持，则可以自定义自动配置。
• 准生产的应用监控。Spring Boot 提供基于 http、ssh、telnet 对运行时的项目进行监控。
• 无代码生成和 xml 配置。Spring Boot 的神奇的不是借助于代码生成来实现的，而是通过条件注解来实现的，这是 Spring 4.x 提供的新特性。Spring 4.x 提倡使用 Java 配置和注解配置组合，而 Spring Boot 不需要任何 xml 配置即可实现 Spring 的所有配置。

2.1.2 Spring Boot的优缺点

• 优点：

创建独立Spring应用。内嵌web服务器。自动starter依赖，简化构建配置。自动配置Spring以及第三方功能。提供生产级别的监控、健康检查及外部化配置。无代码生成、无需编写XML。

• 缺点：

版本迭代速度很快，一些模块改动很大。由于不用自己做配置，报错时很难定位。网上现成的解决方案比较少。

2.2 SpringBoot入门案例

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>org.example</groupId>
    <artifactId>SQU_springboot</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>jar</packaging>

    <parent>
        <artifactId>spring-boot-starter-parent</artifactId>
        <groupId>org.springframework.boot</groupId>
        <version>2.3.4.RELEASE</version>
    </parent>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
    </dependencies>
</project>

@Controller
public class TestController {
    @ResponseBody
    @RequestMapping(value = "/hello")
    public String sayhello(){
        return "hello world";
    }
}

/**
 * spring的启动类
 * 只会扫描当前包和所有子包的组件到容器中
 */
@SpringBootApplication
public class MainApplication {
    public static void main(String[] args) {
        //启动spring应用
        SpringApplication.run(MainApplication.class, args);
    }
}

直接运行程序MainApplication，并访问http://localhost:8080/hello

2.3 将项目打包成一个可执行的jar包

pom文件中使用这个插件，可以将应用打包成一个可被执行的jar包

  <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <version></version>
            </plugin>
        </plugins>
    </build>