微服务系统健康度的评估方法及相关设备与流程

1.本技术的实施例涉及微服务的技术领域，尤其涉及一种微服务系统健康度的评估方法及相关设备。


背景技术：

2.在对由多个微服务组成的微服务系统的监控中，由于各个微服务对于微服务系统整体的影响不同，因此，导致的故障严重程度也不同。
3.在相关的微服务系统健康度的评估方式中，在没有综合区分考虑各个微服务对微服务系统整体的影响时，难以根据当前所运行的微服务来对整体微服务系统进行健康度的评估。
4.基于此，需要一种能够综合各个微服务不同影响，确定更加准确的健康度的方案。


技术实现要素：

5.有鉴于此，本技术的目的在于提出一种微服务系统健康度的评估方法及相关设备。
6.基于上述目的，本技术提供了微服务系统健康度的评估方法，应用于微服务系统，所述微服务系统包括多个微服务和应用程序监控工具；
7.所述方法包括：
8.通过对各个所述微服务进行分析，得到该微服务的分析信息；
9.根据所述分析信息确定该微服务发生故障时对所述微服务系统整体的影响程度；
10.根据所述影响程度将全部所述微服务分为多个级别；
11.通过衡量各个所述级别的所述微服务的比例，确定所述微服务系统自身当前的健康度。
12.进一步地，通过对各个所述微服务进行分析，得到各个所述微服务的分析信息，包括：
13.对于每个所述微服务，执行如下操作：
14.对该微服务与其他微服务之间的依赖关系进行分析，得到依赖分析结果；
15.根据获取的历史数据确定该微服务的故障频率；
16.确定该微服务所执行的功能；
17.将得到的所述依赖分析结果、所述故障频率和所述功能作为分析信息进行持久化存储。
18.进一步地，对该微服务与其他微服务之间的依赖关系进行分析，得到依赖分析结果，包括：
19.采集各个所述微服务之间执行各个任务时的工作流，根据所述工作流确定各个所述微服务之间的拓扑结构；
20.根据所述拓扑结构确定依赖该微服务的其他微服务的数量和所述其他微服务所
占用的线程数量；
21.将所述其他微服务的数量和所述线程数量进行融合，得到所述依赖分析结果。
22.进一步地，根据所述分析信息确定该微服务发生故障时对所述微服务系统整体的影响程度，包括：
23.为所述故障频率配置故障频率权重；
24.为所述依赖分析结果配置依赖权重；
25.为所述功能配置功能权重；
26.将所述故障频率、所述依赖分析结果和所述功能，按照所述频率权重、所述依赖权重和所述功能权重进行求和，得到关于该微服务的影响程度的取值。
27.进一步地，根据所述影响程度将全部所述微服务分为多个级别，包括：
28.对于每个所述微服务，执行操作：
29.响应于该微服务的影响程度的取值大于等于预设的关键性阈值，将该微服务的级别判定为关键性服务；
30.响应于该微服务的影响程度的取值小于预设的关键性阈值，将该微服务判定的级别为非关键性服务。
31.进一步地，通过衡量各个所述级别的所述微服务的比例，确定所述微服务系统自身当前的健康度，包括：
32.通过对拦截当前的各个所述微服务的请求，确定各个所述微服务的级别；
33.在当前拦截到的各个全部微服务中，响应于级别为关键性服务的微服务的比例大于等于预设的第一健康阈值，将所述微服务系统自身当前的健康度评估为第一等级；
34.响应于响应于级别为关键性服务的微服务的比例小于预设的第一健康阈值，且大于等于预设的第二健康阈值，将所述微服务系统自身当前的健康度评估为第二等级；
35.响应于响应于级别为关键性服务的微服务的比例小于预设的第二健康阈值，将所述微服务系统自身当前的健康度评估为第三等级。
36.进一步地，拦截当前的各个所述微服务的请求，包括：
37.基于设置的应用性能监控工具，利用所述应用性能监控工具的探针对指定的微服务进行全链路性能监控，以拦截该微服务的请求。
38.基于同一发明构思，本技术还提供了一种微服务系统健康度的评估装置，应用于微服务系统，所述微服务系统包括多个微服务和应用程序监控工具；
39.该装置包括：分析模块、影响程度确定模块、级别划分模块和健康度确定模块；
40.其中，分析模块，被配置为，通过对各个所述微服务进行分析，得到该微服务的分析信息；
41.影响程度确定模块，被配置为，根据所述分析信息确定该微服务发生故障时对所述微服务系统整体的影响程度；
42.级别划分模块，被配置为，根据所述影响程度将全部所述微服务分为多个级别；
43.健康度确定模块，被配置为，通过衡量各个所述级别的所述微服务的比例，确定所述微服务系统自身当前的健康度。
44.基于同一发明构思，本技术还提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如上任意一
项所述的微服务系统健康度的评估方法。
45.基于同一发明构思，本技术还提供了一种非暂态计算机可读存储介质，其中，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令用于使所述计算机执行如上述微服务系统健康度的评估方法。
46.从上面所述可以看出，本技术提供的微服务系统健康度的评估方法及相关设备，基于对微服务系统中的各个微服务进行分析，来得到每个微服务对于微服务系统整体的影程度，可以看出，对于每个微服务分别进行影响程度的判定实质上是综合考虑了各个微服务的差异，并从分析信息中来确定该差异，以具体确定各个微服的影响程度。
47.进一步地，根据各个微服务的影响程度来对其进行级别划分，并以权重的形式衡量各个微服务之间的比例，使得对健康度的评估综合考虑了不同微服务之间的影响，得到更加准确的健康度评估。
附图说明
48.为了更清楚地说明本技术或相关技术中的技术方案，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
49.图1为本技术实施例的微服务系统健康度的评估方法的流程图；
50.图2为本技术实施例的微服务系统健康度的评估装置结构示意图；
51.图3为本技术实施例的电子设备结构示意图。
具体实施方式
52.为使本技术的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本技术进一步详细说明。
53.需要说明的是，除非另外定义，本技术的实施例使用的技术术语或者科学术语应当为本技术所属领域内具有一般技能的人士所理解的通常意义。本技术的实施例中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电性的连接，不管是直接的还是间接的。
54.如背景技术部分所述，相关的微服务系统健康度的评估方法还难以满足在实际应用中对整体微服务系统的监控需要。
55.申请人在实现本技术的过程中发现，相关的微服务系统健康度的评估方法存在的主要问题在于：在对由多个微服务组成的微服务系统的监控中，由于各个微服务对于微服务系统整体的影响不同，因此，导致的故障严重程度也不同。
56.也就是说，当某个微服务，对于整提微服务系统十分重要，例如注册中心服务等，因此，当该微服务出现故障后，将影响整个微服务系统的运行，甚至直接导致微服务系统宕机，而另一些微服务，例如文件服务器等，故障后，并不会影响整体微服务系统的运行，而只
影响上传和下载的功能。
57.可以看出，在没有综合区分考虑各个微服务对微服务系统整体的影响时，难以根据当前所运行的微服务来对整体微服务系统进行健康度的评估。
58.基于此，本技术中的一个或多个实施例提供了微服务系统健康度的评估方法，基于各个微服务个体的不同来整体微服务系统的健康度进行评估。
59.以下结合附图详细说明本技术的实施例。
60.参考图1，本技术一个实施例的微服务系统健康度的评估方法，应用于微服务系统，并包括以下步骤：
61.步骤s101、通过对各个所述微服务进行分析，得到该微服务的分析信息。
62.在本技术的实施例中，基于现有的微服务系统，其中包括有：多个微服务和应用程序监控工具。
63.作为一个具体的示例，该微服务系统可以建立在skywalking框架上，其中，skywalking为一个开源的系统框架，并在逻辑上可以具备4个部分：探针、平台后端、存储对象和用户界面。
64.进一步地，该微服务系统的运行环境可以是java运行环境，并且，在一些实施例中，还可以基于java虚拟机来运行。
65.在本实施例中，该微服务系统中的微服务可以是例如，提供注册中心服务的服务注册与发现组件、提供处理浏览器等网页客户端请求服务的网站服务器、提供上传和下载服务的文件服务器和提供网络互联服务的网关等。
66.在本实施例中，可以以插件的形式，并通过应用性能监控工具的加载，来在java虚拟机中运行。
67.基于此，可以在skywalking框架的基础上，来采集全部插件，也即全部微服务的相关信息，并进行分析。
68.进一步地，通过对各个微服务进行分析，可以得到关于该微服务的依赖分析结果、故障频率和功能。
69.具体地，对各个微服务的依赖关系的分析过程包括：
70.在本实施例中，基于现有的微服务系统，对其中的每个微服务，确定该微服务执行各个任务时的工作流。
71.其中，每个工作流表示了该微服务在执行任务时与其他微服务之间前后组织在一起的逻辑规则。
72.进一步地，可以将得到的工作流导出为一个json(对象简谱)文件，其中，得到的该json文件，具体描述了该工作流的拓扑结构，可以看出，在该工作流中，可以具体确定各个微服务在执行任务时，互相之间在执行上的调用逻辑和交互逻辑等。
73.进一步地，根据该拓扑结构，可以确定在基于该任务下时，该微服务与其他微服务之间的依赖关系，也就是说，当某个微服务执行其任务时，必须依靠其他微服务所提供的服务才可以完成该微服务所执行的任务。
74.其中，基于上述的拓扑结构，对于一个指定的微服务，可以具体确定依赖该微服务的其他微服务。
75.进一步地，可以具体确定出的所述依赖该微服务的其他微服务的数量，以及，其他
微服务所占用的线程数量。
76.可见，从依赖该微服务的其他微服务的数量，可以得知该微服务在发生故障时，所影响的微服务系统的数量。
77.进一步地，从其他微服务所占用的线程数量，可以看出该微服务在发生故障时，对于微服务系统整体所产生的影响。
78.可以看出，上述所影响的微服务的数量，在本实施例中，将其视为体现出了各个微服务的局部影响；所影响的微服务系统的线程数量，在本实施例中，将其视为体现出了微服务系统的整体影响。
79.基于此，还需要进一步将局部影响和整体影响进一步地进行融合，并将融合后的结果作为依赖分析结果。
80.在本实施例中，可以通过设置局部影响因子权重和整体影响因子权重的方式，来对所影响的微服务的数量和所影响的微服务系统的线程数量来进行融合。
81.具体地，可以以如下所示的公式来计算依赖分析结果的取值：
[0082][0083]
其中，i表示计算出的依赖分析结果的取值，i1表示所影响的微服务的数量，i2表示所影响的线程的数量，表示局部影响因子权重，φ表示整体影响因子权重。
[0084]
在本实施例中，局部影响因子权重和整体影响因子权重可以根据预先获取的历史数据中两者对整个微服务系统的影响来确定，也可以根据具体的实际情况进行设置。
[0085]
在本实施例中，如上所述，对各个微服务进行的分析还包括确定该微服务的故障频率。
[0086]
具体地，获取该微服务在一段历史时间内执行各项任务时的历史数据，通过该历史数据可以得到该微服务的在该历史时间内的故障次数，并进一步得到该微服务的故障频率。
[0087]
在本实施例中，在本实施例中，如上所述，对各个微服务进行的分析还包括确定各个微服务所执行的功能。
[0088]
具体地，如上所述，各个微服务可以以插件的形式设置在skywalking框架中，因此，可以基于应用性能监控工具的加载，通过各个插件的api(应用程序接口)来确定对应微服务所具体执行的功能。
[0089]
进一步地，还需要对其所执行的功能进行重要程度的量化，以进行下述步骤的计算。
[0090]
在本实施例中，可以根据微服务系统所运行的具体任务来确定，或者根据该微服务系统的整体框架来确定，或者根据其他具体情况确定。
[0091]
例如，当该微服务所执行的功能为服务注册与发现时，可以认为该微服务所执行的功能属于重要功能，因此可以将其重要程度设置为1，当该微服务所执行的功能为提供上传和下载服务时，则可以认为该微服务所执行功能不属于重要功能，因此可以将其重要程度设置为0.1。
[0092]
进一步地，对于每个微服务，可以将上述确定的依赖分析结果、故障频率和所执行的功能共同作为该微服务的分析信息。
[0093]
进一步地，将该分析信息持久化存储到对应的内存对象。
[0094]
步骤s102、根据所述分析信息确定该微服务发生故障时对所述微服务系统整体的影响程度。
[0095]
在本技术的实施例中，基于上述对各个微服务分析得到的依赖分析结果、故障频率和所执行的功能，可以进一步来评估该微服务对整体微服务系统的影响程度。
[0096]
具体地，对于该微服务，可以分别为依赖分析结果、故障频率和功能配置对应的权重，通过各个权重来衡量该微服务从上述三个方面对整体微服务系统的影响程度。
[0097]
具体地，为依赖分析结果配置依赖权重，为故障频率配置故障频率权重，并为功能配置功能权重。
[0098]
进一步地，采取如下所示的加权求和的方式，来计算该微服务对整体微服务系统的影响程度：
[0099]
f＝i
×
α+j
×
β+k
×
γ
[0100]
其中，f表示影响程度的取值，j表示故障频率，k表示该微服务所执行的功能在重要程度上的取值。
[0101]
步骤s103、根据所述影响程度将全部所述微服务分为多个级别。
[0102]
在本技术的实施例中，对于各个微服务，基于上述所计算出的重要程度的取值，可以将该微服务框架中所设置的各个微服务划分为多个级别，以从关键性上区分出各个微服务。
[0103]
具体地，可以为各个微服务设置关键性阈值，并利用该关键性阈值与各个微服务的重要程度取值进行比较，来将全部的微服务划分为两个级别。
[0104]
进一步地，当任意微服务的重要程度的取值大于等于上述的关键性阈值时，则可以将该微服务判定为关键性服务。
[0105]
进一步地，当任意微服务的重要程度的取值小于上述的关键性阈值时，则可以将该微服务判定为非关键性服务。
[0106]
可以看出，判定为关键性服务的微服务是在故障时对整体微服务系统影响较大的微服务，判定为非关键性服务的微服务是在故障时对整体微服务系统影响较小的微服务。
[0107]
在一些其他实施例中，也可以通过设置多个阈值来对各个微服务进行划分，以得到更加细粒度的级别划分。
[0108]
步骤s104、通过衡量各个所述级别的所述微服务的比例，确定所述微服务系统自身当前的健康度。
[0109]
在本技术的实施例中，基于上述得到的各个微服务的级别，可以对整体微服务系统进行实时的健康度评估。
[0110]
具体地，微服务框架中的应用性能监控工具可以通过探针来对其中的各个微服务进行监控，具体来说，对于任意微服务发送的任务的请求，应用性能监控工具在探针拦截到当前的该请求后，可以通过该请求来确定发送该请求的微服务。
[0111]
进一步地，根据上述步骤中所确定的该微服务的级别，可以确定当前该微服务的级别。
[0112]
在本实施例中，微服务系统在任意时刻所运行的微服务可以是1个也可以是多个，因此，当前所拦截的微服务的任务请求也可以是多个，也就是说，可以确定当前所运行的多个微服务的级别。
[0113]
进一步地，根据获取的当前所运行的全部微服务的级别，可以通过确定其中关键性服务与非关键性服务的比例来确定该整体微服务系统当前的健康度。
[0114]
进一步地，可以为关键性服务与非关键性服务的比例设置相应的阈值，例如，可以将关键性服务占比为60％设置为第一健康阈值，将关键性服务占比为90％设置为第二健康阈值。
[0115]
进一步地，基于上述设置的第一健康阈值和第二健康阈值，可以对该微服务系统当前的健康度进行评估。
[0116]
具体地，可以按照上述的两个健康阈值将微服务系统的健康度评估为三个不同的等级。
[0117]
其中，当级别为关键性服务的微服务的比例小于预设的第一健康阈值时，则可以将该微服务系统其自身当前的健康度评估为第一等级。
[0118]
当级别为关键性服务的微服务的比例大于等于预设的第一健康阈值时，且小于等于预设的第二健康阈值，则可以将微服务系统其自身当前的健康度评估为第二等级。
[0119]
当级别为关键性服务的微服务的比例大于预设的第二健康阈值时，则可以将微服务系统其自身当前的健康度评估为第三等级。
[0120]
可以看出，若当前属于关键性服务级别的微服务更多时，其整体微服务系统在遇到微服务故障时所受影响更大，风险更高；而当属于非关键性服务级别的微服务更多时，其整体微服务系统在遇到微服务故障时所受影响更小，风险更低。
[0121]
在一些实施例中，基于关键性服务的占比，还可以分别为不同的健康度评估出不同的分数，并显示在skywalking框架的用户界面中，。
[0122]
具体地，可以直接将关键性服务的占比作为健康度的评估分数，并在显示该分数时，根据不同的健康度等级，显示出不同颜色。
[0123]
其中，当关键性服务的占比小于60％时，可以将其分数显示为蓝色；当关键性服务的占比在60％至90％的区间内时，可以将其分数显示为橙色；当关键性服务的占比大于90％时，可以将其分数显示为红色，以令使用该微服务系统的用户可以直观地实时获知微服务系统当前的健康度。
[0124]
可见，本技术的实施例的微服务系统健康度的评估方法，基于对微服务系统中的各个微服务进行分析，来得到每个微服务对于微服务系统整体的影程度，可以看出，对于每个微服务分别进行影响程度的判定实质上是综合考虑了各个微服务的差异，并从分析信息中来确定该差异，以具体确定各个微服的影响程度。
[0125]
进一步地，根据各个微服务的影响程度来对其进行级别划分，并以权重的形式衡量各个微服务之间的比例，使得对健康度的评估综合考虑了不同微服务之间的影响，得到更加准确的健康度评估。
[0126]
需要说明的是，本技术的实施例的方法可以由单个设备执行，例如一台计算机或服务器等。本实施例的方法也可以应用于分布式场景下，由多台设备相互配合来完成。在这种分布式场景的情况下，这多台设备中的一台设备可以只执行本技术的实施例的方法中的某一个或多个步骤，这多台设备相互之间会进行交互以完成所述的方法。
[0127]
需要说明的是，上述对本技术的一些实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于上述
实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
[0128]
基于同一发明构思，与上述任意实施例方法相对应的，本技术的实施例还提供了一种微服务系统健康度的评估装置。
[0129]
参考图2，所述微服务系统健康度的评估装置，应用于微服务系统，所述微服务系统包括多个微服务和应用程序监控工具；该装置包括：分析模块201、影响程度确定模块202、级别划分模块203和健康度确定模块204；
[0130]
其中，分析模块201，被配置为，通过对各个所述微服务进行分析，得到该微服务的分析信息；
[0131]
影响程度确定模块202，被配置为，根据所述分析信息确定该微服务发生故障时对所述微服务系统整体的影响程度；
[0132]
级别划分模块203，被配置为，根据所述影响程度将全部所述微服务分为多个级别；
[0133]
健康度确定模块204，被配置为，通过衡量各个所述级别的所述微服务的比例，确定所述微服务系统自身当前的健康度。
[0134]
为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本技术的实施例时可以把各模块的功能在同一个或多个软件和/或硬件中实现。
[0135]
上述实施例的装置用于实现前述任一实施例中相应的微服务系统健康度的评估方法，并且具有相应的方法实施例的有益效果，在此不再赘述。
[0136]
基于同一发明构思，与上述任意实施例方法相对应的，本技术的实施例还提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如上任意一实施例所述的微服务系统健康度的评估方法。
[0137]
图3示出了本实施例所提供的一种更为具体的电子设备硬件结构示意图，该设备可以包括：处理器1010、存储器1020、输入/输出接口1030、通信接口1040和总线1050。其中处理器1010、存储器1020、输入/输出接口1030和通信接口1040通过总线1050实现彼此之间在设备内部的通信连接。
[0138]
处理器1010可以采用通用的cpu(central processing unit，中央处理器)、微处理器、应用专用集成电路(application specific integrated circuit，asic)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本技术实施例所提供的技术方案。
[0139]
存储器1020可以采用rom(read only memory，只读存储器)、ram(random access memory，随机存取存储器)、静态存储设备、动态存储设备等形式实现。存储器1020可以存储操作系统和其他应用程序，在通过软件或者固件来实现本技术实施例所提供的技术方案时，相关的程序代码保存在存储器1020中，并由处理器1010来调用执行。
[0140]
输入/输出接口1030用于连接输入/输出模块，以实现信息输入及输出。输入/输出模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。
[0141]
通信接口1040用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信
交互。其中通信模块可以通过有线方式(例如usb、网线等)实现通信，也可以通过无线方式(例如移动网络、wifi、蓝牙等)实现通信。
[0142]
总线1050包括一通路，在设备的各个组件(例如处理器1010、存储器1020、输入/输出接口1030和通信接口1040)之间传输信息。
[0143]
需要说明的是，尽管上述设备仅示出了处理器1010、存储器1020、输入/输出接口1030、通信接口1040以及总线1050，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本技术实施例方案所必需的组件，而不必包含图中所示的全部组件。
[0144]
上述实施例的装置用于实现前述任一实施例中相应的微服务系统健康度的评估方法，并且具有相应的方法实施例的有益效果，在此不再赘述。
[0145]
基于同一发明构思，与上述任意实施例方法相对应的，本技术还提供了一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令用于使所述计算机执行如上任一实施例所述的微服务系统健康度的评估方法。
[0146]
本实施例的计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。
[0147]
上述实施例的存储介质存储的计算机指令用于使所述计算机执行如上任一实施例所述的微服务系统健康度的评估方法，并且具有相应的方法实施例的有益效果，在此不再赘述。
[0148]
所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非旨在暗示本技术的范围(包括权利要求)被限于这些例子；在本技术的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本技术的实施例的不同方面的许多其它变化，为了简明它们没有在细节中提供。
[0149]
另外，为简化说明和讨论，并且为了不会使本技术的实施例难以理解，在所提供的附图中可以示出或可以不示出与集成电路(ic)芯片和其它部件的公知的电源/接地连接。此外，可以以框图的形式示出装置，以便避免使本技术的实施例难以理解，并且这也考虑了以下事实，即关于这些框图装置的实施方式的细节是高度取决于将要实施本技术的实施例的平台的(即，这些细节应当完全处于本领域技术人员的理解范围内)。在阐述了具体细节(例如，电路)以描述本技术的示例性实施例的情况下，对本领域技术人员来说显而易见的是，可以在没有这些具体细节的情况下或者这些具体细节有变化的情况下实施本技术的实施例。因此，这些描述应被认为是说明性的而不是限制性的。
[0150]
尽管已经结合了本技术的具体实施例对本技术进行了描述，但是根据前面的描述，这些实施例的很多替换、修改和变型对本领域普通技术人员来说将是显而易见的。例如，其它存储器架构(例如，动态ram(dram))可以使用所讨论的实施例。
[0151]
本技术的实施例旨在涵盖落入所附权利要求的宽泛范围之内的所有这样的替换、
修改和变型。因此，凡在本技术的实施例的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本技术的保护范围之内。