SpringBoot 学习总结（1）--- SpringBoot介绍、微服务架构

1. SpringBoot

SpringBoot官网：https://spring.io/projects/spring-boot

1.1 什么是SpringBoot?

Spring是一个开源框架，2003 年兴起的一个轻量级的Java 开发框架。Spring是为了解决企业级应用开发的复杂性而创建的，简化开发。

为了降低Java开发的复杂性，Spring采用了以下4种关键策略：

• 基于POJO的轻量级和最小侵入性编程；
• 通过IOC，依赖注入（DI）和面向接口实现松耦合；
• 基于切面（AOP）和惯例进行声明式编程；
• 通过切面和模版减少样式代码；

SpringBoot呢，就是一个javaweb的开发框架，和SpringMVC类似，对比其他javaweb框架的好处，就是简化开发，约定大于配置， you can “just run”，能迅速的开发web应用，几行代码开发一个http接口。

随着 Spring 不断的发展，涉及的领域越来越多，项目整合开发需要配合各种各样的文件，慢慢变得不那么易用简单，违背了最初的理念，甚至人称配置地狱。Spring Boot 正是在这样的一个背景下被抽象出来的开发框架，目的为了让大家更容易的使用 Spring 、更容易的集成各种常用的中间件、开源软件；

Spring Boot 基于 Spring 开发，Spirng Boot 本身并不提供 Spring 框架的核心特性以及扩展功能，只是用于快速、敏捷地开发新一代基于 Spring 框架的应用程序。也就是说，它并不是用来替代 Spring 的解决方案，而是和 Spring 框架紧密结合用于提升 Spring 开发者体验的工具。Spring Boot 以约定大于配置的核心思想，默认帮我们进行了很多设置，多数 Spring Boot 应用只需要很少的 Spring 配置。同时它集成了大量常用的第三方库配置（例如 Redis、MongoDB、Jpa、RabbitMQ、Quartz 等等），Spring Boot 应用中这些第三方库几乎可以零配置的开箱即用。

简单来说就是SpringBoot其实不是什么新的框架，它默认配置了很多框架的使用方式，就像maven整合了所有的jar包，spring boot整合了所有的框架 。

Spring Boot 出生名门，从一开始就站在一个比较高的起点，又经过这几年的发展，生态足够完善，Spring Boot 已经当之无愧成为 Java 领域最热门的技术。

1.2 Spring Boot 的主要优点

• 创建独立的Spring应用程序
• 直接嵌入Tomcat，Jetty或Undertow（无需部署WAR文件）
• 提供自以为是的“入门”依赖项以简化构建配置
• 开箱即用，提供各种默认配置来简化项目配置
• 提供生产就绪功能，例如指标，运行状况检查和外部化配置
• 绝对没有代码生成，也不需要XML配置

2. 微服务

2.1 单体应用架构

所谓单体应用架构（all in one）是指，我们将一个应用的中的所有应用服务都封装在一个应用中。

无论是ERP、CRM或是其他什么系统，都把数据库访问、web访问，等等各个功能放到一个war包内。

单体架构在规模比较小的情况下工作情况良好，但是随着系统规模的扩大，它暴露出来的问题也越来越多。

优点：

• 便于共享：单个归档文件包含所有功能，便于在团队之间以及不同的部署阶段之间共享。
• 易于测试：单体应用一旦部署，所有的服务或特性就都可以使用了，这简化了测试过程，因为没有额外的依赖，每项测试都可以在部署完成后立刻开始。
• 易于部署：只需将单个归档文件复制到单个目录下。

缺点：

• 复杂性高：由于是单个归档文件，所以整个项目文件包含的模块非常多，导致模块的边界模糊、依赖关系不清晰、代码的质量参差不齐，混乱的堆在一起，使得整个项目非常复杂。以致每次修改代码，都非常小心，可能添加一个简单的功能，或者修改一个Bug都会带来隐藏的缺陷。

• 技术债务：随着时间的推移、需求的变更和技术人员的更替，会逐渐形成应用程序的技术债务，并且越积越多。

• 扩展能力受限：单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩。
  阻碍技术创新：对于单体应用来说，技术是在开发之前经过慎重评估后选定的，每个团队成员都必须使用相同的开发语言、持久化存储及消息系统。

2.2 微服务架构

微服务架构，就是打破之前all in one的架构方式，把每个功能元素独立出来。把独立出来的功能元素动态组合，需要的功能元素才去拿来组合，需要多一些时可以整合多个功能元素。所以微服务架构是对功能元素进行复制，而没有对整个应用进行复制。

微服务架构是将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。

优点：

• 易于开发和维护：一个微服务只会关注一个特定的业务功能，所以业务清晰、代码量较少。开发和维护单个微服务相对简单。
• 单个微服务启动较快
• 局部修改容易部署：单体应用只要有修改，就得重新部署整个应用。微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可。
• 技术栈不受限制：在微服务架构中，可以结合项目业务及团队的特点，合理的选择技术栈。
• 按需伸缩：可根据需求，实现细粒度的扩展。

缺点：

• 运维要求高：更多的服务意味着要投入更多的运维。
• 分布式固有的复杂性：使用微服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的问题。
• 接口调整成本高：微服务之间通过接口进行通信。如果修改某一个微服务的API，可能所有用到这个接口的微服务都需要进行调整。

2.3 如何构建微服务

一个大型系统的微服务架构，就像一个复杂交织的神经网络，每一个神经元就是一个功能元素，它们各自完成自己的功能，然后通过http相互请求调用。比如一个电商系统，查缓存、连数据库、浏览页面、结账、支付等服务都是一个个独立的功能服务，都被微化了，它们作为一个个微服务共同构建了一个庞大的系统。如果修改其中的一个功能，只需要更新升级其中一个功能服务单元即可。

但是这种庞大的系统架构给部署和运维带来很大的难度。

于是，spring为我们带来了构建大型分布式微服务的全套、全程产品：

• 构建一个个功能独立的微服务应用单元，可以使用springboot，可以帮我们快速构建一个应用；

• 大型分布式网络服务的调用，这部分由spring cloud来完成，实现分布式；

• 在分布式中间，进行流式数据计算、批处理，我们有spring cloud data flow。

spring为我们想清楚了整个从开始构建应用到大型分布式应用全流程方案。