PHP简介与网站架构PPT

2020-02-27 176浏览

  • 1.如果将开发产品比作建一所房子,那么框架就是毛坯房开始,省掉从一 砖一瓦开始的搭建,我们就只是将房子装修,添置家私就完成了。
  • 2.软件解决方案缺点也较多,因为每台服务器上安装额外的软件运行会消耗系统不定量的资源,越是功 能强大的模块,消耗得越多,所以当连接请求特别大的时候,软件本身会成为服务器工作成败的一个 关键;软件可扩展性并不是很好,受到操作系统的限制。
  • 3.DNS 负载均衡的优点是经济简单易行,并且服务器可以位于 internet 上任意的位置。 但它也存在不少缺点: 1. 为了使本 DNS 服务器和其他 DNS 服务器及时交互,保证 DNS 数据及时更新, 使地址能随机分配,一般都要将 DNS 的刷新时间设置的较小,但太小将会使 DNS 流量大增造成额外的网络问题。 2. 一旦某个服务器出现故障,即使及时修改了 DNS 设置,还是要等待足够的时
  • 4.Nginx/HAProxy+Keepalived 作 Web 最前端的负载均衡器,后端的 MySQL 数据库架 构采用一主多从,读写分离的方式,采用 LVS+Keepalived 的方式。
  • 5.当单台服务器的压力越来越高,响应速度越来越慢,而这个时候比较明显的是数据 库和应用互相影响,应用出问题了,数据库也很容易出现问题,而数据库出问题的 时候,应用也容易出问题。于是进入了第一步演变阶段:将应用和数据库从物理上 分离,变成了两台机器,这个时候技术上没有什么新的要求,但确实能起到效果, 系统又恢复到以前的响应速度,并且支撑住了更高的流量,并且不会因为数据库和 应用形成互相的影响。
  • 6.随着访问的人越来越多,响应速度又会变慢了,原因主要是访问数据库的操作太多 ,导致数据连接竞争激烈,所以响应变慢。但数据库连接又不能开太多,否则数据 库机器压力会很高,因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据 库读的压力。这个时候首先也许会选择采用 squid 等类似的机制来将系统中相对静 态的页面 ( 例如一两天才会有更新的页面 ) 进行缓存 ( 当然,也可以采用将页面静态 化的方案 ) ,这样程序上可以不做修改,就能够很好的减少对 WebServer 的压力以 及减少数据库连接资源的竞争,于是开始采用 squid 来做相对静态的页面的缓存。
  • 7.增加了 squid 做缓存后,整体系统的速度提升, WebServer 的压力也开始下降了, 但随着访问量的增加,发现系统又开始变的有些慢了,在尝到了 squid 之类的动态 缓存带来的好处后,考虑采用类似 ESI 之类的页面片段缓存策略, OK ,于是开始采 用 ESI 来做动态页面中相对静态的片段部分的缓存。 页面片段缓存技术,例如 ESI 等,想用好的话同样需要掌握 ESI 的实现方式。 静态页面之间的包含一般有如下一些方案: Client Side Includes(CSI) , Server Si
  • 8.在采用 ESI 之类的技术再次提高了系统的缓存效果后,系统的压力进一步降低了, 但同样,随着访问量的增加,系统还是开始变慢。系统中可能存在一些重复获取数 据信息的地方,像获取用户信息等,这个时候可以将这些数据信息也缓存到本地内 存。 这一步涉及到:缓存技术,包括像 Map 数据结构、缓存算法、所选用的框架本身的 实现机制等。
  • 9.随着系统访问量的再度增加, webserver 机器的压力在高峰期会上升到比较高,这 个时候开始考虑增加一台 webserver ,这也是为了同时解决可用性的问题,避免单 台的 webserver 宕机的话就没法使用了,增加一台 webserver 时,会碰到一些问题 ,典型的有: 1. 负载均衡:如何让访问分配到这两台机器上,这个时候通常会用的方案是 Apache 自带的负载均衡方案,或 LVS 这类的软件负载均衡方案 ;
  • 10.当数据库写入、更新的这些操作的部分数据库连接的资源竞争非常激烈,导致了系 统变慢,这下时可选的方案有数据库集群和分库策略,集群方面有些数据库支持的 并不是很好,因此分库会成为比较普遍的策略,分库也就意味着要对原有程序进行 修改,一通修改实现分库后,系统速度比以前甚至更快。
  • 11.慢慢的分库后查询仍然会有些慢,于是按照分库的思想做分表的工作。当然,这不 可避免的会需要对程序进行一些修改,这个时候也许应用自己要关心分库分表的规 则,使用一个通用的框架来实现分库分表的数据访问,这个在 ebay 的架构中对应的 是 DAL ,就是通常用的数据库访问层,这个演变的过程相对而言需要花费较长的时 间。当然,也有可能这个通用的框架会等到分表做完后才开始做。同时,在这个阶 段可能会发现之前的缓存同步方案出现问题,因为数据量太大,导致现在不太可能 将缓存存在本地,然后同步的方式,需要采用分布式缓存方案了。
  • 12.分库分表这些工作后,数据库上的压力已经降到比较低了。如系统的访问又开始有 变慢的趋势 ,这个时候首先查看数据库,之后查看 webserver ,若发现 apache 阻 塞了很多的请求,而应用服务器对每个请求也是比较快的,则是请求数太高导致需 要排队等待,响应速度变慢。这个时候只需添加一些 webserver 服务器,在这个添 加 webserver 服务器的过程,有可能会出现几种挑战: 1 、 Apache 的软负载或 LVS 软负载等无法承担巨大的 web 访问量 ( 请求连接数、网
  • 13.由于添加的 webserver 太多了,导致数据库连接的资源还是不够用,在这个阶段可 能会形成的架构演变是实现数据读写分离,同时编写一些更为廉价的存储方案,例 如 BigTable 这种。