Java vs C# —— J2EE与.NET平台关于电子企业的两种设想(6)

可伸缩性

可伸缩性是指添加更多工作量的能力。一般来说，附加的工作量是客户的增加引起的。可伸缩性是一个复杂的问题，笔者已经在几篇已经可以得到的文章中对此进行了深入探讨[1]。未来简化这个讨论，笔者将在MoneyBroker可能会在接下来的3年中遇到的问题的上下文中讨论可伸缩性。笔者将进一步简化这个讨论，而只考虑运行商务层和数据库层的成本，尽管对表示层进行类似的分析可能会得出类似的结果。

让我们假定，MoneyBroker的商务模型要求它今年每天处理10笔支付，明年为100万，而后年则为1000万。选择J2EE/Unix解决方案或.NET平台/Windows解决方案的相关成本有哪些呢？

为了判断MoneryBroker在接下来的3年中所需的机器规模，我们需要一个事务处理性能的标准的基准。事务处理吞吐量的工业标准基准是由所谓的Transaction Performance Council (TPC)协会规定的，该基准被称为TPC-C基准。TPC会员包括Sun、IBM、Oracle、BEA、微软和其他大部分销售中间层/数据库层产品的公司。

TPC-C基准评定了一个系统可以获得的最高工作量的等级。TPC-C基准定义的测量单位为tpmC，代表每分钟交易处理数（transactions per minute）。除了说该基准考虑的是在分布式订单输入系统环境中的交易处理外笔者将不对其进行讨论。该基准的说明可以在TPC网站[2]得到。

在MoneyBroker使用TPC-C数使其平台成为用户选择方面，正在面临两个问题。

第一个问题是TPC-C规定的交易处理与MoneyBroker交易处理完全不同。这需要MoneyBroker彻底审核TPC-C规范，猜测在工作量中多少 TPC-C交易才能与一个MoneyBroker交易相当。我们假定MoneyBroker计算得出它的一个交易与10个TPC-C交易相当，从而有大量的富余用于处理错误。

第二个问题是，没有一个J2EE开发商已公开发布自己的TPC-C数。这使得MoneyBroker很难计算J2EE实施的吞吐量，即AIX。有趣的是，虽然所有重要的J2EE开发商已经提交了TPC-C基准，但没有一个开发商已经提交了基于他们的J2EE技术的TPC-C数。

例如，对于IBM公司的WebSphere技术（包含在J2EE技术中的IBM公司的一个品牌）有6个基准。但是，如果有人研究WebSphere的结果，就会发现没有一个基准的代码是使用Java编写的，并且没有一个基准使用了任何的WebSphere J2EE性能。实际上，这些基准使用了IBM公司传统的Encina事务处理监控技术，该产品是同时包含在总的WebSphere品牌下。类似地，BEA公司使用了其传统的Tuxedo技术来运行他们的基准，Tuxedo技术是其WebLogic品牌的一部分，但是却没有包含在J2EE中。

由于我们没有J2EE性能数字，我们得必须估计J2EE实现的相关性能。由于J2EE 基于传统的事务处理监控程序（开发商已经确定了基准），但是仍然会增加Java程序设计语言。Java虚拟机和EJB（中间层）的开销，比较合理的推测是J2EE将可以完成与之相当的非J2EE系统（如Tuxedo性能）50%的性能。因此，笔者将使用一个50%调节系数来估计J2EE的吞吐能力。

下面我们使用TPC-C 信息对MoneyBroker行为进行分析。MoneyBroker正在试图确定购买何种系统。显然，MoneyBroker希望花费尽可能少的资金，但仍确信可以获得在客户使用量达到峰值时所需的吞吐量，还确信它的系统可以进行伸缩以满足接下来的三年内的需求。

今年MoneyBroker每天需要处理10万笔交易。这相当于每分钟处理70笔交易，峰值时大约为每分钟处理700笔。由于一个MoneyBroker交易处理等于10 tpmC交易，这等于工作量达到峰值时大约为7000。明年，这个数目增加10倍达到70000 tpmC，而后年，这个数目再增加10倍，达到700000 tpmC。

那么，在接下来的三年中，这些系统需要哪些支出(包括硬件和软件在内)？让我们从J2EE/Unix的可能支出开始，因此笔者将考虑在IBM公司的AIX操作系统、WebSphere和Oracle 8i系统中，哪一个最能代表J2EE/Unix系统。对于这种配置，有6个基准。按tpmC从最低到最高的次序排列，以及J2EE调整（前面已经讨论），结果如下：

 

公司

系统

tpmC

总系统成本

Bull               

Escala T610 c/s                                  

16,785

$1,980,179

IBM                

RS/6000 Enterprise Server F80                    

16,785

$2,026,681

Bull               

Escala EPC810 c/s                                

33,375

$3,037,499

IBM                

RS/6000 Enterprise Server M80                    

33,375

$3,097,055

Bull               

Escala EPC2450                                   

110,403

$9,563,263

IBM                 

IBM eServer pSeries 680 Model 7017-S85           

110,403

$9,560,594

如果我们考虑某些有代表性的.NET平台系统（这些系统太多，不可能全部考虑，但数字非常一致），结果如下：

 

公司

系统

tpmC

总系统成本

Dell               

PowerEdge 4400                                   

16,263

$273,487

Compaq             

ProLiant ML-570-6/700-3P                         

20,207

$201,717

Dell                

PowerEdge 6400                                   

30,231

$334,626

IBM                

Netfinity 7600 c/s                               

32,377

$443,463

Compaq             

ProLiant 8500-X550-64P                           

161,720

$3,534,272

Compaq             

ProLiant 8500-X700-64P                           

179,658

$3,546,582

Compaq             

ProLiant 8500-X550-96P                           

229,914

$5,305,571

Compaq             

ProLiant 8500-X700-96P                            

262,244

$5,305,571

Compaq             

ProLiant 8500-700-192P                           

505,303

$10,003,826

你可以理解MoneyBroker 面临的选择。今年它只需一个7000 tpmC系统。在Unix市场这将大约花费200万美元，而在.NET平台市场则需要花费27.3万美元。明年MoneyBroker将需要一个70000 tpmC系统，在J2EE/Unix市场需要花费950万美元，而在.NET平台市场则需要花费350万美元。后年，MoneyBroker则需要一个700000 tpmC系统。这些系统中，没有一个被评定为700,000 tpmC，但到面前为止最靠近的系统是1000万美元的.NET平台系统。如果一个与之相当的J2EE/Unix机器存在的话，估计需要花费4750万美元。

很明显，如果系统的成本是一个重要的考虑事项，与J2EE相比，.NET平台有很大的优势。可以预计要获得相同的功能，需要花的费用是在.NET平台上所花的费用的5到10倍。如果一个工作单位在.NET平台上花10美分，同一个工作单位则可能需要在J2EE/Unix上花50美分到1美元。

笔者需要再次指出，虽然这些.NET平台基准是实际机器的实际基准，但在这些J2EE基准中，没有一个真正存在。这些基准是外推基准结果，实际的系统不一定能真正获得这些结果。在J2EE开发商发布他们的基准数之前，我们必须记住，没有一个J2EE平台已经被证明可以任何代价的情况下处理这些高工作量。

架构支持

当创建一个大型的电子商务解决方案时，不用说没有人希望从头开始。而是希望在已经完整定义的、结果测试的电子商务架构基础上创建解决方案。使用这样的架构可以极大地降低开发成本，可能至少降低10倍。

.NET平台包括一个所谓的Commerce Server电子商务架构。在这一点上，在J2EE空间内没有与之相当的开发商中立的架构。利用J2EE，你应当假定你需要从头创建你的新的电子商务解决方案。Paul Harmon看来同意这种评价，说：

此外，无论选择哪一个[J2EE]开发商，如果你期望一个允许你很快实施的完善的电子商务应用程序，你将会有令人沮丧不已的体验。[3]

如果使用MS Commerce Server作为你的电子商务基础，那么很可能会对开发系统的成本有很大的影响。Commerce Server尤其适合零售业务。这样的电子商务系统应当仔细考虑这项技术。

---

[1] 请参阅ObjectWatch 通讯第26期Roger Sessions的文章Measuring Scalability by Roger Sessions (可以在www.objectwatch.com获得)和ObjectWatch 通讯第24期Roger Sessions的文章The Sun White Papers (也可以在www.objectwatch.com获得)。

[2]请参考www.tpc.org的规范或正式的基准结果。

[3] Building a Large, Integrated, Multi-EJB Server System ，Paul Harmon 著http://www.cutter.com/consortium/consultants/phbio.html Architecture/e-Business E-Mail Advisory, Cutter Consortium August 23, 2000