前言
本文会介绍微服务架构SpringCloud的入门学习,会对java架构的发展进行介绍,对SpringCloud的关键组件进行介绍,包括Eureka介绍和使用、Ribbon客户端负载均衡的使用,已经在微服务中如何实现通信传输。
目录
系列文章目录
第一章 应用架构的发展史
1. 单体应用架构
单体架构,即所有的模块,组件等都在一个应用中应用最终打成一个(war,jar)包使用一个容器(Tomcat)进行部署,通常一个应用享用一个数据库。
单体应用中我们通常把应用分为三个组成部分:持久层,业务层,表现层,这样的应用结构在项目初期业务较少的情况下没有任何问题,但是随着业务需求不断的增加要求单体应用中的业务逻辑,业务组件等日益扩张,应用将会变得越来越臃肿,往后的开发和维护就会变得特别麻烦,再加上越来越大访的问量,并发越来越高,面对海量的用户无论从应用性能还是从数据库方面都有吃不消的时候。
优点:
-
易于开发 :架构简单,技术成本低
-
易于测试 :所有功能在一个项目,方便测试
-
易于部署 :一个Tomcat就可以实现部署,简单方便
缺点:
-
代码臃肿不方便开发维护(代码可读性差)
-
系统扩展性能变差
-
无法针对某一个业务做扩展(集群)
-
对大数据量,高并发量的处理不占优势
-
技术选型单一
-
模块/业务耦合度高
集群:
单体架构中,为了提升应用的并发作业能力和防止应用的单节点故障(一个Tomcat挂了,应用就挂了)我们通常会对应用做集群, 指的是把应用进行复制多个相同的应用一起工作来提高作业能力,多个应用做的是相同的事情。 可以解决单体故障问题,高并发等问题。
当我们的应用做了集群,那么就会存在多个应用节点,多个应用将会暴露多个访问地址(ip:port),那客户端是不知道该访问哪个应用节点的,这个时候我们就需要有一个请求分发的功能的组件(负载均衡器)将客户端的请求相对平均的分发多个应用节点上,这就是负载均衡,这个做请求分发的组件就是负载均衡器。如图所示:
2. 分布式与SOA
分布式
分布式就是将应用按照业务进行拆分成多个子应用,多个子应用部署在不同的服务器中,多个子应用组成一个完整的系统,所有的子系统一起工作相互通信相互协调才能完成最终的业务流程,缺一不可。
拿生活中的案例“买票排队”,来说,当排队规模小的时候我们一个售票员就可以完成所有工作,当游客增加,一个售票员就忙不过来,这个时候可能要再增加两个售票员,然后进行分工,售票员A负责售票,售票员B负责收票,售票员C负责维护游客,这样一来每个售票员的压力减轻,并且每个售票员就只需要专注一件事情即可。
当然如果某个子系统压力依然很大,可以单独对该子系统再做集群,所以分布式和集群并不冲突。
缺点:
-
项目本身任然是单体,代码臃肿
-
面对海量数据数据库会成为性能瓶颈
-
持续交互能力差,代码臃肿,业务复杂,开发维护时间长,成本高
面向服务的架构SOA
它的思想是每个子应用可以通过网络通信协议向其他子应用提供服务或者消费服务,SOA也是分布式架构,SOA把分布式架构划分成表示层和服务层,服务层中包含了业务逻辑和相关流程,只需要对外暴露服务即可,表现层负责处理和页面的交互。
缺点:
-
增加了浏览消耗
-
相对于单体应用来说,技术,人力成本较高
-
部署和运维相对麻烦
3. 微服务架构
微服务架构风格是一种使用一套小服务来开发单个应用的方式途径,每个服务运行在自己的进程中,并使用轻量级机制通信,通常是HTTP API,这些服务基于业务能力构建,并能够通过自动化部署机制来独立部署,这些服务使用不同的编程语言实现,以及不同数据存储技术,并保持最低限度的集中式管理。
优点:
-
单个服务业务简单,代码简单方便开发维护
-
服务之间无耦合,服务之间升级维护互不影响
-
轻量级HTTP通信机制,使得的不同的服务可以采用不同的编程语言
-
集群
-
微服务架构对现在流行的敏捷开发支持优化
缺点:
-
分布式事务 :服务通信机制增加了事务的复杂性
-
部署麻烦 :微服务众多,部署麻烦
-
技术成本高 :微服务架构本身比较复杂,技术成本高
-
服务通信对性能的损耗相对较大
第二章 介绍SpringCloud
Spring cloud是一个基于Spring Boot实现的服务治理工具包,用于微服务架构中管理和协调服务的,利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。
SpringCloud常用组件
Netflix Eureka:服务发现与注册
当我们的微服务过多的时候,管理服务的通信地址是一个非常麻烦的事情,Eureka就是用来管理微服务的通信地址清单的,有了Eureka之后我们通过服务的名字就能实现服务的调用。
Netflix Ribbon\Feign : 客户端负载均衡
Ribbon和Feign都是客户端负载均衡器,它的作用是在服务发生调用的时候帮我们将请求按照某种规则分发到多个目标服务器上,简单理解就是用来解决微服务之间的通信问题。
Netflix Hystrix :断路器
微服务的调用是非常复杂的,有的时候一个请求需要很多的微服务共同完成,那么一旦某个服务发生故障,导致整个调用链上的微服务全都出现异常,甚至导致整个微服务架构瘫痪。Hystrix就是用来解决微服务故障,保护微服务安全的组件。
Netflix Zuul : 服务网关
zuul作为服务网关,我们可以把它看作是微服务的大门,所有的请求都需要经过zuul之后才能到达目标服务,根据这一特性,我们可以把微服务公共的是事情交给zuul统一处理,如:用户鉴权,请求监控等。
Spring Cloud Config :分布式配置
微服务架构中的服务实例非常的多,服务的配置文件分散在每个服务中,每次修改服务的配置文件和重新服务实例都是一个很麻烦的工作,Spring Cloud Config作为分布式配置管理中心就是用来统一的管理服务的配置文件。
Spring Cloud Bus : 消息总线
消息总线是在微服务中给各个微服务广播消息的一个组件,我们使用消息总线构建一个消息中心,其他微服务来接入到消息中心,当消息总线发起消息,接入的微服务都可以收到消息从而进行消费。
Spring Cloud sleuth :微服务链路追踪
当我们的应用采用微服务架构之后,后台可能有几十个甚至几百个服务在支撑,一个请求请求可能需要多次的服务调用最后才能完成,链路追踪的作用就是来监控维护之间的调用关系,让程序员方便直观的感受到一个请求经历了哪些微服务,以及服务的请求时间,是否有异常等。
第三章 Eureka介绍(服务注册与发现)
Eureka 是Netflix公司提供的服务注册与发现
组件,Eureka是一个服务注册与发现组件,简单说就是用来统一管理微服务的通信地址的组件,它包含了EurekaServer 服务端(也叫注册中心)和EurekaClient客户端两部分组成,EurekaServer是独立的服务,而EurekaClient需要集成到每个微服务中。
1、服务发现
微服务(EurekaClient)会定期默认30s的从EurekaServer拉取一份微服务通信地址列表缓存到本地。
2、服务续约
微服务(EurekaClient)采用定时默认30s发送“心跳”请求向EurekaServer发请求进行服务续约,其实就是定时向 EurekaServer发请求报告自己的健康状况,告诉EurekaServer自己还活着,请求三次为响应,注册中心机会从服务地址清单中剔除该服务。
3、Eureka使用
EurekaClient:
导入依赖:
<!--eureka服务端依赖-->
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>
</dependencies>
主配置类:
通过注解@EnableEurekaClient标记服务作为Eureka客户端
@SpringBootApplication
@EnableEurekaClient
public class OrderApplication {
public static void main(String[] args) {
SpringApplication.run(OrderApplication.class);
}
}
application.yml配置:
可以配置注册地址、实例id、服务名、端口号
#注册到EurekaServer
eureka:
client:
serviceUrl:
defaultZone: http://localhost:10010/eureka/ #注册地址
instance:
instance-id: order-server #实例ID
spring:
application:
name: order-server #服务名
server:
port: 1020 #端口号
Eureka Client
导入依赖:依赖会增加一个SpringBoot的web依赖
<!--eureka服务端依赖-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
<!--spring-boot的web整合依赖-->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
主配置类同上一样,application中除了服务名,端口和用户服务不一样,其他的都一样。
第四章 RestTemplate服务通信
微服务的通信协议主流的有RPC,Http,SpringCloud是基于Http Restful 风格 ,在Java中发起一个Http请求的方式很多,比如 Apache的HttpClient , OKHttp,Spring为我们封装了一个基于Restful的使用非常简单的Http客户端工具 RestTemplate ,我们就用它来实订单服务和用户服务的通信。
RestTemplate 的流程如图:
使用RestTemplate很简单,我们可以在启动类中注入RestTemplate
@Bean //注入RestTemplate进容器
public RestTemplate restTemplate(){
return new RestTemplate();
}
在我们需要使用的controller层注入并调用restTemplate的getForObject(url地址,类型)方法就可实现微服务通信。
第五章 Ribbon客户端负载均
Ribbon是Netflix发布的云中间层服务开源项目,主要功能是提供客户端负载均衡算法
。
在微服务中避免不了集群,为了防止应用出现单节点故障问题,同时为了提高应用的作业能力,在微服务中做集群就需要负载均衡,在Netflix中可以使用Ribbon和 Feign做负载均衡。本文介绍Ribbon的流程和使用。
1、Ribbon的工作机制
Ribbon可以按照负载均衡算法(如简单轮询,随机连接等)向多个服务发起调用
,我们也很容易使用Ribbon实现自定义的负载均衡算法,默认使用轮询。
例如:a-server会定时把服务通信地址清单拉取到本地进行缓存
, 那么当b-server在向a-server发起调用时,需要指定服务名为 a-server
;那么这个时候,ribbon会根据a-server这个服务名找到两个b-server的通信地址
, 然后ribbon会按照负载均衡算法(默认轮询)选择其中的某一个通信地址,发起http请求实现服务的调用.如图:
2、使用Ribbon
导入依赖:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-ribbon</artifactId>
</dependency>
在需要开启负载均衡的地方打上注解@LoadBalanced就可具有负载均衡功能
3、Ribbon内置算法
Ribbon内置7种负载均衡算法,每种算法对应了一个算法类如下:
总结
本文对SpringCloud做了简单介绍,并对SpringCloud的常用组件Eureka和Ribbon做了详细介绍和它们的使用流程,文章如有雷同纯属巧合,如需转载请私信联系,本文为Java技术小白,日常分享学习心得,欢迎您的探讨和交流。