dubbo和webservice区别_架构设计_成都钢结构设计(3)

2 如何控制代码质量。因为团队里大家的水平有高有低，所以团队研发的时候，需要去建立固定的开发规范，比如：“命名规范”，“代码包引用规范等”。当某个人解决某个功能的时候，为了确保代码质量和减少出错几率，最好能画出流程图和配上设计意图说明，来进行讨论确定，同时也可以帮助新人快速成长。

3 需要引入新框架。有时候，某个成员会觉的某某框架的新特性非常好用或者非常合适手头的问题，那么就想引入这个新框架，我的建议，在充分了解的基础上来决定，不能因为某个特性而引入一堆用不到的特性，那样会让项目代码显的冗余。

4 知识总结和培训。当某个成员遇到问题，并解决后或者学习到新东西的时候，不妨拿出来大家一起探讨一下，说不定就有助于提高平台的性能，为大家提供更好的设计思路。

三 架构优化

“过早优化是万恶之源”，所以关于架构优化，我放在研发完成并上线之后来讲。个人觉的没有百分百可用的架构，得看你实际的业务流程和运行情况来进行优化。当你运行了一段时间后，收集到一定的数据，找出性能的弱点后进行针对性调整和优化，当平台的负载强度达到一定程度，就得立即着手做架构升级。

有的朋友会问，有时候网站就是莫名其妙的变慢，但是不知道从何下手怎么办，或者凭经验改改这个改改那个选项，好了一点但好的不彻底。我的经验是从数据开始，从最开始画圈，找到源头。先从开始收集日志，比如access_log访问日志或sql_log操作日志，找出访问最多的10条日志和执行时间最长的10条日志，然后根据日志去反查到底是什么引起的操作，然后一条条的解决。如果解决不了，那么就考虑重构。其他问题解决方式跟这个差不多，就不赘述了。从我自己已有的经验来看，往往就是因为几个功能点的恶化，引起了整体的性能变差。

所以在研发的时候，功能点的实现要好好考虑，前端部分，页面，图片等的大小和有效缓存，后端的局部数据和全局数据的缓存高效利用，层SQL语句尽量避免跨表查询，索引的利用等。

四 其他相关

存储

当平台网站的访问量不断增长的同时，数据也会跟着不断的增长，所以早期做好数据如何存储的方案非常重要。架构设计

现在比较常见的是HASH URL，根据文件名的HASH来选择存储不同的目录，比如20091014131213_abc.xxx 那么就存储到 2009/10/14/a/20091014131213_abc.xxx这样的目录下，方便以后根据目录来划分服务器。

搜索

当平台网站的访问量不断增长的同时，数据搜索也变成了一个问题。肯定有朋友会说，直接模糊查询有什么问题，你试想当你的数据表里有几百万数据你用select * from table where title like '%key%' 没法用索引，那就是全表扫描，拿得花多少时间，一个人查询还没问题，那几百个呢，那你的平台不就歇菜了。还好现在已经有了成熟方案Lucene，只要按照它提供的接口去实现，你就可以使用。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-26397-3.html