内部网关协议

网关 　　网关是一种充当转换重任的计算机系统或设备。在使用不同的通信协议、数据格式或语言,甚至体系结构完全不同的两种系统之间，网关是一个翻译器。 　　与网桥只是简单地传达信息不同，网关对收到的信息要重新打包，以适应目的系统的需求。同时，网关也可以提供过滤和安全功能。大多数网关运行在OSI 7层协议的顶层--应用层。 　　大家都知道，从一个房间走到另一个房间，必然要经过一扇门。同样，从一个网络向另一个网络发送信息，也必须经过一道“关口”，这道关口就是网关。顾名思义，网关(Gateway)就是一个网络连接到另一个网络的“关口”。 　　按照不同的分类标准，网关也有很多种。TCP/IP协议里的网关是最常用的，在这里我们所讲的“网关”均指TCP/IP协议下的网关。 网关到底是什么呢？ 　　 网关实质上是一个网络通向其他网络的IP地址。 　　比如有网络A和网络B： 　　　　网络A的IP地址范围为“192.168.1.1~192. 168.1.254”，子网掩码为255.255.255.0； 　　　　网络B的IP地址范围为“192.168.2.1~192.168.2.254”，子网掩码为255.255.255.0。 　　在没有路由器的情况下，两个网络之间是不能进行TCP/IP通信的，即使是两个网络连接在同一台交换机(或集线器)上，TCP/IP协议也会根据子网掩码(255.255.255.0

一、 网络模型 网络模型分两种，一种是OSI模型，一种是TCP/IP模型，后者应用更加广泛。这里也主要介绍TCP/IP模型。 （一）TCP/IP模型 首先分为4层，从上到下依次是应用层、传输层、网络层、数据链路层。 OSI模型中将网络分为：应用层、表示层、会话层、传输层、网络层、数据链路层、物理层。 TCP/IP的应用层是OSI模型中应用层、表示层、会话层的集合，而物理层由于不是我们经常考虑的问题，所以TCP/IP模型没有把物理层算上。 1、数据链路层 数据链路层的核心是以太网协议。以太网协议规定一组电信号是一个数据包，叫一个振，每个帧（frame）分为标头（head）和数据（data），标头包含一些说明性东西，比如发送者，接收者，和数据类型之类的。例如一个电脑发个数据包出去，会广播给局域网(子网)内所有电脑设备的网卡，然后每台设备都从数据包获取接收者的mac地址与自己网卡的mac地址比对，如果一样就说明这是发给自己的数据包。 2、网络层 定义了一套IP协议，有IPV4和IPV6，以IPV4为例，由32个二进制数字组成，用4个10进制数字表示。 IP地址分为三类： A类：第一个字节为网络号，后三个字节为主机号。该类IP地址的最前面为“0”，所以地址的网络号取值于1~126之间。一般用于大型网络。 B类：前两个字节为网络号，后两个字节为主机号。该类IP地址的最前面为“10”

一、微服务简介 1. 微服务的诞生 微服务是基于分而治之的思想演化出来的。过去传统的一个大型而又全面的系统，随着互联网的发展已经很难满足市场对技术的需求，于是我们从单独架构发展到分布式架构，又从分布式架构发展到 SOA 架构，服务不断的被拆分和分解，粒度也越来越小，直到微服务架构的诞生。 微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。 每个服务运行在其独立的进程中，服务和服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。 2. 微服务架构与SOA架构的区别 微服务是真正的分布式的、去中心化的。把所有的“思考”逻辑包括路由、消息解析等放在服务内部，去掉一个大一统的 ESB，服务间轻通信，是比 SOA 更彻底的拆分。 微服务架构强调的重点是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用，这些小应用之间通过服务完成交互和集成。 3. 微服务架构引发的问题 随着整个业务数据被分散在各个子服务之后，也带来了两个最明显的问题。

本文转载自： 什么是分布式微服务架构？三分钟彻底弄懂什么是分布式和微服务 一、微服务简介 1. 微服务的诞生 微服务是基于分而治之的思想演化出来的。过去传统的一个大型而又全面的系统，随着互联网的发展已经很难满足市场对技术的需求，于是我们从单独架构发展到分布式架构，又从分布式架构发展到 SOA 架构，服务不断的被拆分和分解，粒度也越来越小，直到微服务架构的诞生。 微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。 每个服务运行在其独立的进程中，服务和服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。 2. 微服务架构与SOA架构的区别 微服务是真正的分布式的、去中心化的。把所有的“思考”逻辑包括路由、消息解析等放在服务内部，去掉一个大一统的 ESB，服务间轻通信，是比 SOA 更彻底的拆分。 微服务架构强调的重点是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用，这些小应用之间通过服务完成交互和集成。 3. 微服务架构引发的问题

“ 本文探讨了互联网公司的技术架构，涉及 DNS、负载均衡、长连接、API 网关、PUSH 推送、微服务、分布式事务以及相关支撑的基础服务。主要是为了学习，希望可以给大家一个参考。 图片来自 Pexels 整体架构 App、PC 以及第三方等调用方通过传统的域名解析服务 LocalDNS 获取负载均衡器的 IP，App 可以通过 HttpDNS 的方式来实现更实时和灵活精准的域名解析服务。 通过负载均衡器到达统一接入层，统一接入层维护长连接 。 API 网关作为微服务的入口，负责协议转换、请求路由、认证鉴权、流量控制、数据缓存等。 业务 Server 通过 PUSH 推送系统来实现对端的实时推送，如 IM、通知等功能。 业务 Server 之间通过专有的 RPC 协议实现相互调用，并通过 NAT 网关调用外部第三方服务。 域名解析 传统 DNS DNS（Domain Name System）域名系统，一种分布式网络目录服务，用于域名与 IP 地址的相互转换，能够使人更方便的访问互联网，而不用去记住机器的 IP 地址。 DNS 的解析过程如下： 客户端递归查询 LocalDNS（一般是 ISP 互联网服务提供商提供的边缘 DNS 服务器）获取 IP。 LocalDNS 迭代查询获取 IP，即不断的获取域名服务器的地址进行查询。 HttpDNS 移动解析（HttpDNS）基于 Http

API网关性能比较：NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd http://www.infoq.com/cn/articles/comparing-api-gateway-performances API 网关性能比较：NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd 麦克周 2018 年 4 月 15 日 话题： 语言 & 开发 架构 前几天拜读了 OpsGenie 公司（一家致力于 Dev & Ops 的公司）的资深工程师 Turgay Çelik 博士写的一篇文章（链接在文末），文中介绍了他们最初也是采用 Nginx 作为单体应用的网关，后来接触到微服务架构后开始逐渐采用了其他组件。 我对于所做的工作或者感兴趣的技术，喜欢刨根问底，所以当读一篇文章时发现没有看到我想要看到的设计思想，我就会四处搜集资料，此外这篇文章涉及了我正在捣鼓的 Spring Cloud，所以我就决定写一篇文章，争取能从设计思路上解释为什么会有这样的性能差异。 技术介绍 文中针对 Nginx、ZUUL、Spring Cloud、Linkerd 等技术进行了对比（其实还有 Envoy 和 UnderTow 也是属于可选的 API 网关，本文不予涉及），那我就分别进行介绍，当然，首先得介绍

EIGRP Enhanced Interior Gateway Routing Protocol 即 增强内部网关路由协议。也翻译为 加强型内部网关路由协议。 运行了EIGRP的路由器维持3张表:neighbortable,topologytable和routingtable.其中neighbortable保存了和路由器建立了邻居关系的,直接相连的路由器;topologytable包含路由器学习到的到达目的地的所有路由条目,其过程如下: 1.neighbortable中的每个邻居都转发1份IP路由表的拷贝给它们的邻居 2.然后每个邻居把从它们自己的邻居处得来的路由表存储在自己的EIGRP拓扑数据库中 3.EIGRP检查拓扑数据库,然后选择出一条到达目的地的最佳路由 4.EIGRP从拓扑数据库中选择到达目的地的最佳的successorroutes,然后把它们放到路由表里.路由器为每种协议(比如IP,IPX)各自保持1张单独是路由表 AD和FD 通告距离(AD)：也称为报告距离, 下一跳路由器到目的地的度量值. 可行距离(FD)：是本地路由器到达目的地的度量值. 后继者和可行后继者 后继者（S）：FD最小的 可行后继者（FS）：可行后继者AD小于后继者的FD值（满足AD小于后继者的FD才是可行后继者） EIGRP度量值 计算EIGRP使用一个复合度量，可根据以下指标： 带宽

1.什么是gateway（网关） Spring Cloud Gateway是Spring Cloud官方推出的第二代网关框架，取代Zuul网关。网关作为流量的，在微服务系统中有着非常作用，网关常见的功能有路由转发、权限校验、限流控制等作用。本文首先用官方的案例带领大家来体验下Spring Cloud的一些简单的功能，在后续会使用详细的案例和源码解析来详细讲解Spring Cloud Gateway. 2.网关的作用如下： 协议转换，路由转发 流量聚合，对流量进行监控，日志输出 作为整个系统的前端工程，对流量进行控制，有限流的作用 作为系统的前端边界，外部流量只能通过网关才能访问系统 可以在网关层做权限的判断 可以在网关层做缓存 Spring Cloud Gateway作为Spring Cloud框架的第二代网关，在功能上要比Zuul更加的强大，性能也更好。随着Spring Cloud的版本迭代，Spring Cloud官方有打算弃用Zuul的意思。在笔者调用了Spring Cloud Gateway的使用和功能上，Spring Cloud Gateway替换掉Zuul的成本上是非常低的，几乎可以无缝切换。Spring Cloud Gateway几乎包含了zuul的所有功能。 注：该图片来自官网 如上图所示，客户端向Spring Cloud Gateway发出请求。

1、TCP/IP协议栈 四层模型 TCP/IP这个协议遵守一个四层的模型概念：应用层、传输层、互联层和网络接口层。 网络接口层 模型的基层是网络接口层。负责数据帧的发送和接收，帧是独立的网络信息传输单元。网络接口层将帧放在网上，或从网上把帧取下来。 互联层 互联协议将数据包封装成internet数据包并运行必要的路由算法。 这里有四个互联协议： 网际协议IP：负责在主机和网络之间寻址和路由数据包。 地址解析协议ARP：获得同一物理网络中的硬件主机地址。 网际控制消息协议ICMP：发送消息，并报告有关数据包的传送错误。 互联组管理协议IGMP：被IP主机拿来向本地多路广播路由器报告主机组成员。 传输层 传输协议在计算机之间提供通信会话。传输协议的选择根据数据传输方式而定。 两个传输协议： 传输控制协议TCP：为应用程序提供可靠的通信连接。适合于一次传输大批数据的情况。并适用于要求得到响应的应用程序。 用户数据报协议UDP：提供了无连接通信，且不对传送包进行可靠的保证。适合于一次传输小量数据，可靠性则由应用层来负责。 应用层 应用程序通过这一层访问网络。 网络接口技术 IP使用网络设备接口规范NDIS向网络接口层提交帧。IP支持广域网和本地网接口技术。 串行线路协议 TCP/IPG一般通过internet串行线路协议SLIP或点对点协议PPP在串行线上进行数据传送。

1、前言 所在公司目前接入层是阿里云的SLB，然后经过Nginx+Lua转发到后端服务（Lua主要是限流）。 随着业务的发展，发现nginx配置越来越复杂，但又没有统一的管理，于是把Nginx这层改造成 基于 OpenResty的Nginx 应用的API Gateway 。于是上网总结和梳理网关相关知识。 问题: 由于我们使用的服务系统架构，所以没办法像传统单体应用一样依靠数据库的 join 查询来得到最终结果，那么如何才能访问各个服务呢？ 按照微服务设计的指导原则，我们的微服务可能存在下面的问题： 服务使用了多种协议： 因为不同的协议有不同的应场景用，比如可能同时使用 HTTP, AMQP, gRPC 等。 服务的划分可能随着时间而变化。 服务的实例或者Host+端口可能会动态的变化。 那么，对于前端的UI需求也可能会有以下几种： 粗粒度的API，而微服务通常提供的细粒度的API，对于UI来说如果要调用细粒度的api可能需要调用很多次，这是个不小的问题。 不同的客户端可能需要不同的数据。Web,H5,APP，OpenAPI 不同设备的网络性能，对于多个api来说，这个访问需要转移的服务端会快得多 以上，就是我们构建微服务的过程中可能会遇到的问题。 2、概念 API Gateway（API GW / API 网关），顾名思义， 是企业 IT 在系统边界上提供给外部访问内部接口服务的