大型互联网应用的技术选型和决策，10条成功与失败的记录

作为以老版本为模子重做的解耦版本，这个大型互联网应用产品是从2009年中开始落地的。而我本人也是该版本的主创人员之一，到今日，团队已经发展到开发测试人数百人的大型互联网产品团队的规模，发布、割接和上线了许许多多个商用版本。

 

对架构的审视，对选型和设计的反思，不仅仅要在产品初创时期，更要在产品发展的整个过程中进行，团队做同类型产品的能力就是这样在不断总结和自我批评中成熟的。以下为个人观点，难免不对许多人的胃口，不过还是希望这些文字有足够到让人思考的价值。无论如何，对于这样一款产品，从如今的视角来解读它的历史故事，更别有一番风味。

 

---------------------------------------------------------------------------------------

 

5条成功的记录：

 

1、Portlet技术作为整个架构的核心。

这一条既是成功的记录，也是失败的记录。

Portlet给各个局点的不同定制版本带来了相当的页面定制灵活性，不懂jsp的管理员都可以按照自己的要求部署页面，通过简单的选择和拖动，将一个个内容丰富的频道展现出来。

另一方面，Portlet对于栏目的扩展和定制保留了相当的灵活性，尤其是对于潜在的互联网应用按照栏目维度保持伸缩性方面，留足了空间。

 

2、持久层选择了更加轻量级的iBatis，没有选择Hibernate。

事实证明，iBatis透明、简单，易于配置和使用，多数开发人员可以读透持久层的代码，擅长数据库的开发人员可以轻易地完成Oracle下SQL语句的调优，应用到iBatis的配置文件中去，并不需要太多ORM的技术积累，也不需要深厚的Hibernate调优技巧。

 

3、业务核心逻辑层得以抽象出来，独立成可以单独发布的API模块。

面对多种接入渠道，把核心业务通过API的行为抽取出来，给项目组带来的最大好处是：清晰的团队分工。

虽然API模块还不成熟，但是API的诞生和发展意味着可以让各个接入门户的开发和定制团队更聚焦在以展现为核心的工作上面，把业务代码的梳理交给专门的API团队去做。

从长远看，纯Java的API是干净、简洁和易于UT的，通过这种天然的方式隔离了持久层，也保护了核心业务的代码质量。

 

4、将功能的界面展示部分抽取成可重用的业务标签。

有人会对这个有异议，事实上，除了FreeMarker的性能确实让人不敢恭维以外，将界面的展示部分以标签的方式组件化带来的益处是很大的。

理想状况下，定制团队可以通过简单的标签插入、删减和修改，完成页面的定制工作，这比理解宏伟复杂的jsp页面，进行拷贝粘贴大法简单了不少。

 

5、基础设施稳定且有质量保障。

基础设施包括日志、协议栈、License等等，大多稳定而且易于使用。

比如异常体系，整个异常体系给开发带来了自然和轻松的异常处理流程，开发人员只需要更关注核心流程，把错误流程交给运行时异常去处理；不同的异常捕获层次给最终页面的错误展示和归纳带来便捷。

也有遗憾的地方，比如错误码比较纠结，错误码是团队内部讨论经过激烈的斗争和妥协的结果，有些过于庞大和繁杂了，这似乎更验证了：软件工程不是明主选举。

 

---------------------------------------------------------------------------------------

 

5条失败的记录：

 

1、Portlet技术作为整个架构的核心。

这一条既是成功的记录，也是失败的记录。

Portlet的许多特性还远未得到适合的发挥，譬如Portlet状态的保持、远程聚合的能力等等，却给开发人员带来了许多困扰，譬如页面分解困难，Portlet Session和Portal Session的互异性，聚合流程性能问题等等，给开发人员定制手提出了更高的要求。

 

2、独立出基于Portlet核心的负责门户运营的Portal平台。

Portlet规范作为一种聚合展现行为的抽象，通过组件化这样一种独立平台的形式，将页面控制聚合流程从业务页面展现和业务流程处理中剥离出来，开发人员得以将更多的精力聚焦在业务开发上面。

我想这是它诞生的本意，但是实际上，却带来了聚合流程复杂，方法调用栈过深等问题，而门户定制的开发人员，也必须经过相当的培训才得以上手。

 

3、通过ajax方式聚合Portal位于不同war包内的管理台页面。

本意是想让不同的管理台页面随着不同的Portal接入渠道分离发布，在展现时在页面上进行简单集成。

但由于浏览器的安全机制和对于不同域的会话独立管理的机制，使得它像恶魔一般被引进来，带来的不仅仅是定制的困难，开发人员理解的困难，还有一些因会话无法统一而导致的在不同域页面间信息传递时难以解决的问题。

 

4、保留XDIME、WML和XHTML三套WAP的模板页面。

当然也许这有一些人为无法控制的因素在里面。

XDIME页面的目的就是经过终端适配组件转换成适合手机的WML和XHTML页面的，而由于局点或某些历史原因，WML和XHTML还无法被干脆地摒弃掉，无论是一种主动的决策还是迫于无奈，带来的问题就是页面模板数量增加了两倍，给开发和测试带来了大量的工作量。

最终，WML和XHTML模板还是被抛弃了，只保留了XDIME一套模板。

 

5、缺少一套简易的和可管理的UI框架。

前端开发是整个产品的瓶颈，尽管页面并不非常复杂，前端的混乱却已经带来了诸多问题，这些问题主要暴露在产品定制和最终的用户细节体验环节上。互联网产品是否专业，很大程度上是由产品的前端团队所决定的。

依据不同的团队级别、不同的前端展示要求，需要定制不同的UI框架。由展现的简易性，而且需要定制的基线版本，决定了我们的UI框架应该简单；并且由于开发成员普遍前端能力欠佳，决定的我们的UI框架应当便于控制和管理，不应暴露过于复杂的界面行为给普通开发人员。

 

文章系本人原创，转载请注明作者和出处

 

评论

4 楼 RayChase 2012-11-20  

lazy_ 写道

而对比freemarker的方式，速度是有一定优势的。

确实不同的模板引擎性能有差异。但是我想补充的是，这些差异也不会很大的，通常系统性能优化着力点不应该在这里。Think big。

3 楼 RayChase 2012-11-20  

1 都是用ibatis而不是用mybatis吗？
-- 本质上应该是一个东西，我记得是iBatis后来发展成myBatis了，当时我们用的iBatis。

2 我公司现在使用mybatis的做批量插入，是纯JDBC的时间的3到10倍。。。对mybatis有些不好的印象。
-- 有几种方式，
1. 批量相当于N个单次提交，这是最慢的。
2. 用它那个callback函数来做批量，插入语句N条，提交一次。次慢。
3. 还有就是一条语句同时插入N条记录。如果数据来源来自其他表，这种方式所有数据库都支持；如果数据是你通过iBatis传入的，只有部分数据库支持。更快。
4. 存储过程。最快。

最让人苦恼的是，mybatis的代码写法跟ibatis也不一样，上网找资料的时候，多数找到的是ibatis的，那个叫纠结啊！这是典型的不向旧版本兼容啊，你怎么看这个不兼容的问题的？我真的想不明白为什么会这样。。。
-- 不了解

2 楼 lazy_ 2012-11-20  

引用

2、持久层选择了更加轻量级的iBatis，没有选择Hibernate。
事实证明，iBatis透明、简单，易于配置和使用，多数开发人员可以读透持久层的代码，擅长数据库的开发人员可以轻易地完成Oracle下SQL语句的调优，应用到iBatis的配置文件中去，并不需要太多ORM的技术积累，也不需要深厚的Hibernate调优技巧。

确实，貌似淘宝都是喜欢用ibatis，招聘要求也是写ibatis。

我有几个疑问，不知道您可不可以回复一下。。。
1 都是用ibatis而不是用mybatis吗？

2 我公司现在使用mybatis的做批量插入，是纯JDBC的时间的3到10倍。。。对mybatis有些不好的印象。

最让人苦恼的是，mybatis的代码写法跟ibatis也不一样，上网找资料的时候，多数找到的是ibatis的，那个叫纠结啊！这是典型的不向旧版本兼容啊，你怎么看这个不兼容的问题的？我真的想不明白为什么会这样。。。

1 楼 lazy_ 2012-11-20  

引用

将功能的界面展示部分抽取成可重用的业务标签。
有人会对这个有异议，事实上，除了FreeMarker的性能确实让人不敢恭维以外，将界面的展示部分以标签的方式组件化带来的益处是很大的。

问题：FreeMarker性能成问题，是不是意味着有别的更好的做标签的方案？你都是用JAVA来写标签的吗？难道就是那种原始的那种继承BodyTagSupport的？

-----------------------
PS：
我们公司现在做的标签，多数是结合struts2的ComponentTagSupport,AbstractUITag，UIBean和freemarker来做的，性能确实有些低。。。

后面做一些简单系统的时候，我用了最简单的一种方式来生成具体的UI 的HTML——jsp:include.

例如创建一个jsp，需要引入一个列表UI，那么写代码
<jsp:include page="component/list.jsp">
    <jsp:param value="" name="whereCls"></jsp:param>
    <jsp:param value="" name="maxRows"></jsp:param>
</jsp:include>
就OK了。

jsp:include对比原始的BodyTagSupport在JAVA中write一大堆HTML代码的方式，这种方式爽多了(也许我不知道bodyTag有更好的生成HTML的方式？)，而且简单易学。唯一的缺点就是，引用控件的代码长了点。

而对比freemarker的方式，速度是有一定优势的。