纯技术贴:讨论一个现实中的需求的架构

大家好,这个帖子我打算根据项目的进展不断添加项目过程中碰到的问题,而在这里,就先抛开商业的一些需求,纯从技术上讨论架构及实现,以及可能的风险。下面是对项目的描述。

首先,这是一个管理软件,用于软件公司的。就是说,是为某软件公司开发的软件。 第二点:这是一个需要插件体系的B/S软件,需要通过一些简单配置去实现新功能(包括工作流,但不仅是工作流) 第三点:为了追求易用性,因此需要在B/S中实现单机程序的风格页面,因此可能会包含大量组件,大量复杂页面展示逻辑。 第四点:需要分布式部署 第五点:在特殊需求下,需要在网页内调用一个富客户端完成工作,而客户可以接受的唯一安装的东西是JVM,因此这个软件不需要其他的客户端 第六点:客户的办公室分布在多个城市,需要高速响应用户的需求,抛开网络问题,需要在客户每个城市放上一台或多台服务器。 第七点:在线人数会非常大,因此需要可以横向扩服务器。同时需要较快的访问速度。 第八点:系统大部分地方对数据的查询与写入是二比一的比例,或者说:有很频繁的更新操作 第九点:系统对事务要求较高,因为有财务,还有成本估算等模块,因此不允许垃圾数据的存在,并且事务要求是全局的。

这是简单的几条,下面分别描述几个典型的模块: 1.消息系统。 需要一个完善的消息系统,支持从Email到RSS,站内消息的模块,同时也需要支持手机短信,以及未来可能需要的一些通知方式。

2.工作流系统 需要自定义的工作流,并且工作流需要实现的流程是跨地区的,比如有的流程在一个城市,另一个流程在另一个城市,流程之间可以轮转。

3.在线的绘图、会议 这种地方需要实现在页面内绘图,如果需要,允许使用客户端(但不需要安装,现在考虑的是JavaWebStart)

4.IM,(要求也是在线的) 可以集成MSN和YAHOO,同时自己还需要维护内部的账户(就是自己开发IM,用户如果需要,可以同时聊MSN,就像Gaim那样)

5.WebService支持 需要公开一部分WebService供客户的客户去调用,这里有大量只读的,部分需要进行数据信息交流的

6.SSO 把过去的一些系统也集成起来,一起登录(现在还不清楚是谁集成谁)

7.分布式部署(这是我们经验最不足的地方) 为了访问速度可以快一些,虽然有核心的服务器,但希望客户的不同办公区域都各放上一台服务器对某个地区提供服务。而客户的不同办公区域在不同的城市。而各地方的业务逻辑基本上是相同的,因此,这个部分的架构可以多讨论一下。

在这方面,还有一些细节需求:中心服务器是PostgreSQL或者Oracle,而为了速度,也许可以在客户端的服务器上跑一个简单的MySQL对某些数据进行缓存。

8.关于业务复杂度 在这里我没法把复杂度描述出来,不过的确是相当复杂,涉及财务、时间管理、项目管理、成本、风险等各种东西,因此业务相当复杂。

上面是一些典型的模型,大家对于这种项目,有什么好的技术建议?随着项目的进行,我也把一些问题摆上来,与大家的方案进行对比。这个项目现在还在考察阶段,估计过了年才能够开始。

项目会跑在Solaris上,不排斥Java EE 5的技术,可以使用新的应用中间件。

欢迎大家讨论。

没有人回复? 我说一下我担心的东西之一:把Web层放在用户身边,但业务逻辑还在远端。在网络条件受限的情况下,有什么好的方案?

另外,在表现层的框架选择上,因为需要太多组件,哪一种Web框架更适合?

刚才敲了半天的字,点错了结果都没了。捡重点重来一些吧。

1.感觉你的系统比较复杂,但是你描述出来的内容过于粗浅了无法作为系统分析的基础。 2.上面的模块划分合理性有待探讨,比如:“工作流系统”,工作流不可能作为一个模块,他只能是一个应用方案,在这一点上需要从更高的层次进行思考。

》》我说一下我担心的东西之一:把Web层放在用户身边,但业务逻辑还在远端。在网络条件受限的情况下,有什么好的方案? 你在担心什么呢? 》》另外,在表现层的框架选择上,因为需要太多组件,哪一种Web框架更适合? 其实各个组件都差不多,没有绝对的胜出者。还有web应用需要考虑他的特殊性不能一味的追求与AP的相似。

看了你的描述感觉你们对于这个系统的了解还是比较有限的,还没有能够提炼出足够的信息进行系统的详细思考。

>>1.感觉你的系统比较复杂,但是你描述出来的内容过于粗浅了无法作为系统分析的基础。 的确相对复杂,并且我也没有拿到所有的描述性的东西,现在也许算不上系统分析,只是一个针对这种类似的应用的讨论。

2.上面的模块划分合理性有待探讨,比如:“工作流系统”,工作流不可能作为一个模块,他只能是一个应用方案,在这一点上需要从更高的层次进行思考。 >>上面不算是模块的划分,因为一方面我不能把真正的模块拿出来,另一方面现在系统的需求阶段还没有真正开始,只是大体了解,因此我只是在这里把一些相关的东西简单描述一下。

》》我说一下我担心的东西之一:把Web层放在用户身边,但业务逻辑还在远端。在网络条件受限的情况下,有什么好的方案? 你在担心什么呢? --》我担心的是响应的速度,还有在网络条件相对较差的情况下,Web层与服务层的通信问题。常用的解决方案对于容错性如何处理?

》》另外,在表现层的框架选择上,因为需要太多组件,哪一种Web框架更适合? 其实各个组件都差不多,没有绝对的胜出者。还有web应用需要考虑他的特殊性不能一味的追求与AP的相似。 --》的确不能追求与AP相似,但现在的问题在于,我们没有权力修正需求,因此要尽量满足客户提出的与AP的相似性。另外,针对Web框架,我们用的是自己针对struts和jquery的二次封装,估计最终也不会选择其他的(当然选择权不在我),这里是想讨论一下这种情况下,是传统MVC更适合还是事件驱动更适合。 --》我个人的感觉是Wicket这种事件驱动的更适合,毕竟做组件方便,更何况,对于这种系统,重复性的工作(表现层)会很多,用这种适合做组件的更方便一点。

看了你的描述感觉你们对于这个系统的了解还是比较有限的,还没有能够提炼出足够的信息进行系统的详细思考。 --》现在只是就事论事,还不到系统分析的时候,估计做出需求还要一段时间,到时我会把更详细的信息发上来一些,现在只是就事论事,大家加点自己的想像讨论一下。

还是很好奇大家对于ejb和富血模型的看法,呵。

页面太复杂应该选择事件驱动,js模拟个桌面虽然比不了真的但是也很强大了。 工作流我也没啥研究,就有一回人家要求做审批驳回复审乱七八糟一堆啥的弄过一次,后来去看的时候根本就没按流程走,口头协商好,然后一个人完成全部流程,反正也没责任啥的。 另外JMS和memcached都是可以考虑的。 有第九点做约束,还要在client做缓存,同步是不是有点困难,或者就那一块不要缓存。除了hibernate送的缓存,我们一直都在拿着AOP手工cache。

第9点中的缓存,只是一个规划,因为考虑的问题在于:如果全部通过网络对业务逻辑进行调用,会不会在一些对数据量要求大的地方,会导致网络性能跟不上。

>>freebox,除了Hibernate送的缓存,我们一直都在拿着AOP手工cache Hibernate的cache和手工AOP缓存一起用会不会出现问题?因为hibernate默认返回代理,也就是说二级缓存和手工缓存中缓存的是一个代理对象,表现层读取的时候首先从手工缓存里面读取,这样程序就不会到达hibernate,那么这个时候展开代理对象的时候会发生懒加载异常吧?其实这就是Jdon+Hibernate的处理方式,虽然我还没遇到这个异常但还是一直担心。

BTW:我手上的一个项目和楼主的贼相似,将全部采用jdon+hibernate开发,不知道后期会不会发生什么怪事 [该贴被oojdon于2008-12-04 17:46修改过]

>>oojdon

你的项目有没有打算使用EJB?如果你用JDon+Hibernate,那么在分布的环境下如何去远程调用?我们在规划的时候考虑过EJB3和不使用EJB等方案,你有啥好的解决方案?

banq的理念:保证小系统在做大之后可以向大系统分布式计算升级,所以jdon框架支持这个特性,程序可以在后期向EJB过渡,所以我们公司准备实践它。 但我不知道风险有多大?框架真的能平滑升级吗?足够的稳定吗? [该贴被oojdon于2008-12-04 20:12修改过]

我倒不担心JDon的稳定性,我担心的还是EJB,呵,我们没有足够的经验。

担心的部分在于:远程调用时网络条件不好的情况下,有没有好的处理办法。

不会有惰性载入异常,不是因为它不会出现,是因为我根本不用惰性载入,集合用查询仓储管理。我总是认为惰性载入虽然得到一个代理,但还不是完整的领域实体,因为它离了技术上的session就用不了了。领域实体就应该在传到service上之前全部载入或掷出领域异常。 分布直接EJB多好。 网络差的话,如果放在本地,这块业务数据能不能完全自我封闭式管理,如果不能数据还是要同步到其它节点,这要不要开销,因为您说明了不允许过期对象存在,我觉得应该把缓存集中起来。

TO:oojdon 》》框架真的能平滑升级吗? 除非在框架前期设计的时候就提供了支持,否则是不可能的。升级系统的框架是一件绝对痛苦的事情

TO:saharabear 现在看起来你更多的是担心网络的连通性和带宽,而不是网络屏蔽、安全等问题,这样就比较容易解决了。

在任何时候网络连接都是不可靠的,这一点直接被写入了各种网络协议的规范之中,所以这样的情况在局域网和广域网中其实没有本质的不同。带宽倒是有着显著地不同。

在你的系统中各个服务节点间都必须是松耦合的,每个节点都不能完全依赖于对方,需要是一个基本独立的实体。

我对EJB得了解很少,但是凭感觉EJB属于一种紧密的系统连接结构,在整体框架上很可能不适合于你们的系统。倒是可以借鉴一些MessageQueue的思想。

性能和缓冲常常是存在矛盾的,对性能的追求常常导致数据不能及时到达核心存储,反过来也是一样的。更多的是一种权衡的问题,核心问题是:需要什么样的性能,同时可以接受什么程度的数据损失。通常我们能够提供99%的成功服务就可以了,在剩余1%的情况下只要保证核心数据没有被破坏就是可以接受的了,MSN/QQ这样的系统也会发生丢失消息的情况。

to IceQi:

谢谢你的回复,MessageQueue的东西没怎么了解过,需要仔细研究一下,感觉就是jms?

网络屏蔽的问题在我们的项目中是不存在的,因为我们的项目将是中心软件,其他的硬件与网络部署将为这个项目服务,因此不需要担心网络屏蔽。

安全问题,这方面我们已经有了解决方案,也不需要多考虑,因为需求上对这一块并不是“硬性要求”。

》》在你的系统中各个服务节点间都必须是松耦合的,每个节点都不能完全依赖于对方,需要是一个基本独立的实体。

如果按这种方式去做,那么又如何把业务逻辑进行集中?毕竟不需要在每个客户的办公端的服务器上再部署业务逻辑的东西。

而这个项目对于稳定性的要求比较高,所以在考虑网络不稳定的条件下如何处理。

针对业务逻辑,首先需要考虑核心业务是什么,说起来容易但是在绝大多数情况下这个关键元素都被忽略掉了。

业务过程是分层的,每一层都有他自己的核心过程,实际上从你们准备部署主从服务器的方式上看已经有了这样的考虑,但是可能还没有确切的意识到这一点。

业务处理必须是集中的,这一点在所有的业务系统中都是一样的。对于集中需要确认一点“集中的到底是什么”,在每一个业务层次都需要对子业务进行集中同时再被上一级的业务层集中处理,说的实际一点可以想想Internet的域名服务器总是一级一级的向上查找的。

连接的有效性是可以通过技术在一定程度上保证的,但是业务过程的连续和稳定性是不可能通过技术实现的,这个层次的保障必须经由对于系统整体业务过程的理解、系统架构的设计这样从最高的层次进行,单单依靠EJB/Corba/甚至是JMS等等的技术架构是不可能真正解决问题的。在设计的过程中总需要考虑:什么是危险的、有多危险、需要怎样的安全、怎么算安全什么是可以放弃的、什么是必须保证的、那些可以回滚、哪些不可以回滚,等等。只有从业务过程的角度理解了这些限定才能进行系统结构上的考虑。

如果直接说连接不稳定的问题可以参考一下互联网络的域名服务,这是一个比较简单而且又最实际的例子了。

所以我一直说你提供的信息不足以进行系统级别的思考。