这两天学习的SpringCloud Alibaba,什么SpringCloud Alibaba呢?我们就需要了解什么是SpringCloud,那什么又是SpringCloud呢?我们就需要了解什么是微服务,那什么又是微服务呢?我们就需要了解什么SAO-------------啊啊啊啊啊啊啊啊啊,这难道就是俄罗斯套娃吗。不,这是一个知识体系,下面我就来简单的介绍一下!
一、简介
1.SOA
百度百科:
是不是晦涩难懂呢?,嗯我也是这样认为的。
通俗易懂解释 :
SOA不是具体的什么技术,而是一种开发项目的思想(架构设计模式),更符合现在的互联网系统快速发展的时代。下面举个栗子
场景:现在我有一个数据库,一个JavaWeb的网站客户端,一个安卓app客户端,一个IOS客户端。现在我要给用户提供一个注册账号的功能。
不用SOA的设计思想的实现:JavaWeb里面写一个注册账号的功能,安卓app里面写一个注册账号的功能,IOS同样如此。那么这样的实现有没有什么问题呢?比如有一天,我的注册方法需要改动,那是不是三个地方都要改,而且要改的一模一样。当然问题不止这一个。
SOA的设计思想实现:用Java单独创建一个工程部署在一台服务器上,并且写一个方法执行上述注册操作,然后提供一个接口,其他人可以通过某种途径(广义的API)访问这个方法来注册。就是说把这个操作封装到一个工程中去,然后暴露访问的方式,形成“服务”。要修改关于注册用户的业务方法只要改这个服务就好了,很好的解耦。这样有什么好处呢?
优点:
- 扩展方便:一旦哪天突然有一堆人要注册,假设这堆人仅仅只是注册而不做其他事情,注册这个功能压力很大,而原有的一台部署了注册服务的服务器已经承受不了这么高的并发,这时候就可以单独集群部署这个注册服务,提供多几台服务器提供注册服务。
- 语言通用:实现这个服务的可以试任何语言,只要提供的接口通用就可以了,比如PHP擅长处理逻辑、Ruby语言擅长高并发、java擅长大数据等那我可以再比如某些业务逻辑很复杂的服务中使用PHP,在某些并发很高的服务中使用Ruby。
- 新人友好:新人进公司的时候他无需了解整个项目的架构是怎样的,比如你进阿里了,你想要熟练整个淘宝的架构你会累死,而这种SOA思想开发的项目由于是服务形式的,比方把你分到购物车组,那你只需要了解购物车的功能就好了。
- 发版方便:比方说你是淘宝购物车项目组的,你的项目改了一些东西要发版(发布生产),如果你是传统项目测试可能怕你改动到了其他的东西影响到了其他的功能(虽然你很确信没改动到,但万一呢?)不得不对淘宝整体的功能都做一遍测试,累死人,而这种形式的测试只需要测试你的购物车的功能,so easy。退一步说,万一你改的代码有问题测试没测出来,那也是影响购物车的功能,用户下单支付不影响。
缺点:
- 沟通不便:如果你们在大公司待过的话就会明白,用户组,订单组,购物车组,支付组等等是分别属于不同的领导管理,出了问题沟通起来很麻烦,甚至你都不知道找谁沟通,也能以前跟你沟通的人后来离职了等等的问题。
- 性能问题:相对于传统项目的直觉调用,SOA中不管你是使用RPC还是什么HTTP等技术调用,肯定会有性能的损耗,因为网络通信是需要时间的。
- 关系混乱:当服务越来越多,调用方也越来越多的时候,它们之间的关系就变得非常混乱。
- 运维难度:随着服务的增多,系统架构会越发复杂,这就给运维层面带来了挑战。
- 数据一致性问题:单体项目因为数据都在同一个数据库里面,不需要过多的关注分布式事务等问题,SOA就需要关心了。
整体而言SOA肯定是利大于弊的,虽然缺点很明显,但是基本都是可以克服的,沟通不便就找上级领导多沟通呗,性能问题用内网什么的也能降低到很少,关系乱就可以用服务治理。相对而言好处部分基本上是不可能克服的,比如非SOA项目扩展基本很难,全部的代码丢到一个项目里面类似淘宝这种新人可能看三年五年也看不懂。
服务治理:上面我们提到了一个概念,什么是服务治理呢?
就是当服务越来越多,调用方也越来越多的时候,它们之间的关系就变得非常混乱,需要对这些关系进行管理。举例,还是上面的例子,假如我有一个用户服务,一开始有调用方1和调用方2来使用这个服务,后来越来越多,将近上百个调用方,这个时候作为服务方,它只知道提供服务,却不知道具体为谁提供了服务。而对于开发者来说,知道这=N多调用方和N多服务方之间的关系是非常重要的。所以这个时候就需要能进行服务治理的框架,比如dubbo+zookeeper,比如SpringCloud,有了服务治理功能,我们就能清晰地看到服务被谁谁谁调用,谁谁谁调用了哪些服务,哪些服务是热点服务需要配置服务器集群,而对这个服务集群的负载均衡也是服务治理可以完成的重要功能之一。
2.微服务
百度百科:
通俗易懂解释:
微服务是一种架构模式(MSA),叫微服务架构更合理,就是把一个系统中的各个功能点都拆开为一个个的小应用然后单独部署,微服务架构的基础是将单个应用程序开发为一组小型独立服务,这些独立服务在自己的进程中运行,独立开发和部署。这些服务使用轻量级 API 通过明确定义的接口进行通信。这些服务是围绕业务功能构建的,每项服务执行一项功能。由于它们是独立运行的,因此可以针对各项服务进行更新、部署和扩展,以满足对应用程序特定功能的需求。
程序中的微服务,就是将各个业务系统的共性再进行抽取,做成独立的服务,如图所示:
总之,微服务是分布式系统中的一种流行的架构模型。微服务架构主要解决的是如何快速地开发和部署我们的服务,这对于一个能够适应快速开发和成长的公司是非常必要的。同时,微服务设计中有很多很不错的想法和理念。
3.Spring Cloud
百度百科:
通俗易懂解释:
Spring Cloud 是一套完整的微服务解决方案,基于 Spring Boot 框架,准确的说,它不是一个框架,而是一个大的容器,它将市面上较好的微服务框架集成进来,从而简化了开发者的代码量。简单来说,Spring Cloud是一个微服务框架的规范,注意,只是规范,他不是任何具体的框架。我们知道java大佬最喜欢的做法就是自己制定规范,然后别人基于我这个规范来做实现。
规范功能:
- 服务的注册与发现
- 负载均衡
- 服务熔断和限流
- 智能路由
- 控制总线
- 链路监控
Spring Cloud与Spring Boot的关系:
与其说他们有什么关系,不如说他们就没有什么关系。只是现在微服务当道,而实现一个服务最快的办法就是用spring boot。不然你还要自己搭项目自己找jar包自己搞配置,还有兼容性等情况。那你的服务化进程注定是缓慢的。所以他们之间是没有关系的,只是因为微服务所需要的小应用很多,而spring boot恰恰又是实现小应用最快的方式。
4.Spring Cloud Alibaba
概述:
Spring Cloud Alibaba 是Spring Cloud的一个子项目,致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必需组件,方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。依托 Spring Cloud Alibaba,您只需要添加一些注解和少量配置,就可以将 Spring Cloud 应用接入阿里微服务解决方案,通过阿里中间件来迅速搭建分布式应用系统。
核心组件:
服务限流降级:
默认支持 WebServlet、OpenFeign、RestTemplate、Spring Cloud Gateway, RocketMQ 限流降级功能的接入,可以在运行时通过控制台实时修改限流降级规则,还支持查看限流降级 Metrics 监控。
服务注册与发现:
基于Spring Cloud 服务注册与发现标准,借助Nacos进行实现,默认还集成了 Ribbon 的支持。
分布式配置管理:
基于Nacos支持分布式系统中的外部化配置,配置更改时自动刷新。
消息驱动能力:
基于Spring Cloud Stream 为微服务应用构建消息驱动能力。
分布式事务:
使用 @GlobalTransactional 注解, 高效并且对业务零侵入地解决分布式事务问题。
分布式任务调度:
提供秒级、精准、高可靠、高可用的定时(基于 Cron 表达式)任务调度服务。同时提供分布式的任务执行模型,如网格任务。网格任务支持海量子任务均匀分配到所有 Worker上执行。
架构设计图:
01介绍到这里结束,搞清楚了它们的概念和它们之间的关系,接下来我们来具体学习实践操作!