Web架构师应该具备的能力
最近和几个朋友谈到时下流行的Web 2.0，提到了其中最重要的角色——架构师。多方各有争执，不外乎是因为职业背景和视角的缘故。包括架构一词，本身就从建筑学借鉴而来，至于架构师，则可以简单地从建筑学的设计师来引申，不外乎就是设计结构，设计一个大楼的结构。回到软件本身，那就可以简单地理解为负责设计软件框架的人了。
我们没有讨论清楚架构师、软件架构师、系统架构师及其Web 架构师这些看似相同却有所区别的角色的关键区别，本身见仁见智，也不是一时半会能够说清楚的，最后我们讨论了作为一个Web 2.0 网站架构师需要的一些基本的知识和能力(个人看法，难免有失偏颇)：
1，熟知你的业务模式和目标人群
这是最重要的，Web 2.0 本质上是以Web 作为平台的应用，如果不真正了解你的业务，不了解用户的核心需求，不了解你目标客户的典型行为，是很难做好网站的。从这个角度来讲，一个Web 架构师首先必须是一个出色的产品经理。大多时候，我们只要做到业务技术领先就足够了，一味地追求技术的先进性反倒会深陷泥潭。
在技术和业务之间找到一个平衡，也就意味着必须明白整个业务核心的竞争力在哪里？目标人群的基本诉求在哪里？然后选择最低成本的技术来实现业务需求，但是反过来，又必须适当地为业务拓展保留适当的空间。
打个比方说，如果是一个以照片分享为目的应用，你可以将注册程序写的烂一点（但是不可以烂到不能动），你可以将帮助系统做的不那么好看一点，但是上传照片和浏览照片绝对不可以慢，你可以数据库设计的不是那么好，但是存储问题绝对要慎重，绝对不能够在照片超过1 万张后，网站速度就和牛一般……
只有真正理解你所要做的事情，技术那玩意儿才可能变得可爱起来。
2，了解负载均衡策略实现
不管怎样的Web2.0，怎样的业务，你都必须做一个关键的假设：你的流量一定会上涨的，单台机器一定不能够满足你业务发展的需求。我相信这样的假设是合理的，没有一个Web 2.0 公司相信他们可以用一台机器来改变世界。
并不是要求从一开始就设计一个理想化的负载均衡策略，那样未免有些过于“未雨绸缪”，但是作为一个Web 架构师，一定要给自己留下一些“分家”的余地。因此适当地了解不同层面的负载均衡策略实现是必要的。
一般来说，在小规模发展初期，适当地考虑数据库分拆和按照业务进行域名分拆就足够了。在中等规模的情况下，可能需要适当地采纳硬件或者软件Load-Balancer，在这种场景中，Web 层面的负载均衡你可以通过F5/NetWare 那样的硬件来帮你实现，当然了，选择Apache 或者更加专业的负载均衡软件也未尝不可，比如Windows 下面的NLB 和Linux 下面的LVS 。而为了实现负载均衡，在应用服务器层面作一些适当的调整也是必要的，至少此刻不能够让你随心所欲地使用session 变量了（其实也并不是完全不可用），而一旦你采用了缓存（Web 2.0 有谁不知道MemCached?），如果考虑不够周全，本来单机环境下好好的应用到头来就会变得乱七八糟，本质上无非是数据不同步的问题，其实反过来想，你把流量和压力分解了，数据各自为政了，不出问题也是没有天理的。
言归正传，作为一个Web 架构师，必须了解负载均衡策略的不同实现，更要了解负载均衡之后可能引发的问题和关键点，对此一无所知，在面子上也是说不过去的。
3，设计“合理”的存储
该没有人打算将所有的东西存储在一个关系数据库里面吧，也该没有人可以说，一个Web 2.0 网站用一个关系数据库可以解决问题。如果说Web 2.0 是以用户为中心，那么也可以说成是以用户数据为核心价值，应用的核心驱动是数据。没有办法讨论是应该用关系数据库还是不用关系数据库，许多东西就是在其中找到一个平衡，一个“合理”的平衡。
传统的存储会分为SAN 、NAS 和DAS，只不过随着技术的发展，其中的边界越来越模糊，模糊的可以甚至让你忘记其中的差别，你尽管看好口袋里的银子，大致明白有多少银子能够办多少事情就可以了。但是你还是需要去做选择，对于Web 应用而言，大多还是PC 服务器，也可能许多人热衷于通过相对廉价的设备构建诸如GFS 那样的存储架构。
许多人认为Web 2.0 最关键的是业务，“用钱可以解决的问题，就不是问题”，这话是对的，在早期如果就将架构设计为未来5-10 年的架构，架构师的这种“远见”必定成为日后的笑柄，但是反过来不去考虑任何数据分布的可能，如此短见终究会自食其果。
再看看实际情况中，架构师应该如何面对呢？在启动阶段，简单而直接的关系型数据库就可以了，你并不需要花费太多的精力去考虑，只要大致测算出一台服务器的容纳能力，然后估算出在到达容纳能力上限的一半左右，你有多少的时间可以去折腾，如此而已，也真够了。简单地说，粗鲁一点，一台文件服务器，一台数据库服务器，只要别犯愚蠢错误，诸如文件只有一个目录，完全不可拆分，如数据库只有一个表，耦合了太多逻辑等等，既然没有，那就放手去做。而在业务发展到一定规模，如已经有10 万用户，不考虑你的存储已经不可能了，此时我们会发现，诸多性能问题是因为不太合理的存储问题而导致的，这个时候存储设计更多是应对性能而考虑的。而在发展到更大规模，存储的可管理性和成本问题逐步成为关键。
对于架构师而言，不同时期选择不同的设计策略是尤为重要的，没有最好的，只有合理的架构，存储亦然。
4，异构平台的整合能力
如果从企业应用的角度而言，绝对不赞成一个系统中有多个平台的，那会无谓地增加集成的成本，过去的“数据孤岛”是最好的证明。那么究竟Web 架构师是在一个平台上炉火纯青就够了，还是能够在多个平台之间漂移为好呢？
我们来重新定义“平台”的含义， 我简单地把它理解成两个层面的，一个是操作系统层面，一个是开发语言层面，当然讨论开来，问题就大了，可以说框架，可以说数据库，可以说协议等等。但是有一点必须肯定，操作系统是你业务软件层面的基础，而开发语言是实现业务的工具，而两者结合起来，都有一些推荐的经典架构，.NET 方面是Windows 2003/2008+Sql Server +IIS 6.0，然后通过Visual Studio 2005/2008，以微软为依托，完全使用他们提供的服务。LAMP 则是Linux+Apache+MySql+Php， J2EE Web 架构则普遍接受为Hibernate+Spring+Struts，至于RoR、Python，这是明星式的后起之秀。
一个Web 架构师去仔细考察哪个平台孰优孰劣是愚蠢的，除了能够精通一个平台，那样能够让你处理业务的时候得心应手，但最好还能够同时熟悉另外一个平台，虽然我们可以说时代已经变了，所有的都是XML，都是标准的REST调用，但是你真的能够保证吗？大多应用都是.NET 写的，需要提供一个论坛，你用了Discuz，你需要适当地修改业务，虽然论坛本身的定制功能很强大，但是要嵌入特定的业务，不至于对LAMP 一无所知吧，那样连统一登录的问题都不好解决，当然了，也可以为自己说我不需要它，因为有别的可以选择，但是有一点也是事实，你无法随心所欲地根据业务需要增加最适合你业务的模块。
在我个人的理解，一个好的架构师最好能够同时熟悉两种操作系统，两个以上的开发语言，一个方面是现实世界的业务复杂度使然，一个方面是既然会存在不同的平台，那必定有其合理性，博取众家之长，能够帮助一个架构师在他的工作平台上更加理性、公正地看待问题本身，其实反过来看.NET 、Java 或者PHP，也不就是相互借鉴其优点嘛。
一个好的架构师，是应该有处理异构平台的能力的，必须记住，Web 本身就是异构的。
5，设计更好的交互
说到交互，大多人会想到是产品设计范畴的交互式设计，Web 2.0 强调以用户为中心，而交互，也是以用户为驱动的交互设计。但是我在这里谈及的，更多是通常意义的Web前端设计，也可以称之为“表现层架构”。
我们都知道Web 2.0 很重视交互，也正因为如此，大多工程师耗费更多的时间并不是在后台的数据处理，而是前台的交互。在AJAX 、RIA 大行其道的今天，Web 架构师一个极其重要的职责是简化因为“高度交互”而导致的开发高复杂度。
我们讨论AJAX，但不是让每个开发人员都去操作XmlHttpRequest，不是让每个人去了解HTML DOM 、JavaScript 和CSS，然后组合的眼花缭乱。所有人都知道，让很多开发人员吐血的不是后台代码调试，而是JavaScript 和CSS，因为需要无比的耐心和技巧。而架构的职责呢，就是定义行之有效的规范和实现。
简单一点地说，开发人员要弹出一个类似Facebook 的框，总不至于让每个开发人员各显神通去拼吧，然后绞尽脑汁地去兼容不同的浏览器，兼容不同的版本，再然后兼容不同页面。我需要从后台取数据，需要每个开发人员去自己写，需要一个隐藏的效果，也需要各显神通。
于是，有人会说，上面的几个问题jQuery 可以解决，也有开发人员会采用这个类库，但是也会有人用Prototype或ExtJs，而架构师的职责，就是规定应该用什么，怎么用，而哪些又是不可用的。
那我可以简单地理解，在这个层面的交互架构师的关键职责是定义到底是不是用jQuery, 不同的界面应该用怎样的html，应该采用怎样的服务器界面技术，应该采用怎样的远程处理框架。
定义这些交互技术的目标是用最简单的方式实现最好的交互，这个也正是架构的职责所在。
5，性能和故障诊断
本来不应该把这个问题列入其中的，但是考虑到典型的Web 2.0 是永远的beta 版，换句话说，问题是永远存在的，你不可能一开始就做出一个完美的应用。随着业务的增长，出现性能问题和系统故障的情况是不可避免的。场景很平常： 流量上去了, 却发现整体网站变得奇慢无比,有些页面间歇性地出现错误, 更加要命的是, 开发人员也进行了代码复查, 却还是没有找到“低级”的错误。
一个好的架构师，在这个时候应该能够协助进行一些诊断和优化，基于业务的、技术的判断，在愈加复杂的系统中，找出核心的问题所在。通常来说，一个应用系统的性能和SQL 的水平是有关系的，但是到底哪些SQL 有问题，问题影响的程度如何，需要作出快速、准确的判断。
我不太赞成事后诸葛亮，但是一个好的Web 架构师还是应该能够洞察到性能导致的问题所在，也会提出一套行之有效的故障诊断方案：是数据库、程序还是网络，是操作系统还是硬件本身的问题，或者都兼而有之？
性能和故障诊断涉及到的层面太多了，有操作系统、数据库、配置文件、程序代码，甚至还会和网络有关，每个方面都需要用一本书来说明，也许还不够。但是作为架构师，是必须对此有感觉的。
这是我个人对于Web 2.0 架构师所需要素质的一些理解，但是我想还有很多方面的能力是需要的，比如沟通的能力，抽象的能力，平衡的能力等等，也希望各位来帮忙补充。
我们没有讨论清楚架构师、软件架构师、系统架构师及其Web 架构师这些看似相同却有所区别的角色的关键区别，本身见仁见智，也不是一时半会能够说清楚的，最后我们讨论了作为一个Web 2.0 网站架构师需要的一些基本的知识和能力(个人看法，难免有失偏颇)：
1，熟知你的业务模式和目标人群
这是最重要的，Web 2.0 本质上是以Web 作为平台的应用，如果不真正了解你的业务，不了解用户的核心需求，不了解你目标客户的典型行为，是很难做好网站的。从这个角度来讲，一个Web 架构师首先必须是一个出色的产品经理。大多时候，我们只要做到业务技术领先就足够了，一味地追求技术的先进性反倒会深陷泥潭。
在技术和业务之间找到一个平衡，也就意味着必须明白整个业务核心的竞争力在哪里？目标人群的基本诉求在哪里？然后选择最低成本的技术来实现业务需求，但是反过来，又必须适当地为业务拓展保留适当的空间。
打个比方说，如果是一个以照片分享为目的应用，你可以将注册程序写的烂一点（但是不可以烂到不能动），你可以将帮助系统做的不那么好看一点，但是上传照片和浏览照片绝对不可以慢，你可以数据库设计的不是那么好，但是存储问题绝对要慎重，绝对不能够在照片超过1 万张后，网站速度就和牛一般……
只有真正理解你所要做的事情，技术那玩意儿才可能变得可爱起来。
2，了解负载均衡策略实现
不管怎样的Web2.0，怎样的业务，你都必须做一个关键的假设：你的流量一定会上涨的，单台机器一定不能够满足你业务发展的需求。我相信这样的假设是合理的，没有一个Web 2.0 公司相信他们可以用一台机器来改变世界。
并不是要求从一开始就设计一个理想化的负载均衡策略，那样未免有些过于“未雨绸缪”，但是作为一个Web 架构师，一定要给自己留下一些“分家”的余地。因此适当地了解不同层面的负载均衡策略实现是必要的。
一般来说，在小规模发展初期，适当地考虑数据库分拆和按照业务进行域名分拆就足够了。在中等规模的情况下，可能需要适当地采纳硬件或者软件Load-Balancer，在这种场景中，Web 层面的负载均衡你可以通过F5/NetWare 那样的硬件来帮你实现，当然了，选择Apache 或者更加专业的负载均衡软件也未尝不可，比如Windows 下面的NLB 和Linux 下面的LVS 。而为了实现负载均衡，在应用服务器层面作一些适当的调整也是必要的，至少此刻不能够让你随心所欲地使用session 变量了（其实也并不是完全不可用），而一旦你采用了缓存（Web 2.0 有谁不知道MemCached?），如果考虑不够周全，本来单机环境下好好的应用到头来就会变得乱七八糟，本质上无非是数据不同步的问题，其实反过来想，你把流量和压力分解了，数据各自为政了，不出问题也是没有天理的。
言归正传，作为一个Web 架构师，必须了解负载均衡策略的不同实现，更要了解负载均衡之后可能引发的问题和关键点，对此一无所知，在面子上也是说不过去的。
3，设计“合理”的存储
该没有人打算将所有的东西存储在一个关系数据库里面吧，也该没有人可以说，一个Web 2.0 网站用一个关系数据库可以解决问题。如果说Web 2.0 是以用户为中心，那么也可以说成是以用户数据为核心价值，应用的核心驱动是数据。没有办法讨论是应该用关系数据库还是不用关系数据库，许多东西就是在其中找到一个平衡，一个“合理”的平衡。
传统的存储会分为SAN 、NAS 和DAS，只不过随着技术的发展，其中的边界越来越模糊，模糊的可以甚至让你忘记其中的差别，你尽管看好口袋里的银子，大致明白有多少银子能够办多少事情就可以了。但是你还是需要去做选择，对于Web 应用而言，大多还是PC 服务器，也可能许多人热衷于通过相对廉价的设备构建诸如GFS 那样的存储架构。
许多人认为Web 2.0 最关键的是业务，“用钱可以解决的问题，就不是问题”，这话是对的，在早期如果就将架构设计为未来5-10 年的架构，架构师的这种“远见”必定成为日后的笑柄，但是反过来不去考虑任何数据分布的可能，如此短见终究会自食其果。
再看看实际情况中，架构师应该如何面对呢？在启动阶段，简单而直接的关系型数据库就可以了，你并不需要花费太多的精力去考虑，只要大致测算出一台服务器的容纳能力，然后估算出在到达容纳能力上限的一半左右，你有多少的时间可以去折腾，如此而已，也真够了。简单地说，粗鲁一点，一台文件服务器，一台数据库服务器，只要别犯愚蠢错误，诸如文件只有一个目录，完全不可拆分，如数据库只有一个表，耦合了太多逻辑等等，既然没有，那就放手去做。而在业务发展到一定规模，如已经有10 万用户，不考虑你的存储已经不可能了，此时我们会发现，诸多性能问题是因为不太合理的存储问题而导致的，这个时候存储设计更多是应对性能而考虑的。而在发展到更大规模，存储的可管理性和成本问题逐步成为关键。
对于架构师而言，不同时期选择不同的设计策略是尤为重要的，没有最好的，只有合理的架构，存储亦然。
4，异构平台的整合能力
如果从企业应用的角度而言，绝对不赞成一个系统中有多个平台的，那会无谓地增加集成的成本，过去的“数据孤岛”是最好的证明。那么究竟Web 架构师是在一个平台上炉火纯青就够了，还是能够在多个平台之间漂移为好呢？
我们来重新定义“平台”的含义， 我简单地把它理解成两个层面的，一个是操作系统层面，一个是开发语言层面，当然讨论开来，问题就大了，可以说框架，可以说数据库，可以说协议等等。但是有一点必须肯定，操作系统是你业务软件层面的基础，而开发语言是实现业务的工具，而两者结合起来，都有一些推荐的经典架构，.NET 方面是Windows 2003/2008+Sql Server +IIS 6.0，然后通过Visual Studio 2005/2008，以微软为依托，完全使用他们提供的服务。LAMP 则是Linux+Apache+MySql+Php， J2EE Web 架构则普遍接受为Hibernate+Spring+Struts，至于RoR、Python，这是明星式的后起之秀。
一个Web 架构师去仔细考察哪个平台孰优孰劣是愚蠢的，除了能够精通一个平台，那样能够让你处理业务的时候得心应手，但最好还能够同时熟悉另外一个平台，虽然我们可以说时代已经变了，所有的都是XML，都是标准的REST调用，但是你真的能够保证吗？大多应用都是.NET 写的，需要提供一个论坛，你用了Discuz，你需要适当地修改业务，虽然论坛本身的定制功能很强大，但是要嵌入特定的业务，不至于对LAMP 一无所知吧，那样连统一登录的问题都不好解决，当然了，也可以为自己说我不需要它，因为有别的可以选择，但是有一点也是事实，你无法随心所欲地根据业务需要增加最适合你业务的模块。
在我个人的理解，一个好的架构师最好能够同时熟悉两种操作系统，两个以上的开发语言，一个方面是现实世界的业务复杂度使然，一个方面是既然会存在不同的平台，那必定有其合理性，博取众家之长，能够帮助一个架构师在他的工作平台上更加理性、公正地看待问题本身，其实反过来看.NET 、Java 或者PHP，也不就是相互借鉴其优点嘛。
一个好的架构师，是应该有处理异构平台的能力的，必须记住，Web 本身就是异构的。
5，设计更好的交互
说到交互，大多人会想到是产品设计范畴的交互式设计，Web 2.0 强调以用户为中心，而交互，也是以用户为驱动的交互设计。但是我在这里谈及的，更多是通常意义的Web前端设计，也可以称之为“表现层架构”。
我们都知道Web 2.0 很重视交互，也正因为如此，大多工程师耗费更多的时间并不是在后台的数据处理，而是前台的交互。在AJAX 、RIA 大行其道的今天，Web 架构师一个极其重要的职责是简化因为“高度交互”而导致的开发高复杂度。
我们讨论AJAX，但不是让每个开发人员都去操作XmlHttpRequest，不是让每个人去了解HTML DOM 、JavaScript 和CSS，然后组合的眼花缭乱。所有人都知道，让很多开发人员吐血的不是后台代码调试，而是JavaScript 和CSS，因为需要无比的耐心和技巧。而架构的职责呢，就是定义行之有效的规范和实现。
简单一点地说，开发人员要弹出一个类似Facebook 的框，总不至于让每个开发人员各显神通去拼吧，然后绞尽脑汁地去兼容不同的浏览器，兼容不同的版本，再然后兼容不同页面。我需要从后台取数据，需要每个开发人员去自己写，需要一个隐藏的效果，也需要各显神通。
于是，有人会说，上面的几个问题jQuery 可以解决，也有开发人员会采用这个类库，但是也会有人用Prototype或ExtJs，而架构师的职责，就是规定应该用什么，怎么用，而哪些又是不可用的。
那我可以简单地理解，在这个层面的交互架构师的关键职责是定义到底是不是用jQuery, 不同的界面应该用怎样的html，应该采用怎样的服务器界面技术，应该采用怎样的远程处理框架。
定义这些交互技术的目标是用最简单的方式实现最好的交互，这个也正是架构的职责所在。
5，性能和故障诊断
本来不应该把这个问题列入其中的，但是考虑到典型的Web 2.0 是永远的beta 版，换句话说，问题是永远存在的，你不可能一开始就做出一个完美的应用。随着业务的增长，出现性能问题和系统故障的情况是不可避免的。场景很平常： 流量上去了, 却发现整体网站变得奇慢无比,有些页面间歇性地出现错误, 更加要命的是, 开发人员也进行了代码复查, 却还是没有找到“低级”的错误。
一个好的架构师，在这个时候应该能够协助进行一些诊断和优化，基于业务的、技术的判断，在愈加复杂的系统中，找出核心的问题所在。通常来说，一个应用系统的性能和SQL 的水平是有关系的，但是到底哪些SQL 有问题，问题影响的程度如何，需要作出快速、准确的判断。
我不太赞成事后诸葛亮，但是一个好的Web 架构师还是应该能够洞察到性能导致的问题所在，也会提出一套行之有效的故障诊断方案：是数据库、程序还是网络，是操作系统还是硬件本身的问题，或者都兼而有之？
性能和故障诊断涉及到的层面太多了，有操作系统、数据库、配置文件、程序代码，甚至还会和网络有关，每个方面都需要用一本书来说明，也许还不够。但是作为架构师，是必须对此有感觉的。
这是我个人对于Web 2.0 架构师所需要素质的一些理解，但是我想还有很多方面的能力是需要的，比如沟通的能力，抽象的能力，平衡的能力等等，也希望各位来帮忙补充。