- 论坛徽章:
- 0
|
本帖最后由 coolesting 于 2011-09-11 11:35 编辑
############################################################
# 1,初学者怎么入门Web开发?
############################################################
没编程基础从静态网页学起, 相对简单, 容易上手, 如html, javascript/jquery, css/sass。
有编程基础从动态网页学起, (如果没基础但想学动态, 可以从ASP.NET学起, ASP.NET可能只是过渡, 不一定是你最终的选择)
因为新人起步, 关键是培养兴趣, 打基础可以边实践边恶补。
############################################################
# 2,你选哪种Web开发技术,JEE、PHP、.Net、RoR、Django......?,依据是什么?
############################################################
我爱ruby, 依据就是, ruby大方得体, 方便好用, 简单, 可读性强(有人会反对这点,但对于懂英语又没编程基础的人很容易上手)。
我大学毕业的作品是用ASP.ENT做的, 毕业那年看了几部1000+页的.NET部头, 但出来工作第一个项目就是对discuz的维护和二次开发, 基于公司的需要, 我放弃ASP.NET转向PHP, 一眨眼就是三年, 2011年, 五月份, 我第七次重构和设计一个CMF(CMS+FW), 其中我发现二个问题(以前遇到过, 但这次特别严重), 第一, PHP本身性能。 第二, PHP代码极丑, 多余累赘的代码, 在大量阅读和维护时极影响效率, 以始同时, 我在设计一个新的模板引擎, (我叫它nohtml) 就是把html的逻辑从html的标签中分离, 方便维护和html各版本的兼容, 后来这个项目流产。 因为我这个CMF设计过程中要去别的框架和语言寻找灵感, 我发现了python, 觉得它非常优雅, 又因为python, 我认识了ruby, 最终选择了ruby。
############################################################
# 3,如果你是一名Web开发者,请把你在Web开发中遇到的性能问题跟大家做个分
############################################################
1. 问题前言:
影响web性能比较多, 首先把它切割为硬件和软件二块, 这分别映射为静态和动态网页,
如果把整个项目都静态化, 在高并发下仍然撑不住, 这基本就是硬件问题, 软件就是操作系统问题。
随着六前年web2.0和SNS的风起云涌, 恐怕Web应用上真正的性能瓶颈在于项目的复杂性和实时性。
2. 问题分析:
影响web性能有几点:
- 硬件, 如内存, 处理器, 网路带宽布局
- 操作系统的I/O, 如不同的操作系统, 不同的文件处理, 储存格式, 文件压缩
- 服务器应用,如nginx做反代理, lighttpd做静态文件
- web接口, 如cgi, fcgi的设计
- 数据库应用, sql优化, 分表, 表的设计等等
- 软件应用, 语言, 框架/软件系统等
这里结合我对设计CMF的过程,并对第6点的复杂性和实时性结合实例进行谈探。
任何一个强大键壮的项目都是经过无数次的重构, 无数次架构调整, 维护开发得出来的, 但这个过程是一个链锁反应, 开始一个项目的架构设计不行, 随着后期大量的应用插入(无论是第三方还是自身) 这好比堆叠代码一样, ,要增加一个功能就往文件里写一个方法, 一个类, 堆的代码越多, 特别是在逻辑阵乱插代码, 项目运行起来越慢, 越难维护, 因为本身架构的设计限制了软件应用的弹性。
以Discuz X为例, 懂PHP的都知道, 拿这个来二次开发, 极为头痛(相对刚接触discuz的新手), 其实这个就是ucenter, uchome, discuz... 堆在一起的杰作。
------ 架构设计问题影响项目的开发和维护
以Drupal 为例,这个CMF功能众所周知的强大, 应用架构设计不错, 但复杂的功能严重影响了性能, 仅仅是主页就三十多条sql查询。
------- 随着复杂的应用带来的性能问题
以Dedecms 为例, 一个门户型CMS, 把大部分页面静态化以达到最好的速度性能。
------- 因为静态页面, 基本没什么实时性可言, 文章要修改得重新生成一个静态页
以上三个案例都是相对来默认版本设定情况, 要自己可以修改和优化处理才能达到最佳的性能。
3. 问题处理和结果 :
对于小网站没什么优化可言, 那么我们来讨论高并发的。
首先, 服务器对应用的处理, 数据库的分表分段, 操作系统的I/O处理和文件压缩, 这些请用google。
我们针对以上第2点提出的问题来研究,一个应用的复杂性和实时性如何优化。
首先, 我们把一个应用切分为好几个版本, 或者叫阶段, 如测试, 开发, 产生。
产生阶段是整个应用最稳定时期, 性能达到当前版本最好状况,
开发和测试阶段就是对一个项目应用进行升级和维护时期, 为了实际性的测试, 我们可以在用户在线最少的时候将整个项目切换到这个开发版本, 以减少对用户使用不便的影响。 (等测试版本达到稳定阶段才正式投入生产)
复杂的应用, 逻辑层的类和方法, 显示层的连接和块模型很多, 我们分别建一个表把所有的应用标记上, 每当用户点击一个事件, 就记录一次, 相当于把所有url的路由记录下来分析, 看什么应用是点击最多, 什么应用点击最少, 点击最多的部份我们把它独立出来, 如果不能静态处理又要实时性, 则memcache+background进程多层处理, 在保证数据的实时性同时, 我们对点击少的全静态化, 如果ajax调用实时数据还要注意对seo的影响进行特别的处理。 (具体怎么做, 这涉及到所使用的语言和框架, 以及自身的特性, 就不长篇大论了)
这里以chinaunix为例, 用一个如何用实时性解决一个web应用性能瓶颈的问题。
假设这个discuz论坛在发帖时要增加一个tag功能, 但以chinaunix以帖子目前数量, 这个tag假定可能上万个, 或者更多, 这个功能要在帖子提交时检查一遍这些tag, 如果用户当前贴子添加的tag不存在, 那必需创建一个。
并假设这个操作需要花三秒钟(操作多,数据量大时可能要花更长时间), 但对于常规用户发个帖子要等三秒的提交时间是什么概念, 可能非常痛苦(如csdn)。
那么我们可以这样, 用ajax来提交帖子, 因为这个操作并不影响seo, 浏览器兼容问题可以用js平稳退化解决,
我们这个ajax提交, 在显示层的操作可以是先假定用户能正常提交帖子, 并显示提交结果的操作, 然后把要提交的数据送回服务器让一个background进程去处理, 那么现在我们提交帖子的速度一下提升到零点几秒(对用户而言), 至于后台的进程要花多少时间去处理这个帖子, 那就后台的工作了, 这个工作无论是三秒还是五秒, 只要用户感觉起来永远都是零点几秒就算成功。
4. 经验教训总结:
简单点, 架构的设计很重要, 直接影响到后期的应用开发和维护, 它决定了web应用方面的性能。
因为许多php本身特性的问题, 现在我放弃php, 以全心投入对ruby/rack/rails/git/thin等等的学习和研究。
开始, 我想用ruby对原先的php的CMF重写, 但考虑到“重覆做轮”的问题, 所以决定深入rails。(可见一个语言自身的架构对其上层作品和市场的影响)
最后修改于2011.09.11,by coolesting@gmail.com, 欢迎指正错误, 提出建议。 |
|