Jack Zhou的专栏

    搭建PHP开发环境：    1、准备并安装下列软件：    MySQL 5.1.30: http://dev.mysql.com/downloads/。    Apache 2.2.14: http://httpd.apache.org/. 在安装过程中,会出现3个文本框，上面两个输入你的本机IP（如：127.0.0.1），最下面输入你的EMAIL。安装完成后，apache

嘉宾介绍洪强宁，豆瓣首席架构师。豆瓣第一位全职员工。清华毕业后，洪强宁一直做嵌入式系统。在2002年开始接触Python语言，从硬件工程师变为软件工程师，对一种语言在计算机底层如何工作有深入的理解。架构

来自雅虎的网站加速最佳实践。先讲

最近，阅读了Will Larson的文章Introduction to Architecting System for Scale，感觉很有价值。作者分享了他在Yahoo!与Digg收获的设计可伸缩系统的架构经验。在我过往的架构经验中，由于主要参与开发企业软件系统，这种面向企业内部的软件系统通常不会有太大的负载量，太多的并发量，因而对于系统的可伸缩性考虑较少。大体而言，只要在系统部署上考虑集群以及

美国计算机科学家，LaTex的作者Leslie Lamport说：“分布式系统就是这样一个系统，系统中一个你甚至都不知道的计算机出了故障，却可能导致你自己的计算机不可用。”一语道破了开发分布式系统的玄机，那就是它的复杂与不可控。所以Martin Fowler强调：分布式调用的第一原则就是不要分布式。这句话看似颇具哲理，然而就企业应用系统而言，只要整个系统在不停地演化，并有多个子系统共同存在时，这条

在eBay，可伸缩性是我们每天奋力抵抗的一大架构压力。我们所做的每一项架构及设计决策，身前身后都能看到它的踪影。当我们面对的是全世界数以亿计的用户，每天的页面浏览量超过10亿，系统中的数据量要用皮字节（1015或250）来计算——可伸缩性是生死交关的问题。在一个可伸缩的架构中，资源的消耗应该随负载线性（或更佳）上升，负载可由用户流量、数据量等测量。如果说性能衡量的是每一工作单元所需的资源消 耗

前言新技术层出不穷。过去十年时间里，我们经历了许多激动人心的新技术，包括那些新的框架、语言、平台、编程模型等等。这些新技术极大地改善了开发人员的工作环境，缩短了产品和项目的面世时间。然而作为在软件行业第一线工作多年的从业者，我们却不得不面对一个现实，那就是当初采用新技术的乐趣随着项目周期的增长而迅速减少。无论当初的选择多么光鲜，半年、一年之后，只要这个项目依然活跃，业务在扩张——越来越

基本思路1. 为什么要做组件化？无论前端也好，后端也好，都是整个软件体系的一部分。软件产品也是产品，它的研发过程也必然是有其目的。绝大多数软件产品是追逐利润的，在产品目标确定的情况下，成本有两个途径来优化：减少部署成本，提高开发效率。减少部署成本的方面，业界研究得非常多，比如近几年很流行的“去IOE”，就是很典型的，从一些费用较高的高性能产品迁移到开源的易替换的产品集群，又比如使用Li

前言为了解决传统Web开发模式带来的各种问题，我们进行了许多尝试，但由于前/后端的物理鸿沟，尝试的方案都大同小异。痛定思痛，今天我们重新思考了“前后端”的定义，引入前端同学都熟悉的NodeJS，试图探索一条全新的前后端分离模式。　　随着不同终端(Pad/Mobile/PC)的兴起，对开发人员的要求越来越高，纯浏览器端的响应式已经不能满足用户体验的高要求，我们往往需要针对不同的终端开发定

前后端分离模式下的安全解决方案前言在前后端分离的开发模式中，从开发的角色和职能上来讲，一个最明显的变化就是：以往传统中，只负责浏览器环境中开发的前端同学，需要涉猎到服务端层面，编写服务端代码。而摆在面前的一个基础性问题就是如何保障Web安全？本文就在前后端分离模式的架构下，针对前端在Web开发中，所遇到的安全问题以及应对措施和注意事项，并提出解决方案。跨站脚本攻击(XSS)

鄙人先后在CERNET做过拨号接入，在Yahoo&3721搞过搜索前端，在猫扑处理过mop.com的架构升级，在6.cn视频网站从事开发工作，还在多年的工作中接触和开发过不少大中型网站的模块，因此在大型网站应对高负载和并发的解决方案上有一些积累和经验，希望和大家一起探讨。　　一个小型的网站，比如个人网站，可以使用最简单的html静态页面就实现了，配合一些图片达到美化效果，所有的页面均存放在一个

摘要：　　负载均衡(Load Balance)是集群技术（Cluster）的一种应用。负载均衡可以将工作任务分摊到多个处理单元，从而提高并发处理能力。目前最常见的负载均衡应用是Web负载均衡。根据实现的原理不同，常见的web负载均衡技术包括：DNS轮询、IP负载均衡和CDN。其中IP负载均衡可以使用硬件设备或软件方式来实现。

REST架构风格最初由Roy T. Fielding（HTTP/1.1协议专家组负责人）在其2000年的博士学位论文中提出。HTTP就是该架构风格的一个典型应用。从其诞生之日开始，它就因其可扩展性和简单性受到越来越多的架构师和开发者们的青睐。它必将得到更大的发展。一方面，随着云计算和移动计算的兴起，许多企业愿意在互联网上共享自己的数据、功能；另一方面，在企业中，RESTful API（也称RE

本文翻译自：http://www.aosabook.org/en/index.html （卷2第1章）    中文版参考了这里的翻译：http://www.oschina.net/translate/scalable-web-architecture-and-distributed-systems    开源软件已成为一些超大型网站的基础组件。并且随着那些网站的发展，围绕它们的架构出现

本文整理自：http://www.cnblogs.com/sunli/archive/2011/02/19/mobile_architecture.html    今天参加了InfoQ组织的百度技术沙龙活动“移动互联网基础技术解析——无线搜索与HTML5开发”，在最后的Open Space环节主持了一个话题“移动互联网系统架构的特点”，现在把讨论的一些重点给记录一下。    （一）并发

不知你是否意识到，围绕着什么才是实现异构的应用到应用通信的“正确”方式，一场争论正进行的如火如荼：虽然当前主流的方式明显地集中在基于SOAP、WSDL和WS-*规范的Web Services领域，但也有少数人用细小但洪亮的声音主张说更好的方式是REST，表述性状态转移（REpresentational State Transfer）的简称。在本文中，我不会涉及争论的话题，而是尝试对REST和RES

我们已习惯于在大型中间件平台（比如那些实现CORBA、Web服务协议栈和J2EE的平台）之上构建分布式系统了。在这篇文章里，我们将采取另一种做法：我们把支撑Web运行的协议和文档格式视为一种应用平台，一种可通过轻量级中间件访问的平台。我们通过一个简单的客户-服务交互的例子，展示了Web在应用集成中的作用。在这篇文章里，我们以Web为主要设计理念，提炼并分享了我们下本书《GET /connected

三种流行 web 服务的架构　　Web 服务是一种面向服务的架构的技术，通过标准的 Web 协议提供服务，目的是保证不同平台的应用服务可以互操作。根据 W3C 的定义，Web 服务（Web service）应当是一个软件系统，用以支持网络间不同机器的互动操作。网络服务通常是许多应用程序接口（API）所组成的，它们通过网络，例如国际互联网（Internet）的远程服务器端，执行客户所提交服务的请

这是一个关于订单的故事。四个月前，我在某刚刚上市不久的网上书城框框网购买了一包纸尿裤，因为尺寸不对，我选择了退货，由此开始了我糟糕的用户体验：首先是快递公司取回了纸尿裤却没有还款给我，接下来，在两个月的时间里，我不得一次又一次的向框框的客服投诉，客服很客气，她让我说出我的订单号然后说需要帮我查一查，两分钟后，她说需要和快递公司联系，稍后再打给我；随后的客服都很客气，但无一例外的，她们都不清楚我订单

由于 REST 可以降低开发的复杂度，提高系统的可伸缩性，增强系统的可扩展性，简化应用系统之间的集成，因而得到了广大开发人员的喜爱，同时得到了业界广泛的支持。比如 IBM，Google 等公司的很多产品都提供了 REST API 给开发人员；与此同时，大量的开源项目和云计算服务都提供了 REST API 接口。　　而在最近，一些新产品的开发甚至已经几乎完全抛弃了传统的类似 JSP 的技术， 转

这是一篇知识性的文档，主要目的是为了让Web缓存相关概念更容易被开发者理解并应用于实际的应用环境中。为了简要起见，某些实现方面的细节被简化或省略了。如果你更关心细节实现则完全不必耐心看完本文，后面参考文档和更多深入阅读部分可能是你更需要的内容。什么是Web缓存，为什么要使用它？Web缓存的类型：浏览器缓存；代理服务器缓存；Web缓存无害吗？为什么要鼓励缓存？Web缓存如何工

引子　　在移动互联网、云计算迅猛发展的今天，作为一名Web开发者，如果您还没听说过“REST”这个buzzword，显然已经落伍了。夸张点说，甚至“出了门都不好意思跟别人打招呼”。尽管如此，对于REST这个泊来品的理解，大多数人（包括一些资深的架构师）仍然停留在“盲人摸象”的阶段。常常听到各种各样关于REST的说法，例如：有人说：“我们这套新的API决定不用Web Service（SOAP+W

最近业务试水电商，接了一个秒杀的活。之前经常看到淘宝的同行们讨论秒杀，讨论电商，这次终于轮到我们自己理论结合实际一次了。　　ps：进入正文前先说一点个人感受，之前看淘宝的ppt感觉都懂了，等到自己出解决方案的时候发现还是有很多想不到的地方其实都没懂，再次验证了“细节是魔鬼”的理论。并且一个人的能力有限，只有大家一起讨论才能想的更周全，更细致。好了，闲话少说，下面进入正文。 一、秒杀带来