深入浅出的学习微服务之架构


微服务架构

微服务架构到底是怎么样的?

  • 服务提供者按照一定的格式的服务描述,向注册中心注册服务,声明自己能够提供哪些服务,以及服务地址是什么,完成服务发布。
  • 服务消费者请求注册中心,查询所需要调用的服务地址,然后以约定的通信协议向服务提供者发起请求,得到请求结果后再按照约定的协议解析结果

而且在服务调用过程中,服务的请求耗时,调用量,以及成功率等指标都会被记录下来用作监控,调用经过的链路信息会记录下来,用于故障定位和问题追踪。在这期间,如果调用失败,可以通过重试等服务治理手段来保证成功率。

微服务架构下 服务调用主要依赖于下面几个组件

服务描述

服务调用首先要解决的问题就是服务如何对外描述。比如,你对外提供了一个服务,那么这个服务的服务名是什么?调用这个服务需要提供哪些信息?调用这个服务返回的结果是什么格式的?该如何解析?这些就是服务描述要解决的问题。

常见的服务描述方式有RESTful API,XML 配置以及IDL文件三种。

RESTful API方式通常用于HTTP协议的服务描述,并且常用Wiki或者Swagger来进行管理。下面是一个RESTful API方式的服务描述的例子。

在这里插入图片描述
XML配置方式多用作RPC协议的服务描述,通过*.xml配置文件来定义接口名,参数以及返回值类型等。下面是XML配置方式的服务描述 的例子。
在这里插入图片描述

IDL 文件方式通常用作 Thrift 和 gRPC 这类跨语言服务调用框架中,比如gRPC就是通过Protobuf文件来定义服务的接口名,参数以及返回值的数据结构,实例如下:
在这里插入图片描述

注册中心

有了服务的接口描述,下一步要解决的问题就是服务的发布和订阅,就是说你提供一个服务,如何让外部想调用你的服务的人知道。这个时候就需要一个类似注册中心的角色,服务提供者将自己提供的服务以及地址登记到注册中心,服务消费者则从注册中心查询所需调用的服务的地址,然后发起请求。

注册中心的工作流程是:
  • 服务提供者在启动时,根据服务发布文件中配置的发布信息向注册中心注册自己的服务。
  • 服务消费者在启动时,根据消费者配置文件中配置的服务信息向注册中心订阅自己所需要的服务。
  • 注册中心返回服务提供者地址列表给服务消费者。
  • 当服务提供服务者发生变化,比如有节点新增或者销毁,注册中心将变更通知给服务消费者。

在这里插入图片描述

服务框架

通过注册中心,服务消费者就可以获取到服务提供者的地址,有了地址就可以发起调用。但在发起调用之前你还需要解决以下几个问题。

服务通信采用什么协议?就是说服务提供者和服务消费者之间以什么样的协议进行网络通信,是采用四层TCP,UDP协议,还是采用七层HTTP协议,还是采用其他协议?

数据传输采用什么方式?就是说服务提供者和服务消费者之间的数据传输采用哪种方式,是同步还是异步,实在单连接传输,还是多路复用。

数据压缩采用什么格式?通常数据传输都会对数据进行压缩,来减少网络传输的数据量,从而减少带宽消耗和网络传输时间,比如常见的JSON序列化,Java对象序列化以及Protobuf序列化等。

服务监控

一旦服务消费者和服务提供者之间能够正常发起服务调用,你就需要对调用情况进行监控,以了解服务是否正常。通常来讲,服务监控主要包括三个流程。

指标收集。就是要吧每一次服务调用的请求耗时以及成功与否收集起来,并上传到集中的数据处理中心
数据处理。有了每次调用的请求耗时以及成功与否等i西南西,就可以计算每秒服务请求量,平均耗时以及成功率等指标。

服务追踪

除了需要对服务调用情况进行监控之外,你还需要记录服务调用经过的每一层链路,以便进行问题追踪和故障定位。
服务追踪的工作原理大致如下:

  • 服务消费者发起调用前,会在本地按照一定的规则生成一个requestid,发起调用时,将requestid当作请求参数的一部分,传递给服务提供者。
  • 服务提供者接收到请求后,记录下这次请求的requestid,然后处理请求。如果服务提供者继续请求其他服务,会在本地再生成一个自己的requestid,然后把这两个requestid都当作请求参数传递下去。

以此类推,通过这种层层往下传递的方式,一次请求,无论最后依赖多少服务调用,经过多少服务节点,都可以通过最开始生成的requestid串联所有节点,从而达到服务追踪的目的。

服务治理

服务监控能够发现问题,服务追踪能够定位问题所在,而解决问题就的靠服务治理。服务治理就是通过一系列的手段来保证在各种意外情况下,服务调用仍然能够正常进行。

  • 单机故障。通常遇到单机故障,都是靠运维发现并重启服务或者从线上摘除故障节点。然而集群的规模越大,越是容易遇到单机故障,在机器规模超过一百台以上时,靠传统的人肉运维显然难以应对。而服务治理可以通过一定的策略,自动摘除故障节点,不需要认为干预,就能保证单机故障不会影响业务
  • 单IDC故障。你应该经常听说某APP,因为施工挖断光缆导致大批量用户无法使用的严重故障。而服务治理可以通过自动化切换故障IDC的流量到其他正常IDC,可以避免因为单IDC故障引起的大批量业务受影响。
  • 依赖服务不可用。比如你的服务依赖另一个服务,当另一个服务出现问题时,会拖慢甚至拖垮你的服务。而服务治理可以通过限流,在依赖服务异常的情况下,一段时间内停止发起调用而直接放回,这样一方面保证了服务消费者能够不被拖垮,另一方面也给服务提供者减少压力,使其能够尽快恢复。

总结

这几个基本组件共同组成了微服务架构,在生产环境下缺一不可,所以在引入微服务架构之前,你的团队必须掌握这些基本组件的原理并具备相应的开发能力。

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值