我既非该项目的负责人,也不是该项目的实施者,仅仅是某一方面的参与.写此文的目的是为了对我所预见的问题先列在此,不做马后炮的评论家.
群博软件在此之前并不有多少名气(至少是我不太知道,可能是我自己有些孤陋寡闻),所以高性能超(注意这个超)大规模的成功安例也不得而知.
在国内,凡重大项目,好象那些能力非凡的专家都没有自信了,非得"学习","参考"一些国外的案例.结果就是本来自己能做好的项目因为国外"专家"的参与而完全失败.最典型的莫过于奥运售票系统.
项目从2月份启动,时间是急了些,当时征求我们意见时,群博的架构师介绍他们的架构设计时,我有一个强烈的感觉:
这是一个企业应用方案架构师,而不是一个超大规模的互联网应用方案架构师.
互联网应用与企业应用的区别在于应用的侧重点不同,互联网应用的业务逻辑相对简单,宽松,但性能至关重要,而企业应用的业务逻辑比较复杂,严密,但性能需求不是很高.
而目前我们被太多的"企业级"理念所迷惑,有一位大师说得好"企业应用"主要体现在资金投入上是企业级的.真正的企业应用不仅仅是技术的问题,更重要的是对企业的业务理解的问题,没有对企业业务三五年的认识,依靠技术上一些基础积累去寻求企业"通用"的解决方案,结果就是"通通不能用".
而目前基础这种通通不能用的最终结果爆发出来的新名词新理念(老技术),其最终的关键词就是"重组".
有人把它称为解耦,有人把它称为AOP/IOP/SOA等等足以让外行吃惊的名称,说到底就是把错综复杂的应用按不同粒度划分然后再按不同分类重组,这就是现代"企业应用"新理念的本质。
对于以业务逻辑的复杂性和严密性为视点的企业应用,其性能与互联网应用不可同日而语,虽然对于有些低层次的技术人员而言处理3000用户请求就已经应付不了,企业应用对他们而言还有"性能"的话题,但从我的观点而言,企业应用谈不上性能问题.我们所能见到的千人以上已经是很大的公司了,即使有万人(是指需要使用企业IT系统的人)规模的公司,不包括那些在车间做档车工的员工.也没有万人同时使用一个企业局域网的场景.
而相对于以千万级的超大规模互联网应用而言,企业应用的性能可以忽略,所以,把企业应用架构模式拿到超大规模互联网应用上来,最终的结果就是死路一条!
且不说目前的企业应用架构是否真正能为企业所用,我们只看这些架构的核心实现,"透明",为企业应用的各业务间傻瓜式地整合而包装的"透明",其本质却是性能的杀手.
用昂贵的贵族式通讯协议来实现业务逻辑的严密性,以性能低下的数据存储来实现对象关系的清析,当你知道你所做的结果是你能承担的情况下,当然无可非论.当一个企业仅有3000个员工对象时,采用OR工具将数据直接以完整的对象来存取有利于我们清析地把握业务流程,但当一个互联网门户的注册用户达到3000万时甚至更多时,任何OR工具都将是性能的致命杀手.
奥运门户网站设计理念是把门户做成一个"网络电视台",以flash为用户界面的承载,服务端架构在最底层为10到20台左右的application server做群集与中央数据库交互,实现数据存取和计算,在全国重要城市分布两位数的webservice服务器提供与客户端的falsh交互.其中静态文件和点播的视频文件将通过CDN进行分发,直播的视频将通过P2P工具来分发.
我们把静态文件,直播和点播的视频文件都归为静态可委托分配的逻辑,这方面通过P2P和CDN可以方便地解决.但是作为用户动态请求逻辑,采用client->webservice->application server->database这种典型的企业应用架构,真的能满足对奥运狂热关注的1.6亿中国网民的访问吗?
未完,随时更新....................
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
