1 微服务基础知识
1.1 系统架构的演变
随着互联⽹的发展,⽹站应⽤的规模不断扩⼤,常规的应⽤架构已⽆法应对,分布式服务架构以及微服 务架构势在必⾏,必需⼀个治理系统确保架构有条不紊的演进。
1.1.1 单体应⽤架构
Web应⽤程序发展的早期,⼤部分web⼯程(包含前端⻚⾯,web层代码,service层代码,dao层代码)是将 所 有的功能模块,打包到⼀起并放在⼀个web容器中运⾏。
⽐如搭建⼀个电商系统:客户下订单,商品展示,⽤户管理。这种将所有功能都部署在⼀个web容器中 运⾏的系统就叫做单体架构。
优点:
- 所有的功能集成在⼀个项⽬⼯程中
- 项⽬架构简单,前期开发成本低,周期短,⼩型项⽬的⾸选
缺点:
- 全部功能集成在⼀个⼯程中,对于⼤型项⽬不易开发、扩展及维护。
- 系统性能扩展只能通过扩展集群结点,成本⾼、有瓶颈。
- 技术栈受限。
1.1.2 垂直应⽤架构
当访问量逐渐增⼤,单⼀应⽤增加机器带来的加速度越来越⼩,将应⽤拆成互不相⼲的⼏个应⽤,以提 升效率
优点 :
- 项⽬架构简单,前期开发成本低,周期短,⼩型项⽬的⾸选。
- 通过垂直拆分,原来的单体项⽬不⾄于⽆限扩⼤
- 不同的项⽬可采⽤不同的技术。
缺点 :
- 全部功能集成在⼀个⼯程中,对于⼤型项⽬不易开发、扩展及维护。
- 系统性能扩展只能通过扩展集群结点,成本⾼、有瓶颈。
1.1.3 分布式SOA架构
1.1.3.1 什么是SOA
SOA 全称为 Service-Oriented Architecture,即⾯向服务的架构。它可以根据需求通过⽹络对松散耦合 的粗粒度应⽤组件(服务)进⾏分布式部署、组合和使⽤。⼀个服务通常以独⽴的形式存在于操作系统进程 中。
站在功能的⻆度,把业务逻辑抽象成可复⽤、可组装的服务,通过服务的编排实现业务的快速再⽣,⽬ 的:把原先固有的业务功能转变为通⽤的业务服务,实现业务逻辑的快速复⽤。
通过上⾯的描述可以发现 SOA 有如下⼏个特点:分布式、可重⽤、扩展灵活、松耦合
1.1.3.2 SOA架构
当垂直应⽤越来越多,应⽤之间交互不可避免,将核⼼业务抽取出来,作为独⽴的服务,逐渐形成稳定 的服务 中⼼,使前端应⽤能更快速的响应多变的市场需求
优点 :
- 抽取公共的功能为服务,提⾼开发效率
- 对不同的服务进⾏集群化部署解决系统压⼒
- 基于ESB/DUBBO减少系统耦合
缺点 :
- 抽取服务的粒度较⼤
- 服务提供⽅与调⽤⽅接⼝耦合度较⾼
1.1.4 微服务架构
优点 :
- 通过服务的原⼦化拆分,以及微服务的独⽴打包、部署和升级,⼩团队的交付周期将缩短,运维成 本 也将⼤幅度下降
- 微服务遵循单⼀原则。微服务之间采⽤Restful等轻量协议传输。
缺点 :
- 微服务过多,服务治理成本⾼,不利于系统维护。
- 分布式系统开发的技术成本⾼(容错、分布式事务等)。
1.1.5 SOA与微服务的关系
SOA( Service Oriented Architecture )“⾯向服务的架构”:他是⼀种设计⽅法,其中包含多个服务, 服务之间通过相互依赖最终提供⼀系列的功能。 ⼀个服务通常以独⽴的形式存在与操作系统进程中。各 个服务之间通过⽹络调⽤。
微服务架构:其实和SOA 架构类似,微服务是在SOA上做的升华,微服务架构强调的⼀个重点是“业务需 要 彻底的组件化和服务化” ,原有的单个业务系统会拆分为多个可以独⽴开发、设计、运⾏的⼩应⽤。
这些⼩应⽤之间通过服务完成交互和集成
总结:单体应⽤架构--->垂直应⽤架构--->分布式架构--->SOA架构--->微服务架构,当然还有悄然 兴起的Service Mesh(服务⽹格化)。
1.2 分布式核⼼知识
1.2.1 分布式中的远程调⽤
在微服务架构中,通常存在多个服务之间的远程调⽤的需求。远程调⽤通常包含两个部分:序列化和通 信协议。常⻅的序列化协议包括json、xml、 hession、 protobuf、thrift、text、 bytes等,⽬前主流的 远程调⽤技术有基于HTTP的RESTful接⼝以及基于TCP的RPC协议。
( 1 )RESTful接⼝
REST,即Representational State Transfer的缩写,如果⼀个架构符合REST原则,就称它为RESTful架 构。
资源(Resources )
所谓"资源" ,就是⽹络上的⼀个实体,或者说是⽹络上的⼀个具体信息。它可以是⼀段⽂本、 ⼀张图 ⽚、 ⼀⾸歌曲、 ⼀种服务,总之就是⼀个具体的实在。你可以⽤⼀个URI(统⼀资源定位符)指向它, 每种资源对应⼀个特定的URI。要获取这个资源,访问它的URI就可以,因此URI就成了每⼀个资源的地 址或独⼀⽆⼆的识别符。 REST的名称"表现层状态转化"中,省略了主语。 "表现层"其实指的是"资 源"( Resources)的 "表现层"。
表现层(Representation)
"资源"是⼀种信息实体,它可以有多种外在表现形式。我们把"资源"具体呈现出来的形式,叫做它的"表 现层"(Representation)。⽐如,⽂本可以⽤txt格式表现,也可以⽤HTML格式、XML格式、JSON格 式表现,甚⾄可以采⽤⼆进制格式;图⽚可以⽤JPG格式表现,也可以⽤PNG格式表现。 URI只代表 资源的实体,不代表它的形式。严格地说,有些⽹址最后的".html"后缀名是不必要的,因为这个后缀名 表示 格式,属于"表现层"范畴,⽽URI应该只代表"资源"的位置。
状态转化(State Transfer )
访问⼀个⽹站,就代表了客户端和服务器的⼀个互动过程。在这个过程中,势必涉及到数据和状态的变 化。互联⽹通信协议HTTP协议,是⼀个⽆状态协议。这意味着,所有的状态都保存在服务器端。因此, 如果客户端想要操作服务器,必须通过某种⼿段,让服务器端发⽣"状态转化"( State Transfer )。 客 户端⽤到的⼿段,只能是HTTP协议。具体来说,就是HTTP协议⾥⾯,四个表示操作⽅式的动词:
GET、 POST、 PUT、 DELETE。它们分别对应四种基本操作:GET⽤来获取资源,POST⽤来新建资 源 (也可以⽤于更新资源),PUT⽤来更新资源,DELETE⽤来删除资源。 综合上⾯的解释,我们总结⼀下什么是RESTful架构:
- 每⼀个URI代表⼀种资源;
- 客户端和服务器之间,传递这种资源的某种表现层;
- 客户端通过四个HTTP动词,对服务器端资源进⾏操作,实现"表现层状态转化"。
( 2 )RPC协议
RPC( Remote Procedure Call )⼀种进程间通信⽅式。允许像调⽤本地服务⼀样调⽤远程服务。 RPC框架的主要⽬标就是让远程服务调⽤更简单、透明。 RPC框架负责屏蔽底层的传输⽅式(TCP或者 UDP)、序列化⽅式(XML/JSON/⼆进制)和通信细节。开发⼈员在使⽤的时候只需要了解谁在什么位 置提供了什么样的远程服务接⼝即可,并不需要关⼼底层通信细节和调⽤过程。
( 3)区别与联系
⽐较项 | RESTful | RPC |
通讯协议 | HTTP | ⼀般使⽤TCP |
性能 | 略低 | 较⾼ |
灵活度 | ⾼ | 低 |
应⽤ | 微服务架构 | SOA架构 |
1、 HTTP相对更规范,更标准,更通⽤,⽆论哪种语⾔都⽀持http协议。如果你是对外开放API,例如 开放平台,外部的编程语⾔多种多样,你⽆法拒绝对每种语⾔的⽀持,现在开源中间件,基本最先⽀持 的⼏个协议都包含RESTful。
2、 RPC 框架作为架构微服务化的基础组件,它能⼤⼤降低架构微服务化的成本,提⾼调⽤⽅与服务提 供⽅的研发效率,屏蔽跨进程调⽤函数(服务)的各类复杂细节。让调⽤⽅感觉就像调⽤本地函数⼀样 调⽤远端函数、让服务提供⽅感觉就像实现⼀个本地函数⼀样来实现服务
1.2.2 分布式中的CAP原理
现如今,对于多数⼤型互联⽹应⽤,分布式系统(distributed system)正变得越来越重要。分布式系 统的最⼤难点,就是各个节点的状态如何同步。 CAP 定理是这⽅⾯的基本定理,也是理解分布式系统 的起点。
CAP理论由 Eric Brewer 在ACM研讨会上提出,⽽后CAP被奉为分布式领域的重要理论。分布式系统的 CAP理 论,⾸先把分布式系统中的三个特性进⾏了如下归纳:
Consistency(⼀致性) :数据⼀致更新,所有数据的变化都是同步的
Availability(可⽤性) :在集群中⼀部分节点故障后,集群整体是否还能响应客户端的读写请求
Partition tolerance(分区容忍性) :某个节点的故障,并不影响整个系统的运⾏
通过学习CAP理论,我们得知任何分布式系统只可同时满⾜⼆点,没法三者兼顾,既然⼀个分布 式系统 ⽆法同时满⾜⼀致性、可⽤性、分区容错性三个特点,所以我们就需要抛弃⼀样:
1.3 常⻅微服务框架
1.3.1 SpringCloud
Spring Cloud是⼀系列框架的有序集合。它利⽤Spring Boot的开发便利性巧妙地简化了分布式系统基 础设施的开发,如服务发现注册、配置中⼼、消息总线、负载均衡、断路器、数据监控等,都可以⽤ Spring Boot的开发⻛格做到⼀键启动和部署。 Spring Cloud并没有重复制造轮⼦,它只是将⽬前各家 公司开发的⽐较成熟、经得起实际考验的服务框架组合起来,通过Spring Boot⻛格进⾏再封装屏蔽掉 了复杂的配置和实现原理,最终给开发者留出了⼀套简单易懂、易部署和易维护的分布式系统开发⼯具 包。
1.3.2 ServiceComb
Apache ServiceComb是业界第⼀个Apache微服务顶级项⽬, 是⼀个开源微服务解决⽅案,致⼒于帮助 企业、⽤户和开发者将企业应⽤轻松微服务化上云,并实现对微服务应⽤的⾼效运维管理。其提供⼀站 式开源微服务解决⽅案,融合SDK框架级、 0侵⼊ServiceMesh场景并⽀持多语⾔。
1.3.3 ZeroC ICE
ZeroC IceGrid是ZeroC公司的杰作,继承了CORBA的⾎统,是新⼀代的⾯向对象的分布式系统中间件。 作为⼀种微服务架构,它基于RPC框架发展⽽来,具有良好的性能与分布式能⼒。
2 SpringCloud概述
2.1 微服务中的相关概念
2.1.1 服务注册与发现
服务注册:服务实例将⾃身服务信息注册到注册中⼼。这部分服务信息包括服务所在主机IP和提供服务 的Port ,以及暴露服务⾃身状态以及访问协议等信息。 服务发现:服务实例请求注册中⼼获取所依赖服务信息。服务实例通过注册中⼼,获取到注册到其中的 服务实例的信息,通过这些信息去请求它们提供的服务。
2.1.2 负载均衡
负载均衡是⾼可⽤⽹络基础架构的关键组件,通常⽤于将⼯作负载分布到多个服务器来提⾼⽹站、应 ⽤、数据库或其他服务的性能和可靠性。
2.1.3 熔断
熔断这⼀概念来源于电⼦⼯程中的断路器(Circuit Breaker)。在互联⽹系统中,当下游服务因访问压 ⼒过⼤⽽响应变慢或失败,上游服务为了保护系统整体的可⽤性,可以暂时切断对下游服务的调⽤。这 种牺牲局部,保全整体的措施就叫做熔断。
2.1.4 链路追踪
随着微服务架构的流⾏,服务按照不同的维度进⾏拆分,⼀次请求往往需要涉及到多个服务。互联⽹应 ⽤构建在不同的软件模块集上,这些软件模块,有可能是由不同的团队开发、可能使⽤不同的编程语⾔ 来实现、有可能布在了⼏千台服务器,横跨多个不同的数据中⼼。因此,就需要对⼀次请求涉及的多个 服务链路进⾏⽇志记录,性能监控即链路追踪
2.1.5 API⽹关
随着微服务的不断增多,不同的微服务⼀般会有不同的⽹络地址,⽽外部客户端可能需要调⽤多个服务 的接⼝才能完成⼀个业务需求,如果让客户端直接与各个微服务通信可能出现:
- 客户端需要调⽤不同的url地址,增加难度
- 再⼀定的场景下,存在跨域请求的问题
- 每个微服务都需要进⾏单独的身份认证 针对这些问题,API⽹关顺势⽽⽣。
API⽹关直⾯意思是将所有API调⽤统⼀接⼊到API⽹关层,由⽹关层统⼀接⼊和输出。 ⼀个⽹关的基本 功能有:统⼀接⼊、安全防护、协议适配、流量管控、⻓短链接⽀持、容错能⼒。有了⽹关之后,各个 API服务提供团队可以专注于⾃⼰的的业务逻辑处理,⽽API⽹关更专注于安全、流量、路由等问题。
2.2 SpringCloud的介绍
Spring Cloud是⼀系列框架的有序集合。它利⽤Spring Boot的开发便利性巧妙地简化了分布式系统基 础设施的开发,如服务发现注册、配置中⼼、消息总线、负载均衡、断路器、数据监控等,都可以⽤ Spring Boot的开发⻛格做到⼀键启动和部署。 Spring Cloud并没有重复制造轮⼦,它只是将⽬前各家 公司开发的⽐较成熟、经得起实际考验的服务框架组合起来,通过Spring Boot⻛格进⾏再封装屏蔽掉 了复杂的配置和实现原理,最终给开发者留出了⼀套简单易懂、易部署和易维护的分布式系统开发⼯具 包。
2.3 SpringCloud的架构
2.3.1 SpringCloud中的核⼼组件
Spring Cloud的本质是在 Spring Boot 的基础上,增加了⼀堆微服务相关的规范,并对应⽤上下⽂进⾏ 了功能增强。既然 Spring Cloud 是规范,那么就需要去实现,⽬前Spring Cloud 规范已有 Spring官 ⽅,Spring Cloud Netflix ,Spring Cloud Alibaba等实现。通过组件化的⽅式,Spring Cloud将这些实 现整合到⼀起构成全家桶式的微服务技术栈。
Spring Cloud Netflix组件
组件名称 | 作⽤ |
Eureka | 服务注册中⼼ |
Ribbon | 客户端负载均衡 |
Feign | 声明式服务调⽤ |
Hystrix | 客户端容错保护 |
Zuul | API服务⽹关 |
3 案例搭建
使⽤微服务架构的分布式系统,微服务之间通过⽹络通信。我们通过服务提供者与服务消费者来描述微服 务间的调⽤关系。
服务提供者:服务的被调⽤⽅,提供调⽤接⼝的⼀⽅
服务消费者:服务的调⽤⽅,依赖于其他服务的⼀⽅
我们以电商系统中常⻅的⽤户下单为例,⽤户向订单微服务发起⼀个购买的请求。在进⾏保存订单之前 需要调⽤商品微服务查询当前商品库存,单价等信息。在这种场景下,订单微服务就是⼀个服务消费 者,商品微服务就是⼀个服务提供者
3.1 数据库表
shop_order订单表
shop_product商品表
shop_user⽤户表
3.2 服务模块
创建公共⽗模块springcloud_alibaba
创建公共模块 shop_common ,⽤于存放公共的实体类和⼯具类
创建订单微服务模块 shop_order 端⼝809X
创建商品微服务模块 shop_product 端⼝808X
创建⽤户微服务模块 shop_user 端⼝807X
3.3 服务调⽤
前⽂已经编写了三个基础的微服务,在⽤户下单时需要调⽤商品微服务获取商品数据。那应该怎么做 呢?总⼈皆知商品微服务提供了供⼈调⽤的HTTP接⼝。所以可以再下定单的时候使⽤http请求的相关⼯ 具类完成,如常⻅的HttpClient ,OkHttp,当然也可以使⽤Spring提供的RestTemplate
3.5.1 RestTemplate介绍
Spring框架提供的RestTemplate类可⽤于在应⽤中调⽤rest服务,它简化了与http服务的通信⽅式,统 ⼀了RESTful的标准,封装了http链接, 我们只需要传⼊url及返回值类型即可。相较于之前常⽤的 HttpClient ,RestTemplate是⼀种更优雅的调⽤RESTful服务的⽅式。
package com.xn.controller;
import com.xn.domain.Order;
import com.xn.domain.Product;
import com.xn.service.IOrderService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.client.RestTemplate;
@RestController
public class OrderController {
@Autowired
private RestTemplate restTemplate;
@Autowired
private IOrderService orderService;
//下单
@RequestMapping("/order/prod/{pid}")
public Order order(@PathVariable("pid") Integer pid) {
//调用商品微服务,查询商品信息
Product product =
restTemplate.getForObject("http://localhost:8081/product/" + pid, Product.class);
//下单(创建订单)
Order order = new Order();
order.setUid(1);
order.setUsername("测试用户");
order.setPid(pid);
order.setPname(product.getPname());
order.setPprice(product.getPprice());
order.setNumber(1);
orderService.createOrder(order);
return order;
}
}
在Spring应⽤程序中访问第三⽅REST服务与使⽤Spring RestTemplate类有关。 RestTemplate类的设 计 原则与许多其他Spring 模板类(例如JdbcTemplate、JmsTemplate)相同,为执⾏复杂任务提供了⼀ 种具有默认⾏为的简化⽅法。 RestTemplate默认依赖JDK提供http连接的能⼒(HttpURLConnection),如果有需要的话也可以通过 setRequestFactory⽅法替换为例如 Apache HttpComponents、 Netty或OkHttp等其它HTTP library。 考虑到RestTemplate类是为调⽤REST服务⽽设计的,因此它的主要⽅法与REST的基础紧密相连就不⾜ 为奇了,后者是HTTP协议的⽅法:HEAD、GET、 POST、 PUT、 DELETE和OPTIONS。例如, RestTemplate类具有headForHeaders()、getForObject()、 postForObject()、 put()和delete()等⽅ 法。
3.5.2 RestTemplate⽅法介绍
3.5.3 通过RestTemplate调⽤微服务
( 1 )在 shop_order⼯程中配置RestTemplate
( 2 )编写下订单⽅法
案例:
公共⽗模块springcloud_alibaba坐标
<!-- 项目基本信息 -->
<groupId>com.xn</groupId>
<artifactId>springcloud_alibaba</artifactId>
<version>1.0-SNAPSHOT</version>
<!-- pom:父文件 -->
<packaging>pom</packaging>
<!-- 父项目的子模块 -->
<modules>
<module>shop_common</module>
<module>shop_user</module>
<module>shop_product</module>
<module>shop_order</module>
</modules>
<!-- 父工程 -->
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.1.3.RELEASE</version>
</parent>
<!-- 依赖版本的锁定 -->
<properties>
<java.version>1.8</java.version>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<spring-cloud.version>Greenwich.RELEASE</spring-cloud.version>
<spring-cloud-alibaba.version>2.1.1.RELEASE</spring-cloud-alibaba.version>
</properties>
<!--
dependencyManagement所包含的坐标,子项目不会直接继承,需要声明才可继承
-->
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>${spring-cloud.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-alibaba-dependencies</artifactId>
<version>${spring-cloud-alibaba.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>v
shop_product 坐标
<!-- springboot-web -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<!-- shop-common -->
<dependency>
<groupId>com.xn</groupId>
<artifactId>shop_common</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
</dependencies>
Controller
package com.xn.controller;
import com.alibaba.fastjson.JSON;
import com.xn.domain.Product;
import com.xn.service.IProductService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
public class ProductController {
@Autowired
private IProductService productService;
//商品信息查询
@RequestMapping("/product/{pid}")
public Product product(@PathVariable("pid") Integer pid) {
Product product = productService.getById(pid);
return product;
}
}
dao
package com.xn.dao;
import com.xn.domain.Product;
import com.baomidou.mybatisplus.core.mapper.BaseMapper;
import org.apache.ibatis.annotations.Mapper;
@Mapper
public interface ProductMapper extends BaseMapper<Product> {
}
IProductService
package com.xn.service;
import com.xn.domain.Product;
import com.baomidou.mybatisplus.extension.service.IService;
public interface IProductService extends IService<Product> {
}
ProductServiceImpl
package com.xn.service.impl;
import com.xn.dao.ProductMapper;
import com.xn.domain.Product;
import com.xn.service.IProductService;
import com.baomidou.mybatisplus.extension.service.impl.ServiceImpl;
import org.springframework.stereotype.Service;
@Service
public class ProductServiceImpl extends ServiceImpl<ProductMapper, Product> implements IProductService {
}
package com.xn;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
@SpringBootApplication
public class ProductApplication {
public static void main(String[] args) {
SpringApplication.run(ProductApplication.class);
}
}
3.5.4 硬编码存在的问题
⾄此已经可以通过RestTemplate调⽤商品微服务的RESTFul API接⼝。但是我们把提供者的⽹络地址 (ip,端⼝)等硬编码到了代码中,这种做法存在许多问题:
- 应⽤场景有局限
- ⽆法动态调整
就需要通过注册中⼼动态的对服务注册和服务发现