PHP简介与网站架构PPT

2020-02-27 177浏览

  • 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 这种。