目录
3.3 Spring Boot 与 其他 Spring 应用之间的关系
1 从单体框架到微服务框架
1.1 单体框架的概念
软件系统通常会采用分层架构形式,如Java EE三层架构,即表示层、业务层、数据访问层。
用户——表示层——业务层——数据访问层——数据库
表示层:提供交互(前端设计HTML CSS JavaScript)
业务层:处理数据验证,规定相应逻辑(编程语言)
数据访问层:曾放管理持久性业务数据(DML DDL SQL)
单体框架:将三层结构,功能、代码、数据集中化,编译成一个发布包,部署运行在统一进程的应用程序的架构;Java EE就是典型的单体框架的项目,存在形式为WAR包或EAR包;部署时,整个发布包部署在web容器中(一般是Tomcat、Jetty或GlassFlash等serlvet容器);运行时,所有功能运行在同一进程中。
1.2 单体框架转化为微服务框架
(SOA) 单体架构系统整体过大,不容易管理,将其拆分成各种功能单元(服务),再服务之间定义良好的接口和契约。接口采用中立、与平台无关的方式进行定义,实现跨越不同的硬件平台、操作系统、编程语言。
2 微服务设计原则
2.1 颗粒度问题
略
2.2 轻量级通信
单体架构中,通信的方式就是组件之间的调用;微服务架构中,由于服务是跨域进程或跨主机的,组件需要通过REST、Web服务或类似RPC的机制在网上进行通信。
服务间采用轻量级通信协议;
2.3 领域驱动原则
应用程序的功能可以通过领域驱动原则(DDD)进行分解,降低微服务环境中通用语言的复杂性,有助于弄清楚领域的边界,厘清上下文边界;建议将每个微服务都设计成一个DDD的上下文边界(Bounded Context)。
2.4 单一职责原则
服务之间”低耦合,高内聚“。
2.5 DevOps及两个比萨原则
每个服务的开发团队要小而精(拥有全系列的开发人员,实现独立运维)。
2.6 不限于技术栈
不同服务,可以根据不同的应用场景,采用不同的技术栈。
2.7 可独立部署
每个服务可以独立运行在各自的进程中,不需要协调其他的服务进行调试。
3 Spring Boot 概述
3.1 Spring Boot 产生背景
Spring框架产生,采用了依赖注入和AOP(面向切面编程),无需继承复杂的Bean,解决了传统EJB中以Bean为中心的强耦合、强侵入的弊端;
但Spring框架还是存在大量的XML文件配置问题,XML配置包括Bean配置和其他框架集成配置;
之后,Spring 简化了XML文件配置,采用了”约定大于配置”的思想;
再后来,Spring 抽象出了Spring Boot ,Spring Boot时一些依赖库的集合,是Spring的一个应用;Spring Boot 紧密结合 Spring,提供了可零配置“开箱即用 ” 的第三方库。
3.2 Spring Boot 的目标
①为所有Spring开发他提供更快更广泛的入门体验;
②“开箱即用”,不适合时可快速抛弃;
③提供一系列大型项目常用的非功能性特征,如嵌入式服务器等配置;
④零配置,“约定大于配置”;
3.3 Spring Boot 与 其他 Spring 应用之间的关系
①与 Spring 框架 之间的关系:
Spring依赖Ioc机制管理Bean,Spring Boot 依赖 Spring 框架管理项目;Spring Boot 是Spring的一个应用,将依赖根据业务需求“组装”成不同的starter,开发者无须自行配置不同库之间的依赖关系,直接使用Spring Boot的Starter即可。
②与Spring MVC 框架 之间的关系:
Spring MVN 实现了Web项目中的MVC模式;Spring Boot如果是web项目,可以采用Spring MVC来实现Spring MVC模式。
③与Spring Cloud 框架 之间的关系:
Spring Cloud框架可以实现一整套分布式系统的解决方案(也包括微服务架构的方案),包括服务注册、服务发现、监控等,而Spring Boot只是作为开发单一服务的框架基础。
3.4 Starter
Starter是快速启动Spring应用的“启动器”;将依赖按照业务要求,集成组装成不同的starter;开发者使用时无需配置依赖之间的关系;
比如说,需要使用Spring和JPA进行数据库访问,只需要在项目中包含 Spring-boot-starter-data-jpa依赖即可;
所有Starter的命名格式都是Spring-boot-starter-*,*表示特定的业务功能类型的应用程序。
Starter的分类: