易栈网-膘叔

其实关于这方面我并不了解，昨天在“PHP研讨会议群”里，一直有人在问，但，我确实不了解，于是乎，我没有参与

今天一大早翻开google reader，发现Sanotes就给了我一个惊囍，真是说曹操曹操就到啊。头条就是：keepalived权威指南，吓死我了。

我想，我并没有求过签咋的呀。哈哈

本地做了一个备份：keepalived.pdf

最近，好象谈架构比较多了，所以，我也就跟着copy,paste了一把。。原文来自DBA notes，网址为：http://www.dbanotes.net/arch/best_practices_for_scaling_websites_lessons_from_ebay.html，作者：feng。

内容如下：

很多人都觉得 eBay 在 QCon (北京) 上的技术讲座不错，但对我来说，其实冲击力没那么大了。eBay 一两年前就是这个 PPT 。不过还是比 Amazon 的 Jeff Barr 强了很多，以后要是开个什么会，你把 Jeff Barr 请来还讲那个销售文档，估计自己都不好意思。

不过，eBay 这次的PPT 总算还是有点更新的。

1）数据分片(Partition Everything)

说是分区(Partition)，这里不能简单等同于 Oracle 的分区，理解成分片(Sharding)就好啦。可以参考一下我以前写的科普小文：开源数据库 Sharding 技术 (Share Nothing)。这里要强调一下的是，分片是在数据量的确有规模的时候才适合进行，如果单节点足以应付，那么还是不要冒进。

从分片的模式上，eBay 主要根据功能切分(Functional Segmentation)和水平分割(负载均衡考虑)，作为推论，所有会话都是无状态性的。

2）异步处理(Asynchrony Everywhere)

其实对于任何网站来说，过度追求"同步"化设计还是比较糟糕的做法。以用户能观察到的数据为视角进行设计，中间可以最大限度用异步来完成。

eBay 的举例的模式有两个，一个是事件队列(Event Queue)，另一个是信息分发(Message Multicast)。前者基本上是个生产者--消费者的模型。后者主要用在搜索的架构上。

（膘叔：不知道怎么回事，我下载总是只显示一半看来是我的RP不好？）

注意到图中的消息总线，这才是 eBay 整个架构中的动脉，估计轻易不会批露技术细节

3）自动化(Automate Everything)

这里的自动化举了两个例子，一个是针对运维方面的，另外举了关于机器学习的东西，这是演讲者 Randy Shoup 的强项所在。

eBay 的自动化，在一年前的另一篇文章里可以窥测一点东西。只是这篇文章当初没有被更多人重视，参见：eclipse at eBay。可以看到 eBay 能在自动化方面做得这么好(起码敢出来讲)不是一朝一夕之功。

4）故障检测与回溯(Remember Everything Fails)

更好的失败检测机制: 监控每天超过 2TB 的日志，根据日志中的相关事件得出判断或者预警。这个看起来简单，但实现起来还是需要一点技巧和策略的，重要的是，需要不断根据结果的反馈去改进。

完美回滚: 任何服务都通过服务配置中的标记来识别，无痛回滚。(个人感觉这个非常有难度，尤其是升级的时候)

优雅降级(Graceful Degradation)：能够相对容易的对应用标记"Marks down（下线）"

5）拥抱不一致性(Embrace Inconsistency)

举了 CAP 原则，程立将其形象描述为帽子戏法，非常准确。说起一致性，自从 Amazon CTO Werner Vogels的 Eventually Consistent 一出，基本上不需要我废话了，这就是事务处理的九阴真经，大家回家慢慢参详好了。

eBay 也有自己的绝对准则: 绝对没有分布式事务(两阶段提交), 通过状态机与操作顺序最小化不一致性，通过异步事件(消息总线?)达到最终一致性。

--EOF--

另外小道消息：Amazon CTO Werner Vogels 可能会参加六月份在杭州举办的侠客行大会。

以前的老帖子：eBay 的Scalability最佳实践

对了，如果想直接看讲了什么内容，请看

InfoQ中文站相关内容：

1. 可伸缩性最佳实践：来自eBay的经验
2. eBay的表示层架构与Eclipse
3. 牺牲一致性来换取分布式架构的可伸缩性
4. ActionScript类库推动mash-up Web2.0平台
5. 从业务角度论证如何采用REST风格架构
6. Engine Yard要接管Ruby 1.8.6的维护？
7. 可伸缩性原则
8. 透过digg.com和Reddit了解mashup应用
9. 使用WCF消费REST服务
10. eBay技术特别专题

jQuery这种轻量级的框架大家使用的都比较多，1.3后效率据说又上升了不少，因此，开发基于jQuery的插件也就显得那么理所当然了。
一般来说，jQuery有两种插件模式，一种是：$.extends({}) ，另一种是：$.fn.extends({})
个人理解：前一种是属于全局性的调用，后一种是针对某个元件的绑定调用。这当然是简单的理解。但事实上，也基本上就是这么做的。

官方的例子也比较简单：

看上去是不是容易？然后就可以直接调用了。 $.min(2,3) 返回2
一般情况下，为了在扩展中使用$，却又担心的页面使用了jQuery.noConflict()而取消了$指向jQuery的引用，则需要这样写

这样写不仅能够将$显式指向jQuery，而且将产生的变量封在function的作用范围内，不会污染window全局。
而基于$.fn.extends({})的扩展又如何开发呢？

在这里我引用Roby的译文：http://www.robysky.com/archives/171
英文原文：http://www.learningjquery.com/2007/10/a-plugin-development-pattern

我认为以下插件开发模式是必须应该掌握的：
1.在JQuery命名空间内声明一个特定的命名；
2.接收参数来控制插件的行为；
3.提供公有方法访问插件的配置项值；
4.提供公有方法来访问插件中其他的方法（如果可能的话）；
5.保证私有方法是私有的；
6.支持元数据插件；

下面，我将逐一讲述上面的内容，并在同时给出相关的简单插件开发代码。
1.在JQuery命名空间内声明一个特定的命名

这意味着开发的是一个单一命名的插件脚本，如果你的脚本包含多个插件或者有补充性质的插件，比如$.fn.doSomething() 和$.fn.undoSomething()，那你得声明多个命名了。但是总体来说，当开发一个插件时，我们应该努力做到用一个单一的命名来搞定整个插件。

在例子中，我们将声明一个名为“hilight”的插件。

我们可以这样调用：
$(’#myDiv’).hilight();
但是假如我们需要打破这种单一的命名和调用方式呢？有很多理由支持我们这么做：设计上的需要；更加简单和可读的配置；而且那样将更加符合OO的要求。

在没有给命名空间来到麻烦的前提下，将插件的部署打破成为多个函数的形式将是十分繁琐的。我们通过认识并利用JavaScript中 functions是最高层的对象，和其他对象一样，functions可以被赋予属性，前面我们已经将hilight命名声明在了JQuery的原型对象上，那么，其实，其他的我们想扩展的属性或对象都能够在hilight上进行声明。稍后将详细讲述此点。
2.接收参数来控制插件的行为；

来为我们的hilight插件添加指定前景和背景色的功能，我们需要在函数中允许一个object类型的选项设置。如下所展示的那样：

现在，我们的插件可以这样来调用：

$(’#myDiv’).hilight({
  foreground: ‘blue’
});
3.提供公有方法访问插件的配置项值；

上面的代码我们可以做一下改进，使得插件的默认值可以在插件之外被设置。这无疑是十分重要的，因为它使得插件用户可以使用最少的代码来修改插件配置，这其实是我们利用函数对象的开始。

 4.提供公有方法来访问插件中其他的方法（如果可能的话）

这里要讲的方法和前面的讲解一脉相承，用此方法来扩展你的插件（而且能够让其他人进行扩展）是件很有意思的事情。例如，在扩展hilight插件时，我们可以定义一个format方法用来格式化高亮显示的文本，原来的hilight插件和扩展了format方法的插件代码如下：

如前面所述，我们已经很容易的通过设置options对象的属性来允许一个回调函数来覆写默认的格式设置。在这里有另外一个非常棒的方法来个性化你的插件，上面展示的方法实际上就是通过暴露format方法，使其可以被重新定义。这种做法使得其他人可以采用他们自己的习惯和方式来重写你的插件，这意味着他们可以为你的插件写额外的扩展插件。
仔细考量一下前面我们用到的插件例子程序，你可能会想“我们究竟应该在什么时候使用这种插件方式来实现需求”的问题。一个来自现实应用中的插件便是“ Cycle Plugin”，它是一个支持多种滑动显示特效的插件，特效包括滚动、滑动和渐变等等。但是，实际上，并没有办法来定义每一个可能会用在滑动变幻上的特效。这就是这种扩展方式的有用之处。“ Cycle Plugin”插件暴露了”transitions”对象，这使得用户只需要按照如下方式便可以添加自己的变幻定义：
$.fn.cycle.transitions = {
…
};
这种技巧使得用户可以定义或者采用自己习惯的方式来扩展“ Cycle Plugin”。
5.保证私有方法是私有的；

上面提到的暴露插件中的公有方法的技巧使得插件能够被覆写，这将使插件变得十分灵活而强大，但至于哪一部分，那些属性和方法应该被暴露出来，你得小心了。一旦使其能够被外界访问到，你就得注意到任何调用参数和语义化的变动都可能使其丧失向前的兼容性。作为一般准则，如果不确定是否应该暴露某个属性或对象的话，那就最好别那样做。
那么我们应该怎样来定义多个方法而不至于使命名空间混乱并且保证不被暴露再外呢？这就是闭包的工作，为了便于演示，我们给插件加入了一个叫做 “debug”的功能，它用来记录firebug控制台所选择的网页元素数目。为了创建一个闭包，我们将整个功能的定义放入在一个function中了（有关这方面的知识，可参见JQuery手册）。

debug方法在这里是无法被在插件以外访问到的，因此，我们称之为它是插件私有的。
6.支持元数据插件；

根据你所写的插件的类型，为你的插件加入元数据插件的支持将使其变得更强大。就我个人来说，喜欢采用元数据插件的重要原因便是它可以让你使用定义之外的标签来覆写你的插件属性设置（这在创建demo和例子时十分有用），而且支持它十分的简单。
更新：这部分内容可以在本文的评论中展开讨论（既然有争议的话）

改动部分的代码会做如下的事情：
*测试metadata插件是否可用
*如果可以，将用metadata扩展options对象
这被加入到jQuery.extend，作为其最后一个参数，所以它可以覆写任何其他参数设置。现在我们可以通过下面的方式控制其行为：

而在调用方面，我们通过一行简单的代码就可以实现预期的效果：
$(’.hilight’).hilight();

将上面所述内容涉及到的代码放在一起，完整的例子程序代码如下：

看完以上的内容，你是不是对jQuery的插件开发加深了一定的了解了呢？
顺便提一下，yhustc在自己的博客上写了一个基于jQuery的软键盘插件，你是不是又可以根据上面的教程来写一个基于$.fn.extends的扩展呢？让yhustc的插件可以绑定在某个元件上？

放在PHP栏目是我仔细想过的，虽然文章内容里并未提及到PHP
开发WEB，很多人在一开始就考虑了优化优化再优化，但是，如果按照你这样的优化下去，当你发现瓶劲的时候你怎么办？你已经无法优化了。。
因此，为自己的代码预留一点优化空间，先赶着把代码上线，然后再边运行边优化。一来也保证了上线的时间，二来也可以在运行时注意到哪些地方是需要重点优化的。

以下内容来自守望轩（博客园）的文章：原文http://www.cnblogs.com/xjb/archive/2009/04/13/no-premature-optimization.html

Donald Knuth说“过早优化是万恶之源”（premature optimization is the root of all evil）。这话也许有些夸张，但“过早优化”的危害我觉得不能忽视。同时，我觉得“过早优化”的概念不专属编写程序，生活中的示例也比比皆是。不信，你看看下面这些情形你是否遇到过：

http://www.watch-life.net/life-thinking/no-premature-optimization.html

1、当你开始学一门程序语言的时候（比如c#），你想如果可以精通开发工具（比如Visual Studio）一定如虎添翼，于是一开始你就花很多时间去研究开发工具，而忘记自己学习的重点是语言本身，而非工具。或者，一开始，你花不少的时间去选择哪门程序语言，比较各种语言的优劣，在五花八门的语言前面犹豫不决，这个想学，那个也不想放弃，结果都是学个半路子。

2、当你学习一门外语比如英语的时候，一开始，你花了很多的时间去下载有关英语资料，花了很多的时间去找英语书籍，以为有了这些资料和书籍就可以学好英文，而不是一开始就踏踏实实的从单词、语法开始，结果后来资料下载了一大堆，书籍买了不少，却没有坚持下去。

3、你想搞体育锻炼，比如打羽毛球，于是一开始你花大量时间去买球衣、球鞋、球拍等装备，可没连几天，你发现自己开始三天打鱼了，最后，那些装备都起了灰，也没锻炼几次。

4、你想做时间管理(Getting Things Done),于是你研究各种时间管理的资料，上各种时间管理技巧的网站，比如lifehack、 digg 、gtdlife，下载对最流行的GTD的管理软件，以节省时间的名义浪费时间，很浮躁，不能做到实实在在把每天的计划都落实,拖拖拉拉。

5、你有没有这样的体验，一本书你总是对开头的部分看的最仔细，后面的章节没坚持看下去，下次又重复这种循环。当你计划做一件事的时候，总是规划的 非常完美，几乎考虑每个细节，但却没有认认真真、一步一步执行，或者过早完美计划，反而让你缩手缩脚，犹豫不前，瞻前顾后，顾此失彼，最后虎头蛇尾。

6、比如，如果我有了钱，我就如何如何享受快乐，比如，如果我将来有了很多的时间，我就会花更多的时间陪家人或锻炼…

这样类似的例子还可以举很多。

过早优化对大的问题在于：过早关注不重要的部分，而忽略行动和目标本身。以静态的思维来优化，殊不知，事务发展总是动态的，“优化”是需要长期的实 践积累才可以获得。出发点是好的，但往往好心办坏事，折腾大量的时间，做了很多不该做的，而该做的、重要的反而没做。强化外部条件、工具等外在，而忽略内 在因素和行动本身，或者，过多期望将来，而忽略当下眼前。

活在当下，实实在在做好手头的事，是避免“过早优化”最好的方法之一。

再往 后，取名不用担心了。什么翻康熙字典？不允许
你凭什么翻呀？想反清复明？做梦吧你。
国家有规定，取名有规范，不得取变态名，不得取超长名，象赵C这样的，你敢取？我不给你登记 。
为啥？
看这里：http://news.southcn.com/china/zgkx/content/2009-04/11/content_5057672.htm
我简单摘要一下：