分类目录归档:程序相关

C,Python,环境配置等

面向模式的软件架构–分布式计算的模式语言读后感

数个早晨,捧着这本书,一个人

终于看完了,在痛苦中煎熬,回头望去,却不知所得。只看过GOF的23个模式及其它一些书籍中不成系统的介绍。 仰望这一望无际的模式,作者对模式信手拈来,娓娓而谈,不得不叹服。至此,不敢写总结,只能写读后感,权当慰藉。

每种模式是记录了一个在特定环境下不断重复发生的问题以及相应的解决方案。 也许一种实现方法很常见,或者说已经用过,这是个人经验。 模式与个人经验相比:它被正式命名并记录,更有利于提炼、交流和分享架构层次上的知识。 本书一共介绍了114种模式,并且连接到其它文献中的介绍的150多种模式。 如此多的模式浓缩到这一本书中,确实页页都是精华。 读完整本书,以前的一些模糊性的内容被整理成模式语言的论述,如Layers、Pipes and Filters等等。 这些都有见过或用过,却不成系统。 由于接触分布式的内容较少,对于作者在分布式基础设施中提出的模式很难理解,待后续。 对于GOF的23种模式,作者按其主题分到了不同的章,每当遇到这些会有一种熟悉感,从而对其它模式的理解有一定的帮助作用。 但是读完本书后,觉得这23种模式处于一个基础或者说是实现层次位置。

每章,作者列出主题和此主题中的问题,然后展示可以解决这些问题的模式,以及相关模式的关系。 对每个模式,作者列出此模式的相关模式,此模式的应用场景,此模式的意图和大概实现。

对于这本书,我是直接从头到尾的通读,遇到不懂的模式去书上或网上查找,不懂的跳过,通读而已。 其它我们可以按主题阅读(按章阅读)或按模式阅读(按小节阅读)。 不过如果对模式了解不多,如我,还是老老实实从头到尾先看一遍吧,后面读第二遍再按主题和模式阅读吧。

虽然有人反对模式,个人认为,存在即合理。模式将一些经验性的内容记录下来,值得推崇,却不可全按此来, 所有的解决方案都是基于特定问题的处理,虽然有通用的方案,却只能解决一些常见的问题,当我们遇到问题时,模式是一个很好的参考方案。 尽信书不如无书,若书未阅,何来信书之说?

现在,好读书,不求甚解,每有会意,欣然却不敢忘食。

构建可扩展的WEB站点读书笔记

关键字

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. 让我认清了在项目管理和日常中一些工作的意义

UTF-8编码的前世今生

这个标题有点标题党了,其实我想写的是UTF-8编码的一些概况,以及如何使用PHP识别UTF-8编码和PHP对UTF-8编码的支持。 文章的目的只是为了理清原本不清楚的概念,完善知识体系。

概述

在不远的曾经,如果应用需要支持国际化(i18n),则需要应用程序能够使用不同的字符集和编码输入、存储和输出数据。 不同的字符集都可以展现和编码定义好的字符,但是一个字符集不能使用另一个字符集来显示。 当人们受不了这种不兼容时,人们开始考虑使用一种标准的字符集和编码来统一这个世界。 于是,在1991年,Unicode产生了。 它涵盖了所有已知的可写语言的所有字符的字符集。而UTF-8编码只是UNICODE的一种变长度的编码表达方式。

维基百科中对于UTF-8编码的解释是: UTF-8(8-bit Unicode Transformation Format)是一种针对Unicode的可变长度字符编码(定长码), 也是一种前缀码。它可以用来表示Unicode标准中的任何字符,且其编码中的第一个字节仍与ASCII兼容, 这使得原来处理ASCII字符的软件无须或只须做少部份修改,即可继续使用。

UTF-8适用于紧凑地存储拉丁字母。UTF-8编码的一个优点是它可以编码成字节流,这样可以将透明化底层的体系架构。

UTF-8字节布局

字节数 位数 UTF-8字节流
1 7 0xxxxxxx
2 11 110xxxxx 10xxxxxx
3 16 1110xxxx 10xxxxxx 10xxxxxx
4 21 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
5 26 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
6 31 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
7 36 11111110 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
8 42 11111111 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

关于BOM

BOM是Byte Order Mark的简称, 它出现在Unicode流的开头部分,用来说明编码类型。因为系统可能是big endian,也可能是little endian, 或者是多字节的Unicode编码.把BOM放置在文件开头部分,利用它来判断字节序。

在UTF-8编码中,BOM没有太大的意义,并且不推荐使用它。在HTML或XML的文件开头放置BOM,可能会导致无法解析。 在PHP中,如果头部有BOM,则可能会出现网页头部多一行、导致网页出现乱码或者其它不可预知的错位或错误, 因此,我们应该避免在PHP模板文件或源码代码文件的开头放置BOM。 但是Windows下,有些程序会默认给utf-8文件添加BOM,此时需要手动清除BOM头, 如果此类文件太多,可以考虑写程序遍历指定目录下所有文件,清除开头的BOM.

使用UTF-8编码

输出UTF-8编码文件

如果要告诉浏览器你输出的编码格式,在PHP中可以使用:

 header("Content-Type: text/html; charset=utf-8");

除了这种PHP的方式,也可以使用meta标签设置编码:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

对于xml文档,它可以直接支持编码作为xml的一部分。

<?xml version="1.0" encoding="utf-8" ?>

PHP中的UTF-8编码支持

在PHP中,内置的字符串函数并不支持多字节的字符串,Unicode需要mbstring扩展支持,此扩展重载了现有的字符串处理函数。 PHP6计划将Unicode支持内置到语言中。

Mysql中的utf-8

如果我们的Mysql是使用utf-8编码,则在执行查询前经常会使用

SET names utf8;

它的作用相当于执行下面的三条语句:

SET character_set_client = utf8;
SET character_set_results = utf8;
SET character_set_connection = utf8;

在应用中出现编码问题,一个比较笨却有效的办法是将PHP文件,mysql客户端,mysql服务器端,前端页面,全部统一用utf-8编码。 另外在phpMyAdmin中有多种字符集,其中utf8_unicode_ci和utf8_general_ci是最常用的, 但是utf8_general_ci对某些语言的支持有一些小问题,如果可以接受, 那最好使用utf8_general_ci,因为它速度快。否则,请使用较为精确的utf8_unicode_ci,不过速度会慢一些。

识别UTF-8编码

在应用开发过程中,如果需要验证输入是否为UTF-8序列,则可能需要写代码实现相关功能。 虽然我们可以指定前端页面为UTF-8,但是我们并不能控制到服务器的数据一定是从指定的页面发送的。 因此,我们需要识别UTF-8编码。

/**
 * 识别UTF-8编码 判断一个字符串是否为utf-8编码 2011-04-18 sz
 * @author phppan.p#gmail.com
 * http://www.phppan.com
 * 哥学社成员(http://www.blog-brother.com/)
 * TIPI团队成员(http://www.php-internal.com/)
 * @package blog
 */

/**
 * 判断一个字符串是否为utf-8编码 方法一
 * 依据UTF-8编码的字节布局,以逆向思维,通过判断其不是UTF-8编码来判断正确性。
 * 此算法来源于<<Building Scalable Web Sites>>
 * @param <type> $string
 */
function is_utf8($string) {
    $pattern = '[\xC0-\xDF]([^\x80-\xBF]|$)'; //  匹配110xxxxx,其后应该有1个字节,如果此字节无法匹配10xxxxxx,或为结束符,则不是utf-8
    $pattern .= '|[\xE0-\xEF].{0,1}([^\x80-\xBF]|$)'; //匹配1110xxxx,其后应该有2个字节,
    $pattern .= '|[\xF0-\xF7].{0,2}([^\x80-\xBF]|$)';//匹配11110xxx,其后应该有3个字节,
    $pattern .= '|[\xF8-\xFB].{0,3}([^\x80-\xBF]|$)';//匹配111110xx,其后应该有4个字节,
    $pattern .= '|[\xFC-\xFD].{0,4}([^\x80-\xBF]|$)';//匹配1111110x,其后应该有5个字节,
    $pattern .= '|[\xFE-\xFE].{0,5}([^\x80-\xBF]|$)';//匹配1111110,其后应该有6个字节,
    $pattern .= '|[\x00-\x7F][\x80-\xBF]';
    $pattern .= '|[\xC0-\xDF].[\x80-\xBF]';
    $pattern .= '|[\xE0-\xEF]..[\x80-\xBF]';
    $pattern .= '|[\xF0-\xF7]...[\x80-\xBF]';
    $pattern .= '|[\xF8-\xFB]....[\x80-\xBF]';
    $pattern .= '|[\xFC-\xFD].....[\x80-\xBF]';
    $pattern .= '|[\xFE-\xFE]......[\x80-\xBF]';
    $pattern .= '|^[\x80-\xBF]';

    return preg_match("!$pattern!", $string) ? FALSE : TRUE;
}

/**
 * 网上流传的一个验证方法 方法二
 * @link http://www.w3.org/International/questions/qa-forms-utf-8.en.php
 * @param <type> $string
 * @return <type>
 */
function is_utf8($string) {
    $pattern = '/^(?:';
    $pattern .= '[\x09\x0A\x0D\x20-\x7E]';             # ASCII
    $pattern .= '|[\xC2-\xDF][\x80-\xBF]';             # non-overlong 2-byte
    $pattern .= '|\xE0[\xA0-\xBF][\x80-\xBF]';         # excluding overlongs
    $pattern .= '|[\xE1-\xEC\xEE\xEF][\x80-\xBF]{2}';  # straight 3-byte
    $pattern .= '|\xED[\x80-\x9F][\x80-\xBF]';         # excluding surrogates
    $pattern .= '|\xF0[\x90-\xBF][\x80-\xBF]{2}';      # planes 1-3
    $pattern .= '|[\xF1-\xF3][\x80-\xBF]{3}';          # planes 4-15
    $pattern .= '|  \xF4[\x80-\x8F][\x80-\xBF]{2}';
    $pattern .= ')*$/xs';

    return preg_match($pattern, $string);
}

/**
 * 判断字符串是否为utf8编码 方法三
 * @param <type> $string
 * @return <type>
 */
function is_utf8($string) {
    if (preg_match("/^([" . chr(228) . "-" . chr(233) . "]{1}[" . chr(128) . "-" . chr(191) . "]{1}[" . chr(128) . "-" . chr(191) . "]{1}){1}/", $string) == TRUE
            || preg_match("/([" . chr(228) . "-" . chr(233) . "]{1}[" . chr(128) . "-" . chr(191) . "]{1}[" . chr(128) . "-" . chr(191) . "]{1}){1}$/", $string) == TRUE
            || preg_match("/([" . chr(228) . "-" . chr(233) . "]{1}[" . chr(128) . "-" . chr(191) . "]{1}[" . chr(128) . "-" . chr(191) . "]{1}){2,}/", $string) == TRUE
    ) {
        return TRUE;
    }

    return FALSE;
}

第一种和第二种基本类似,结果也基本类似,但是对于“营业”等字符串无法准确的识别。 第三种方法对于上面提到的字符串可以正确识别,但是对于“欧舒丹”等字符串却无法识别。