dot-com 体系结构框架


(来源:http://www.sun.com.cn)

网络是运行网络服务的物理基础设施。这包括硬件和基础软件产品,例如服务器、工作站、存储阵列与存储库、路由器、交换机、操作环境等等。

平台指网络交付的通用基础服务。网络服务类型包括如下:

网络与系统服务。它包括由应用服务器、Web 服务器、信息传递服务器、通 信服务器等交付的功能。设计这些服务的宗旨,是为了便于把客户服务分隔成为适 当的范畴。它们为软件开发商提供标准的应用编程接口,允许他们快速而便捷地编 写软件,并创建更高水平的服务。有五类平台服务或层次:

  • 设备平台:管理服务和内容的输入与显示。

  • 网关服务:为所有需要的设备准备要交付的内容,其中包括内容变换、高速缓 存以及代理服务。

  • 表示服务:集合内容与服务,并执行个性化处理,它们需要对内容执行汇编、格式 化、转换以及变换-凡是跟文件的物理外观和最终用户使用的信息相关的任何环节, 均包括在内。

  • 商务服务:执行商务逻辑,管理事务。相关实例包括过程自动化、工作流以及事务 服务 (其中包括企业商务规则)。

  • 集成服务:与其它服务相集成,并跟外部资源相结合,以提供数据库存取、发布/ 订购通信、同步或异步信息传递等商务服务。

    除五个网络服务层之外,应用平台层还包含资源层,其中包括现行 (传统) 系统、 数据库以及服务。这些资源可以集成于dot-com 构架。我们将在"要素 3:开发集 成策略"章节阐述这个问题。

    dot-com 服务:即最高等级的网络服务,它们是企业在网络部署的实际应用。实例 包括 ERP、CRM、供应链管理 (SCM)、销售队伍自动化 (SFA) 等。值得注意的 是,服务宗旨是规范应用平台层服务应如何编写。也就是说,它们将有利于确定开 发人员在平台层编写代码时,应该使用的标准应用编程接口 (API)。

    网络服务间的相互关系

    虽然网络服务是为最终用户提供功能的,但它们也可消费其它网络服务。实际上,许多网络服务的主要用户就是其它网络服务。通过了解网络服务相互间的使用方式,就可以创建一个网络服务在某个环境中的相依图。这将是dot-com 构架功能最强大的工具之一,并为了解和演进整体设计提供了必不可少的结构。

    为了阐明网络服务间的相互关系,可以考虑 Web 订单表这个简单例子。 订单表本身是一种设备服务。它可以通过一个 HTML 表格容器服务 (浏览器) 执行 访问,并管理最终用户内容的输入和显示。

    订单表使用Web 订单表处理器 (服务器小程序) 服务。它是一种表示服务,即对表 格内容和最终用户使用的信息物理外观执行个性化处理。

    Web 订单表处理器使用许多商务服务,其中包括支付服务。该服务将验证用户身份, 对用户信用卡号码执行舞弊审查,并核查交付地址信息等。

    支付服务使用许多集成服务,例如访问存储用户的客户地址和以前历史信息的数据库、

    XML/HTTP 服务、排队服务、处理服务等。

    支付服务也访问传统订单处理系统 (有可能是一个外包供应商的系统)、CICS 服务以 及其它服务等资源,以完成订单输入和支付过程

    设计指导原则:网关与表示服务


    下列标准对设计网关与表示服务比较有用:

  • 应考虑采用联合服务,以便收集外部源 (经销商) 的数据,并向外部消费者 (附属 机构) 推送服务。使用集成服务搜集数据,特别是搜集来自传统系统的数据。使用 应用服务,以对构成各服务基础的信息施加影响。

  • 对信息、表示和信息行为实行严格的分离。采用单独的分布包,将商务规则跟用户接 口布局相隔离。要在可能条件下采用基于变换的方式,重新确定信息意图,使之适用 于新的目标设备和客户机团体。

  • 设计网关和表示服务时,通常要依靠若干供应商实现的接口。支持 JavaServer Pages 和 Java 技术服务器小应用的 Web 服务器平台适合于共用。

  • 定义的用户交互模式,不应依靠低延时或从客户机至服务点的持续连接。这可能需要 考虑降低 Java 技术和 HTML 或 XML 功能在传统客户机环境的等级,并就此作出决 策。可能需要为过时的环境定义较低的服务等级,同时在符合现行 Web 标准的浏览 器环境提交比较丰富的交互。

  • 在网络面临挑战的情况下执行测试将是一种好办法,譬如带宽受到限制,出现网络错 误的可能性较大,或网络延迟较严重等情况。在配置严密防火墙的环境下,为异常或 边缘设备执行测试同样是个好办法。

  • 服务产品要经常以一系列主要设计标准为中心实现优化处理。服务元件的设计应能够 跨越这些中心而重复使用。例如,在许多情况下,设计标准将在不依靠网络持续可用 性的条件下 (譬如所有的移动用户),规定服务的可用性。在其它情况下,设计可能 设想提供持续不断的连接性 (譬如,机顶盒及其有限的本机处理能力)。在可能存在 许多设计中心的条件下,允许在一系列客户机设备和服务器为中心的实现中执行商务 规则编码,将是明智之举。为实现这一目标,这些商务规则应该使用工作于许多平台 的对象部件模型执行开发,其中包括客户机和服务器。行之有效的部件模型,应允许 通过专业化实现重复使用 (有可能是基于继承的)。它应该允许识别和调用代表客户 机状态的特定元件对象,以便处理客户机事件。它必须受到广泛的客户机设备以及服 务器平台的支持:商务规则实现可以在客户机与服务器之间进行移植,并肯定需要在 许多客户机设备环境来执行。

  • 为每个客户机交互确定相关安全和保密规则。在某些情况下,这些策略是由服务提供 商规定的,在其它情况下则是由消费者规定的。要确定在每种情况下采用的策略。而 且,还要考虑既保护用户隐私,又要为用户提供丰富多彩的交互,协调二者间的关系。 要确定最能适应服务消费者需求的策略,随着消费者以及你跟消费者的关系日臻成熟, 还应经常重新确定该项策略。

  • 为构成门户的网关和表示服务,创建远程监控功能。在运营期间,要注意观察总需求 衡量标准的发展趋势:应尽早和保持经常地观察。要考虑用于可预测性能模型的衡量 标准 (譬如队列长度和响应时间分配)。

    设计指导原则:商务与集成服务


    下列指导原则对设计商务和集成服务比较有用。

  • 服务接口应根据供应商中立的工业标准执行定义。这些接口通常使用 XML 模式予以 说明。预计的输入和输出,应采用定义明确的 XML 模式。为实现服务互操作,应使 用 XML创建一个过程流模型,以便定义商务协议。对于专用行业的定义,应经常考 虑采用供应商中立的模式库。一般情况下,这将允许供应商跟他们的供应商以及其他 策略伙伴之间实现互操作。

  • 在服务内部,可以对定义的部件执行集合,以生成服务。在设计 (以及由设计工具生 成的设计产品) 中,集合应采用显式方式来表示,以鼓励重复使用构成部件。

  • 接口应该从联结特定供应商的部署和实现、以及本地系统服务的相关性中进行提取。 部署相关信息在本质上应该是说明性的,不应该嵌入商务对象。

  • 服务与实现的结合应尽早推迟至部署时间,并依靠公用目录服务解决具体实现问题。

  • 应为部件提供容器,进而提供基本的安全和并行 (事务) 特性。应采用说明方式,规 定部件操作需要以及由这些特性提供的功能,以支持重复使用,并减轻可靠实现的负 担。

  • 应支持状态部件模型和无状态部件模型。对于长事务来说,限制向数据库操作表明状 态,将可以有效利用系统资源。在经常通过一系列中间基准访问数据的情况下,数据 库遍历负担比较高,而状态对象将反映最佳的系统设计。应该提供相关工具,以支持 状态对象与数据库间的映象。

  • 从设计开始起,每个服务调用点都将仔细检查同步调用的需求。尽管同步调用较为普 遍和直接了当,但它有可能不合理地占用商务系统中交叉各层次的操作资源。异步调 用将释放呼叫站点的资源,即使服务生产者与消费者之间的连接时断时连,异步调用 仍将工作。异步 (发布和订购) 传输允许系统在今后随着服务生产者和消费者发生变 化时,以更便捷的方式实现演进。当变化难以通过中央当局进行协调时,此种情况尤 为真实。

  • 接口应包括寿命周期问题、监控、安全以及企业建立的商务规范等操作管理的有关规 定。 dot-com 构架优势总结

    基于网络服务的构架 (服务驱动型网络),将为企业、最终用户、供应商和客户提供 许多重大优势。

  • 加快部署和交付:这将进一步有利于识别网络中的热点以及服务过载或安全问题等, 有利于增加系统支撑能力或对特定服务执行修改的能力。而且,由于服务具有高度的 可重用特性,这将更加便于快速部署新的服务,或在现行服务基础上执行创建。

  • 协调部署:服务驱动型网络允许为每种服务创建部署策略。例如,可以逐项确定需求 的可伸缩性、可用性、安全性以及带宽消耗水平。这将允许使系统级资源与服务实现 匹配。

  • 外包机会:同样重要的是,由于服务驱动型网络服务基于定义明确的接口,而且可以 从网络的任何地方执行访问,因此你将拥有把网络服务外包给第三方服务提供商的选 择权。这将允许你将重点放在核心技能方面,同时实现成本经济和外包模式的效率。

  • 更加有效利用资源:配置服务驱动型网络,就可以采用更有效的方式集合并利用资源。 采用传统构架时,资源要实行分布,而不是以本机方式进行连接,因此往往有资源但 却不能使用。当集合资源创建服务时,就可以集合那些闲置资源,并加以充分利用。

  • 灵活使用和重复使用服务:鉴于服务可以通过网络使用,因此它们可采用多种方式使 用。而且,由于服务可用于网络,故每次增加新服务时,就丰富了整个网络环境。

  • 构架一致性:基于标准的服务驱动型网络,比传统网络更易于设计,从而更加容易看 清全局和跟踪环境。

  • 模块化:在一个高度网络化环境,IT 部门需能够开发网络的各个部分,但不必了解整 个构架。dot-com 构架不需要知道每个部分是如何部署的。

    下表旨在显示传统构架与 dot-com 构架思维方式的差异。

  • 传统方式 新方式
    平台是一种独立自主式系统。 平台是一种独立自主式系统。
    工作是由运行于系统的
    单块应用程序执行的。
    工作是由驻留于网络任何
    地方的服务关联执行的。
    大多数软件不是共享软件;
    软件统一体是重新创建的。
    服务可以共享、集合、组合以
    及重新组合,以创建新的服务。
    部署策略是由粗纹理结构和固定
    的应用/系统堆栈作为驱动因素。
    部署策略是由服务以及需
    求的服务质量作为驱动因素。



    要素三:制定集成策略

    一旦创建了 dot-com 构架,就可以着手选择如何将新体系结构跟现行系统和资源相集成,确定哪些网络服务实行内部部署,哪些将外包给第三方公司。

    把传统系统集成于 dot-com 构架

    如果遵循前面章节概括介绍的构架设计原理,就可创建一种 dot-com 构架,从而为部署和集合网络服务提供极具灵活性和敏捷性的框架。你将如何集成新系统与现行系统、存储器资源、应用程序以及其它资源,以便创建 dot-com 网络服务,同时又不浪费资源,不搞无效劳动,不引入新的复杂性呢?

    答案是迭代设计过程。该过程将重点满足最终用户的需求,消除不确定因素。

    "老派"设计过程采用一系列线性步骤:分析用户需求,然后指定开发组织着手创建各种部件 (譬如商务对象、用户接口、传统集成包)。这些部件通常以并行方式创建,结束时对所有部件实现一次性集成,最后一个步骤是测试。这种"大爆炸"集成方式通常要耗费时间,而满足最终用户需求的结果往往是令人遗憾的,因为用户的需求已经完全改变了。

    老派设计过程:"大爆炸式"集成

    "新派"集成模式不采用一系列线性步骤,而是采用一种迭代设计过程,其重点是每次为需要的一个过程实现必要的集成。在用户看来,这种技术注重的是过程,而不是功能。这些过程被称为"使用实例",遵循有理统一过程模式。它是业界领先的对象分析与设计方法。采用此方法,设计队伍将创建"第一个建设迭代" ,并向最终用户交付适用于测试的过程,然后根据用户反馈意见重新访问设计,不必逐项实现每种部件。如果这样做,就可以非常迅速地执行变化,而且最终用户最后得到的过程将更加适应其需要。

    例如,一种使用实例可能是联机股票交易,而另一种可能是联机期权交易。设计队伍将通过进行彻底分析,掌握用户对两种使用实例的全部要求,然后着手实现股票交易使用实例正常工作所需要的全部功能。在向用户提交第一个建设迭代的同时,设计队伍将动手实现期权交易过程。用户很可能根据股票交易使用实例,提出应同时改变期权交易过程的建议。这样,两种过程都可以很快地执行相应调整。

    此种使用实例驱动型集成方法,允许设计队伍迅速地识别和弥补用户需求与交付功能间的差距,从而消除不确定因素。

    新派设计过程:迭代、使用实例驱动型

    开发和定义集成策略,是实现企业上网最困难的阶段之一。值得庆幸的是,优秀的咨询公司具有丰富的经验与技术,可提供一臂之力。


    制定外包策略

    外包是作为内部设计、部署和管理网络服务的一种切实可行的替代模式而问世的。随着外包模式的日益盛行,现已出现了三种基本策略。

    1.全部外包

    许多公司发现,无论从经济上还是策略上讲,由第三方供应商把传统 IT 基础设施以及应用程序跟 dot-com 构架相集成,是一种明智的做法。此种方法允许公司把重心放在自己的核心技能方面,而集成商则把重心放在它的核心技能方面。这将消除招聘、雇佣和维护专业人员的必要性,并允许企业从一流系统集成商提供的规模经济、全球覆盖和专业化技术技能中受益。

    除传统系统集成商之外,如今还有大量的第三方服务提供商可在应用和基础设施方面,提供全部外包。

    例如,出现的全方位应用服务提供商 (ASP) 就提供涵盖整个寿命周期的服务,从设计广泛的应用程序到提供主机受托。ASP 模式引起了人们的关注,原因如下:

  • ASP 可通过集中式基础设施和分布式客户群,实现规模经济效益。他们拥有运行应用 程序所需求的基础设施,而且具备优异的性能和可靠性。这为他们提供了超过所有企 业内部 IT 部门的优势,当然最大型企业内部的 IT 部门除外。

  • 一流的ASP 拥有一支规模庞大、经验丰富的 IT 员工队伍。他们在安装和管理应用程 序方面,具有专业化技术和技能。

  • ASP 可以提供不受限制的实时可伸缩性,而许多内部 IT 部门却不能以合理的成本提 供此种可伸缩性。

  • ASP 可以为平衡所谓的封装型商务应用"中间层"版本,提供优异的替代方案。中间 层版本以较小型公司为目标,往往为了降低价格和简化实现而牺牲特性。ASP 可以提 供全特性软件版本,而且其价格跟购买、安装和维护封装型中间层版本相比,通常具 有竞争力。

    2.双方合作

    第二种选项是采用比较传统的合作方式。在这种情况下,第三方供应商在集成基础设施方面,对你的内部努力将是一种推动。如果公司内部拥有强大的 IT 部门,他们将需要专业化技能和/或培训及支持计划,采用此种选项是明智之举。

    第三方供应商往往是系统集成商。他们在跟你的环境最相关的系统和应用领域,具有高度专业化经验。在组合传统系统和为 dot-com 应用专门引进较新系统方面,系统集成商可以帮助组织机构处理有关的复杂问题。

    3.自己动手

    对某些公司来说,需要实现上网的商务功能具有高度的敏感性,是组织机构的核心技能,或者是关键竞争优势。在这些条件下,明智的做法是,应考虑完全采用内部方式提供网络服务。例如,Sun 公司已为设计微处理器开发了专用应用程序。这些应用程序永远不实行外包,因为它们是 Sun 的核心技术。


    外包服务指导原则

    你应如何确定哪些服务实行内部管理以及哪些服务实行外包?外包是一个复杂的问题,需要查阅许多书籍的内容处出,并要投入大量的咨询时间。然而,可以使用下列三个问题作为指导原则:

  • 服务对公司商务模式是否具有独特性?如丧失设计、部署和维护服务的技术,将来是 否会产生严重影响?如答案是肯定的,实行内部管理则可能是明智的。

  • 组织机构能否使服务显著地增值?换言之,公司使用服务的方式,是否不同于其它企 业的使用方式?如答案是否定的,对服务实行外包不失为上策。

  • 除外包选择这一原因外,是否还有其它原因使企业能够以更经济有效的方式交付服 务?如答案是否定的,服务应实行外包。


    要素四:部署和管理基础设施

    当完成 dot-com 构架设计和确定集成策略后,将需要实现和管理生产环境,采用的方法应能交付最终用户需求的 QoS 等级。这将包括定期进行监控、评价和调整,以确保构架今后将继续为企业提供优异服务,满足最终用户服务质量要求。这些就是部署与管理服务的宗旨。 对此,我们将在下面予以阐述。


    服务质量 (QoS) 的构成

    说到底,衡量 dot-com 构架效率的标准,是它交付给最终用户的 QoS 。例如,它必须提供商务目标需求的可伸缩性、可用性、性能、可管理性以及安全性。实现最终用户需求的高度 QoS 水平,是第二个构架要素域,人们称之为控制与管理平面。下面的举例,旨在说明通过控制与管理平面交付的若干操作功能。

  • 容量规划:在 dot-com 时代,IT 面临的最棘手问题之一是如何预测网络服务的需求 水平。诸如日平均量这样一类统计数字将没有用处,因为需求量可能存在巨大和临时 高峰期。只要问问在互联网上提供这类报告的服务提供商就可得到佐证。由于当今网 络的复杂性及其相依性,很难确定特定服务需求量的驱动因素是什么。因此, dot-com 构架的容量规划,应该视为一种经常性和循环性过程。它应考虑网络服务的相依性, 考虑由每个用户请求生成的服务级事务和生成的网络通信总量,还应考虑物理基础设 施在支撑通信量方面存在的限制。通过对基础设施执行监控和测量,并经常不断地进 行适应性调整,就可以处理峰值负载,而且不浪费网络资源。

  • 可缩放性:服务的可缩放性,将对可以同时支持的用户数量和用户经历的服务级性能 产生影响。为网络服务创建高水平缩放性时,需要考虑下列三方面问题:基础性规模 估计与调整;直接通过硬件提高缩放性 (处理器、服务器以及存储器系统);通过间 接技术提高可伸缩性,例如高速缓存与复制。

  • 定义网络服务范围:网络服务范围指服务通过网络的可访问性。例如,其范围可以扩 大到"互联网的任何地方",也可以缩小至"特定的专用网络"。网络服务范围还可以 限于一幢大楼内或一个特定部门。在某些情况下,明智的作法是简单地定义不可以使 用网络服务的所有地方。例如,内部服务就不应该供用户在互联网上查看或访问。网 络服务范围应该按照商务需要和目标进行定义。另一种可选方法,是根据需要使用本 服务的其它服务所部署的位置来定义。但此种方法缺乏部署灵活性。

  • 可用性:连续服务是 dot-com 世界中最困难的需求之一。 服务预计可以在每年 365 天、每周 7 天、每天 24 小时的互联网时间内使用。实现这一目标,将对基础设施的 各个方面产生影响,因为这将不允许存在任何弱连接。

    基础设施模块化,是实现连续可用性的关键因素。因为存在如此之多的不同潜在故障 源,单一模块系统根本不能为各种网络服务交付足够的正常运行时间。

  • 除此之外,由于网络服务在很大程度上具有互依性,经常监测服务可用性对隔离故障 区具有重要意义。

  • 监控服务部署:监测服务很重要,同样重要的是监测部署服务的那些系统。下面的问 题需要引起注意:服务访问率是否跟系统负载保持一致?你的模式是否存在任何偏 差?系统需要升级前还留有多少扩展空间?如果部署服务需要跨多部系统,这些系统 是否承载相同的负荷?有些系统的访问量是否超过了其它系统?如果服务经历性能降 级时期 (访问时间长,低带宽),与降级相关的系统活动有哪些?


    交付 QoS

    在了解了 QoS 构成之后,现在我们可以把注意力转向如何部署和管理基础设施,以交付需要的 QoS 水平。这意味着需解决下列问题:

  • 你将如何开发一种以解决方案为重心的集成化方法,以满足服务级需求?

  • 你如何才能减少因缺乏足够的一线设计和操作规范或培训,而导致的系统故障停机风 险?

  • 哪些供应商可为端对端生产环境提供单一源解决方案?

  • 你将如何运用拥有的资源实现优异的生产环境?

  • 你将准备如何培训员工以支持上述变化?

    Sun 认为,交付 QoS 的重点如下:服务方法、 服务交付构架、 全方位高可用 (HA) 模式、提供持久服务以实现连续访问和性能。


    服务方法

    服务方法是为实现企业上网而采用的一种结构化模式。 不同供应商采用的原理和方法有多种多样,但服务方法应说明过程的每个步骤-从初始评估到实时支持服务。

    一般情况下,需要经过下列五个关键阶段:

  • 解决方案设计。定义现行服务级承诺,以及创建生产环境和实现预期服务水平而 需要采取的步骤。

  • 实现规划。根据第 1 阶段确定的解决方案设计要素,制定详细的技术规范和计 划。这将有利于保障生产环境实现第 1 阶段定义的所有目标。重心应放在人员、 过程、产品需求的准备与规划方面,以确保实现完善的解决方案。

  • 原型实现。在原型环境集成适合目标生产环境的各种部件,其中包括生产工具。 该分级过程通过为测试环境之目的提供一个安全可靠的地方,将减少把复杂系统 投入生产环境的常见风险。

  • 生产实现。配置和集成生产环境,并执行测试,以保证系统和数据的稳定性与可 恢复性。

  • 投产:又称为投入运行阶段-即生产环境开始投入生产运行。当这一阶段完成 时,生产环境即处于使用状态。


    服务交付构架

    服务交付构架是为了交付构成 QoS 的操作功能而部署的有形基础设施。它既可以通过内部予以实现和管理,也可以通过第三方服务提供商实行全部外包。服务交付构架的实现方法,必须使 QoS 实现可测量目标。必须采用客观公正的方法,证明系统达到了可用等级、性能、安全性以及可伸缩性标准等。这样做将允许 IT 部门或服务提供商,向最终用户交付合同服务级协定 (SLA)。


    全方位高可用模式

    连续不断的服务级正常运行时间,是无所不包的全方位高可用 (HA) 模式的必然产物。采用的平台硬件和软件技术不仅须具有内在可靠性,而且还涉及到更多的问题。实际上,由于硬件或软件故障而造成的服务级故障停机时间,仅占很小的比例。绝大部分中断运行,是由于操作员失误、诸如洪水这样一类天灾或断电、以及为执行例行服务、维护和重新配置而采取计划内停机所造成的。

    因此,必须统盘考虑与高可用性相关的人员、过程和产品诸问题。有四种技术对转向此种全方位高可用模式颇有帮助,它们分别是部件选择、集群与复制、过程与商务规范以及灾难恢复规划。


    部件选择

    熵定理认为,任何事物最终都将崩溃。但通过许多办法,可以保证部件故障不会导致服务停机时间。

  • 了解部件现行正常运行时间的特点,并同时考虑与硬件和软件相关的问题,这将 会表明哪些问题要首先处理。例如,平均多长时间需要执行重新引导?执行重新 引导需要多长时间?恢复服务需要多长时间?由于硬件故障和软件故障而引起的 重新引导频率有多快?

  • 对即将使用的少量系统实现规范化。这将有利于增强内部操作水平,大大减少须 准备的备件数量。

  • 使用跟系统一并交付的 RAS 特性。在可能条件下,要检查联机重新配置和修理 功能、远程监控、热交换部件以及部件冗余等。


    集群与复制

    许多应用程序和服务均具有增加可用性的技术。目前,先进的高可用集群软件,包括尖端故障管理软件,可以自动检测和隔离单一硬件或软件故障,并实现故障恢复。

    在集群配置中部署服务的一个问题是连接服务的接口。在较为理想的条件下,接口将掩盖服务跨冗余系统而实现这样一个事实。这样,服务和用户均不知道被隐含的复杂性。与向服务和访问服务的用户暴露服务器配置的作法相比,这是一种更好的选择。如强迫服务用户规定部署密码,将会大大降低未来的灵活性,并增加所有服务的复杂性。

    最后,关于集群的两个问题需要注意。首先,集群有两个或更多的系统可以十分密切地进行合作,因此可提供连续服务。此种合作,是通过精确而复杂的配置予以实现的。一旦致力于集群配置,就不能在产品、人员或过程方面图省事。否则就会发现,服务的可用性水平比开始阶段降低了。第二,增加系统数量将会相应提高性能,但系统之间的合作将要付出代价,即通常会使预期性能降低。当实行紧密的集群化时,少数应用程序既可以实现扩展,又可以提高可用性。但设想集群将同时带来上述两种好处时,一定要注意实际情况。

    尽管我们提出上面的警告,但集群化将继续是增强某些最重要服务可用性的重要技术。如果能精确地使用集群技术,它将允许实现主流系统的可用性水平,而且可以与深奥的容错设计相媲美。


    过程与商务规范

    过程相关问题,是造成故障停机的共同原因。解决过程相关问题,没有什么灵丹妙药。你必须建立正式的商务规范,并要制定教育和培训计划。在使用定义的过程方面,必须保持高度的一致性。


    灾难恢复计划

    纽约世界贸易中心发生了爆炸,南加州北岭地区发生了地震,芝加哥发了洪水。活生生的事例表明,不可预测的事件会对服务可用性造成影响。仅环境性断供就包括广泛的可能性,例如断电,冷气系统和网络连接出现故障等。

    在互联网上,只要一天时间就会使享有的盛誉化为乌有;坏消息传得更快;客户有更多的选择;而且营业时间没完没了。因此,关键是要全面考虑各种防灾方案,每种灾难都 要制定防灾计划。

    一个新兴帮助源,是提供优异机房功能的公司犹如雨后春笋,数量呈爆炸性增长。许多公司有能力执行远程备份和负载管理。如今,这些服务的价格具有极大的吸引力,许多互联网新建公司都直接采用此种模式,从来不维护他们自己的服务。


    提供持续服务以实现连续访问和性能

    企业上网的最重要目标是创建和部署连续可用,并可实现峰值性能操作的网络服务。正确的服务方法跟正确的服务交付构架相结合,就可以实现上述目标。以维护构架可访问性和性能为目的的持续服务,是保障构架继续提供其优势的关键因素。 Sun 可以提供鼎力帮助

    作为 dot-com 构架的主要发明企业和推动 dot-com 时代发展的主要力量,Sun 公司处于一种得天独厚的有利地位,可以提供一系列产品、服务和支持,帮助企业转向 dot-com 经济。

    Sun 提供全面的端对端解决方案,可以为组织机构发挥多方面的作用,从策略技术顾问到网络计算专家,乃至基础设施供应商和支持服务商。虽然我们在下面章节将不推荐任何特定产品或服务,但我们认为,你如果了解 Sun dot-com 能力的广度和深度将具有十分重要的意义。

    "如果你想知道计算机业的发展走向,请问 Sun 公司。"

    -Steve Milunovich, Merrill Lynch 银行;引自《商业周刊》1999 年 1 月


    dot-com 计划概述

    dot-com 计划是 Sun 公司为适应企业上网需求而出台的一项综合性计划。通过该项计划,Sun 可以帮助定制独具特色的解决方案,以满足客户的各种需求。dot-com计划将提高所有公司-从大型企业到新建的小型公司-实现其dot-com目标的便捷性、快速性和安全性。

    dot-com首创计划旨在解决客户最关注的以下五个关键问题:

  • 远见:你希望跟同时具有技术和商务领导才干的供应商开展业务。该供应商在技术可 行性方面,具有清晰而又令人信服的先见之明,拥有化远见为现实的蓝图。

  • 证明:你需要确凿无疑的凭证,以证明供应商的策略、产品、服务和解决方案能够适 应现实世界。这不仅包括成功案例和证言书,而且包括业界分析家乃至竞争对手所 独立提出的确认。

  • 计算平台:你需要跟能够提供全方位端对端平台解决方案的供应商开展业务-从服务 器和存储器,到系统软件和支持服务。

  • 一流解决方案与服务:你不仅需要访问核心供应商的解决方案,而且需要访问第三方 联盟的一流增值解决方案和服务。

  • 服务质量:服务质量特性包括高可用性、高可靠性、高可伸缩性以及高可预测性能。 为了实现这些目标,你需要拥有有形、客观和可核查的手段,以确定特定服务或服务 提供商真正交付你需要的服务质量水平。

    当然,任何供应商都不可能单枪匹马地提供综合性解决方案中一所有可以想象的部件。这需要一个联盟-即由合作性解决方案供应商、系统集成商、实现伙伴、电子集成商、独立软件供应商 (ISV)、服务提供商以及崭露头角的创新者共同组成的一个强大的、繁荣兴旺的组织,他们的产品可以相互补充和实现增值。因此,联盟就成为 dot-com 计划的统一主旋律。

    下面,我们将阐述 Sun 如何处理客户关注的有关产品、解决方案、联盟以及定制服务等五个关键问题。为方便起见,我们将分别探讨 Sun 筹划企业上网的四个要素的能力。


    dot-com 计划

    整个全部要素,实现企业上网

    要素 1:帮助定义商务策略

    Sun 提供技术技能和顶尖级联盟,帮助你定义商务策略与目标。

    通过我们的联盟计划,Sun 可以把你跟领先咨询公司相连接。这些咨询公司专门提供关于开发和定义 dot-com 时代商务策略的全方位支持。除此之外,Sun 自己的专业服务组织也可以就如何利用 Sun 技术满足你的需求提供帮助和建议,而且可以就如何以最佳方式利用 Sun 技术的问题,向我们的咨询伙伴提出建议。


    跟关键系统集成商和电子集成商结盟

    Sun 制定了一项旨在支持顶尖级系统集成商和电子集成商的计划。这些集成商坚持以互联网策略和联机商务过程作为重点,并可支持你定义和演进面向 dot-com 时代的商务策略。

    由于 Sun 在当今企业数据中心领域处于十分强有力的地位,大部分顶尖级系统集成商均提供使用 Sun( 系统的高水准技术技能。为帮助崭露头角的电子集成商了解Sun 平台,Sun 制定了一系列计划,以便于他们积累操作Sun 系统的知识和信心。除此之外,Sun 及其第三方伙伴还在客户站点开展密切合作,保障实现最大的成功。


    iForce ready 中心

    Sun dot-com / ready 准备中心汇集了Sun 和第三方的技术技能,可以提供无所不包的全方位帮助:为创建 dot-com 基础设施提供技术选项、执行快速概念证明实现和实际试验计划等。这些中心是开始分析需求和制定商务策略的绝好地方,并为实现 dot-com 远见性目标提供涵盖每个步骤的全程服务和支持。Sun iForce ready 中心免费为合格的客户提供策略规划服务。


    一流解决方案集

    Sun 承诺帮助你发现优异的解决方案,以满足你的 dot-com 需求。正是出于这种考虑,我们和许多策略伙伴共同为各个市场的客户交付水平和垂直解决方案集。我们对独立软件供应商以及Sun 的产品执行评价,严格测试其可伸缩性和集成能力,并创建紧密集成的一流产品组合。这将允许你快速实现完整的解决方案。

    当前,Sun 正在交付零售解决方案集。它集成了来自 Sun、Cisco 和 InterWorld 的一流产品,从而为零售网站提供丰富的特性,其中包括产品采购、客户服务、订单管理、渠道集成等。

    除此之外,Sun 最终还将为制造、金融服务、汽车、电信、政府、教育以及其它市场,提供一系列垂直解决方案。Sun 还将为最新的解决方案集的相关信息,提供中央联系点和中央网站。


    Sun 专业服务组织

    作为面向 dot-com 时代计算的技术咨询服务领先供应商,Sun 专业服务组织可为你提供广泛的服务,宗旨是要在企业上网的各个方面为你提供帮助,其中包括定义商务策略。从我们的 dot-com 研讨会到 dot-com 启始服务,Sun 技术顾问可以帮助你评价各种选项,定义目标,并着手筹划把远见转化为现实。

    例如,在dot-com 启始服务中,Sun 技术顾问将和你共同创建旨在融合商务目标与dot-com 目标的技术策略。我们将和你的开发组织密切协作,探讨和识别有利于推进组织机构重要成功因素的关键互联网技术与 Java 技术。我们还将评估你的现行 IT 环境,筹划你创建和交付独特的客户经历所需要的技术。然后,我们将根据你的独特商务策略和技术要求,帮助你创建一个高水准的互联网基础设施和电子商务解决方案设计。

    要素 2:帮助创建 .com 构架

    Sun 开发了一种体系结构框架,目的是为了帮助各类规模的公司实现行之有效的dot-com 构架。关于该框架的基础问题,本文已在前面《要素 2:创建 dot-com 构架》章节作了阐述。本章节将介绍在该框架基础上执行创建时,Sun 可以提供的增值,阐述我们推荐的各种标准以及Sun 出台的构架计划,它将进一步扩大体系结构框架的优势。

    关键标准

    鉴于网络服务是供环境内许多其它服务和系统执行访问,坚持标准就成为关键。更有甚者,许多网络服务将成为外包的候选项目,因此基于标准的平台独立性也是一个关键因素。