多数大学生出来选择的工作和专业无关
首页 > 专业知识

PHP设计模式漫谈之代理模式

时间:2018-04-19 18:14:23 [来源]:郑州PHP培训学校

   PHP设计模式漫谈之代理模式

  PHP也有设计模式?是的,我们经常看到关于Java和.NET平台上设计模式的论述和讲解,其实,在PHP 5对面向对象的支持更加完善之后,设计模式的应用也可引入到PHP中并发挥重要作用。
  设计模式( Design Pattern)是从建筑设计领域引入到计算机科学的。设计模式是对软件设计中普遍存在(且反复出现)的各种问题,所提出的解决方案。设计模式并不直接用来完成程序码的编写,而是描述在各种不同情况下,要怎么解决问题的一种方案。
  更多关于PHP设计模式方面的入门与应用可以参考51CTO之前的报道《使用设计模式改善程序结构》以及《架构、框架、设计模式之间的关系简述》。
  我们经常看到关于Java和.NET平台上设计模式的论述和讲解,其实,在PHP 5对面向对象的支持更加完善之后,设计模式的应用也可引入到PHP中并发挥重要作用。51CTO.com将从本周起以每周一期的形式连载《PHP设计模式漫谈》的系列文章,以理论与代码实例相结合的方式讲解PHP中的设计模式。希望对从事PHP研发的读者有所帮助。
  今天我们要谈的是PHP设计模式中的代理模式(Proxy),它是对简单处理程序(或指针)的增强,用于引用一个对象:这个指针被代理(Proxy)对象取代,代理对象位于客户端(Client)和真实执行程序之间,指针有一个可被多个目标利用的钩子。
  从技术上讲,这种模式在客户端和真实主体(RealSubject)之间插入一个代理对象,维护subject接口和用不同的方式委派它的方法。代理可以透明地做任何事情:懒散创建RealSubject或载入数据,与其它机器交换消息,写时复制策略等。这与HTTP代理有点类似,其客户端(如浏览器)和应用程序依赖于与HTTP服务器的联系,代理在管理连接时可以完成其它任务,如访问控制和缓存大型下载文件。
  PHP设计模式中的代理模式
  PHP设计模式中的代理模式示例
  代理模式的对象图与装饰模式对象图在结构上类似,但表达的目的各有不同,装饰者给对象动态增加行为,而代理则控制来自客户端的访问。此外,代理只在需要时才创建RealSubject。
  参与者:
  客户端(Client):取决于主体(Subject)实现;主体(Subject):RealSubject的抽象;
  真实主体(RealSubject):完成代价高昂的工作或包含大量的数据;代理(Proxy):为Client提供一个与Subject一致的引用,仅在需要时才创建RealSubject实例或与RealSubject实例通信。
  创建大型高性能Web站点的十项规则
  本文试图从可操作性和可靠性的角度讨论最重要的几点,不管是在开发还是在运营过程中,创建可靠的高性能Web系统都有很多应该注意的事项。
  在中国,开源的LAMP栈是最流行的网络架构,它使用PHP开发,运行在Apache服务器上,以MySQL作为数据库,所有这些都运行在Linux上。它是个可靠的平台,运行良好,是现在全球最流行的Internet系统架构。
  然而,我们很难对其规模进行正确的扩展并保持安全性,因为每个应用层都有其自身的问题、缺陷和最佳实践。当前的实际情况是,很多网站都是由开发人员快速而廉价地创建,通常没有任何IT人员或者经理,只是由程序员来管理系统。
  造成的结果是,虽然花费很低的成本网站就可以开始运行,但是当拥有大量用户、 需要扩展规模的时候,通常就会面临真正的问题。毕竟,中国拥有三亿八千万的Internet用户,如果其中的0.01%访问这个站点,就很容易引发25 万~50万的页面访问量。
  这些问题在各个级别上都会产生,下面总结的规则是对最一般的问题进行概述,并且说明为什么这些规则如此重要,以及最好采用什么方法来修正它们。遵循这些建议的站点会提高它的可伸缩性、安全性以及操作上的稳定性。
  使用合适的会话管理
  第一个想到的扩展系统的方法就是添加更多硬件。例如,使用两台服务器而不是一台。这听着合理,但会产生潜在问题:会话管理。这对Java程序来说是很严重的问题,在PHP中也会产生可延展性问题, 对于数据库的负载尤其如此。
  会话被定义为单独的最终用户登录或者连接一 段时间,其中通常会包含多个TCP/IP的HTTP连接、几个Web页面,通常还包括几十个甚至上百个页面元素,如框架、菜单、Ajax更新等。所有这些 HTTP请求都需要知道用户是谁,才能满足安全的要求,并向用户传送适当的内容,因为这些都是会话的组成部分。通常每个会话都会包括相互关联的会话数据, 如用户名、用户ID、历史、购物车、统计资料等等信息。
  问题在于,在有两台Web服务器和多个HTTP连接的情况下,用户流量会在两台服务器之间分配和移动,服务器很难知道用户是谁,并对所有数据进行跟踪,因为每个页面或者页面的组成部分都可能来 自不同的服务器。在PHP中,通常是这样解决的,在第一次连接或登录的时候就创建一个会话ID并将其放在Cookie中,然后这个Cookie会和每个 HTTP请求一起发送。
  这样做带来一个问题,接下来每段PHP脚本 都需要基于ID来查找会话数据。由于PHP无法在执行过程之间保持状态(这与Java不同),这个会话数据需要存储在某个地方,通常是在数据库中。但是, 如果复杂的页面需要在每个页面载入过程中对其进行十次查找(这是经常要做的),那就意味着每个页面都要执行10次SQL查询,这会导致数据库上很大的负载。
  在前面所举的中国Internet用户 0.01%的例子中,可能很容易在每秒内仅仅为了管理会话就生成上百个查询。解决方法是一直使用位于Cookie中的会话ID,并且使用像Memcached之类的服务来缓存会话数据以获得高性能。
  还要注 意其中存在安全性的问题,因为黑客可 以伪造另一个用户的会话ID,这是很容易找到或看到的,特别是在公用的Wi-Fi中。解决方法是对会话ID进行恰当的加密或者签名,并将其与时间区间、 IP地址以及其他关键信息 像浏览器或者其他细节相绑定。在Internet上有很多不错的关于良好的会话管理的例子,你可以根据需要找到最适合的。
  总是要考虑安全性
  尽管编写像防止SQL注入和登录安全之类的 代码涉及很多安全问题,但不幸的是,几乎没有人考虑过安全性,而那些考虑到的人也没有对其进行很好地理解。而本文要关注的是操作性的系统安全。对于这类安 全,我们的焦点集中在三个安全领域:防火墙、运行的用户以及文件访问权限。
  除了配置专门的硬件防火墙(像Cisco的 ASA)之外,所有服务器都还应该运行像Iptables之类的防火墙,它会保护服务器免受其他威胁和攻击。这些威胁和攻击可能来自公共的 Internet、其他服务器或本地服务器,也包括使用VPN或者SSH通道的开发和操作人员。我们仅对指定的IP开放确实需要的端口。Iptables 可能会很复杂,但是有很多不错的模板,我们通常可以使用它们来帮助客户创建Iptables。例如,默认的RedHat或者CentOS防火墙的配置说明 只有10行,显然并不实用。我们最佳实践的Iptables配置大概有5页,这其中包含了Linux所能提供的最高级的安全防范。
  所有公用的服务,都应该运行在专门的用户 下,如Apache。切记永远都不要使用Root用户运行,因为这会让任何闯入到Apache的用户接管整个服务器。如果Apache只是运行在 Apache用户下或者运行在Nobody下,那么闯入Apache就不是一件容易的事情了。
  Web服务器运行或者服务的文件 (像.php和.html文件)对于Web服务器的用户应该是不可写的。这意味着Apache或者Nginx用户不应该拥有Web目录的写权限。有很多方 法都可以做到这一点,而最简单的就是将这些文件为其他用户所有,然后让Apache/Nginx等用户归属于能够使用640权限读取文件的组中。这会防范 几乎所有的黑客和针对页面的攻击。
  此外,永远不要使用Ftp来上传文件,特别是在公用的Wi-Fi环境中,因为在其中黑客很容易盗取用户名和密码。取而代之的是使用Sftp会更加安全。另外,每个雇员都应该拥有自己的用户ID和随机密码。
  使用标准的路径和安装配置
  一个令人讨厌的部署问题是,开发者很少考虑 他们的软件会被部署到生产Web服务器的什么位置,以及如何部署。我们看到过许多大型的系统将它们的PHP代码部署在/home/xiaofeng或者 /web/code路径下。事实上,这两个路径都是非常不标准的,并且会带来操作和安全性的问题。当这些系统从开发环境转移到测试环境再到生产环境中时, 因为每个安装配置都是非标准的,所以经常会出现问题,这时就需要开发者调整才能够正常工作。
  你应该总是使用标准的安装包和二进制文件来 安装像Apache之类的服务器。不要从源代码编译或者安装Tarball,因为这会导致长期稳定性和管理上的问题,另外在服务器上安装多个不同的版本也 会造成混淆。
  PHP设计模式漫谈之调解者模式
  当PHP中对象的关系和依赖发生冲突时,我们可以使用调解者模式在耦合的对象之间协调工作流,有效的防止对象之间相互干扰。
  同事对象之间应该保持松散耦合,避免一个对象直接明确指向另一个对象。在调解者模式下,对象的关系和依赖发生冲突时,我们可以使用调解者在耦合的对象之间协调工作流,依赖可以从同事朝调解者或从调解者向同事建立,这两个方向上的依赖都可以使用AbstractColleague或AbstractMediator中断。
  对象不是孤立的,对象之间必须相互协作才能完成任务。虽然调解者模式可以限制对象之间的相互作用,但如果滥用,会致使编写聚合性类变得非常困难。举一个实用的例子,在领域驱动设计(Domain-Driven Design)中的服务就是实体之间的调解者。再举一个PHP相关的例子,Zend_Form装饰和过滤功能实际上可以看作是Zend_Form_Decorator和Zend_Filter实例之间的一个简单调解者,它们都使用Zend_Validate对象进行验证。
  当调解者必须监听同事对象的事件时,它通常是作为观察者(Observer)实现的,产生一个黑板(blackboard)对象,一些同事写,另一些同事就读。来自同事的事件被推向调解者,再由调解者将其转发给其它订阅的同事,同事之间不需要相互了解,这个架构成功用于随Zend框架发布的Dojo JavaScript库。这个模式的另一个好处是对象的变化包含在计算方法中,可以通过配置不同的调解者实现这一目标,但实例化相关对象将是一个松散的操作,不同容器和工厂之间的协作关系将是分散的。参与者:
  同事(Colleague):重点是它的职责,它只与一个调解者Mediator或AbstractMediator通信。
  调解者(Mediator):协同多个Colleagues(AbstractColleagues)共同工作。
  AbstractMediator,AbstractColleague:从这些角色的真实实现解耦的可选接口,可能不止一个AbstractColleague角色。
  下面的代码实现了一个表单输入的过滤过程,类似于Zend_Form_Element功能。
  <?php
  /**
  * AbstractColleague.
  */
  interface Filter
  {
  public function filter($value);
  }
  /**
  * Colleague. We decide in the implementation phase* that Colleagues should not know the next Colleague* in the chain, resorting to a Mediator to link them together.
  * This choice succesfully avoids a base abstract class* for Filters.
  * Remember that this is an example: it is not only* Chain of Responsibility that can be alternatively implemented* as a Mediator.
  */
  class TrimFilter implements Filter
  {
  public function filter($value)
  {
  return trim($value);
  }
  }
  /**
  * Colleague.
  */
  class NullFilter implements Filter
  {
  public function filter($value)
  {
  return $value ? $value : '';
  }
  }
  /**
  * Colleague.
  */
  class HtmlEntitiesFilter implements Filter{
  public function filter($value)
  {
  return htmlentities($value);
  }
  }
 

上一篇:探讨PHP编码转换函数应用技巧

下一篇:如何正确实现PHP获取博客数据