Springboot必知必会系列(1)——springboot与微服务

原创
2018/05/01 22:53
阅读数 8.1K

我的反复无常

年初写过几篇springboot的博客,但是觉得条理性差了点,本来想接着写,但是在写spring cloud的时候发现之前很多东西没整理好,决定还是放弃,重新开坑。

本次打算把整个系列计划一下,分为上下两个部分:

前半部分介绍所有必知必会的使用方法和基本原理:包括(1)springboot与微服务相关的内容,(2)如何配置,(3)与常用日志框架log4j、slf4j、logback等整合,(4)springboot在web开发中的各类问题,(5)springboot与虚拟化容器技术docker的整合应用,(7)springboot与数据访问方面的功能(springboot底层用spring data对sql和nosql的数据进行访问),(8)springboot的内部原理。

后半部分介绍一些高级应用场景整合和特性,如缓存、消息、检索等:包括(1)springboot的缓存管理机制,我们会使用redis作为缓存服务器作为示例进行介绍;(2)springboot与消息中间件,如rabbitmq进行整合;(3)springboot与全文检索ES整合;(4)springboot与邮件任务、定时任务、异步任务(提高并发能力);(5)springboot的安全机制(springboot底层用的安全框架是spring security);(6)springboot与分布式的整合使用,zookeeper和Dubbo,以及与springcloud的整合使用;(7)以及有关部署和运维springboot应用的要点(springboot的开发热部署 和监控管理)。

可以看出springboot不是一个单纯的框架,而是一个机遇J2EE的全套一站式解决方案。

(本文出自oschina博主happybks的博文:https://my.oschina.net/happyBKs/blog/1805314)

springboot为什么会出现?

所有的技术框架的发展似乎都遵循了一条主线规律:从一个复杂应用场景 衍生 一种规范框架,人们只需要进行各种配置而不需要自己去实现它,这时候强大的配置功能成了优点;发展到一定程度之后,人们根据实际生产应用情况,选取其中实用功能和设计精华,重构出一些轻量级的框架;之后为了提高开发效率,嫌弃原先的各类配置过于麻烦,于是开始提倡“约定大于配置”,进而衍生出一些一站式的解决方案。

是的这就是Java企业级应用->J2EE->spring->springboot的过程。

 

springboot的目标

Spring Boot来简化Spring应用开发,约定大于配置,去繁从简,只要run就能创建一个用来独立的。

其简化的手段是:包含一个个starter启动器来管理各类依赖和配置,你只需要POM引入这些start,所有的配置基本上springboot的start都会自行配置好,不需要你心。
 

spring全家桶

如今spring的项目越来越多,但当下最火的当属Spring Boot和Spring Cloud:
Spring Boot :J2EE一站式解决方案
Spring Cloud : 分布式整体解决方案

 

springboot的优势:

(1)快速创建独立运行的Spring项目以及与主流框架集成

(2) 使用嵌入式的Servlet容器,应用无需打成WAR包

    springboot的web项目不再需要我们去配置一个tomcat引入相关servlet的类,它自含servlet容器,你可以打成一个jar来运行一个web项目。

(3) starters自动依赖与版本控制

所有的企业级开发场景都有相应的启动器,这些启动器帮我们导入这个场景所需要的所有依赖,并且自动控制版本。

像你要用Mongo、用ES、用redis,开发web项目等等,都只需要在maven的pom下引入相应的starter启动器即可。注意,以mongo为例,它不是像一般项目那样引入一个driver,而是引入一个springboot的mongodb的starter。它不仅会为我们将java访问mongo的driver相关的各个jar按正确的版本导入,还能为我们默认做好各类配置,我们直接继承某些抽象类或者接口,直接使用即可。

(4)大量的自动配置,简化开发,也可修改默认值

用springboot开发应用,用户只需要开发一个微小的入口;我们不需要进行大量的配置,大部分配置springboot已经自动为我们配置好了。

(5)无需配置XML,无代码生成,开箱即用

springboot的无须配置xml,不是因为它会将对应的代码自动生产成,而是springboot已经实现了一些API,它能够帮我们自动配置好。我们只要通过springboot创建出来就能用。

(6) 准生产环境的运行时应用监控

运维期间的健康状况,每个服务的状态等都能监控。

(7)与云计算的天然集成

 

那么springboot有什么缺点呢?

其实如非要说一个缺点,只能说:方便的springboot让一些程序员丧失了对其封装实现原理有更深了解的机会。因为springboot是在spring基础上的再次封装。当你学习springboot的内部实现原理时,你会发现你必须了解spring内部大量的API。所以如果你需要对springboot深度定制,必须对spring本身有相当的了解。

 

总结

springboot的目的是构建一个简化spring开发的框架

springboot框架本身是spring技术栈的大整合

springboot是一个基于J2EE的一站式解决方案

 

 

微服务

什么是微服务?

微服务是一种架构风格,它要求我们在开发一个应用的时候,这个应用必须构建成一系列小服务的组合;

可以通过http的方式进行互通。

要说微服务架构,先得说说过去我们的单体应用架构。

单体应用架构(All in one)

所谓单体应用架构是指,我们将一个应用的中的所有应用服务都封装在一个应用中。

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

这样做的好处是,易于开发和测试;也十分方便部署;当需要扩展时,只需要将war复制多份,然后放到多个服务器上,再做个负载均衡就可以了。

单体应用架构的缺点是,哪怕我要修改一个非常小的地方,我都需要停掉整个服务,重新打包、部署这个应用war包。特别是对于一个大型应用,我们不可能吧所有内容都放在一个应用里面,我们如何维护、如何分工合作都是问题。

 

 

 

微服务架构

all in one的架构方式,我们把所有的功能单元放在一个应用里面。然后我们把整个应用部署到服务器上。如果负载能力不行,我们将整个应用进行水平复制,进行扩展,然后在负载均衡。

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

这样做的好处是:

(1)节省了调用资源。

(2)每个功能元素的服务都是一个可替换的、可独立升级的软件代码。

 

微服务与SOA的比较

微服务应该微到什么程度?大家可以看看Martine Flower的有关微服务和SOA的比较的文章:

https://martinfowler.com/articles/microservices.html#MicroservicesAndSoa

这里我就不细说了,等到后面重新写spring cloud文章的时候再说。

 

如何构建微服务

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

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

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

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

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

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

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

 

 

 

 

 

 

展开阅读全文
加载中

作者的其它热门文章

打赏
1
2 收藏
分享
打赏
0 评论
2 收藏
1
分享
返回顶部
顶部