做网站运营需要学什么,网站开发技术要学什么软件,购物网站,详述网站建设的过程简答题介绍 想象这样一个场景#xff0c;一开始在公司里#xff0c;所有的部门的物理机、POD都在一个经典网络内#xff0c;它们可以通过 IP 访问彼此#xff0c;没有任何限制。因此有很多系统基于此设计了很多点对点 IP 直连的访问#xff0c;比如中心控制服务器 S 会主动访问物…介绍 想象这样一个场景一开始在公司里所有的部门的物理机、POD都在一个经典网络内它们可以通过 IP 访问彼此没有任何限制。因此有很多系统基于此设计了很多点对点 IP 直连的访问比如中心控制服务器 S 会主动访问物理机上的 Agent 从而拉取信息或下发配置假设调用频率很高数据量很大。 现在由于各种原因各个部门之间的网络不再被允许互通而是出现了隔离
每个部门有自己专用的物理机每个部门的POD只能部署到本部门的物理机POD 与物理机的网络是隔离的同一个部门的物理机是网络互通的不同部门的物理机是网络隔离的同一个部门的POD是网络互通的不同部门的POD的网络是隔离的允许给为应用申请 VIP而该 VIP 可以被所有 VPC 访问 相当于对于每个部门来说物理机处于一个单独的 VPC 内POD 处于另外一个单独的 VPC 内默认情况下 VPC 与 VPC 之间是网络隔离的。 这里我们先假设所有部门的物理机和 POD 的 IP 依旧不会重复从而先简化问题的讨论。 上述只是我创造的一个虚拟场景实际并不是这样的但也不影响问题讨论。 由于网络隔离的出现它会导致
部署在每台物理机上的AgentDaemonset形式无法访问我们的中心控制服务器S中心控制服务器S无法主动访问每台物理机上的 Agent 拉取信息或下发配置 我们的系统严格依赖上述2点因此网络隔离的出现导致我们的系统连基本功能都用不了。我们并不想为每个部门单独部署一套我们的系统运维成本高而是想使用一套系统服务所有部门。 解法 面对该问题考虑了如下解法
改造系统架构变成 “拉取配置” 推送信息基于反向代理的网络访问每个部门单独部署一套我们的系统 解法1需要将点对点访问变成边缘 Agent 对中心控制服务器 S 的访问一般来说 Agent 访问哪台 S 都是可以的因此可以给 S 挂一个 VIP让 Agent 去访问该 VIP 即可。 但这涉及整个系统架构大改暂时不考虑。 基于反向代理的网络访问 解法2的来源是想到如果每台 Agent、中心控制服务器 S 能找一个第三方组成一个 VPN 网络那么每个成员都会有一个新的虚拟 IP使用该新的虚拟 IP 就可以实现原来的点对点IP直连访问。而我们要做的是在访问时查询一下原始IP对应的新的虚拟IP然后访问该 IP 即可。 但是组 VPN 了解不够并且只有一台VPN服务器也是不够的应该是需要VPN集群这对我来说就更难了。 后来经过一些调研发现有一个技术叫做“反向代理”相关的软件参考了 frp https://github.com/fatedier/frp 反向代理介绍 假设有如下4个角色: A: 处于 VPC 1 内 R: 处于 VPC 1 内 R 也可以就是 A 自身 S: S代表一组服务器处于 VPC 2 内; 并且它配置了一个 VIP, VIP 可以被 VPC 1 里的成员访问 B: 处于 VPC 2 内 B 也可以就是 S 自身 此时 VPC 1 与 VPC 2 网络不通仅 VPC 1 的成员可以通过 S 的 VIP 访问到 S。 A 向 S 的 VIP 发起反向代理请求 (R IP, R port)S 的某个成员 S 收到了反向代理请求 (R IP, R port)S 为反向代理请求分配一个随机端口 S port (也可以是固定端口不过在我们这个场景下随机更好)。 此后B 就可以通过 (S IP, S port) 访问到 (R IP, R port)。 因此如果你有一个公网IP那么你就可以把你某个内网的端口通过该公网IP做反向代理暴露出去。经常折腾软路由的人应该对此了解较深。 引入反向代理 假设我们在中心引入一个 proxy server (简称PS)的角色让每台 Agent、中心控制服务器 S 通过 VIP 找到任意一台中心 PS 服务器建立反向连接建立反向连接后可以得到一条反向链路(某PS的IP,某PS的端口,某Agent的IP,某Agent的端口)以下简称反向连接4元组. 当我们要访问(某Agent的IP,某Agent的端口)时, 换成去访问(某PS的IP,某PS的端口)就可以了。 当每台 PS 服务器建立反向连接时它会将该反向连接4元组记录在某个地方供后续查询。当然销毁反向连接时也要记得删除4元组。 使用代理服务器屏蔽反向连接的细节 考虑到还有其他应用也会访问物理机上的Agent我们可以将该4元组的查询做成服务或者SDK供其他应用使用。但是这种方式对这些应用有一定侵入性他们不一定愿意接入。 我们还可以使用 socks5 代理技术来简化其他应用访问物理机上的Agent的流程。 我们实现一个 socks5 server 的角色对外提供一个 VIP:port 供其他应用连接其他应用要做的仅仅只是在它们发网络请求的地方配置 socks5 代理socks5 代理的支持很普遍的。这个 socks5 server 的实现就是根据目标 IP 去查 4 元组然后将请求转发到对应的 (PS IP,PS port) 上。 如果你的Agent提供的是 HTTP 服务那么你可以提供 HTTP 代理服务器而非 socks5那应该会更简单一些。 性能问题
每个反向连接会消耗一台 PS 的一个 port, 因此每台 PS 最多贡献6万个 反向连接, 保守点估算成5万. (我们假设 VIP 会尽量使得连接均匀分配到后端)所有的网络流量需要经过 VIP, 它本身有带宽限制, 比如 10Gb/s; 关于这一点我们可以想办法可以PS server 挂多个 VIP, 然后再申请一个域名, 将A记录设置为这多个VIP, 应该就可以起到一个负载均衡的效果如果你实现了 socks5 或 http 代理服务器, 那么它的 VIP 也是性能瓶颈当 PS 故障时一些反向连接会在短时间内不可用; 我们可以要求每个 Agent 往 PS 建立 2 个连接(并且要想办法尽可能保证2个连接落在不同的PS实例上), 每个反向连接信息里可以维护一个心跳时间, 如果一个挂了, 那么流量都走另外一个.反向建连4元组脏了, 在一个非常繁忙的系统中 (S IP, S port) 可能被复用, 如果此时4元组数据脏了, 可能你想连到 (C IP, C port) 但实际却是连到 (D IP, D port); 关于这一点可以让每个 PS 手动维护 S port 的分配, 在分配之前检查是否有脏数据残留; 或者可以在业务层的协议加入一个目标IP, 当Agent 收到请求时检查一下是否确实是发给自己的请求, 如果不是则报错(对业务有侵入性). 安全问题 一般来说公司之所以要引入 VPC 网络架构就是为了隔离各部门的网络属于有意为之。而我们的这种做法无疑是打破了这种隔离。但好在我们打破的范围仅仅局限在我们系统的业务 POD 之间并不涉及其他业务 POD虽然说我们确实有这个能力。所以我的这种做法目前是可以被接受的。
