一、服务的三要素
一个网络服务主要包括以下三个要素:
地址: 调用方需要根据地质访问网络。IP地址、服务端口、服务协议;
协议格式: 协议都有哪些字段
协议名称: 或者叫协议类型,用协议类型(名称)区分不同的网络接口。
服务调用的寻址过程如下:
名词解释:
服务实例: 服务对应的IP地址加端口的简称。
服务注册: 某个服务实例宣称自己提供了哪些服务,即某个IP地址+端口都提供了哪些服务接口。
服务发现: 调用方通过某种方式找到提供方,即知道服务运行的IP+端口。
服务注册是服务器的行为,服务发现是客户端的行为叭。
二、具体如何调用
2.1 调用方式
2.1.1 基于IP地址的调用
即把IP地址暴露给调用者,缺点如下:
IP地址难于记忆且无意义;
如果使用IP地址进行寻址,则换机器就很麻烦。
所以,这种方式很不合理,不建议使用。
2.1.2 域名系统
域名系统的优点很明显,一个是名字有意义好记忆,而是,就算更换机器,也只需要更换域名对应的IP即可。
调用链:用户访问域名 -》 根据DNS协议解析IP地址 -》根据IP地址访问服务。
2.2 协议的接收和解析
一个网络协议主要包含两部分:
**协议包头:**存储协议的元信息,包括协议类型、报体长度、协议格式等;有固定大小,或者明确边界。
**协议包体:**具体的协议内容。
一般会采用状态机来做协议数据的接收:
一个协议,有多个字段,而不同的字段有不同的类型,该如何解析呢?常见手段:
使用json或者xml这样的数据结构 ,容易看明白,但是会容易被破解,且数据较大。
使用二进制协议,TVL格式(Type - Length - Value),但是可视性较差,容易出错。
google的Protocol Buffer(PB):具体如下:
优点:
1、使用proto格式(DSL(domain-specific language)文件)来定义协议,文中描述了协议的具体格式,每个字段的类型,字段是可选字段还是必选字段,客服端和服务器通过这个文件来进行协议的沟通和交流,而不是具体的技术细节。
2、PB能通过proto文件生成各种语言对应的序列化反序列化代码,利于跨语言调用。
3、PB能对特定类型的数据进行压缩,减少数据大小。
2.3 服务网关
随着越来越丰富的业务,单机服务器负载不了,肯定要多加服务器的。
2.3.1 在DNS解析的时候处理
在DNS解析的时候,将域名与多个地址进行绑定。
缺点:
1、如何监控实例的情况,做到发现问题的时候增删实例地址?
2、把这些服务暴露给外网,是否安全?
3、DNS增删服务并不是实时的,可能会影响到业务。
2.3.2 网关接入层
反向代理网关,提供功能:
负载均衡: 把所有的请求尽可能平均的分配到服务器上;
提供管理功能: 管理服务实例;
因为可以决定服务请求流量的走向,所以还可以做 灰度引流,安全防攻击等。
常见的负载均衡软件有两种,四层和七层。
四层:LVS (用于TCP协议)
七层:nginx(用于HTTP协议)
(1)、四层负载均衡:LVS
终端互联网用户从外部访问公司的外部负载均衡服务器,终端用户的Web请求会发送给LVS调度器,调度器根据自己预设的算法决定将该请求发送给后端的某台Web服务器。
(2)、七层负载均衡:Nginx
系统内部要访问外网的时候,统一通过一个代理服务器把请求发出去,代理服务器实现的就是正向代理。
如果有外部请求进入系统的时候,代理服务器把这些请求集中转发到某台服务器上,此时,代理服务器实现的就是反向代理。
所以,正向代理就是代理服务器代替系统内部向外发起请求的过程,而反向代理是外部请求通过代理服务器转发到内部服务器的过程。
反向代理的好处:
a.将请求均衡的发送给web服务器。
b.只用将反向代理服务器的地址暴露出去,做到限流、安全等。
c.统一接入客户端的请求,可以在反向代理的接入层做更多的控制,比如灰度流量发布、权重控制等。
2.4 服务发现与RPC
提供给外网的服务一般以域名的方式提供出去即可,对于服务内部之间的相互调用,只有域名系统往往不够。所以需要一个“服务发现”类的系统,主要包括:
(1)、服务发现系统:用于提供服务的寻址,注册能力,以及统计服务状态,根据服务情况更改服务的调用情况等;
(2)、一套与服务发现系统配合使用的RPC库;
RPC库提供的功能:
(1)、服务提供方:使用RPC库注册自己的服务到服务发现系统,上报自己的服务情况;
(2)、服务调用方:使用RPC库进行寻址服务,实时从服务发现系统获取最新的服务调度策略;
(3)、提供协议的序列化、反序列化功能,负载均衡的调用策略、熔断限流等安全访问策略;
优点:
1、业务逻辑无需关注服务地址、协议解析、服务调度、自身服务情况上报等工作,只需关注业务逻辑即可;
2、可以通过管理后台界面,对服务的策略进行修改和查看等;
3、服务监控系统对服务质量一目了然;
3、服务的健康状态的检查自动化,在不好的时候对服务进行降级处理,实现智能化和自动化。
加入服务发现系统,架构调用如下:
2.5 Service Mesh(服务网格)
Service Mesh可以解决的问题:支持多语言,解决库升级的麻烦。
在服务mesh之前,调用方实例通过自己内部的rpc与服务方实例进行通信,
在服务mesh之后,调用方实例通过Service Mesh proxy代理层与服务方实例进行通信;
总结:域名系统解决了需要记住复杂的数字 IP 地址的问题。
PB 类软件库的出现解决协议定义解析的痛点。
网关类组件解决客户端接入以及服务器横向扩展等一系列问题。