锁定老帖子 主题:两年服务器开发的一句话经验集...
该帖已经被评为精华帖
|
|
---|---|
作者 | 正文 |
发表时间:2008-10-14
* 配置多资源时,各种公用的内容没有提取,导致修改时非常麻烦,推荐使用include方式 * 子资源要能使用父资源的指标值,也就是父子要有继承关系 * 国际化时不应该再另起一个模型,这样会使同一修改改动很多文件 * 任何会导致特殊字符危险的方案不能用,比如 - 在解析命令时会解析参数 /o ,后来有一个目录叫"/opt/home" ,导致解析不成功,非常隐蔽而且危险 * 打日志时要尽量的全,哪怕是trace,调试时很方便。不需要的可以不配置,需要时不必再次修改代码。 * cc 的文件名长度有限制,非常不便 * 做配置时,某个对象的属性集中一处配置,哪怕是include,不可分散至引用处重复配置,比如现在原型的资源类型的 disporder * log4j 要做动态加载 * 打日志要规范,利用解析,使用多logger输出 * 队列要集中管理,分配 * 线程要集中管理,分配。无论是线程池还是独立线程的创建。 * 模块化工作的敌人是建一个模块的工程时很麻烦,所以要从架构设计时解决这个问题,因为这个而导致今后结构不清晰,很不值得 * 大数据量的删除操作很慢,约几个小时的时间。所以需要在批量插入的时候判断是否需要删除部分数据 * 用URL返回本地文件路径时,注意URLDecode.decode(path,"UTF-8"); 来转换特殊编码 * 真实环境的压力测试(尤其是异常测试)很重要,未经此测试不要出售,会带来很大的维护压力 * socket 连接重试一定要有间歇,不然会把服务器搞宕 * 用到线程时,线程要继承一处,并作统一创建和管理,以便于在内部设置路标。并且在线程内要及时写入路标。设置路标时,参数以map形式添加,读取时再格式化成字符串。 * 对于多线程程序,线程池分配时,分配策略要可配置以调节性能 * 2008-6-13 06:34下午 今天开发时,A改过的东西 我们B不知道,他在本地修改因为版本已经冻结,导致严重问题复现。今后采用为某个现场环境建立一个hotfix版,在这个版本上记录更改历史 * 给现场安装不知该分配多大内存时,要有一个自动修正功能,设置内存在一个范围内递增。捕获oom 异常,让监控线程关闭系统并修改内存配置重启。但是前提是要保证数据的完整性受损是可接受,或者有解决方案的。 * 当一个小组成员分头支持现场问题时,每个人解决问题后要全体知悉,便于积累经验和对外表达一致 * Joel曾经说过:不要先去完成界面,因为在很多用户看来,完成了界面,就等于功能也快完成了。而要让功能和界面的开发保持同步最好。 * 开发软件不能只顾自己开发时方便,还要考虑到运行维护时是否方便 * 模块依赖api时,此模块要把自己需要的api整理为一套adapter去适配,便于整理出对api方法的依赖,另外在api强行变动时,其他应用也有应急办法 * 留下足够的程序内部信息的监控入口,生产环境是不让动的,xstream * OOM, StackOverflow, JMX高负载后停止服务 * 系统中用到的环境变量名要集中使用常量管理 * io 远程调用传输过程中,尽量合并携带参数 ,减小传输量。不要使用zip。 * 线程要提供一个暂停的方法,以便调试 * 使用需要持久华的缓存,注意与持久化及时同步问题 * 作小于判断时,注意-0 是等于0 的,应该用<=来判断。 * windows 2003系统中当开着服务控制台启动DaemonServer后不关闭mmc控制台,向控制台输内容会导致阻塞。要自定义文件流,使他们保存至文件。 * 持续进数据的队列 要对处理慢的情况有考虑,否则会oom * 同步数据需要在一个事务内完成写入,否则会导致界面的坏体验 * 使用具体类来代替type类型区分,可以帮助在有性能问题时快速定位,只是有可能增加些代码量,值得。 大家还有什么补充嘛! 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2008-10-15
谢谢楼主分享,收藏了。
|
|
返回顶楼 | |
发表时间:2008-10-15
myreligion 写道 看错了,自己删除帖子。 <script>alert(111);<script> |
|
返回顶楼 | |
发表时间:2008-10-15
很强大。
不过看标题,楼主是开发 app server,也就是开发中间件? 不过看内容,似乎是运用 app server做企业级应用开发? 能否详细介绍下你的项目情况,方便大家理解。因为可能都是一句话的缘故,有些内容看的不是很明白。 |
|
返回顶楼 | |
发表时间:2008-10-15
TO raymond2006k :
这里的一句话,很多都是我们找问题一星期甚至更多弄出来的,全都写出来有点不得要领,你对哪个感兴趣呢,我把过程回忆一下! |
|
返回顶楼 | |
发表时间:2008-10-15
另外,我们不是中间件,是一个分布式数据采集引擎!我们所谓的server,其实都是要处理请求,只是处理的过程也很复杂!
|
|
返回顶楼 | |
发表时间:2008-10-28
有兴趣,建议LZ可以展开讲讲,一句话写一个故事,然后LZ就可以出书了,哇咔咔
|
|
返回顶楼 | |
发表时间:2008-10-28
zeelong2 写道 有兴趣,建议LZ可以展开讲讲,一句话写一个故事,然后LZ就可以出书了,哇咔咔
不是有兴趣,而是感同身受,呵 |
|
返回顶楼 | |
发表时间:2008-10-28
jeickey 写道 * 任何情况下不能吞异常,一般使用logger,哪怕只能用e.print... 也是有补救措施的,而吞掉便无从知晓。
* 配置多资源时,各种公用的内容没有提取,导致修改时非常麻烦,推荐使用include方式 * 子资源要能使用父资源的指标值,也就是父子要有继承关系 * 国际化时不应该再另起一个模型,这样会使同一修改改动很多文件 * 任何会导致特殊字符危险的方案不能用,比如 - 在解析命令时会解析参数 /o ,后来有一个目录叫"/opt/home" ,导致解析不成功,非常隐蔽而且危险 * 打日志时要尽量的全,哪怕是trace,调试时很方便。不需要的可以不配置,需要时不必再次修改代码。 * cc 的文件名长度有限制,非常不便 * 做配置时,某个对象的属性集中一处配置,哪怕是include,不可分散至引用处重复配置,比如现在原型的资源类型的 disporder * log4j 要做动态加载 * 打日志要规范,利用解析,使用多logger输出 * 队列要集中管理,分配 * 线程要集中管理,分配。无论是线程池还是独立线程的创建。 * 模块化工作的敌人是建一个模块的工程时很麻烦,所以要从架构设计时解决这个问题,因为这个而导致今后结构不清晰,很不值得 * 大数据量的删除操作很慢,约几个小时的时间。所以需要在批量插入的时候判断是否需要删除部分数据 * 用URL返回本地文件路径时,注意URLDecode.decode(path,"UTF-8"); 来转换特殊编码 * 真实环境的压力测试(尤其是异常测试)很重要,未经此测试不要出售,会带来很大的维护压力 * socket 连接重试一定要有间歇,不然会把服务器搞宕 * 用到线程时,线程要继承一处,并作统一创建和管理,以便于在内部设置路标。并且在线程内要及时写入路标。设置路标时,参数以map形式添加,读取时再格式化成字符串。 * 对于多线程程序,线程池分配时,分配策略要可配置以调节性能 * 2008-6-13 06:34下午 今天开发时,A改过的东西 我们B不知道,他在本地修改因为版本已经冻结,导致严重问题复现。今后采用为某个现场环境建立一个hotfix版,在这个版本上记录更改历史 * 给现场安装不知该分配多大内存时,要有一个自动修正功能,设置内存在一个范围内递增。捕获oom 异常,让监控线程关闭系统并修改内存配置重启。但是前提是要保证数据的完整性受损是可接受,或者有解决方案的。 * 当一个小组成员分头支持现场问题时,每个人解决问题后要全体知悉,便于积累经验和对外表达一致 * Joel曾经说过:不要先去完成界面,因为在很多用户看来,完成了界面,就等于功能也快完成了。而要让功能和界面的开发保持同步最好。 * 开发软件不能只顾自己开发时方便,还要考虑到运行维护时是否方便 * 模块依赖api时,此模块要把自己需要的api整理为一套adapter去适配,便于整理出对api方法的依赖,另外在api强行变动时,其他应用也有应急办法 * 留下足够的程序内部信息的监控入口,生产环境是不让动的,xstream * OOM, StackOverflow, JMX高负载后停止服务 * 系统中用到的环境变量名要集中使用常量管理 * io 远程调用传输过程中,尽量合并携带参数 ,减小传输量。不要使用zip。 * 线程要提供一个暂停的方法,以便调试 * 使用需要持久华的缓存,注意与持久化及时同步问题 * 作小于判断时,注意-0 是等于0 的,应该用<=来判断。 * windows 2003系统中当开着服务控制台启动DaemonServer后不关闭mmc控制台,向控制台输内容会导致阻塞。要自定义文件流,使他们保存至文件。 * 持续进数据的队列 要对处理慢的情况有考虑,否则会oom * 同步数据需要在一个事务内完成写入,否则会导致界面的坏体验 * 使用具体类来代替type类型区分,可以帮助在有性能问题时快速定位,只是有可能增加些代码量,值得。 大家还有什么补充嘛! |
|
返回顶楼 | |
发表时间:2008-11-18
好的经验,一定要收藏。
|
|
返回顶楼 | |