miller
发布于

微服务 名词解释

看go-zero框架时候偶然看到的

概述

概述

在开发中,我们经常提到一些名词 “单体”、“微服务”、“API”、“gRPC”、“gRPC stub”,”Protobuf“、“rest”、“负载均衡”,“服务发现” 等名词,这些名词后后续文档中也会经常提到,为了保证大家对这些名词有初步概念,我们将针对一些高频名词进行说明。

单体

单体式应用程序(英语:Monolithic application)是指单层的应用程序,其用户界面和资料存取程式整合在单一系统平台上的一个程式里。

单体式应用程序可以独立运作,不会受到其他应用程序的影响。其设计理念是此应用程序不只负责单一特定任务,所负责的是要完成特定功能所需要进行的所有步骤。像目前有些个人财务管理软件就属于单体式应用程序,可以让使用者进行单一任务,以端到端的方式进行,类似信息烟囱,不是大型应用程序中的一部分。有些文字处理器也属于单体式应用程序 [2]。有时这些应用程序是用在大型计算机上。

在软件工程中,单体式应用程序是指在设计时没有考虑模组化的程式来源请求。一般而言会希望软件有模组化的特性,因为可以复用应用逻辑中的一部分,在维护时也可以只更换应用程序中的一部分,不需更改整个应用程序。

详情可参考 《维基百科 • 单体式应用程序》

微服务

微服务(英语:Microservices)是一种软件架构风格,它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础,利用模块化的方式组合出复杂的大型应用程序,各功能区块使用与语言无关 (Lang 而且复杂的服务背后是使用简单 URI 来开放接口,任何服务,任何细粒都能被开放(exposed)。这个设计在 HP 的实验室被实现,具有改变复杂软件系统的强大力量。

微服务的另一个对比是单体式应用程序。单体式应用表示一个应用程序内包含了所有需要的业务功能,并且使用像主从式架构(Client/Server)或是多层次架构(N-tier)实现,虽然它也是能以分布式应用程序来实现,但是在单体式应用内,每一个业务功能是不可分割的。若要对单体式应用进行扩展则必须将整个应用程序都放到新的运算资源(如:虚拟机) 内,但事实上应用程序中最吃耗费资源、需要运算资源的仅有某个业务部分(例如跑分析报表或是数学算法分析),但因为单体式应用无法分割该部分,因此无形中会有大量的资源浪费的现象。

详情可参考 《维基百科 • 微服务》

API

应用程序接口(英语:application programming interface[1]),缩写为 API[2],是一种计算接口,它定义多个软件中介之间的交互,以及可以进行的调用(call)或请求(request)的种类,如何进行调用或发出请求,应使用的数据格式,应遵循的惯例等。它还可以提供扩展机制,以便用户可以通过各种方式对现有功能进行不同程度的扩展 [3]。一个 API 可以是完全定制的,针对某个组件的,也可以是基于行业标准设计的以确保互操作性。通过信息隐藏,API 实现了模块化编程,从而允许用户实现独立地使用接口。

详情可参考 《维基百科 • 应用程序接口》

gRPC

gRPC (gRPC Remote Procedure Calls) 是 Google 发起的一个开源远程过程调用(Remote procedure call)系统。该系统基于 HTTP/2 协议传输,使用 Protocol Buffers 作为接口描述语言 [2]。

其他功能:

  • 认证(authentication)
  • 双向流(bidirectional streaming)
  • 流控制(flow control)
  • 超时(timeouts)
  • 最常见的应用场景是:

微服务框架下,多种语言服务之间的高效交互。 将手机服务、浏览器连接至后台 产生高效的客户端库

详情可参考 《维基百科 • gRPC》

Protocol Buffers

Protocol Buffers(简称:ProtoBuf)是一种开源跨平台的序列化数据结构的协议。其对于存储资料或在网络上进行通信的程序是很有用的。这个方法包含一个接口描述语言,描述一些数据结构,并提供程序工具根据这些描述产生代码,这些代码将用来生成或解析代表这些数据结构的字节流。

详情可参考 《维基百科 • Protocol Buffers》

RESTful API

表现层状态转换(英语:Representational State Transfer,缩写:REST)是 Roy Thomas Fielding 博士于 2000 年在他的博士论文中提出来的一种万维网软件架构风格,目的是便于不同软件 / 程序在网络(例如互联网)中互相传递信息。表现层状态转换是根基于超文本传输协议(HTTP)之上而确定的一组约束和属性,是一种设计提供万维网络服务的软件构建风格。符合或兼容于这种架构风格(简称为 REST 或 RESTful)的网络服务,允许客户端发出以统一资源标识符访问和操作网络资源的请求,而与预先定义好的无状态操作集一致化。因此表现层状态转换提供了在互联网络的计算系统之间,彼此资源可交互使用的协作性质(interoperability)。相对于其它种类的网络服务,例如 SOAP 服务,则是以本身所定义的操作集,来访问网络上的资源。

目前在三种主流的 Web 服务实现方案中,因为 REST 模式与复杂的 SOAP 和 XML-RPC 相比更加简洁,越来越多的 Web 服务开始采用 REST 风格设计和实现。例如,Amazon.com 提供接近 REST 风格的 Web 服务执行图书查询;雅虎提供的 Web 服务也是 REST 风格的。

详情可参考 《维基百科 • 表现层状态转换》

ETCD

etcd 是一种高度一致的分布式键值存储,它提供了一种可靠的方式来存储需要由分布式系统或机器集群访问的数据。它在网络分区期间优雅地处理领导者选举,并且可以容忍机器故障,即使在 leader 节点中也是如此。

详情可参考 《etcd》

Nacos

服务(Service)是 Nacos 世界的一等公民。Nacos 支持几乎所有主流类型的 “服务” 的发现、配置和管理,Nacos 的关键特性包括:

  • 服务发现和服务健康监测
  • 动态配置服务
  • 动态 DNS 服务
  • 服务及其元数据管理

详情可参考 《Nacos》

服务发现

服务发现(Service discovery)是自动检测一个计算机网络内的设备及其提供的服务。服务发现议定 (service discovery protocol) 帮助发现服务的网络传输协议。服务发现的目的在于为用户自行配置而减负。

服务发现通常需要一个共同的语言, 帮助用户通过软件代理器(software agents)调用另一个服务, 而不需要用户自行调用.

详情可参考 《维基百科 • 服务发现》

负载均衡

负载平衡(英语:load balancing)是一种电脑技术,用来在多个电脑(电脑集群)、网络连接、CPU、磁盘驱动器或其他资源中分配负载,以达到优化资源使用、最大化吞吐率、最小化响应时间、同时避免过载的目的。 使用带有负载平衡的多个服务器组件,取代单一的组件,可以通过冗余提高可靠性。负载平衡服务通常是由专用软件和硬件来完成。 主要作用是将大量作业合理地分摊到多个操作单元上进行执行,用于解决互联网架构中的高并发和高可用的问题。

详情可参考 《维基百科 • 负载均衡》

网关

网关(英语:Gateway)是转发其他服务器通信数据的服务器,接收从客户端发送来的请求时,它就像自己拥有资源的源服务器一样对请求进行处理。有时客户端可能都不会察觉,自己的通信目标是一个网关。

区别于路由器(由于历史的原因,许多有关 TCP/IP 的文献曾经把网络层使用的路由器(英语:Router)称为网关,在今天很多局域网采用都是路由来接入网络,因此现在通常指的网关就是路由器的 IP),经常在家庭中或者小型企业网络中使用,用于连接局域网和互联网。

网关也经常指把一种协议转成另一种协议的设备,比如语音网关。

在传统 TCP/IP 术语中,网络设备只分成两种,一种为网关(gateway),另一种为主机(host)。网关能在网络间转递数据包,但主机不能转送数据包。在主机(又称终端系统,end system)中,数据包需经过 TCP/IP 四层协议处理,但是在网关(又称中介系统,intermediate system)只需要到达网际层(Internet layer),决定路径之后就可以转送。在当时,网关(gateway)与路由器(router)还没有区别。

在现代网络术语中,网关(gateway)与路由器(router)的定义不同。网关(gateway)能在不同协议间移动资料,而路由器(router)是在不同网络间移动资料,相当于传统所说的 IP 网关(IP gateway)。

网关顾名思义就是连接两个网络的设备,对于语音网关来说,他可以连接 PSTN 和以太网,这就相当于 VOIP,把不同电话中的模拟信号通过网关而转换成数字信号,而且加入协议再去传输。在到了接收端的时候再通过网关还原成模拟的电话信号,最后才能在电话机上听到。

对于以太网中的网关只能转发三层以上数据包,这一点和路由是一样的。而不同的是网关中并没有路由表,他只能按照预先设定的不同网段来进行转发。网关最重要的一点就是端口映射,子网内用户在外网看来只是外网的 IP 地址对应着不同的端口,这样看来就会保护子网内的用户。

详情可参考 《维基百科 • 网关》

SOA 治理

SOA 治理(Service-Oriented Architecture (SOA) governance)是指在面向服务架构中对服务执行控制相关的活动。SOA 治理可以看作是信息技术治理的子集,而信息技术治理又是公司治理的一个子集。SOA 治理主要关注于如何利用资源为企业带来价值。SOA 即需要许多 IT 支持流程,也需要许多使企业领导人参与的组织上的流程。面向服务架构需要一个基于标准的,并包括策略,合约和服务等级协议在内的坚实的基础。通过使用服务,企业希望能够快速地构建和变更组织的业务流程。要实现敏捷,需要存在可以使用的粗粒度的和细粒度的服务。因此,一个面向服务架构增加了对良好治理的需求,良好的治理将帮助分派决策权力,角色和责任,并使得关注点集中在获取成功所需的组织能力上。

详情可参考 《维基百科 • SOA 治理》

事务

数据库事务(简称:事务)是数据库管理系统执行过程中的一个逻辑单位,由一个有限的数据库操作序列构成。

数据库事务通常包含了一个序列的对数据库的读 / 写操作。包含有以下两个目的:

为数据库操作序列提供了一个从失败中恢复到正常状态的方法,同时提供了数据库即使在异常状态下仍能保持一致性的方法。 当多个应用程序在并发访问数据库时,可以在这些应用程序之间提供一个隔离方法,以防止彼此的操作互相干扰。 当事务被提交给了数据库管理系统(DBMS),则 DBMS 需要确保该事务中的所有操作都成功完成且其结果被永久保存在数据库中,如果事务中有的操作没有成功完成,则事务中的所有操作都需要回滚,回到事务执行前的状态;同时,该事务对数据库或者其他事务的执行无影响,所有的事务都好像在独立的运行。

详情可参考 《维基百科 • 数据库事务》

健康检查

健康检查是分布式系统中的一种常见模式,它通过健康检查组件来检查服务实例,健康检查组件通过健康检查算法来检查服务实例,常见的健康检查算法有心跳检查、健康检查、健康检查等。

服务认证

身份验证(英语:Authentication)又称 “认证”、“鉴权”,是指通过一定的手段,完成对用户身份的确认。

身份验证的目的是确认当前所声称为某种身份的用户,确实是所声称的用户。在日常生活中,身份验证并不罕见;比如,通过检查对方的证件,我们一般可以确信对方的身份。虽然日常生活中的这种确认对方身份的做法也属于广义的 “身份验证”,但“身份验证” 一词更多地被用在电脑、通信等领域。

身份验证的方法有很多,基本上可分为:基于共享密钥的身份验证、基于生物学特征的身份验证和基于公开密钥加密算法的身份验证。不同的身份验证方法,安全性也各有高低。

详情可参考 《维基百科 • 身份验证》

消息队列

消息队列(英语:Message queue)是一种进程间通信或同一进程的不同线程间的通信方式,软件的贮列用来处理一系列的输入,通常是来自用户。消息队列提供了异步的通信协议,每一个贮列中的纪录包含详细说明的资料,包含发生的时间,输入设备的种类,以及特定的输入参数,也就是说:消息的发送者和接收者不需要同时与消息队列交互。消息会保存在队列中,直到接收者取回它。

详情可参考 《维基百科 • 消息队列》

参考文献

原文地址 go-zero.dev

浏览 (1445)
点赞
收藏
评论