Web 架构师的能力

文/刘如鸿

最近和几个朋友在谈到时下流行的Web 2.0,也提到了其中最重要的角色——架构师。多方各有争执,不外乎是因为背景和视角的缘故,包括架构一词,本身就从建筑学借鉴而来,至于架构师,则可以简单地从建筑学的设计师来引申,不外乎就是设计结构,设计一个大楼的结构。回到软件本身,那就可以简单地理解为负责设计软件框架的人了。

我们没有讨论清楚架构师、软件架构师、系统架构师及其Web 架构师这些看似相同却有所区别的角色的关键,本身智者见智,仁者见仁,也不是一时半会能够说清楚的,最后我们讨论作为一个Web 2.0 网站架构师需要的一些基本的知识和能力,既然是个人看法,难免有失偏颇:

熟知你的业务模式和目标人群

这是最重要的,Web 2.0 本质上是以Web 作为平台的业务应用,如果不真正了解你的业务,不了解用户的核心需求,不了解你目标客户的典型行为,是很难做好网站的。从这个角度来讲,一个Web 架构师首先必须是一个出色的产品经理。大多时候,我们只要做到业务技术领先就足够了,一味地追求技术的先进性反倒会深陷泥潭。

在技术和业务之间找到一个平衡,也就意味着必须明白整个业务核心的竞争力在哪?目标人群基本诉求在哪?然后选择最低成本的技术来实现业务需求,但是反过来,又必须适当地为业务发展保留适当的平台空间。

打个比方说,如果是一个以照片分享为目的应用,你可以将注册程序写的烂一点(但是不可以烂到不能动),你可以将帮助系统做的不那么好看一点,但是上传照片和浏览照片绝对不可以慢,你可以数据库设计的不是那么好,但是存储问题绝对要慎重,绝对不能够在照片超过1 万张后,网站速度就和牛一般……

只有真正理解你所要做的事情,技术那玩意儿才可能变得可爱起来。

了解负载均衡策略实现

不管怎样的2.0,怎样的业务,你都必须做一个关键的假设:你的流量一定会上涨的,单台机器一定不能够满足你业务发展的需求。我相信这样的假设是合理的,没有一个Web 2.0 公司相信他们可以用一台机器来改变世界。

并不是要求从一开始就设计一个理想化的负载均衡策略,那样未免有些“未雨绸缪”,但是作为一个Web 架构师,一定要给自己留下一些“分家”的余地。因此适当地了解不同层面的负载均衡策略实现是必要的。

一般来说,在小规模发展初期,适当地考虑数据库分拆和按照业务进行域名分拆就足够了。在中等规模的情况下,可能需要适当地采纳硬件或者软件Load-Balancer,在这种场景中,Web 层面的负载均衡你可以通过F5/NetWare 那样的硬件来帮你实现,当然了,选择Apache 或者更加专业的负载均衡软件也未尝不可,比如Windows 下面的NLB 和Linux 下面的LVS 。而为了实现负载均衡,在应用服务器层面作一些适当的调整也是必要的,至少此刻不能够让你随心所欲地使用session 变量了(其实也并不是完全不可用),而一旦你采用了缓存(Web 2.0 有谁不知道MemCached?),如果不考虑周全,本来单机环境下好好的应用到头来就变得乱七八糟,本质上无非是数据不同步的问题,其实反过来想,你把流量和压力分解了,数据各自为政了,不出问题也是没有天理的。

言归正传,作为一个Web 架构师,必须了解负载均衡策略的不同实现,更加要了解负载均衡之后可能引发的问题和关键点,对此一无所知,在面子上也是说不过去的。

设计“合理”的存储

该没有人打算将所有的东西存储在一个关系数据库里面吧,也该没有人可以说一个Web 2.0 网站用一个关系数据库可以解决问题。如果说Web 2.0 是以用户为中心,那么也可以说成是以用户数据为核心价值,应用的核心驱动是数据。没有办法讨论是应该用关系数据库还是不用关系数据库,许多东西就是在其中找到一个平衡,一个“合理”的平衡。

传统的存储会分为SAN 、NAS 和DAS,只不过随着技术的发展,其中的边界越来越模糊,模糊的可以甚至让你忘记其中的差别,你尽管看好口袋里的银子,大致明白有多少银子能够办多少事情就可以了。但是你还是需要去做选择,对于Web 应用而言,大多还是PC 服务器,也可能许多人热衷于通过相对廉价的设备构建诸如GFS 那样的存储架构。

许多人认为Web 2.0 最关键的是业务,“用钱可以解决的问题,就不是问题”,这话是对的,在早期如果就将架构设计为未来5-10 年的架构,架构师的这种“远见”必定成为日后的笑柄,但是反过来不去考虑任何数据分布的可能,如此短见终究会自食其果。

再看看实际情况中,架构师应该如何面对呢?在启动阶段,简单而直接的关系型数据库就可以了,你并不需要花费太多的精力去考虑,只要大致测算出一台服务器的容纳能力,然后估算出在到达容纳能力上限的一半左右,你有多少的时间可以去折腾,如此而已,也真够了。简单地说,粗鲁一点,一台文件服务器,一台数据库服务器,只要别犯愚蠢错误,诸如文件只有一个目录,完全不可拆分,如数据库只有一个表,耦合了太多逻辑等等,既然没有,那就放手去做。而在业务发展到一定规模,如已经有10 万用户,不考虑你的存储已经不可能了,此时我们会发现,诸多性能问题是因为不太合理的存储问题而导致,这个时候存储设计更多是应对性能而考虑的。而在发展到更大规模,存储的可管理性和成本问题逐步成为关键。

对于架构师而言,不同时期选择不同的设计策略是尤为重要的,没有最好的,只有合理的架构,存储也亦然。

异构平台的整合能力

如果从企业应用的角度而言,绝对不赞成一个系统中有多个平台的,那会无谓地增加集成的成本,过去的“数据孤岛”是最好的证明。那么究竟Web 架构师是在一个平台上炉火纯青就够,还是能够在多个平台之间漂移为好呢?

我们来重新定义“平台”的含义, 我简单地把它理解成两个层面的,一个是操作系统层面,一个是开发语言层面,当然讨论开来,问题就大了,可以说框架,可以说数据库,可以说协议等等。但是有一点必须肯定,操作系统是你业务软件层面的基础,而开发语言是实现业务的工具,而两者结合起来,都有一些推荐的经典架构,.NET 方面是Windows 2000+Sql Server +IIS 6.0,然后通过Visual Studio 2005/2008,以微软为依托,完全使用他们提供的服务,LAMP 则是Linux+Apache+MySql+Php, J2EE Web 架构则普遍接受为Hibernate+Spring+Struts, 至于RoR, 这是明星式的后起之秀。

一个Web 架构师去思量哪个平台孰优孰劣是愚蠢的,除了能够精通一个平台,那样能够让你处理业务的时候得心应手,但最好还能够同时熟悉另外一个平台,虽然我们可以说时代已经变了,所有的都是XML,都是标准的REST调用,但是你真的能够保证吗?大多应用都是.NET 写的,需要提供一个论坛,你用了DiscuZ,你需要适当地修改业务,虽然论坛本身的定制功能很强大,但是要嵌入特定的业务,不至于对LAMP 一无所知吧,那样连统一登录的问题都不好解决,当然了,也可以为自己说我不需要它,因为有别的可以选择,但是有一点也是事实,你无法随心所欲地根据业务需要增加最适合你业务的模块。

在我个人的理解,一个好的架构师最好能够同时熟悉两种操作系统,两个以上的开发语言,一个方面是现实世界的业务复杂度,一个方面是既然会存在不同的平台,那必定有其合理性的,博取众家之长,能够帮助一个架构师在他的工作平台上更加理性,公正地看待问题本身,其实反过来看.NET 、Java 或者PHP,也不就是相互借鉴其优点嘛。

一个好的架构师,是应该有处理异构平台的能力的,必须记住,Web 本身就是异构的。

设计更好的交互

说到交互,大多人会想到是产品设计范畴的交互式设计,Web 2.0 强调以用户为中心,而交互,也是以用户为驱动的交互设计。但是我在这里谈及的,更多是通常意义的前端设计,也可以称之为“表现层架构”。

我们都知道Web 2.0 很重视交互,也正因为如此,大多工程师耗费更多的时间并不是在后台的数据处理,而是前台的交互。在AJAX 、RIA 大行其道的今天,Web 架构师一个极其重要的职责是简化因为“高度交互”而导致的开发高复杂度。

我们讨论AJAX,但不是让每个开发人员去操作XmlHttpRequest,不是让每个人去了解HTML DOM 、JavaScript 和CSS,然后组合的眼花缭乱,所有人都会知道,让很多开发人员吐血的不是后台代码调试,而是JavaScript 和CSS,因为需要无比的耐心和技巧。而架构的职责呢,就是定义行之有效的规范和实现。

简单一点地说,开发人员要弹出一个类似Facebook 的框,总不至于让每个开发人员各显神通去拼吧,然后绞尽脑汁地去兼容不同的浏览器,兼容不同的版本,再然后兼容不同页面。我需要从后台取数据,需要每个开发人员去自己写,需要一个隐藏的效果,也需要各显神通。

于是,有人会说,上面的几个问题jQuery 可以解决,也有开发人员会采用这个类库,但是也会有人用prototype,而架构师的职责,就是规定应该用什么,怎么用,哪些不可用。

那我可以简单地理解,在这个层面的交互架构师的关键职责是定义到底是不是用jQuery, 不同的界面应该用怎样的html,应该采用怎样的服务器界面技术,应该采用怎样的远程处理框架。

定义这些交互技术的目标是用最简单的方式实现最好的交互,这个也正是架构的职责所在。

性能和故障诊断

本来不应该把这个问题列入其中的,但是考虑到典型的Web 2.0 是永远的beta 版,换句话来说,问题永远存在的,你也不可能一开始就做出一个完美的应用,随着业务的增长,出现性能问题和系统故障的情况是不可避免的,场景很平常, 流量上去了, 却发现整体网站变得奇慢无比,有些页面间歇性地出现错误, 更加要命的是, 开发人员本身也进行了代码复查, 却还是没有找到“愚蠢”的错误。

一个好的架构师,是应该在这个时候能够协助进行一些诊断和优化的,基于业务的、技术的判断,在愈加复杂的系统中,找出核心的问题所在。通常来说,一个应用系统的性能和SQL 的水平是有关系的,但是到底哪些SQL 有问题,问题影响的程度如何。

我不太赞成事后诸葛亮,但是一个好的Web 架构师还是应该能够洞察到性能导致的问题所在,也会提出一套行之有效的故障诊断方案,是数据库是程序还是网络,是操作系统还是硬件本身的问题,或者都兼而有之。

性能和故障诊断涉及到的层面太多了,有操作系统、数据库、配置文件、程序代码,甚至还会和网络有关,每个方面都需要用一本书来说明,也许还不够。但是作为架构师,是必须对此有感觉的。

这是我个人对于Web 2.0 架构师所需要素质的一些理解,但是我想还有很多方面的能力是需要的,比如沟通的能力,抽象的能力,平衡的能力等等,也希望各位来帮忙补充。

作者简介:

刘如鸿, 就职于百合网, 作为技术总监, 也是公司的共同创办人,他有着7 年以上的.NET 开发经验,熟悉各种平台上的大型系统架构设计。他是《.NET 组件程序设计,第二版》(Programming .NET Components,2nd edition)译者。

(本文选自《程序员》2008年6月刊)

阅读更多 登录后自动展开
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页