中间件管理方法及装置与流程

1.本发明涉及金融技术领域，具体地，涉及一种中间件管理方法及装置。


背景技术：

2.传统的企业web中间件在银行、保险等金融行业的交易系统得到了广泛应用，是金融行业众多业务系统的基础组成部分，例如ibm公司的websphere application server(以下简称was)。
3.当下，此类传统的企业级web中间件在一台pc服务器安装完成后能且仅能由其配套的管理控制台(例如ie浏览器)进行日常管理，常见的管理操作主要包括启动、停止中间件进程。同时要对该中间件(例如ibm was)进行管理。除了要手动登陆其管理控制台，还要牢记web中间件软件的必需的各类配置信息，例如安全管理特性、概要运行环境、对外服务的server名称及端口等。
4.上述情形是目前对一台pc服务器上部署的web中间件的日常管理的场景。在实际的生产运维中运维人员通常负责多达几台、十几台甚至几十台的web中间件，因此这种管理方式存在以下几个弊端：
5.1.手动操作，费时、低效。在管理十几台甚至几十台大量中间件的场景中，目前仅能手动依次逐台登陆中间件的管理控制台进行操作，是一种十分低效的方式，无法并发对多台web中间件进行启停等操作，大量浪费管理人员的操作时间。
6.2.操作繁琐、工作量大。绝大多数web中间件各自的运行配置信息基本不会相同，通过其各自的管理控制台实施操作管理时，运维人员必须牢记十几台甚至几十台web中间件环境各自的配置信息，无法一目了然查看重要的配置，必须在操作过程中仔细一一核对确认，浪费大量精力。
7.3.无法实时动态对web中间件的应用负载和宿主pc服务器的负载容量进行关注并以此调整并发管理策略。在手动管理中间件中很难做到动态依据宿主服务器的cpu或内存等核心资源的使用负载以及web中间件自身的业务权重进行启停等管理，只能按照顺序依次操作下来，对业务应用的影响欠缺考虑。


技术实现要素：

8.本发明实施例的主要目的在于提供一种中间件管理方法及装置，以自动化的对大批量中间件进行并发集中管理，提高运维管理效率、优化并发管理模式。
9.为了实现上述目的，本发明实施例提供一种中间件管理方法，包括：
10.确定中间件对应的核心资源数据和辅助资源数据；
11.根据辅助资源数据和所述核心资源数据确定资源排序数据；
12.根据资源排序数据对对应的中间件进行排序，对排序后的中间件依次进行处理。
13.本发明实施例还提供一种中间件管理装置，包括：
14.资源确定模块，用于确定中间件对应的核心资源数据和辅助资源数据；
15.资源排序数据模块，用于根据辅助资源数据和核心资源数据确定资源排序数据；
16.中间件处理模块，用于根据资源排序数据对对应的中间件进行排序，对排序后的中间件依次进行处理。
17.本发明实施例还提供一种计算机设备，包括存储器、处理器及存储在存储器上并在处理器上运行的计算机程序，处理器执行计算机程序时实现所述的中间件管理方法的步骤。
18.本发明实施例还提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现所述的中间件管理方法的步骤。
19.本发明实施例的中间件管理方法及装置先根据中间件对应的辅助资源数据和核心资源数据确定资源排序数据，再根据资源排序数据对对应的中间件进行排序，对排序后的中间件依次进行处理，可以对大批量中间件进行并发集中管理，提高运维管理效率，优化并发管理模式。
附图说明
20.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
21.图1是本发明实施例中中间件管理方法的流程图；
22.图2是本发明实施例中并发调度的示意图；
23.图3是本发明实施例中远程探针的示意图；
24.图4是本发明实施例中中间件管理装置的结构框图；
25.图5是本发明实施例中计算机设备的结构框图。
具体实施方式
26.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
27.本领域技术人员知道，本发明的实施方式可以实现为一种系统、装置、设备、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。
28.需要说明的是，本发明的中间件管理方法及装置可用于金融领域的中间件管理场景中，也可用于除金融领域之外的任意领域。本发明实施例对中间件管理方法及装置的应用领域不做限定。
29.鉴于现有技术受限于软件产品本身的限制，目前仅能手动对每个web中间件进行独自管理，无法实现自动化、大批量的并发集中管理，管理效率低下，本发明实施例提供了一种中间件管理方法及装置，能够并发管理多个web中间件，并能够依据web中间件的实时状态和业务应用的差异动态调整并发管理策略，从而提高运维管理效率、优化并发管理模
式，减少人为疏漏情况的发生。
30.图1是本发明实施例中中间件管理方法的流程图。图2是本发明实施例中并发调度的示意图。如图1和图2所示，中间件管理方法包括：
31.s101：确定中间件对应的核心资源数据和辅助资源数据。
32.图3是本发明实施例中远程探针的示意图。如图3所示，在执行s101之前，还包括：通过远程探针获取中间件对应的核心资源数据、辅助资源数据、应用类型、应用级别、应用负载数量和配置文件。
33.探针的作用是用来捕获企业web中间件的信息，主要包括三个方面：企业web中间件的自身的关键配置(配置文件)、其上部署的应用信息以及web中间件的宿主服务器资源的运行动态。探针探测所获得的信息是并发调度concurrency mgmt中并发管理策略的主要决定因子。
34.构造远程探针首先明确探针选型，使用什么样的探针；其次明确探针探查的内容，即需要探针探测到与web中间件相关的哪些信息，最后明确探针探测的位置，即从哪里探测获取web中间件相关的信息。按照上述三步逐步完成探针的构造，详细描述如下：
35.①
探针选型：主要根据web中间件宿主操作系统的类型和版本，设计构造专用的探针。根据操作系统类型(例如aix系统、windows系统和linux系统)、操作系统的程序语言(例如python语言和java语言等)以及操作系统专用的脚本语言(例如vbs脚本、windows系统的powershell脚本和linux系统的shell脚本)确定探针类型。以ibm was中间件为例，中间件部署在linux服务器上，则采用shell脚本实现探针的构造。
36.②
探测内容：是指探针需要从web中间件探测的内容，主要包括三个方面：
37.a.web中间件自身的配置信息(配置文件)，不同类型中间件的配置信息会略有不同，一般包括web中间件的安装运行用户、安装路径、运行环境、对外服务名称和对外端口等。
38.b.web中间件上部署的应用信息，包括部署应用的应用类型、应用级别和负载数量。可以通过判断应用属于网上银行等重要门户类应用还是内部oa所用系统来确定应用类型，不同类型应用的影响力和业务分级是有巨大差异的。负载数量指的web中间件上部署的应用数量，一台web中间件上可能会部署多个轻量级web应用，或仅部署一个复杂重要的大型web应用。
39.c.web中间件在宿主服务器上的资源，是指web中间件的进程所依存的操作系统cpu使用率、内存数据、io读写数据或其他系统资源的使用负荷。
40.③
探测位置：明确探针探测内容之后，则需要针对探查内容确定探针获取信息的来源，即探针从web中间件的什么配置文件或参数文件来获取信息，从什么命令结果获取信息，从什么相关系统获取基础信息等。
41.以ibm was中间件为例，部署在linux操作系统上的探针构造过程具体如下：
42.1、探针选型：web中间件部署在linux操作系统上，选用了较为通用的bash shell脚本进行探针构造。
43.2、探测内容：ibm was中间件需要探测的内容如下：
44.a.web中间件自身的配置信息：需要探测的was中间件的配置信息包括：安装用户《install_user》、安装路径《install_path》、概要路径《profile_path》、中间件对外服务名《
was_server_name》、中间件对外端口《was_server_port》、中间件状态《was_server_status》以及was安全管理特性《was_securty_user》。
45.b.web中间件上部署的应用信息：应用类型和应用级别，分别表示业务应用的权重和影响力度。通常在机构内部会对应用依据对外服务、数据重要性等多个维度进行类型划分和级别划分。应用负载数量即在ibm was中间件上部署的应用数量。
46.c.web中间件在宿主服务器上的资源：ibm was中间件进程，即对应的java进程所消耗的操作系统资源，例如cpu使用率、内存数据或者io读写数据等。
47.探测位置：以ibm was中间件为例，探测内容的具体点位信息如下：
48.a.web中间件自身的配置信息：通过运行的ibm was进程或通过目录搜索ibm was必备安装路径关键字ibm/websphere/appserver可获取was的安装用户、安装路径、概要路径等基础配置信息。
49.一实施例中，还包括：根据中间件的基础配置信息确定中间件的配置文件。
50.例如，根据如下三个was配置文件profileregistry.xml、serverindex.xml和security.xml分别可获取对应的对外服务名、对外端口和安全管理特性。
51.b.web中间件上部署的应用信息：应用类型或应用级别一般在企业内部由cmdb(configuration management database)配置管理数据库或其他同类似的应用repository中获取，也可以通过用户定义来指定应用类型或应用级别。was中间件部署的应用数量可以通过如下途径获取：《was_profile_path》/config/cells/《cell_name》/applications。
52.c.web中间件在宿主服务器上的资源：可通过操作(os)系统命令top、vmstat和iostat来获取对应的实时cpu使用率、实时内存数据或者实时io读写数据等。
53.s102：根据辅助资源数据和核心资源数据确定资源排序数据。
54.在各类应用中均存在部署相同应用的web中间件。一个非基础应用会在多个web中间件上进行分布部署，可能会出现几个、十几个、几十个甚至上百个web中间件均部署在同一个应用以实现分布部署和负载均衡的情况。虽然多个基础应用共用一个web中间件，且基础应用的重要性和对外服务权重比较低，但鉴于系统冗余和备份的考虑，也会有1-2个web中间件部署相同的多个基础应用。部署相同应用的多个web中间件可称为同构中间件。因此本发明所考虑的决策因素是针对部署相同应用的多个同构中间件。
55.具体实施时，先根据中间件的应用确定对应的核心资源数据和辅助资源数据。例如，当应用为网上银行时，核心资源数据为cpu使用率，辅助资源数据为内存数据和io读写数据；此时根据内存数据和io读写数据对cpu使用率进行调整以确定资源排序数据。
56.对于系统核心资源的选取依赖于该应用的特性。当该应用的特性偏向计算和实时处理时，核心资源数据为cpu使用率，辅助资源数据为内存数据和io读写数据。当该应用的特性偏向io处理和文件处理时，核心资源数据为io读写数据，辅助资源数据为内存数据和cpu使用率等。
57.s103：根据资源排序数据对对应的中间件进行排序，对排序后的中间件依次进行处理。
58.具体实施时，可以将中间件对应的资源排序数据按照从小到大的顺序进行排序以确定中间件的资源排序数据。
59.一实施例中，对排序后的中间件依次进行处理包括：
60.根据中间件的配置文件对排序后的中间件依次进行处理。
61.其中，根据web中间件自身的配置信息确定的配置文件用来封装和实现具体的管理操作，web中间件上部署的应用信息和宿主系统的资源用于进行后续的并发管理的调度决策。
62.具体实施时，对web中间件的处理至少包括启动和停止。处理操作一般基于中间件功能进行封装，然后通过http和ftp等网络协议推送至web中间件宿主服务器进行执行，并实时唤醒后台守护线程对管理操作监控其执行状态。以ibm was中间件为例：
63.启动是对《was_profile_path》/bin/startserver.sh进行功能封装；
64.停止是对《was_profile_path》/bin/stopserver.sh进行功能封装。
65.图1所示的中间件管理方法的执行主体可以为计算机。由图1所示的流程可知，本发明实施例的中间件管理方法先根据中间件对应的辅助资源数据和核心资源数据确定资源排序数据，再根据资源排序数据对对应的中间件进行排序，对排序后的中间件依次进行处理，可以对大批量中间件进行并发集中管理，提高运维管理效率，优化并发管理模式。
66.一实施例中，根据资源排序数据对对应的中间件进行排序还包括：根据应用类型排序数据、应用级别排序数据、应用负载排序数据和资源排序数据对对应的中间件进行排序。
67.对web中间件的集中并发管理操作是利用多线程技术进行封装实现的，本发明通过python语言的threading多线程技术实现对大量web中间件的并发操作。
68.在管理大量web中间件的场景下，并非是按照简单的从先到后的顺序或者按照用户勾选的初始顺序进行并发管理的，应充分考虑不同的web中间件的特异性进行并发管理调度。本发明主要考虑web中间件部署的业务应用的差异(包括应用级别应用类型、应用级别应用负载)以及宿主系统资源的实时负荷。并发队列的调度策略按照从高到低的优先级可概括为：优先考虑业务应用的应用类型或者应用级别，相同应用类型内部再根据中间件部署的应用负载情况进行决策，最后依据宿主系统资源的实时负荷进行微调，生成资源排序数据。
69.一实施例中，还包括：根据中间件对应的应用类型确定应用类型排序数据和应用中间排序数据。
70.具体实施时，不同类型业务应用之间存在巨大差异，通常应用类型的定义是由cmdb配置管理数据库进行定义和规划的。在本发明中应用类型具体划分为以下四类：
71.a类应用(非基础应用)：重要对外服务应用，例如网上银行、手机银行和atm等系统。
72.b类应用(非基础应用)：重要对外服务应用的后台经管系统，涉及客户重要信息，例如个人客户营销和银行卡辅助管理等。
73.c类应用(非基础应用)：重要企业基础系统，例如人力资源系统和财务管理类系统等。
74.d类应用(基础应用)：内部oa类系统，例如考勤系统等。
75.在上述分类中，ab两类应用是极其重要的业务应用，为了保证业务响应速度和宿主核心资源的充裕，一般不存在多个应用争抢资源，通常一个web中间件上部仅部署一个a类业务应用或b类业务应用；同时采用分布部署，通过多台web中间件进行负载均衡的架构。
c类应用虽然非对外服务类应用，但同样也是重要的基础系统，因此也会采用同a类应用或b类应用相似的架构。d类应用是应用数量最多、分布最广的应用，但由于应用重要性相对较低，通常将多个应用部署在一个web中间件上，也会采用负载均衡的架构，即多个相同应用在另外的web中间件上也会部署相同架构的一套环境。
76.在本发明的并发应用管理中首先按照应用类型进行调整，因此应用类型排序数据为：a类应用处于并发队列中的第一梯队，接下来依次是b类应用、c类应用，最后是d类应用。
77.一实施例中，根据中间件对应的应用类型确定应用中间排序数据包括：
78.当中间件对应的应用类型为基础应用时，确定中间排序数据为应用响应排序数据；
79.当中间件对应的应用类型为非基础应用时，确定中间排序数据为应用负载排序数据。
80.具体实施时，按照前述应用分类的情况，对于非基础应用(包括a类应用、b类应用和c类应用)，web中间件上均只部署了一个应用，应用负载的数量相同；而对于基础应用(d类应用)，web中间件上一般会部署多个轻量级web应用，负载应用数量有差异性。因此非基础应用(包括a类应用、b类应用和c类应用)与基础应用(d类应用)需分开考虑。
81.一实施例中，还包括：
82.1、根据中间件对应的应用响应数据确定应用响应排序数据。
83.具体实施时，若web中间件上部署非基础应用(包括a类应用、b类应用和c类应用)，在同一应用级别内部无法通过应用负载数量来进行数据排序的决策，可根据应响应数据进一步细分调整其在并发队列中的排序数据或由用户自行调整同一类别应用中不同应用的排序数据。例如，网上银行和atm均为a类应用，若网上银行和atm均有进一步的对外响应数据，而网上银行的对外响应数据大于atm的对外响应数据，则网上银行所在web中间件在并发队列中的位置在atm之前；若企业内部不存在此类更细致的应用划分，则用户自行调节或者无需调整亦可。因此可以将中间件对应的应用响应数据按照从大到小的顺序进行排序以确定中间件的应用响应排序数据。
84.2、根据中间件对应的应用负载数量确定应用负载排序数据。
85.具体实施时，按业务应用的不同类别进行并发队列的调整后，可以进一步根据web中间件上部署的应用负载的数量进行并发队列中的排序调整。
86.若web中间件上部署了基础应用(d类应用)，则可充分依据中间件上部署的负载数量进行决策调度。基础应用所在web中间件上通常会部署多个轻量级web应用，web中间件的管理操作时间就取决于部署应用的多少，部署应用越多的web中间件其管理操作的等待时间越长。而且d类应用无需极高的对外响应速度，为了减少管理操作的等待时间、提升用户体验，可以将d类应用的web中间件的操作等待时间尽量均衡。若部署应用多的web中间件排在并发队列后端，其本身管理操作的等待时间也较长，不利于用户体验。因此对于部署了多个d类应用的web中间件，可以将中间件对应的应用负载数量按照从大到小的顺序进行排序以确定中间件的应用负载排序数据。例如同为oa类应用的多个web中间件，一台web中间件上部署了4个应用，另一台web中间件上部署了6个应用，那么将部署6个应用的web中间件调整至部署4个应用的web中间件的前面。
87.综上，对于部署了d类应用的中间件，根据远程探针探测的应用负载数量进行并发
队列的优先级决策，部署应用越多，其在同类应用内部的并发队列中优先级越高。
88.综上，本发明实施例的具体流程如下：
89.1、根据中间件对应的应用类型确定应用类型排序数据。
90.2、根据中间件对应的应用响应数据确定应用响应排序数据。
91.3、根据中间件对应的应用负载数量确定应用负载排序数据。
92.4、确定中间件对应的核心资源数据和辅助资源数据。
93.5、根据辅助资源数据和核心资源数据确定资源排序数据。
94.6、当中间件对应的应用类型为基础应用时，根据应用类型排序数据、应用响应排序数据和资源排序数据对对应的中间件进行排序；当中间件对应的应用类型为非基础应用时，根据应用类型排序数据、应用负载排序数据和资源排序数据对对应的中间件进行排序。
95.7、根据中间件的配置文件对排序后的中间件依次进行处理。
96.综上，本发明实施例的中间件管理方法采用定制的远程探针自动探测web中间件的关键配置、应用负载和系统负荷等，通过并发技术实现对多台web中间件的集中管理，并在并发集中管理中能够根据web应用的特异性和负载动态灵活调整并发管理方式。与传统的web中间件管理模式相比，本发明克服了只能对一台web中间件进行手动管理的弊端，实现了自动化和批量管理，大幅提升了web中间件管理的工作效率，节省了大量人力成本和时间成本。
97.基于同一发明构思，本发明实施例还提供了一种中间件管理装置，由于该装置解决问题的原理与中间件管理方法相似，因此该装置的实施可以参见方法的实施，重复之处不再赘述。
98.图4是本发明实施例中中间件管理装置的结构框图。如图4所示，中间件管理装置包括：
99.资源确定模块，用于确定中间件对应的核心资源数据和辅助资源数据；
100.资源排序数据模块，用于根据辅助资源数据和核心资源数据确定资源排序数据；
101.中间件处理模块，用于根据资源排序数据对对应的中间件进行排序，对排序后的中间件依次进行处理。
102.综上，本发明实施例的中间件管理装置先根据中间件对应的辅助资源数据和核心资源数据确定资源排序数据，再根据资源排序数据对对应的中间件进行排序，对排序后的中间件依次进行处理，可以对大批量中间件进行并发集中管理，提高运维管理效率，优化并发管理模式。
103.本发明实施例还提供能够实现上述实施例中的中间件管理方法中全部步骤的一种计算机设备的具体实施方式。图5是本发明实施例中计算机设备的结构框图，参见图5，所述计算机设备具体包括如下内容：
104.处理器(processor)501和存储器(memory)502。
105.所述处理器501用于调用所述存储器502中的计算机程序，所述处理器执行所述计算机程序时实现上述实施例中的中间件管理方法中的全部步骤，例如，所述处理器执行所述计算机程序时实现下述步骤：
106.确定中间件对应的核心资源数据和辅助资源数据；
107.根据辅助资源数据和核心资源数据确定资源排序数据；
108.根据资源排序数据对对应的中间件进行排序，对排序后的中间件依次进行处理。
109.综上，本发明实施例的计算机设备先根据中间件对应的辅助资源数据和核心资源数据确定资源排序数据，再根据资源排序数据对对应的中间件进行排序，对排序后的中间件依次进行处理，可以对大批量中间件进行并发集中管理，提高运维管理效率，优化并发管理模式。
110.本发明实施例还提供能够实现上述实施例中的中间件管理方法中全部步骤的一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中的中间件管理方法的全部步骤，例如，所述处理器执行所述计算机程序时实现下述步骤：
111.确定中间件对应的核心资源数据和辅助资源数据；
112.根据辅助资源数据和核心资源数据确定资源排序数据；
113.根据资源排序数据对对应的中间件进行排序，对排序后的中间件依次进行处理。
114.综上，本发明实施例的计算机可读存储介质先根据中间件对应的辅助资源数据和核心资源数据确定资源排序数据，再根据资源排序数据对对应的中间件进行排序，对排序后的中间件依次进行处理，可以对大批量中间件进行并发集中管理，提高运维管理效率，优化并发管理模式。
115.以上所述的具体实施例，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施例而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
116.本领域技术人员还可以了解到本发明实施例列出的各种说明性逻辑块(illustrative logical block)，单元，和步骤可以通过电子硬件、电脑软件，或两者的结合进行实现。为清楚展示硬件和软件的可替换性(interchangeability)，上述的各种说明性部件(illustrative components)，单元和步骤已经通用地描述了它们的功能。这样的功能是通过硬件还是软件来实现取决于特定的应用和整个系统的设计要求。本领域技术人员可以对于每种特定的应用，可以使用各种方法实现所述的功能，但这种实现不应被理解为超出本发明实施例保护的范围。
117.本发明实施例中所描述的各种说明性的逻辑块，或单元，或装置都可以通过通用处理器，数字信号处理器，专用集成电路(asic)，现场可编程门阵列或其它可编程逻辑装置，离散门或晶体管逻辑，离散硬件部件，或上述任何组合的设计来实现或操作所描述的功能。通用处理器可以为微处理器，可选地，该通用处理器也可以为任何传统的处理器、控制器、微控制器或状态机。处理器也可以通过计算装置的组合来实现，例如数字信号处理器和微处理器，多个微处理器，一个或多个微处理器联合一个数字信号处理器核，或任何其它类似的配置来实现。
118.本发明实施例中所描述的方法或算法的步骤可以直接嵌入硬件、处理器执行的软件模块、或者这两者的结合。软件模块可以存储于ram存储器、闪存、rom存储器、eprom存储器、eeprom存储器、寄存器、硬盘、可移动磁盘、cd-rom或本领域中其它任意形式的存储媒介中。示例性地，存储媒介可以与处理器连接，以使得处理器可以从存储媒介中读取信息，并可以向存储媒介存写信息。可选地，存储媒介还可以集成到处理器中。处理器和存储媒介可
以设置于asic中，asic可以设置于用户终端中。可选地，处理器和存储媒介也可以设置于用户终端中的不同的部件中。
119.在一个或多个示例性的设计中，本发明实施例所描述的上述功能可以在硬件、软件、固件或这三者的任意组合来实现。如果在软件中实现，这些功能可以存储与电脑可读的媒介上，或以一个或多个指令或代码形式传输于电脑可读的媒介上。电脑可读媒介包括电脑存储媒介和便于使得让电脑程序从一个地方转移到其它地方的通信媒介。存储媒介可以是任何通用或特殊电脑可以接入访问的可用媒体。例如，这样的电脑可读媒体可以包括但不限于ram、rom、eeprom、cd-rom或其它光盘存储、磁盘存储或其它磁性存储装置，或其它任何可以用于承载或存储以指令或数据结构和其它可被通用或特殊电脑、或通用或特殊处理器读取形式的程序代码的媒介。此外，任何连接都可以被适当地定义为电脑可读媒介，例如，如果软件是从一个网站站点、服务器或其它远程资源通过一个同轴电缆、光纤电缆、双绞线、数字用户线(dsl)或以例如红外、无线和微波等无线方式传输的也被包含在所定义的电脑可读媒介中。所述的碟片(disk)和磁盘(disc)包括压缩磁盘、镭射盘、光盘、dvd、软盘和蓝光光盘，磁盘通常以磁性复制数据，而碟片通常以激光进行光学复制数据。上述的组合也可以包含在电脑可读媒介中。