WEB、可扩展、架构体系结构、开发、测试、数据、优化、负载均衡、监控、规划

第1章 绪论

WEB站点包含的是页面数据，而WEB应用程序则是由具备分离交付机制的数据组成的。 一个WEB应用至少包括硬件和软件。 好的应用体系结构的关键在于开始的规划。

第2章 WEB应用程序体系结构

系统架构分层，一如OSI的七层，各司其职，确保每层都能很好的完成自己的职责。 每个层的功能都只建立在同层或较低层所提供的功能之上。 层内通常都是自我完备，自制的。层与层的交互通过接口实现， 但是会产生一些问题，层与层之间的交互会增加额外的消耗，并且分层会给调试带来困难。

作者认为WEB应用分为展现层（CSS），标记层（html），页面逻辑层，业务逻辑层，持久化层。 如果采用多语言编程，就会被分层。此时，关键问题是如何在层间进行有效的交互。 分层将导致分工的出现，分工将使技术方向更加明确。

由于小系统到大系统的一个步骤是将展现层分离出来，这需要三步：

1. 将逻辑代码从标记代码中分离出来
2. 将标记代码划分成一个文件对应一个页面
3. 切换到模板系统

页面逻辑和业务逻辑的分离最为简易的方法是函数分组。

** 忘记那些微不足道的性能调整，在97%的情况下，不成熟的优化是罪恶之源** WEB应用包括硬件和软件。硬件需要考虑经费、操作系统、软件、空间、容灾、容量规划、冗余、网络……

第3章 开发环境

三条不成文的规则，它能帮助你避开从小规模应用程序迁移到大型应用程序时常常遇到的问题。

1. 使用源码控制 版本控制，版本控制软件
2. 使用单步创建 开发环境、筹备环境和生产环境分离。每次版本发布都需要经过开发，提交和测试，部署三个环节。 对于配置文件，可以以文件合并，覆盖变量的方式使用开发环境、生产环境的db配置等分离。 对于发布操作，建议统一出口，由专人管理或者由专人兼职管理
3. 跟踪程序缺陷 问题跟踪系统，跟踪缺陷、特性、操作、支持请求。

在项目不同的阶段建议更新副本，我理解的是建立项目的基线。

编码规范：对同一小组的人而言，对一种编码风格达成共识，远比找到完美的风格更重要。

第4章 国际化、本地化和Unicode

国际化(i18n)是为应用程序添加输入、处理、输出国际文本的能力。 本地化(L10n)是为特定地址提供定制的应用程序的过程。

统一编码字符集.国际化是WEB应用本地化的先决条件。除了我们在程序中经常见到的多语言外， 本地化还包括语言、地区、时区、日期和时间格式、数字显示、货币的其它设定等。 本地化一般包括三种方法：

1. 字符串替换 如gettext的类库
2. 多个模板集合
3. 多个前端

第5章 数据一致性和安全性

数据完整性是工程应用程序成功的关键。可行的数据完整性策略基于一个基本的原则：应用程序的内部数据是有用的。 换句话说，引入的数据在边界处被过滤，以过滤后的结果存储。个人想法：在应用程序内部的各层之间也应该基于这样一个前提条件， 在把数据引入到当前层之前需要对数据进行处理。

对于数据是否转义，作者建议坚持使用一种方式即可，不能混合使用。 过滤和安全可以在各层实现，在数据库层，对于特定用户的权限要区分，只需要读权限的，就只给读权限，秉承权限最小化原则。

第6章 电子邮件

通过为用户提供额外的获取及发布数据的途径，可以拓展Web应用程序的可用性。 电子邮件是异步的，能够实现交互，可以为应用程序拓展异步操作。 可以使用现有技术在应用程序中实现电子邮件机制，不需要重复发明轮子。这是程序员的美德之一：懒惰。

电子邮件的方案一般包括两种：

1. 将邮件直接传给应用程序
2. 把邮件传输到本地的POP或IMAP 收件箱，然后应用程序周期性的读取收件箱中的邮件并处理。 这里就产生了一个需求：邮件解析。关注附件，注意字符集编码，过滤不相关内容，识别用户。

第7章 远程服务

本章涉及WEB应用程序中在两个或多个组件之间交换数据的协议、格式和策略的问题。 远程服务小组的首要规则就是不能依赖服务。第二条：服务可能会失败。

套接字： 所有使用TCP或UDP发送的数据都使用了socket连接。当我们执行socket的I/O操作时，都需要在每一步明确的检查失败。 HTTP: 基于XML-RPC、SOAP和REST的服务全部都用HTTP进行基本的传输。HTTP作为高层协议的传输层是相当理想的。 HTTP是无状态、无连接的协议，基于连接-请求-断开连接的语义。在HTTP请求中使用Authorization标头，从而触发http协议的认证功能。 在PHP中可以使用fscokopne函数构造http请求。

远程服务冗余性：系统组件链中的任一组件都可能出现故障，对于故障的不同的情况需要使用不同的表述来说明。 面向用户的组件，往往倾向于使用专门的软件或硬件负载平衡器来处理在线故障转移。

当一个系统中的异构组件之间交换数据时，需要定义两个元素。首先需要媒介和协议，然后是交换数据所需要的元素，就是数据格式 XML的解析有两种主流方式：SAX和DOM](). XML和HTTP都很好，但并不是银弹。有时轻型协议和格式对于特定的问题是更好的解决方案。 在使用XML交换数据时需要考虑内存使用、网络速度、解析速度、写入速度等。 如果没有合适的，自己构建一个协议吧，但是要记住：要避免做任何复杂和费时的事情，努力把工作建立在他人的现有工作成果之上。

第8章 瓶颈

本章讨论了在瓶颈产生前和它们已经影响到系统时，找出和修改体系结构中瓶颈的技术。 所谓的瓶颈就是程序中耗时最多的部分。瓶颈可能从CPU、I/O、网络I/O、内存、数据库等方面着手查找原因 其中磁盘速度是I/O的主要限制因素。 一般来说，WEB应用程序都会有缓存，包括文件缓存，内存缓存等等，有的应用有一层甚至几层的缓存。 有些数据适宜使用缓存，这种一般是读多写少。 在做数据库设计时可以有一定的冗余，到一定规模后，逆范式必不可少。

第9章 扩展WEB应用程序

可扩展的系统有三个简单特性：

• 系统能够容纳使用率的增加
• 系统能够容纳数据集的增加
• 系统可维护

可扩展性与语言无关，与特定的技术无关，与XML无关，并且页面逻辑和业务逻辑的分享对于可扩展性来说也不是必需的。

扩展硬件平台，可以垂直扩展，但其最终会爱到限制，成果较高。可以水平扩展，以不断添加更多硬件的方式实现，以常规机器为主。 然而水平扩展会带来维护成本和管理成本的增加。

冗余：机器都会发生故障，唯一保证故障状态下正常服务的办法就是有多个硬件备份。 所有备份的各类可能是冷备份、热备份和完全热备份。其中完全热备份最为推荐。 扩展PHP：PHP和HTTP一样，是无状态的。PHP将数据集的增长的责任下放到了存储层，这样就能随心所欲地进行扩展。

负载平衡：

• DNS负载均衡 这是最简单的方法，它是在DNS区域(zone)中为应用程序的域创建不止“一条”记录。 优点：简单，易实现； 缺点：向池中添加和移除机器比较缓慢，无法实现精确控制，不能定制均衡方式
• 硬件方式的负载均衡 优点：添加和移除机器生效快，能很好的处理故障问题，自动检测自动分流；缺点：价格较贵，可配置性较差
• 软件方式的负载均衡 通过运行在常规机器上的服务软件来完成负载均衡。应该配置两个或多个进行冗余。

第四层的负载均衡的形式是使用循环(round robin)算法,并且其高度算法也包含定制的度量值。 第七层的负载平衡器检测包括第七层的消息，检查HTTP请求自身。 对于特定应用领域的大型程序，可能需要把应用的服务划分成一个或者多个透明的集群。 有点类似于树结构。

作者在论述Mysql扩展这部分非常精彩，值得多看。包括对Mysql的结构和各个存储引擎的介绍。一些关键点都讲出来了。 Mysql复制有三种方式：

1. 三主从复制
2. 从主从复制扩展出来的树状复制
3. 主主复制 对于自增ID的处理比较麻烦，可以考虑将一个表只放在一个库，也可以去掉自增ID. 它有一个不足之处：任何时候都不存在一份“真实的”数据副本。

复制虽然提供了冗余，提供了扩展，但是它会存在复制失败，复制延迟的情况。当复制延迟时，可以使用同步复制或降低负载，或者自己实现某种技术。 在一定的上下文中可以考虑使用分区扩展。 联合是横向扩展在数据为领域的等价物。

存储扩展：考虑合适的文件系统，协议，使用RAID.

要为给定的组件提高 性能，可以在它的前端添加一个缓存，以减少请求数。如HTTP协议等都有类似缓存的功能。 缓存可以缓存数据，缓存HTTP请求。

第10章 统计数据、监测与警告

数据来源：服务器日志文件分析、负载平衡器 监控应用程序、监控网络带宽，监控Mysql，监控其它软件，将所有的信息收集后，进行汇总，分析，按照需求定制数据的展示。

检查包括资源级别监测，阈值检查，低位检查。

第11章 APIs

数据订阅源：RSS、RDF、Atom等。

读后感

总体来说，这是一本务实的书，或者说这是一本讲术的书。 在一定的时间维度里，这本书有较大的阅读价值。

读完此书后，它对我的作用如下：

1. 理顺了整个WEB应用的开发流程
2. 介绍了一些工具和完善了我的知识体系结构
3. 让我认清了在项目管理和日常中一些工作的意义