科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网软件频道评论专栏: Erik Burckart:了解代理服务器基础知识

评论专栏: Erik Burckart:了解代理服务器基础知识

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

代理服务器是 IBM® 的 WebSphere® Application Server Network Deployment 和 WebSphere Extended Deployment 产品中一个重要的组件,但通常没有被正确认识。以下是一些关于代理服务器的最常见问题及您需要知道的答案。

作者:ibm 来源:ibm 2007年10月6日

关键字: 应用 中间件 代理 服务器

  • 评论
  • 分享微博
  • 分享邮件

什么是代理服务器,它是怎么出现的?

您可能没有意识到,在 WebSphere Application Server Network Deployment 包中实际上提供了两个代理服务器。

一个通常被称为 Web Traffic Express,之前随 WebSphere Performance Pack 和 WebSphere Edge Server 之类的包一起提供,同时充当反向 HTTP 代理和转发 HTTP 代理。 从 WebSphere Application Server Network Deployment 的 Version 5.0 开始,Web Traffic Express 就一直包括在其中。

从 WebSphere Application Server Network Deployment Version 6.0.2 开始,随其提供的作为反向 HTTP 代理的代理服务器与 WebSphere Application Server 平台就存在很多共同点。 在传输通道框架 (Transport Channel Framework) 上构建的代理服务器与其他 WebSphere Application Server 组件(如 Web 容器、SIP 容器和 JMS Server)使用框架和组件的方式非常相似。

代理还是可扩展的高级体系结构,支持我们的 WebSphere 开发团队添加各种高级功能。 代理是 WebSphere Extended Deployment On Demand Router 的基础,而后者从 WebSphere Extended Deployment V5.1 就开始提供了。

除了充当反向 HTTP 代理外,从 WebSphere Application Server Network Deployment V6.1 开始,此代理服务器还可以作为无状态 SIP 代理使用。为了提供高可用性,需要为 SIP 容器使用无状态 SIP 代理。 这是我们的代理服务器的战略进步,并将在以后的版本中继续通过更多卓越的功能加以扩充。

那么我为什么要解释这么多呢?

代理服务器是 WebSphere Application Server Network Deployment(以下称为 Network Deployment)和 WebSphere Extended Deployment 产品中的一个重要组件,由于最近大量客户表现出对代理服务器的兴趣,因此我就自己所听到的关于此组件的最常见问题进行了回答。 例如……

反向和转发 HTTP 代理之间的区别何在?

很多人听到 HTTP 代理服务器时,就会想到在浏览器中配置的转发代理服务器,用于转发 HTTP 请求来连接到外部 HTTP 服务器。 通常为了进行网络访问授权和身份验证、内容筛选或通过缓存更好地利用网络带宽而进行此活动。 很多转发代理服务器都可以透明地配置,因此您永远都没有必要配置浏览器使用代理。 转发代理无法看到 SSL 请求中的内容,因此只是将请求作为一堆字节进行转发,而所知的信息并不多。

与转发代理不同,反向代理服务器位于 Web 服务器或 Web 应用服务器之前,用于处理来自客户机的请求,并将其转发到 Web 服务器;转发代理通常部署在网络的客户端,而反向代理部署在服务器端。 浏览器客户机直接指向反向代理——并不知道连接到的是反向代理,而不是 Web 服务器本身。 由于反向代理是主要的接触点,因此可以执行 SSL 负载分散等工作;SSL 负载分散要求服务器为客户机希望连接到的主机名对应的服务器。

Network Deployment 代理服务器中包括了哪些 HTTP 功能?

此代理服务器的功能非常多,并不能在此予以全面讨论,但我将重点讨论两个我认为最好的功能。

  • 动态路由与配置。 由于代理服务器构建于 WebSphere Application Server 中的 High Availability Manager 上,因此能够动态地处理容器本身中的配置和可用性信息。 这与 Web 服务器插件的可用模型形成对比,后者通过插件配置文件静态地获取其配置。 代理能够发现所部署的新应用程序,并能够将数据路由到这些应用程序,另外还具有将数据路由到通用的非应用服务器 HTTP 端点。

  • 服务器内置缓存功能。 代理服务器可以在内存和磁盘上缓存动态和静态内容。 此缓存功能可缓存应用程序中的静态内容(如图像)和 Web 容器中的一些动态内容(包括通过 Servlet 启用的任何内容),从而支持代理充分地分散后端服务器的负载。

那么,是否可以使用代理服务器替代 Web 服务器和插件呢?

这是个难题。 可以说能,也可以说不能。Version 6.0.2 和 Version 6.1 的代理服务器具有 Web 服务器和插件提供的很多功能,但并不能进行完全替代。 首先,代理并不具有 Web 服务提供功能,静态内容可以从代理缓存提供,但并不能将这些信息通过 Push 操作送到代理本身中。 另外,它也没有 Web 服务器所具有的很多功能(如 CGI)。 此外,不能将代理服务器视为可直接支持隔离区(DeMilitarized zone,DMZ)。

什么原因导致代理服务器不能直接支持 DMZ 呢?

因为代理服务器不直接支持 DMZ,代理服务器应该只位于内部网/安全区中。

代理服务器缺乏一些功能,因此不能直接支持 DMZ;例如,如果不驻留在大多数操作系统的根目录,则代理服务器不能绑定到受保护的端口(1024 以下的端口),目前不能在绑定之后切换用户。

图 1 和图 2 显示了代理的一些网络拓扑选项。


图 1. 代理和 Web 服务器均位于应用服务器前
图 1. 代理和 Web 服务器均位于应用服务器前

图 2. 代理采用应用程序级别的防火墙和可选的 DataPower 应用程序
图 2. 代理采用应用程序级别的防火墙和可选的 DataPower 应用程序

这是否意味着您需要一个代理服务器和一个 Web 服务器?

没有必要。 如果 Web 服务器的唯一用途是根据会话关联性进行路由和负责进行负载平衡工作,则完全可以使用代理服务器替代 Web 服务器。 如果将 Web 服务器作为 DMZ 中的安全措施,则代理无法替代它——但可以在安全区内帮助进行路由和负载平衡。 如果使用有状态的应用程序级别防火墙,除非将其用于进行身份验证、授权和审核,否则 DMZ 中的 Web 服务器并不会在安全性方面有太多的提高。 如果采用这种类型的防火墙设施,则可以忽略 MDZ 中的 Web 服务器,而仅在安全区内保护代理服务器。

构建于 WebSphere Application Server 基础上的代理服务器具有什么样的优势?

代理服务器对 WebSphere Application Server 中的某些特定组件进行了充分利用。 首先,它将使用 Network Deployment V6.0 中引入的高可用性基础设施。此基础设施向代理提供关于位于代理之后的容器中发生的事件的深入信息。 代理还将使用传输通道框架( WebSphere Application Server 中的高可伸缩性的 I/O 框架)。 在 Version 6.1 中,传输通道框架根据平台构建了特定的 I/O 代码,以处理数千个连接和快速执行 I/O 操作。

代理服务器还构建于 WebSphere Application Server 控制与基础设施之上,从而能够作为 WebSphere Application Server 计算单元的一部分进行配置并通过 JMX 进行管理,就像管理 WebSphere Application Server 一样。 另外,还可以通过 Application Server Toolkit 中的 Jython 等工具使用 Jython 等语言编写脚本来执行代理配置更改。 最后,由于构建于 WebSphere Application Server 之上,代理可以使用强大的监视功能,如 IBM Tivoli® Performance Viewer 中提供的此类功能。

我如何使用代理来对相同容器中的多个 HTTP 应用程序的线程进行隔离?

虽然传输和代理能够一起协作,从而将 Web 应用程序的线程隔离开,但这是在应用程序间管理资源的一种非常粗粒度方式。 是否成功可能会视情况而定。 WebSphere Extended Deployment 的 On Demand Router 通过利用 CUP 和内存负载以及响应时间等因素来实现此工作,以恰当地确保资源的分离并达到所需的服务水平。 如果您尝试在一组物理服务器内或单个应用服务器中隔离应用程序资源,我强烈建议使用此方法。 即使这样,根据应用程序对线程池进行隔离仍然是代理对变更进行抽象的很好示例。 以下是完成此工作所需的步骤:

  1. 首先在 WebSphere Application Server 中设置代理。 对于 Version 6.0.2,Web 容器中的资源可以采取多种非常有效的方法进行隔离。 其中一种方法是为 Web 容器中的虚拟主机设置不同的端点侦听器,从而获得唯一的主机名和端口组合。 要在管理控制台中进行此工作,您首先需要为每个虚拟主机创建端点:

    1. 在控制台中,导航到 Servers => Application Servers,然后右键单击服务器名称,并选择 Web Container Settings => Web Container Transport Chains
    2. 在此处单击 New 按钮,以创建新传输。
    3. 您将需要提供要用于这组应用程序的新主机名和端口。
  2. 创建了传输链后,请在 Web 容器传输链 (Web Container Transport Chains) 集合中将其选中。

  3. 在该页的第一个链接指向 TCP Inbound Channel,其中包括线程池和最大开放连接的设置,可以按端口在 TCP Inbound Channel 中对此进行设置。

  4. 在 TCP 通道配置面板的右侧单击 ThreadPools,为此通道创建新线程池(图 3)。



    图 3. 定义线程池
    图 3. 定义线程池

  5. 创建线程池之后,可以按照上面的步骤选中 TCP inbound channel 链接,从而回来设置该端口的线程池(图 4)。



    图 4. 定义 TCP 通道
    图 4. 定义 TCP 通道

  6. 创建了传输链并设置线程池后,必须为该端口配置虚拟主机。 在右侧的 Environment 部分选择 Virtual Hosts 链接(图 5)。



    图 5. 配置虚拟主机
    图 5. 配置虚拟主机

  7. 在新配置屏幕的顶部创建新虚拟主机。 为该虚拟主机创建主机别名,以将端口的通信流绑定到应用程序。 这样做的结果是,使用传输链配置的主机名和端口被配置为了主机别名。 安装后,应用程序应该安装到新虚拟主机上。

那么,现在已经配置了 Web 容器,需要对代理进行什么操作呢? 什么也不用! 启动应用程序后,代理将检测可用的应用程序和端口,并对通信流进行恰当的路由。

正如您所看到的,了解什么是代理服务器及其如何在最新版本的 WebSphere Application Server 上工作,可以明显地为您的企业 Web 应用程序带来大量的好处。

    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章