初探微服务架构
之前介绍了什么时候进行服务化,以及服务化拆分的两种方式即横向拆分和纵向拆分,还提到了引入微服务架构需要解决的问题。
这篇文章将进行介绍微服务架构的各个组成部分。
下图是微服务架构的模块图,在具体介绍之前先来看下一次正常的服务调用的流程。
首先服务提供者(就是提供服务的一方)按照一定格式的服务描述,向注册中心注册服务,声明自己能够提供哪些服务以及服务的地址是什么,完成服务发布。
接下来服务消费者(就是调用服务的一方)请求注册中心,查询所需要调用服务的地址,然后以约定的通信协议向服务提供者发起请求,得到请求结果后再按照约定的协议解析结果。
而且在服务的调用过程中,服务的请求耗时、调用量以及成功率等指标都会被记录下来用作监控,调用经过的链路信息会被记录下来,用于故障定位和问题追踪。在这期间,如果调用失败,可以通过重试等服务治理手段来保证成功率。
总结一下,微服务架构下,服务调用主要依赖下面几个基本组件:
- 服务描述:RESTful API (HTTP)、XML 配置(RPC)、IDL 文件(gRPC/Thrift)
- 注册中心:注册(服务提供者->注册中心)、订阅(服务消费者->注册中心)、返回(注册中心->服务消费者)、通知(注册中心->服务消费者)
- 服务框架:通信框架、通信协议、序列化和反序列化
- 服务监控(发现问题):指标收集、数据处理、数据展现
- 服务追踪(定位问题):RequestId传递
- 服务治理(解决问题):单机故障-自动摘除、单IDC故障-自动切换、依赖服务不可用-熔断
接下来进行介绍这些组件。
服务描述
服务调用首先解决的问题就是服务如何对外描述。服务描述主要解决对外服务的服务名是什么,调用需要提供哪些信息,返回格式是什么以及如何进行解析。
常用的服务描述方式包括 RESTful API、XML 配置以及 IDL 文件三种。
RESTful API 方式通常用于 HTTP 协议的服务描述。RESTful API 方式的服务描述如下:
GET /sysDictoryDict/mapByUserId/{userId} POST /enterprise/enterpriseDetail/top PUT /enterprise/{enterpriseId} DELETE /enterprise/{enterpriseId}
XML 配置方式多用作 RPC 协议的服务描述,通过 *.xml 配置文件来定义接口名、参数以及返回值类型等。XML 配置方式的服务描述主要分三个步骤:
- 服务提供者定义接口,并实现接口
- 服务提供者进程启动时,通过加载 server.xml 配置文件将接口暴露出去。
- 服务消费者进程启动时,通过加载 client.xml 配置文件引入要调用的接口。
IDL 文件方式通常用作 Thrift 和 gRPC 这类跨语言服务调用框架中,比如 gRPC 就是通过 Protobuf 文件来定义服务的接口名、参数以及返回值的数据结构。
服务描述方式比较
服务描述方式 | 使用场景 | 缺点 |
---|---|---|
RESTful API | 跨语言平台,组织内外都适用 | 相比 TCP,HTTP 作为通信协议性能较差 |
XML 配置 | Java 平台,一般用于组织内部 | 不支持跨语言平台 |
IDL 文件 | 跨语言平台,组织内外都适用 | 修改/删除 PB 字段不能向前兼容 |
注册中心
接下来要解决的问题就是服务的发布和订阅,也就是说你提供一个服务,如何让外部想调用这个服务的人知道。就需要注册中心出场了,服务提供者将自己提供的服务以及地址登记到注册中心,服务消费者则从注册中心查询所需要调用的服务的地址,然后发起请求。
在整个微服务架构中,注册中心是最基础的核心服务之一,它记录着服务和服务地址的映射关系,为服务提供方提供注册、注销功能,为服务消费方提供服务发现的功能。
注册中心一般的工作流程是:
- 服务提供者在启动时,根据服务发布文件中配置的发布信息向注册中心注册自己的服务。
- 服务消费者在启动时,根据消费者配置文件中配置的服务信息向注册中心订阅自己所需要的服务。
- 注册中心返回服务提供者地址列表给服务消费者。
- 当服务提供者发生变化,比如有节点新增或者销毁,注册中心将变更通知给服务消费者。
常见的注册中心有 Netflix 的 Eureka、HashiCorp 的 Consul、雅虎的 Zookeeper、阿里的 Nacos 等。
服务框架
通过注册中心,服务消费者就可以获取到服务提供者的地址,有了地址后就可以发起调用。但在发起调用之前你还需要解决以下几个问题。
- 服务通信采用什么协议?就是说服务提供者和服务消费者之间以什么样的协议进行网络通信,是采用四层 TCP、UDP 协议,还是采用七层 HTTP 协议,还是采用其他协议?
- 数据传输采用什么方式?就是说服务提供者和服务消费者之间的数据传输采用哪种方式,是同步还是异步,是在单连接上传输,还是多路复用。
- 数据压缩采用什么格式?通常数据传输都会对数据进行压缩,来减少网络传输的数据量,从而减少带宽消耗和网络传输时间,比如常见的 JSON 序列化、Java 对象序列化以及 Protobuf 序列化等。
这三部分就组成了一个完成的 RPC 调用框架,通信框架提供了基础的通信能力,通信协议描述了通信契约,而序列化和反序列化则用于数据的编/解码。一个通信框架可以适配多种通信协议,也可以采用多种序列化和反序列化的格式。
- 通信框架:解决客户端和服务端如何建立连接、管理连接以及服务端如何处理请求的问题。
- 通信协议:解决客户端和服务端采用哪些数据传输协议的问题。
- 序列化和反序列化:解决客户端和服务端采用哪种数据编码的问题。
服务监控
可以正常发起服务调用后,就需要对调用情况进行监控,以了解服务是否正常。通常来讲,服务监控主要包括三个流程。
- 指标收集:把每一次服务调用的请求耗时以及成功与否收集起来,并上传到集中的数据处理中心。
- 数据处理:根据每次调用的请求耗时以及成功与否等信息,就可以计算每秒服务请求量、平均耗时以及成功率等指标。
- 数据展示:通常都是将数据展示在 Dashboard 面板上,并且每隔 10s 等间隔自动刷新,用作业务监控和报警等。
服务追踪
记录服务调用经过的每一层链路,以便进行问题追踪和故障定位。
服务追踪的工作原理大致如下:
- 服务消费者发起调用前,会在本地按照一定的规则生成一个 requestid,发起调用时,将 requestid 当作请求参数的一部分,传递给服务提供者。
- 服务提供者接收到请求后,记录下这次请求的 requestid,然后处理请求。如果服务提供者继续请求其他服务,会在本地再生成一个自己的 requestid,然后把这两个 requestid 都当作请求参数继续往下传递。
以此类推,通过这种层层往下传递的方式,一次请求,无论最后依赖多少次服务调用、经过多少服务节点,都可以通过最开始生成的 requestid 串联所有节点,从而达到服务追踪的目的。
常用的服务追踪有 Twitter 的 Zipkin、华为的 skywalking、Uber 的 jaeger、大众点评的 CAT等。
服务治理
服务治理就是保证在各种意外情况下,服务调用仍然能够正常进行。
在生产环境中,经常会遇到下面几种情况:
- 单机故障:服务治理可以通过一定的策略,自动摘除故障节点,就能保证单机故障不会影响业务。
- 单 IDC 故障:服务治理可以通过自动切换故障 IDC 的流量到其他正常 IDC,可以避免因为单 IDC 故障引起的大批量业务受影响。
- 依赖服务不可用:服务治理可以通过熔断,在依赖服务异常的情况下,一段时期内停止发起调用而直接返回。既保证了服务消费者能够不被拖垮,也给服务提供者减少压力,使其能够尽快恢复。
还有其他服务治理的手段比如自动扩缩容、负载均衡、服务路由以及服务容错等。
总结
主要对微服务架构中的组件进行了介绍,微服务架构主要由服务描述、注册中心、服务框架、服务监控、服务追踪以及服务治理等组成。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
从单体应用走向服务化
之前讲解了什么是微服务:微服务的核心在于服务治理,微服务架构是将复杂臃肿的单体应用进行细粒度的服务化拆分,每个拆分出来的服务各自独立打包部署,并交由小团队进行开发和运维,从而极大地提高了应用交付的效率。 什么时候进行服务化拆分?拆分单体应用有哪些标准呢? 什么时候进行服务化拆分? 比如做社交 App,初期为了快速上线,验证可行性,可以只开发首页信息流、评论等基本功能。产品上线后,经过一段时间的运营,用户开始逐步增多,可行性验证通过,下一阶段就需要进一步增加更多的新特性来吸引更多的目标用户,比如再给这个社交 App 添加个人主页显示、消息通知等功能。 这个时候就需要大规模地扩张开发人员,以支撑多个功能的开发。如果这个时候继续采用单体应用架构,多个功能模块混杂在一起开发、测试和部署的话,就会导致不同功能之间相互影响,一次打包部署需要所有的功能都测试 OK 才能上线。而且,多个功能模块混部在一起,对线上服务的稳定性也是个巨大的挑战。 再例举一个 58 到家的例子,随着业务越来越复杂,数据量越来越大,并发量越来越大,15 年的时候,58 到家的架构碰到了种种问题: 垂直业务扩展,家政、丽人、速...
- 下一篇
Java中Set集合是如何实现添加元素保证不重复的?
Java中Set集合是如何实现添加元素保证不重复的? Set集合是一个无序的不可以重复的集合。今天来看一下为什么不可以重复。 Set是一个接口,最常用的实现类就是HashSet,今天我们就拿HashSet为例。 先简单介绍一下HashSet类 HashSet类实现了Set接口, 其底层其实是包装了一个HashMap去实现的。HashSet采用HashCode算法来存取集合中的元素,因此具有比较好的读取和查找性能。 先看下HashSet的几个构造方法。 // 默认构造函数 底层创建一个HashMap public HashSet() { // 调用HashMap的默认构造函数,创建map map = new HashMap<E,Object>(); } // 带集合的构造函数 public HashSet(Collection<? extends E> c) { // 创建map。 map = new HashMap<E,Object>(Math.max((int) (c.size()/.75f) + 1, 16)); // 将集合(c)中的全部元素添...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- CentOS关闭SELinux安全模块
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- CentOS7安装Docker,走上虚拟化容器引擎之路
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS7设置SWAP分区,小内存服务器的救世主
- Red5直播服务器,属于Java语言的直播服务器
- Docker快速安装Oracle11G,搭建oracle11g学习环境