Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

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

Posted on 06/05/201206/23/2019 by 四火

internet 作为以老版本为模子重做的解耦版本,这个大型互联网应用产品是从 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 框架应当便于控制和管理,不应暴露过于复杂的界面行为给普通开发人员。

 

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

×Scan to share with WeChat

你可能也喜欢看:

  1. 网站性能优化的三重境界
  2. 前端解耦的一个最简单示例
  3. 实际技术选型的考虑因素
  4. DAO 的演进
  5. Web 页面的聚合技术

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Spark 互联网 亚马逊 前端 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 数据库 曼联 测试 生活 眼界 程序员 管理 系统设计 缓存 编程范型 美股 英语 西雅图 设计 问题 面向对象 面试

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (13)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (6)
  • Automation and Operation Excellence (13)
  • Machine Learning and Artificial Intelligence (6)
  • Product Design (7)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (25)
  • Career Growth (57)
  • Life Experience and Thoughts (45)

推荐文章

  • 聊一聊分布式系统中的时间
  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • rocky on 关于时间管理的一点新的感悟
  • panshenlian.com on 初涉 ML Workflow 系统:Kubeflow Pipelines、Flyte 和 Metaflow
  • panzhixiang on 关于近期求职的近况和思考
  • Anonymous on 闲聊投资:亲自体验和护城河
  • 四火 on 关于近期求职的近况和思考
  • YC on 关于近期求职的近况和思考
  • mafulong on 常见分布式基础设施系统设计图解(四):分布式工作流系统
  • 四火 on 常见分布式基础设施系统设计图解(八):分布式键值存储系统
  • Anonymous on 我裸辞了
  • https://umlcn.com on 资源链接
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme