认识微服务
- 随着互联网行业的发展,对服务的要求也越来越高,服务架构也从单体架构逐渐演变为现在流行的微服务架构,这些架构之间有怎样的差别呢?
导学:
- 了解微服务的优缺点;
- 了解微服务架构的演变过程;
- 认识微服务的一种实现:Spring Cloud
微服务架构的演变
单体架构
单体架构:将业务的所有功能都集中在一个项目中开发,打成一个包去部署。
单体架构的优缺点如下:
优点:
- 架构简单
- 部署成本低
缺点:
- 耦合度高,扩展性差,因为所有代码写在一个项目里(维护困难、升级困难) ,适合小型项目,比如:学生管理系统
分布式架构
分布式架构:根据业务功能对系统做拆分,每个业务功能模块作为独立项目开发,称为一个服务,说白了就是按照业务垂直划分,每个业务都是单体架构,通过API互相调用。
分布式架构的优缺点:
优点:
- 降低服务耦合
- 扩展性好,有利于服务升级和拓展
缺点:
- 难度大,服务调用关系错综复杂(只能远程调用:跨越机器、跨越服务的调用) ,适合大型互联网项目,比如:淘宝、京东
分布式架构虽然降低了服务耦合,但是服务拆分时也有很多问题需要思考:
- 服务拆分的粒度如何界定?
- 服务集群的地址如何维护?
- 服务之间如何实现远程调用?
- 服务的调用关系如何管理?
- 服务健康状态如何感知?万一你这个服务都挂了我还来调你,导致我这里也调用失败 - 级联失败
人们需要指定一套行之有效的标准来约束分布式架构,因此就出现了微服务~!
知识补充:热更新(Hot Reload)
- 热更新指的是应用程序运行时,修改程序代码后无需重启整个应用程序,而是只需要重新加载修改后的部分代码,使得修改的代码可以立即生效,通过这种方式,可以避免每一次修改后都需要重新启动应用程序,等待整个应用程序重新加载的情况出现,使得开发人员可以更加方便地进行代码调试和修改。
什么是微服务?
- 微服务是一种经过良好架构设计的分布式架构方案。
微服务的优缺点:
优点:
- 拆分粒度更小、服务更独立、耦合度更低
缺点:
- 架构非常复杂,运维、监控、部署难度提高
微服务的架构特征:
-
单一职责:微服务的拆分粒度更小,每一个服务都对应唯一的业务能力,每个服务都围绕着具体业务进行构建,做到单一职责,避免重复业务开发
-
面向服务:微服务要对外暴露业务接口(这样服务之间就可以做一些相互的调用了),服务提供统一标准的接口,与语言和技术无关
-
自治:指的就是独立:团队独立、技术独立、数据独立(是指每个服务可以有自己独立的数据库)、部署独立(能够被独立的部署到生产环境)和交付独立
-
隔离性强:服务调用要做好隔离、容错、降级,避免出现级联问题
微服务的上述特征其实是在给分布式架构制定一个标准,这些特征其实最终的目的就是为了实现高内聚、低耦合,降低服务之间的耦合度,(降低服务它所能产生影响的范围),提高服务的独立性和灵活性,避免整个集群的故障!
因此,可以认为微服务是一种经过良好架构设计的分布式架构方案。
- 微服务它一种其实是分布式架构的一种,所谓分布式架构就是要把服务做拆分,而拆分的过程中其实会产生各种各样的问题需要去解决,而Spring Cloud其实仅仅是解决了服务拆分时的服务治理问题,至于其它的一些分布式的更复杂的一些问题,并没有给出解决方案,所以一个完整的微服务技术,要包含的不仅仅是Spring Cloud。
- 微服务要做的第一件事情就是拆分,因为传统的单体结构,所有的业务功能全部写在一起,随着业务越来越复杂,代码也变得耦合的越来越多,将来你想升级、维护就会很困难,所以像一些大型的互联网项目,就必须去做拆分;
- 微服务在做拆分的时候,会根据业务功能模块把一个单体的项目拆分成许多个独立的项目,每个项目完成一部分业务功能,将来独立开发和部署,我们把这样一个独立的项目称为一个服务;
- 一个大型的互联网项目往往会包含数百甚至上千的服务,最终形成一个服务集群,而集群中的每个服务都要遵循单一职责的原则,并且要面向服务,对外暴露业务接口,这样服务之间就可以做一些相互的调用,只不过不同技术在实现这些接口的时候,可能会有差异;
- 而一个业务往往需要有多个服务共同来完成,比如说一个请求来了,它可能先去调了服务A,而服务A可能又调了服务B,然后又去调了服务C,当业务越来越多,越来越复杂的时候,这些服务之间的调用关系就会越来越复杂,这么复杂的一个调用关系一定需要我们去维护,想靠人去记录和维护,这是不可能的,所以在微服务里,一定会有一个组件,叫做注册中心:它可以去维护微服务里面每个节点的信息,并且去监控这些节点的状态:它可以去记录微服务中每一个服务的IP、端口以及它能干什么事这些信息,当有一个服务需要调用另外的服务时,它不需要自己去记录对方的IP,只需要去找注册中心就行了,由注册中心去拉取对应的服务信息;
- 并且将来随着服务越来越多,每一个服务都有自己的配置文件,如果将来有一些配置需要去做修改,将来如果要更改配置,难道我们手动的去微服务里面逐一去修改吗?这就太麻烦了,所以在微服务里还会有一个配置中心:它可以去统一的管理整个服务群体成千上百的这个配置信息,如果以后有配置需要变更,只需要去找到配置中心就可以了,它会去通知相关的微服务,利用通知的方式去让对应的服务服务监控到配置的变化,从而实现配置的热更新;
- 将来当我们的微服务一旦部署上线,用户就可以来访问我们了,但这个时候,还需要有一个网关组件,因为你这里有这么多的微服务,用户怎么知道该访问哪一个呢?而且也不是说你随便什么人都能来访问我们的服务吧,所以这些服务集群还需要有一个统一的服务网关作为入口,我们的服务网关一方面就是对用户身份对校验,另一方面就是由网关把用户的请求路由到我们的具体的服务,当然在路由过程中,也可以去做一些负载均衡,并且路由的时候或者服务之间的调用过程中,我们还要做好服务的容错处理,避免因为服务故障带来级联失败,还要做好服务保护、隔离、降级等等这些措施;
- 而这时候呢,服务进入到你的请求去处理业务,该访问数据库的时候就去访问数据库,最后再把查询到的数据返回给用户,将来数据库肯定要做集群,但是你集群再庞大,也不可能有用户多把,所以数据库将来肯定无法抗住高并发的场景,因此还会加入缓存,缓存就是把数据库数据放入到内存当中,内存查询效率肯定要比数据库快很多,而且这种缓存还不能是单体缓存,为了应对高并发,还要做成分布式缓存,也是一个集群:用户请求先到缓存,缓存未命中,再去查询数据库。
- 以后我们的业务中还会有一些复杂的搜索功能,简单查询可以走缓存,一些海量数据的复杂的搜索、统计和分析,缓存也做不了,这个时候就需要用到分布式搜索功能,数据库将来主要的职责其实就是做一种数据的写操作,还有一些事务类型、对数据安全要求较高的一些数据存储;
- 最后在微服务里边,还需要一种异步通信的消息队列组件,因为对于这种分布式的服务或者微服务里面,它的业务往往会跨越多个服务,一个请求来了,先调的服务A,A再调B,B再去调C,整个业务的链路就很长,调用时长就会等于每个服务的执行时长之和,所以其实性能是有一定的下降的,而异步通信的意思就是,请求来了,我调了服务A,服务A我不是去调你服务B和C,而是通知你们,发一条消息,你们两个赶紧干活去,于是,那两个哥们去干了,而服务A直接结束了,所以它的业务链路就会变短了,响应时间也缩短了,自然吞吐能力也就变强了,所以异步通信可以提高我们服务的并发,在一些类似于秒杀这样的高并发场景下就可以去利用了。
当然,我们如此庞大和复杂的一个服务,在运行的过程当中,如果出现了什么问题,就不太好排查,所以在微服务运行过程中,我们还会引入两个新的组件来去解决服务的异常定位:
- 第一个是分布式日志服务,它可以去统计整个集群当中成千上百的这些服务,它们的运行日志,统一的去做一个存储、统计和分析,将来如果出现问题,就比较好定位了;
- 而且还有第二个东西,叫做系统监控和链路追踪,它可以去实时监控我们整个群体中每一个服务节点的一个运行状态、CPU的负载、内存的占用等等的情况,一旦出现任何的问题,直接可以定位到具体的某一个方法(栈信息),那么你就能够很快速的定位到异常所在了。
那么如此庞大、复杂的一个微服务集群,将来很有可能会达到成千上万的服务,这个时候,我们部署该怎么办呢?
- 如果还是靠以前,人工去部署,显然不太现实,所以将来这些微服务集群还需要去做一种自动化的部署,我们就会利用Jenkins这样的工具,它可以对这些微服务项目进行自动化的编译,基于docker再去一些打包,形成镜像,再基于kubernetes(K8s)或RANCHER这样的技术去实现自动化的部署,这一套我们称之为持续集成。
结合微服务的这些技术再加上持续集成,这才是完整的微服务技术栈!
- DevOps:开发运维
微服务技术对比
目前最流行的两种微服务解决方案是Spring Cloud和Dubbo。
- 微服务这种方案也需要技术框架来落地,全球的互联网公司都在积极尝试开发自己的微服务落地技术,在国内最知名的就是Spring Cloud和阿里巴巴的Dubbo => 不管是Spring Cloud还是Alibaba的Dubbo,都是微服务方案的实现,所以它们所包含的组件实现的功能基本是一致的,首先它们都需要去做微服务的拆分,形成微服务集群,而集群中的每个服务都要遵循单一职责的原则,并且要面向服务,对外暴露业务接口,这样服务之间就可以做一些相互的调用了...
- 微服务这种分布式架构方案的落地,其实在Java领域最引人注目的就是SpringCloud提供的方案了。
Spring Cloud和Dubbo其实它们在实现的过程中,其实是有一些差异的:
Dubbo技术它早在2012年左右就已经开源出来了,是Alibaba公司开源的,但是那个时候微服务技术在国内可能连听都没听过,所以说Dubbo并不是严格意义上的一个微服务技术,Dubbo最开始只是一个简单的RPC调用框架,在那个时候,它的核心就是服务的远程调用以及注册发现,所以在Dubbo里面技术体系并不完整,而且注册中心也不是Dubbo里面自己实现的,而是依赖于zookeeper、Redis去做的,这些并不是专业的注册中心(半吊子),像Redis是做缓存的,zookeeper是做集群管理的,所以Dubbo并不具备完善的注册中心功能,而服务的这种远程调用才是Dubbo的核心,Dubbo它最开始的优势是在于自定义的Dubbo通信协议,效率要比HTTP协议高不少,在当时,Dubbo专门基于这种TCP的协议定义了一套标准,也就是Dubbo协议,Dubbo协议是一种基于TCP协议的RPC协议,所以遵循Dubbo这种远程调用,必须得定义Dubbo这种标准的接口。而且配置中心和服务网关Dubbo都没有实现,至于服务监控Dubbo里面只提供了一个非常基本的dubbo-admin功能,只是来统计一下服务调用时的一个响应时间、QPS等等,功能非常单一,所以Dubbo所实现的这个服务的治理,其实是非常不完善的。
而到了2015年~2017年这段时间,可以说是微服务技术井喷的时候,各种各样的微服务技术层出不穷,但是一直没有一个一统江湖的,直到Spring Cloud的出现,Spring Cloud它并不是发明了什么东西,而是整合,它把全球各个公司的开源的这种微服务技术都给整合起来了,而后形成了一套完整的微服务技术体系,是一个集大成者,它里面的功能是非常完善的,它首先有完善的注册中心,里面包含了Eureka、Consul这种专业的注册中心,并且Spring Cloud的服务调用它并没有去整一种全新的协议和标准,它用的是直接基于HTTP协议的标准的Feign客户端,由它来去发送HTTP的请求(不用它也行,只要遵循Restful风格 => 基于HTTP协议的RESTful API),Spring Cloud还提供了专业的配置中心,叫做SpringCloudConfig,另外Spring Cloud还提供了SpringCloudGetway以及Zuul两个不同的网关,在目前比较流行的是SpringCloudGetway网关,因为它里面基于了最新的响应式编程,吞吐能力非常强,还有服务监控和保护 - Hystrix,Hystrix它是一个非常强大的服务保护技术,但是它里面也带有一些监控的功能,但核心是保护,主要就是实现了服务的隔离和熔断等等一些相关技术,功能也是十分强大。
由于Dubbo和Spring Cloud相比还是存在比较大的差距,Dubbo它不是一个完善的微服务的技术栈,所以阿里巴巴也认识到了这一点,因此阿里巴巴为了追赶Spring Cloud的脚步,形成了一套能够与Spring Cloud无缝衔接的开源组件和工具,也就是Spring Cloud Alibaba,Spring Cloud Alibaba本质上是实现了Spring Cloud标准的,所以可以认为Spring Cloud Alibaba是Spring Cloud的一部分,Spring Cloud Alibaba是Spring Cloud的子项目,Spring Cloud Alibaba是Spring Cloud的拓展,用于构建云原生微服务应用。
Spring Cloud和Spring Cloud Alibaba在概念和功能上有很大的相似性,都致力于构建和管理微服务架构,但Spring Cloud Alibaba更加专注于阿里巴巴云生态,并提供了一些额外的功能和针对云原生应用的支持。
Spring Cloud
- Spring Cloud是目前国内使用最广泛的微服务框架。
- Spring Cloud是微服务架构的一站式解决方案,集成了各种优秀的微服务功能组件。
官网地址:Spring Cloud
中文网站:Spring Cloud中文网-官方文档中文版
Spring Cloud集成了各种微服务功能组件,并基于Spring Boot实现了这些组件的自动装配,从而提供了良好的开箱即用体验。
其中常见的组件包括:
另外,Spring Cloud底层是依赖于Spring Boot的,Spring Cloud是一个基于Spring Boot实现的服务治理工具包,Spring Boot专注于快速、方便的开发单个微服务(单体架构应用的开发),而Spring Cloud关注于全局的微服务整合和管理,Spring Cloud是构建在Spring Boot之上的一个服务治理框架,并且有版本的兼容关系,如下: