微服务基础知识

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	微服务
组件⼤⼩	⼤块业务逻辑	单独任务或⼩块业务逻辑
耦合	通常松耦合	总是松耦合
公司架构	任何类型	⼩型、专注于功能交叉团队
管理	着重中央管理	着重分散管理
⽬标	确保应⽤能够交互操作	执⾏新功能、快速拓展开发团队

总结：单体应⽤架构--->垂直应⽤架构--->分布式架构--->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理论，我们得知任何分布式系统只可同时满⾜⼆点，没法三者兼顾，既然⼀个分布 式系统⽆法同时满⾜⼀致性、可⽤性、分区容错性三个特点，所以我们就需要抛弃⼀样：

选 择	说 明
CA	放弃分区容错性，加强⼀致性和可⽤性，其实就 是传统的关系型数据库的选择
AP	放弃⼀致性（这⾥说的⼀致性是强⼀致性），追 求分区容错性和可⽤性，这是很多分布式 系统设 计时的选择，例如很多NoSQL系统就是如此
CP	放弃可⽤性，追求⼀致性和分区容错性，基本不 会选择，⽹络问题会直接让整个系统不可⽤

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服务⽹关

Spring Cloud Alibaba组件

组件名称	作⽤
Nacos	服务注册中⼼
Sentinel	客户端容错保护

Spring Cloud原⽣及其他组件

组件	作⽤
Consul	服务注册中⼼
Config	分布式配置中⼼
Gateway	API服务⽹关
Sleuth/Zipkin	分布式链路追踪

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服务的⽅式。

在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

//配置RestTemplate交给spring管理
@Bean
public RestTemplate getRestTemplate() {
return new RestTemplate();
}

（ 2 ）编写下订单⽅法

//通过restTemplate调⽤商品微服务
restTemplate .getForObject("http://127.0.0.1:8081/product/1" , Product.class);

3.5.4 硬编码存在的问题

⾄此已经可以通过RestTemplate调⽤商品微服务的RESTFul API接⼝。但是我们把提供者的⽹络地址 （ip，端⼝）等硬编码到了代码中，这种做法存在许多问题：

• 应⽤场景有局限
• ⽆法动态调整

就需要通过注册中⼼动态的对服务注册和服务发现