|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-01-04
george_space 写道 melin 写道 讨论这些问题，基本没有ali系的人，失去意义。要先把业务做起来，架构是迭代出来的，不是一天拍脑袋定下来的、taobao最初是从cgi，php做的
paulwong 写道 
最后所有的临时架构，或者说拍脑袋定下来的架构，都会对未来的重新设计造成深深地烙印，或者造成不必要的麻烦。 |
| 返回顶楼 | |
|
发表时间：2012-01-04
很多性能问题没有提到， 一片很泛泛的文章。
|
| 返回顶楼 | |
|
发表时间：2012-01-04
realviv 写道 很多性能问题没有提到， 一片很泛泛的文章。
说起性能问题，那又是一个很大很大的话题。从SQL优化，系统架构和到各个服务器的配置都大有学问，这里是讨论不完的，现在主要关注架构代码结构方面，刚才很多人发表了对各种技术和框架的意见，也是出于对系统的性能和扩展性维护性等的考虑，比如说我用freemarker/velocity实现的功能，jsp也可以实现，但为什么还要freemarker/velocity？另外一个是想展现一个良好的代码风格，如果你有什么好的关于性能优化的建议可以提出来让大家学习. |
| 返回顶楼 | |
|
发表时间：2012-01-04
melin 写道 讨论这些问题，基本没有ali系的人，失去意义。要先把业务做起来，架构是迭代出来的，不是一天拍脑袋定下来的、taobao最初是从cgi，php做的
楼主要是拍脑袋的人就不会在这里发帖了。 话说回来，据说ali可以抛弃项目的所有代码，彻底重写，估计一般的公司不会有这样的机会和实力 |
| 返回顶楼 | |
|
发表时间：2012-01-04
melin 写道 讨论这些问题，基本没有ali系的人，失去意义。要先把业务做起来，架构是迭代出来的，不是一天拍脑袋定下来的、taobao最初是从cgi，php做的
由本书是将关于重构的，我发现良好的代码都是不断的重构而来啊。ali系的人是有机会不断的提炼他们的架构，但我们自己也可以不断的学习。 |
| 返回顶楼 | |
|
发表时间：2012-01-04
刚发现一个淘宝的web开源框架，https://github.com/webx/citrus
可以参考下 |
| 返回顶楼 | |
|
发表时间：2012-01-04
flyoversky 写道 刚发现一个淘宝的web开源框架，https://github.com/webx/citrus
可以参考下 这是个好东西 |
| 返回顶楼 | |
|
发表时间：2012-01-04
sanshizi 写道 george_space 写道 tongyi2005 写道 onecan 写道 ..., 能否列举一下freemarker velocity能做到的jsp又做不到的应用在商城中的效果？
我想用freemarker， velocity的理由并不是 jsp 不能做到才去用的。实话跟你说，jsp能做到的freemark,velocity都能做到，反之也是一样。 目前的技术都很成熟了，没有做不到只有想不到。 理论上FreeMarker和velocity能做的，jsp都能做到，但是jsp能做的，FreeMarker和Velocity就不一定能做了，比如你可以直接在jsp中定义内部类，可以在jsp中调用web service等等，可以说普通java类可以做得事情，jsp都可以做，但是FreeMarker和Velocity就不行了。 FreeMarker和Velocity的优势不是和jsp比谁的功能更强大，而是为了实现表示层中尽量不出现业务逻辑。 我的项目中很多地方用到FreeMarker，比如分页标签的渲染、各种自定义标签的渲染、内容模型自定义字段的渲染、发送email的模板、发送短信的模板等等，但是我的MVC视图层是直接用的jsp，因为，避免视图层出现过多业务逻辑，这一条可以通过人员的培训和约束来实现，但是有时候特殊情况下你不得不用一些jsp的特性，比如：我们经常需要仓促得为客户修改正在运行中的项目，系统不允许停，更不允许重启web server，这样的情况下，我就不得不把一些简单的功能直接在jsp中修改，这样的情景很多。 是的, 有时候我觉得逻辑也得分种类, 纯粹为了控制显示效果的,而且重用性很低的逻辑就直接搞到jsp里面算了, 省得都搞到类里面, 修改起来实在不方便, 不然有可能就会因为很小的一个东西重启服务, 感觉真是不直当的 模板语言中是可以定义一些显示上的逻辑，简单的逻辑。也可以调用service等java类。 如果非要把业务上的逻辑放到模板语言中是不可取的。 大家有兴趣可以去研究一下 alibaba 的 webx3 |
| 返回顶楼 | |
|
发表时间：2012-01-04
osacar 写道 onecan 写道 osacar 写道 到底大型体现在哪?说点核心的东西吧。别光堆框架。
大型系统却不是很好去定义，是由功能去定义还是访问量去定义呢？就说一下我们这边的情况 第一，我们的目标很远大，是要做"java 商城"里面的数一数二的能和目前php商城抗衡的经典之作，因此我们对代码规范和质量上要下狠功夫。 第二，我希望我们的系统能部分使用J2EE的最优实践，能给大家带来技术上的帮助和启发，这个影响也是挺大的。 第三，我们确实是实现了一个java商城的功能，已经包括B2C商城的基本功能，包括支付宝的直接/担保支付，货到付款功能都已经上去，是Java商城中功能比较全的一个。 第四，我们同时支持B2C/C2C，甚至观望B2B2C的功能，我不是做一个技术框架DEMO，而是一个可以实战使用的，并且已经使用中的商城。可以弥补java商城的空白部分，我们的任务就是要使用适合的开发模式降低Java商城的开发成本而已。 虽然目前还不是很完善，但是google/baidu “java 商城”前面3页还是有我们的连接的。 所以说，把标题中的“大型”去掉可能会更贴切些。 你所列的这些框架平常我做个普通网站也是用这些。 我相信，如果一个能叫得上大型的系统，肯定有它一些独特技术架构和业务处理。而大家想知道的也正是这些。 +1,想知道的是，“大”在哪里，使用什么技术解决什么问题，比如，搜索用的一些排序，分类，聚类算法。大型项目，IO是瓶颈，怎么处理这个瓶颈，靠那些框架？，使用信道复用技术了，NIO？多线程，线程池? 使用了什么分布式技术，比如，lucene+RMI，solr的多shards，多core，缓存分布式？ DB分布式？ 你该讲讲大在哪里，独特的技术，堆堆框架有什么讲头，你开发出来了，只能说你堆的好，哪怕你说你使用zero copy解决大型文件传输，我都感觉有用。唉，没什么恶意的意思，只是感觉，学而求精，说反对重复造轮子的是因为他们菜，大轮子可以造不了，小轮子呢。你们说说，看看java开发的那个不是争论框架的，难道javaEE开发，就这些框架么。再大型，不是只你的框架堆的多，除了繁琐的业务，更重要的是高访问量，吞吐量，并发效率等等。 例如搜索吧，单一访问一次分类统计5KW多数据统计达1.7s，这就是不可取的，至少达0.3s以下。总不能让用户等着你在那搜索响应吧，也不可能不让用户不用搜索而一个个找吧。 |
| 返回顶楼 | |
|
发表时间：2012-01-04
最后修改：2012-01-04
george_space 写道 evanzzy 写道 myreligion 写道 如果系统较小，用什么都无所谓。
如果系统较大，hibernate，尤其是hibernate的缓存，非常不合适～～ 我们有个系统经常内存溢出，hibernate的Entity不知道什么时候累积了，也不知道它到底都在干什么，很麻烦。 如果用IBatis，其实也就是出的早点。IBatis并不严谨，看源代码你就知道。 对于商城，如果做起来了，数据层估计以后就是在开发guzz的单个项目定制版。希望您了解下，或许思路上有所帮助。 hibernate偷偷干的事情太多，跟钱有关的系统还是少用比较好，IBatis都比它强。个人见解。 严重同意啊。 一想起来Hibernate要缓存我的钱，还要按照它的规矩设计数据库，我就恨的呀 同意对iBatis的看法，涉及到分表分库，也要做大量改造扩展，还不如直接用Spring JdbcTemplate控制力强 Spring JDBC Template遇到分表、分库就好使了？好使在哪里？ 很多人提倡Spring JDBC Template，对其崇拜程度就像崇拜Spring一样，Spring是不错，但是不代表Spring出品的所有东西都OK，Spring JDBC Template在我看来就是一个JDBC Template，如同它的名字，如果你可以忍受程序中夹杂一堆SQL语句，那么你认为它是好东西这无可厚非。 因为Spring JDBC Template简单易于包装改造，所以在做分表分库这类需要自行改造框架的任务时比较合适。iBatis也可以，但是因为包装的多一些，所以要麻烦一些，淘宝网的经验可以借鉴。Hibernate包装的过多，不适合自行改造，改造成本也比较高。Spring JDBC Template就是个JDBC Template，其实没什么具体功能的。程序中夹杂一堆SQL语句，那就属于使用不当了。用Hibernate我一样见过夹杂一堆SQL语句的，这是使用问题，和Hibernate本身没关系 |
| 返回顶楼 | |
