CN105872028A - 服务端、客户端及访问策略管理方法 - Google Patents

服务端、客户端及访问策略管理方法 Download PDF

Info

Publication number
CN105872028A
CN105872028A CN201610179767.4A CN201610179767A CN105872028A CN 105872028 A CN105872028 A CN 105872028A CN 201610179767 A CN201610179767 A CN 201610179767A CN 105872028 A CN105872028 A CN 105872028A
Authority
CN
China
Prior art keywords
client
access
access strategy
strategy
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201610179767.4A
Other languages
English (en)
Other versions
CN105872028B (zh
Inventor
林伟
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nubia Technology Co Ltd
Original Assignee
Nubia Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nubia Technology Co Ltd filed Critical Nubia Technology Co Ltd
Priority to CN201610179767.4A priority Critical patent/CN105872028B/zh
Publication of CN105872028A publication Critical patent/CN105872028A/zh
Application granted granted Critical
Publication of CN105872028B publication Critical patent/CN105872028B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/55Push-based network services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004Server selection for load balancing

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明公开了一种服务端、客户端及访问策略管理方法,在客户端访问服务端的路由服务器时,向该客户端返回访问策略,客户端在对服务端后续的访问过程中,可以根据该访问策略对服务端进行服务端预期的访问。相对现有技术中只能根据开发者预埋在其本地的访问策略对服务端进行访问的方式,本发明中提供的访问策略管理方法不仅能让客户端获取新的访问策略,而且服务端也可以通过访问策略让客户端进行其预期的访问,对客户端的访问情况进行管理,有利于资源的优化配置。另一方面,在现有技术中,当服务端对客户端的访问方式进行更改时,客户端必须升级,但是根据本发明提供的访问策略管理方法,客户端不需要进行升级,这提升了用户体验。

Description

服务端、客户端及访问策略管理方法
技术领域
本发明涉及通信领域,尤其涉及服务端、客户端及访问策略管理方法。
背景技术
为了提高用户体验,现在很多App(Appl ication,应用程序)都有消息推送服务。消息推送就是"web广播",其通过一定的技术标准或协议,在互联网上定期传送用户需要的信息来减少信息过载。消息推送机制有这样两个优点:一方面,开发者能够通过消息推送,向用户推送用户感兴趣的相关信息,这可以有效地提升用户的活跃度,增大其的APP的使用率。另一方面,消息推送根据用户的兴趣来搜索、过滤信息,并将这些信息定期推送给用户,帮助用户高效率地发掘有价值的信息,减少了用户用于网络上搜索的时间,提高了用户体验。
消息推送机制需要在服务端和客户端之间建立一条稳定、可靠的长连接,以保证服务端能随时将推送消息传递到客户端,即保证消息发送与接收的实时性。但在实际情况中,一般一个APP的客户端数量会达到几十上百万之多,如果一台服务器需要随时与这么多的客户端保持长连接,那服务器要承受的压力就不言而喻。
为了解决上述问题,系统一般会在服务端设置多个服务器,让这多个服务器共同实现消息推送的功能,这些服务器是客户端需要访问的目的服务器。服务端前端设置有用于提供接口给客户端访问的路由服务器,客户端可以从路由服务器处获取可访问的目标服务器的路由信息表,然后再从路由信息表中选择一个路由地址,进行真正的数据访问。针对客户端的访问策略,现有技术中是由开发者在开发APP时就制定完成的,开发者将客户端访问服务端的策略预埋在客户端当中,让客户端根据这预先设定好的访问策略在固定的时间进行路由接口访问。也就是说,现有技术中,客户端访问服务端的策略是单一不可更改的,这样的方式会带来这样几个问题:
首先,现有技术中,客户端始终按照预先设定的单一访问策略对服务端进行访问,没有兼顾到服务器面向大量客户端的特点,可能会造成服务器压力过大,例如,预先设定的访问策略是整点访问服务端,那么每当到了整点时,服务端就必须承受来自数量巨大的客户端的访问压力,这样可能会造成服务器崩溃。而在其他时间点,服务器处于“闲时”状态,这时候却几乎没有访问的客户端,因此,单一的访问策略不利于资源的优化配置。
其次,若是服务端针对访问策略进行了调整,例如,由于服务端发现某一时刻的压力过大,需要将该时刻的压力分散到其他时刻去,这时,由于访问策略发生了改变,客户端就必须要升级才能保证消息推送机制的正常运行。也就是说,按照现有技术中单一访问策略的访问方式,服务端的策略调整必定会带来客户端的升级,这降低了用户的体验。
发明内容
本发明的主要目的在于提出一种访问策略管理方法,旨在解决现有技术中,客户端无法获得新的访问策略,只能根据开发者预埋在其本地的访问策略对服务端进行访问的技术问题。
为实现上述目的,本发明提供的一种服务端,包括:
策略生成模块,用于生成访问策略,所述访问策略用于指示客户端在后续过程中如何对所述服务端的各目的服务器及路由服务器进行访问,所述目的服务器为所述客户端实际需要访问的服务器;
策略返回模块,用于向访问所述路由服务器的客户端返回所述访问策略。
进一步地,所述策略生成模块包括:
实时生成模块,用于监测所述服务端当前的访问量,并根据所述当前的访问量为所述客户端生成实时访问策略;
所述策略返回模块包括:
第一返回模块,用于将为所述客户端实时生成访问策略返回给所述客户端。
进一步地,所述策略生成模块包括:
预先生成模块,用于根据预先设定至少一种访问量情况,为各所述访问量情况生成对应的预先访问策略;
所述策略返回模块包括:
第二返回模块,用于监测所述服务端当前的访问量,并为所述客户端返回与当前的访问量匹配的所述预先访问策略。
进一步地,路由访问模块,用于访问服务端的路由服务器;
策略获取模块,用于接收所述路由服务器返回的访问策略并将其更新至本地,所述访问策略用于指示客户端在后续过程中如何对所述服务端的各目的服务器及所述路由服务器进行访问,所述目的服务器为所述客户端实际需要访问的服务器。
进一步地,策略判断模块,用于判断本次获取到的所述访问策略与上次获取到的访问策略是否相同;
第一执行模块,用于当本次获取到的所述访问策略与之前执行的访问策略相同时,则跳过所述访问策略中已执行过的部分,继续执行未执行的部分;
第二执行模块,用于当本次获取到的所述访问策略与之前执行的访问策略不同时,则重新执行本次获取到的所述访问策略。
此外,为实现上述目的,本发明还提出一种访问策略管理方法,包括:
生成访问策略,所述访问策略用于指示客户端在后续过程中如何对所述服务端的各目的服务器及路由服务器进行访问,所述目的服务器为所述客户端实际需要访问的服务器;
向访问所述路由服务器的客户端返回所述访问策略。
进一步地,所述生成访问策略包括:
监测所述服务端当前的访问量,并根据所述当前的访问量为所述客户端生成实时访问策略;
所述向访问所述路由服务器的客户端返回所述访问策略包括:
将所述实时生成访问策略返回给所述客户端。
进一步地,所述生成访问策略包括:
根据预先设定至少一种访问量情况,为各所述访问量情况生成对应的预先访问策略;
所述向访问所述路由服务器的客户端返回所述访问策略包括:
监测所述服务端当前的访问量,并为所述客户端返回与当前的访问量匹配的所述预先访问策略。
进一步地,访问服务端的路由服务器;
接收所述路由服务器返回的访问策略并将其更新至本地,所述访问策略用于指示客户端在后续过程中如何对所述服务端的各目的服务器及所述路由服务器进行访问,所述目的服务器为所述客户端实际需要访问的服务器。
进一步地,判断本次获取到的所述访问策略与之前执行的访问策略是否相同;
当本次获取到的所述访问策略与之前执行的访问策略相同时,则跳过所述访问策略中已执行过的部分,继续执行未执行的部分;
当本次获取到的所述访问策略与上一次获取到的访问策略不同时,则重新执行本次获取到的所述访问策略。
本发明提出的访问策略管理方法在客户端访问服务端的路由服务器时,服务端通过路由服务器为该客户端返回其生成的访问策略,客户端通过这种方式得到了非开发者预埋的访问策略,在对服务端后续的访问过程中,可以根据获取的访问策略对服务端进行服务端预期的访问。相对现有技术中客户端只能根据开发者预埋在其本地的访问策略对服务端进行访问的方式,本发明中提供的访问策略管理方法不仅能让客户端获取到新的访问策略,而且服务端也可以通过返回的访问策略让客户端进行其预期的访问,对客户端的访问情况进行管理,有利于资源的优化配置。另一方面,在现有技术中,当服务端对客户端的访问方式进行更改时,客户端必须升级,但是根据本发明提供的访问策略管理方法,客户端不需要进行升级,这提升了用户体验。
附图说明
图1为实现本发明各个实施例的移动终端一个可选的的硬件结构示意图;
图2为本发明第一实施例中访问策略管理方法的流程图;
图3为本发明第一实施例中预先生成访问策略的流程图;
图4为本发明第一实施例中返回预先生成策略的流程图;
图5为本发明第二实施例中实时生成访问策略的流程图;
图6为本发明第三实施例中访问策略管理方法的流程图;
图7为本发明第三实施例中判断访问策略的流程图;
图8为本发明第四实施例中客户端对目的服务器的访问方法流程图;
图9为本发明第五实施例中提供的服务端示意图;
图10为图9中策略生成模块的一种示意图;
图11为图9中策略返回模块的一种示意图;
图12为图9中策略生成模块的另一种示意图;
图13为图9中策略返回模块的另一种示意图;
图14为本发明第七实施例中提供的客户端示意图;
图15为本发明第七实施例中提供的系统架构图。
本发明目的的实现、功能特点及优点将结合实施例,参照附图做进一步说明。
具体实施方式
应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。
现在将参考附图描述实现本发明各个实施例的移动终端。在后续的描述中,使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明的说明,其本身并没有特定的意义。因此,"模块"与"部件"可以混合地使用。
移动终端可以以各种形式来实施。例如,本发明中描述的终端可以包括诸如移动电话、智能电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、导航装置等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。下面,假设终端是移动终端。然而,本领域技术人员将理解的是,除了特别用于移动目的的元件之外,根据本发明的实施方式的构造也能够应用于固定类型的终端。
图1为实现本发明各个实施例的移动终端一个可选的硬件结构示意图。
移动终端100可以包括无线通信单元110、存储器120、电源单元130和控制器140等等。图1示出了具有各种组件的移动终端,但是应理解的是,并不要求实施所有示出的组件。可以替代地实施更多或更少的组件。将在下面详细描述移动终端的元件。
无线通信单元110通常包括一个或多个组件,其允许移动终端100与无线通信系统或网络之间的无线电通信。例如,无线通信单元可以包括广播接收模块111、移动通信模块112、无线互联网模块113、短程通信模块114和位置信息模块115中的至少一个。
广播接收模块111经由广播信道从外部广播管理服务器接收广播信号和/或广播相关信息。广播信道可以包括卫星信道和/或地面信道。广播管理服务器可以是生成并发送广播信号和/或广播相关信息的服务器或者接收之前生成的广播信号和/或广播相关信息并且将其发送给终端的服务器。广播信号可以包括TV广播信号、无线电广播信号、数据广播信号等等。而且,广播信号可以进一步包括与TV或无线电广播信号组合的广播信号。广播相关信息也可以经由移动通信网络提供,并且在该情况下,广播相关信息可以由移动通信模块112来接收。广播信号可以以各种形式存在,例如,其可以以数字多媒体广播(DMB)的电子节目指南(EPG)、数字视频广播手持(DVB-H)的电子服务指南(ESG)等等的形式而存在。广播接收模块111可以通过使用各种类型的广播系统接收信号广播。特别地,广播接收模块111可以通过使用诸如多媒体广播-地面(DMB-T)、数字多媒体广播-卫星(DMB-S)、数字视频广播-手持(DVB-H),前向链路媒体(MediaFLO@)的数据广播系统、地面数字广播综合服务(ISDB-T)等等的数字广播系统接收数字广播。广播接收模块111可以被构造为适合提供广播信号的各种广播系统以及上述数字广播系统。经由广播接收模块111接收的广播信号和/或广播相关信息可以存储在存储器120(或者其它类型的存储介质)中。
移动通信模块112将无线电信号发送到基站(例如,接入点、节点B等等)、外部终端以及服务器中的至少一个和/或从其接收无线电信号。这样的无线电信号可以包括语音通话信号、视频通话信号、或者根据文本和/或多媒体消息发送和/或接收的各种类型的数据。
无线互联网模块113支持移动终端的无线互联网接入。该模块可以内部或外部地耦接到终端。该模块所涉及的无线互联网接入技术可以包括WLAN(无线LAN)(Wi-Fi)、Wibro(无线宽带)、Wimax(全球微波互联接入)、HSDPA(高速下行链路分组接入)等等。无线互联网模块113还用于接入无线互联网后,访问服务端的路由服务器。
短程通信模块114是用于支持短程通信的模块。短程通信技术的一些示例包括蓝牙TM、射频识别(RFID)、红外数据协会(IrDA)、超宽带(UWB)、紫蜂TM等等。
位置信息模块115是用于检查或获取移动终端的位置信息的模块。位置信息模块的典型示例是GPS(全球定位系统)。根据当前的技术,GPS模块115计算来自三个或更多卫星的距离信息和准确的时间信息并且对于计算的信息应用三角测量法,从而根据经度、纬度和高度准确地计算三维当前位置信息。当前,用于计算位置和时间信息的方法使用三颗卫星并且通过使用另外的一颗卫星校正计算出的位置和时间信息的误差。此外,GPS模块115能够通过实时地连续计算当前位置信息来计算速度信息。
存储器120可以存储由控制器140执行的处理和控制操作的软件程序等等,或者可以暂时地存储己经输出或将要输出的数据(例如,电话簿、消息、静态图像、视频等等)。而且,存储器120可以存储关于当触摸施加到触摸屏时输出的各种方式的振动和音频信号的数据。
存储器120可以包括至少一种类型的存储介质,所述存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如,SD或DX存储器等等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等等。而且,移动终端100可以与通过网络连接执行存储器120的存储功能的网络存储装置协作。
控制器140通常控制移动终端的总体操作。例如,控制器140执行与语音通话、数据通信、视频通话等等相关的控制和处理。控制器140可以执行模式识别处理,以将在触摸屏上执行的手写输入或者图片绘制输入识别为字符或图像。在本发明实施例中,控制器140包括策略获取模块、策略判断模块,策略获取模块用于接收路由服务器返回的访问策略并将其更新至本地,访问策略用于指示客户端在后续过程中如何对服务端的各目的服务器及路由服务器进行访问,目的服务器为所述客户端实际需要访问的服务器。策略判断模块,用于判断本次获取到的访问策略与上次获取到的访问策略是否相同。
电源单元130在控制器140的控制下接收外部电力或内部电力并且提供操作各元件和组件所需的适当的电力。
这里描述的各种实施方式可以以使用例如计算机软件、硬件或其任何组合的计算机可读介质来实施。对于硬件实施,这里描述的实施方式可以通过使用特定用途集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理装置(DSPD)、可编程逻辑装置(PLD)、现场可编程门阵列(FPGA)、处理器、控制器、微控制器、微处理器、被设计为执行这里描述的功能的电子单元中的至少一种来实施,在一些情况下,这样的实施方式可以在控制器140中实施。对于软件实施,诸如过程或功能的实施方式可以与允许执行至少一种功能或操作的单独的软件模块来实施。软件代码可以由以任何适当的编程语言编写的软件应用程序(或程序)来实施,软件代码可以存储在存储器120中并且由控制器140执行。
至此,己经按照其功能描述了移动终端。下面,为了简要起见,将描述诸如折叠型、直板型、摆动型、滑动型移动终端等等的各种类型的移动终端中的滑动型移动终端作为示例。因此,本发明能够应用于任何类型的移动终端,并且不限于滑动型移动终端。
基于上述移动终端硬件结构,提出本发明方法各个实施例。
本发明第一实施例提出一种访问策略管理方法,该访问策略管理方法的主要构思是:在客户端访问路由服务器时,服务端通过路由服务器为该客户端返回其生成的访问策略,让客户端通过这种方式得到非开发者预埋的访问策略,在对服务端后续的访问过程中,客户端可以根据获取的访问策略对服务端进行服务端预期的访问。实现这一构思,需要客户端与服务端都做出相应的改进,下面,先对实现这一构思时服务端执行的流程进行阐述,请参考图2:
S201、服务端生成访问策略。
访问策略实质上是针对客户端访问服务端的一种指示,一般规定了客户端在何时对服务端进行何种访问。这里需要说明的是,在本实施例中,服务端包括路由服务器和至少一个目的服务器,这些目的服务器是客户端真正想要访问的服务器,也正是这些目的服务器需要与客户端建立连接,为用户推送消息。路由服务器设置在服务端前端,为客户端提供访问接口给的路由服务器,客户端可以从路由服务器处获取可访问的目的服务器的路由信息表,并从路由信息表中选择一个路由地址,对目的服务器进行真正的数据访问。也就是说,路由服务器可以起到对访问的客户端进行分流。在第一实施例中,访问策略中指示了客户端如何访问目的服务器、如何访问路由服务器。
在现有技术当中,当开发应用程序(APP)时,考虑到在运营过程中需要向客户端推送用户感兴趣的消息,提升用户活跃度,开发者会事先设定一种访问策略,并将该访问策略预埋在客户端中。当用户下载安装客户端后,客户端根据其携带的访问策略对服务端进行访问,应当明白的是,客户端这时候进行的访问是根据开发者的意愿进行的,这几乎没有考虑服务端接受访问的实时情况。因此,让客户端根据预埋的访问策略访问服务端这一机制存在很多缺陷。
在本实施例提供的访问策略管理方法中,服务端能够在运营过程中生成访问策略,而非像现有技术一样在开发阶段生成访问策略。在本实施例中,提供一种预先生成访问策略的方式,即服务端在客户端访问之前,事先根据访问的客户端的数量将访问情况划分为N个等级,这里N大于等于1,即设定至少一种访问情况,并根据每种情况中访问量的多少,为每种访问量情况生成与之对应的访问策略。请进一步结合图3:
S301、预先设定访问情况。
例如,设定当访问服务端的客户端的数量小于50万时为A型访问量情况,50万到100万时为B型访问量情况,访问量超过100则进入C型访问量情况。
S302、针对预先设定访问量情况生成与之对应的访问策略。
由于A型访问量情况中服务端承受的压力还不算大,所以,针对这种情况,生成的A类访问策略设定客户端可以每1小时对目的服务器进行一次轮询访问、每两个小时访问一次路由服务器获取新的访问策略及路由信息表。针对B型访问量情况,B类访问策略中要求客户端可以每3小时对目的服务器进行一次轮询访问、每5个小时访问一次路由服务器。而对于C型访问量情况,服务端必须要进一步抑制客户端访问的频率,所以,将C型访问策略设置为每6个小时访问一次目的服务器,每24小时访问一次路由服务器。
S202、向访问路由服务器的客户端返回访问策略。
针对预先生成访问策略的方式,在向客户端返回访问策略时,需要考虑当前的访问量情况,为客户端返回与当前情况相对应的访问策略,这里请进一步参考图4:
S401、监测所述服务端当前的访问量;
S402、为客户端返回与当前的访问量匹配的预先访问策略。
例如服务端检测到当前来访问的客户端的数量为77万,这属于B型访问情况,因此,为客户端返回的访问策略也应该是B类访问策略,要求该客户端在后续的过程中,每3小时对目的服务器进行一次轮询访问、每5个小时访问一次路由服务器,以获取新的访问策略以及新的路由信息表。
在本发明的第二实施例中,依然从服务端的角度对本发明提供的访问策略管理方法进行说明。
与第一实施例不同的是,在本实施例中生成访问策略的方式由预先生成的方式变更为实时生成,相应的返回访问策略的时候也有所不同,请参考图5,图5是第二实施例中提供的生成访问策略的流程图:
S501、监测服务端当前的访问量;
S502、根据当前的访问量为客户端生成实时访问策略。
本领域技术人员应该很清楚,这种实时生成访问策略的方式相当于在为每一个客户端“定制”访问策略,因为每一个客户端访问路由服务器时,服务器接受访问的情况都是不同的,可能上一时刻服务端接受30万客户端的访问,而在当前时刻,访问的客户端又变成了30.5万,这种变化在预先生成访问策略的方式中是不予考虑的,但在这种实时生成访问策略的方式中,却会导致上一时刻来访的客户端和当前来访的客户端获得的访问策略不同。举个例子,这就相当于人们买衣服一样,一般厂家生产衣服的时候,只是粗略考虑人的身高、胖瘦程度,生成大、中、小等几种固定类型的衣服。顾客选购衣服时只能将自己的情况划分到其中的某一个类型中去,然后选择其中一个类型的衣服。但定制衣服就不一样了,定制的衣服是根据特定顾客的身高、胖瘦程度甚至是身体的线条等生产出来的,这件衣服会更加满足该特定顾客的需求,提升其满意度,但从另一方面来说,这也增大了生产衣服的压力。回到本实施例中,一方面,实时生成访问策略的方式考虑了服务器每一时刻承受的压力的大小,从而能够更加精确的控制客户端访问服务端的频率,但这种“定制”访问策略的方式对服务端的要求也会更高。而预先生成访问策略的方式虽然不能兼顾每一时刻服务端的访问量情况,但是针对生成策略这一过程来说,这种方式会更加方便。
在实时生成访问策略后,服务端只需要将这一访问策略通过路由服务器返回给客户端即可,不需要再次监测服务端当前的访问量。
本发明还提供第三实施例,在该实施例中,将从客户端侧对访问策略管理方法进行说明,如图6所示:
S601、访问服务端的路由服务器。
客户端访问路由服务器的方式可以与现有技术一样,都是为了获取路由信息表,从而与目的服务器建立连接,获得从服务端发送的推送消息。
S602、接收路由服务器返回的访问策略并将其更新至本地。
可以理解的是,这里客户端接收的访问策略可能是根据当前访问情况实时生成的,也可能是在其访问服务端之前就由服务端后台生成好的。若是客户端获取的访问策略是由服务端预先生成的,就有可能在两次访问路由服务器时获得了相同的访问策略,例如,可能客户端上一次访问服务端时,访问服务端的访问量情况与在当前的访问量情况相同,当然,根据上面的解释,本领域技术人员可以知道,这里所说的访问量情况相同并不一定是当前访问服务端的客户端数量与之前访问服务端的客户端数量相同,而是指两次访问服务端的客户端的数量属于同一个等级,如都属于A型访问量情况,根据预先生成访问策略的方式,客户端获取到的访问策略应该就没有变化。
由于一份访问策略并不一定仅对客户端在接下来对路由服务器或目的服务器的一次访问做出指示,而是针对多次访问的情况做出指示。例如,在一份访问策略中,要求客户端:
步骤一、对每个目的服务器进行3次请求操作,如请求失败后,则进行下一个目的服务器的请求操作;
步骤二、当所有的目的服务器都被轮询过后,且都不能进行访问时,客户端进入等待状态;
步骤三、当等待时间到达1小时时,再次访问路由服务器获取新的路由信息表和访问策略;
步骤四、根据新的路由信息表对目的服务器进行轮询,对每个目的服务器进行3次请求操作,如请求失败后,则进行下一个目的服务器的请求操作;
步骤五、当所有的目的服务器都被轮询过后,且都不能进行访问时,客户端进入等待状态;
步骤六、当等待时间到达24小时时,再次访问路由服务器获取新的路由信息表和访问策略。
在上述访问策略中,客户端会在步骤三之后访问路由服务器,并获得新的路由信息表以及访问策略,如果获取到的访问策略与上一次的相同的话,那么客户端就可能要重新执行已经执行过的过程,所以为了避免客户端始终按照相同的访问策略访问服务端,在本实施例中,客户端在获取到访问策略后进入判断流程,请参考图7:
S701、判断本次获取到的访问策略与之前执行的访问策略是否相同,若是,则执行S802,若否,则执行S803;
S702、跳过访问策略中已执行过的部分,继续执行未执行的部分;
S703、重新执行本次获取到的访问策略。
这个判断机制能够避免客户端在获取到相同的访问策略后,总是执行相同的步骤,按照相同指示访问服务端。
在第四实施例中,将结合服务端与客户端,对本发明的访问策略管理方法进行详细阐述。
在本实施例中,为了使客户端对服务端的访问更安全,因此,在客户端访问路由服务器时,服务端还向客户端返回安全令牌,下面以token令牌为例进行说明,请结合图8:
S801、服务端向访问路由服务器的客户端返回路由信息表、访问策略以及一个token令牌;
S802、服务端将与上述token令牌相匹配的另一个token令牌存入服务端侧缓存中;
S803、当客户端访问目的服务器时,目的服务器验证该客户端携带的token令牌是否与服务端侧缓存的token令牌匹配,若该客户端携带的token令牌与服务端侧缓存的token令牌匹配,则执行S904,若不匹配,则执行S905;
S804、响应该客户端的请求;
S805、拒绝该客户端的请求。
第五实施例提供一种服务端,如图9所示:
服务端10能够在运营过程中生成访问策略,而非像现有技术一样在开发阶段生成访问策略。服务端10包括策略生成模块101和策略返回模块102,策略生成模块101用于预先设定访问情况,策略返回模块102用于向访问路由服务器的客户端返回访问策略。
如图10所示,策略生成模块101包括预先生成模块1011。预先生成模块1011用于预先生成访问策略,即在客户端访问之前,预先生成模块1011事先根据访问的客户端的数量将访问情况划分为N个等级,这里N大于等于1,即设定至少一种访问情况,并根据每种情况中访问量的多少,为每种访问量情况生成与之对应的访问策略。
例如,策略生成模块101设定当访问服务端的客户端的数量小于50万时为A型访问量情况,50万到100万时为B型访问量情况,访问量超过100则进入C型访问量情况。
由于A型访问量情况中服务端承受的压力还不算大,所以,针对这种情况,预先生成模块1011生成的A类访问策略设定客户端可以每1小时对目的服务器进行一次轮询访问、每两个小时访问一次路由服务器获取新的访问策略及路由信息表。针对B型访问量情况,预先生成模块1011生成的B类访问策略中要求客户端可以每3小时对目的服务器进行一次轮询访问、每5个小时访问一次路由服务器。而对于C型访问量情况,服务端必须要进一步抑制客户端访问的频率,所以,预先生成模块1011将C型访问策略设置为每6个小时访问一次目的服务器,每24小时访问一次路由服务器。
图11所示,策略返回模块102包括第一返回模块1021,第一返回模块1021用于向访问路由服务器的客户端返回访问策略。当策略生成模块101使用预先生成模块1011生成返回策略时,第一返回模块1021在向客户端返回访问策略时,需要考虑当前的访问量情况,所以,第一返回模块1021用于监测所述服务端当前的访问量,并为客户端返回与当前的访问量匹配的预先访问策略。
例如第一返回模块1021检测到当前来访问的客户端的数量为77万,这属于B型访问情况,因此,第一返回模块1021为客户端返回的访问策略也应该是B类访问策略,要求该客户端在后续的过程中,每3小时对目的服务器进行一次轮询访问、每5个小时访问一次路由服务器,以获取新的访问策略以及新的路由信息表。
第五实施例中的服务端预先生成访问策略,在第六实施例中,提供另外一种服务端,如图12所示,该服务器中策略生成模块101包括实时生成模块1012,实时生成模块1012用于监测服务端当前的访问量,并根据当前的访问量为客户端生成实时访问策略。
本领域技术人员应该很清楚,实时生成模块1012实时生成访问策略的方式相当于在为每一个客户端“定制”访问策略,因为每一个客户端访问路由服务器时,服务器接受访问的情况都是不同的,可能上一时刻服务端接受30万客户端的访问,而在当前时刻,访问的客户端又变成了30.5万,这种变化在预先生成访问策略的方式中是不予考虑的,但在这种实时生成访问策略的方式中,却会导致上一时刻来访的客户端和当前来访的客户端获得的访问策略不同。举个例子,这就相当于人们买衣服一样,一般厂家生产衣服的时候,只是粗略考虑人的身高、胖瘦程度,生成大、中、小等几种固定类型的衣服。顾客选购衣服时只能将自己的情况划分到其中的某一个类型中去,然后选择其中一个类型的衣服。但定制衣服就不一样了,定制的衣服是根据特定顾客的身高、胖瘦程度甚至是身体的线条等生产出来的,这件衣服会更加满足该特定顾客的需求,提升其满意度,但从另一方面来说,这也增大了生产衣服的压力。回到本实施例中,一方面,实时生成访问策略的方式考虑了服务器每一时刻承受的压力的大小,从而能够更加精确的控制客户端访问服务端的频率,但这种“定制”访问策略的方式对服务端的要求也会更高。而预先生成访问策略的方式虽然不能兼顾每一时刻服务端的访问量情况,但是针对生成策略这一过程来说,这种方式会更加方便。
如图13所示,策略返回模块102包括第二返回模块1022用于实时生成模块1012实时生成访问策略后,将这一访问策略通过路由服务器返回给客户端即可,不需要再次监测服务端当前的访问量。
在第七实施例中,提供一种客户端,如图14,客户端20包括路由访问模块201和策略获取模块202。路由访问模块201用于访问服务端的路由服务器。策略获取模块202用于接收路由服务器返回的访问策略并将其更新至本地。
可以理解的是,策略获取模块202获取的访问策略可能是根据当前访问情况实时生成的,也可能是在其访问服务端之前就由服务端后台生成好的。若是策略获取模块202获取的访问策略是由服务端预先生成的,就有可能在两次访问路由服务器时获得了相同的访问策略,例如,可能路由访问模块201上一次访问服务端时,访问服务端的访问量情况与在当前的访问量情况相同,当然,根据上面的解释,本领域技术人员可以知道,这里所说的访问量情况相同并不一定是当前访问服务端的客户端数量与之前访问服务端的客户端数量相同,而是指两次访问服务端的客户端的数量属于同一个等级,如都属于A型访问量情况,根据预先生成访问策略的方式,策略获取模块202获取到的访问策略应该就没有变化。
所以,为了避免客户端始终按照相同的访问策略访问服务端,在本实施例中,客户端20还包括策略判断模块203、第一执行模块204和第二执行模块205。在策略获取模块202获取到访问策略后,策略判断模块203判断本次获取到的访问策略与之前执行的访问策略是否相同,若相同,则由第一执行模块204跳过访问策略中已执行过的部分,继续执行未执行的部分;若不同,则由第二执行模块205重新执行本次获取到的访问策略。
这个判断机制能够避免在获取到相同的访问策略后,客户端20还总是按照相同指示访问服务端。
请参照图15,图15为上述实施例中客户端与服务端组成的系统架构图,其中系统是由多个tomcat应用服务集群以及路由集群构成,在图中示出了两个应用服务集群,其中每一个应用集群中都提供多个接入容器,在这里接入容器即为上述实施例中提到的目标服务器,当客户端Client SDK从路由集群处获取到访问策略、路由信息表时,还会获得一个token令牌。同时,路由集群也会在服务端缓存当中存储一个与之对应的token令牌,当客户端Client SDK从路由信息表中选择接入容器进行访问时,该被访问的接入容器会从服务端缓存当中获取token令牌,并与客户端Client SDK携带的令牌进行匹配,若匹配成功,才允许客户端Client SDK接入。通过token令牌的校验,可以提高客户端Client SDK访问的安全性。
需要说明的是,在本文中,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中,包括若干指令用以使得一台终端设备(可以是手机,计算机,服务器,空调器,或者网络设备等)执行本发明各个实施例所述的方法。
以上仅为本发明的优选实施例,并非因此限制本发明的专利范围,凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换,或直接或间接运用在其他相关的技术领域,均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种服务端,其特征在于,包括:
策略生成模块,用于生成访问策略,所述访问策略用于指示客户端在后续过程中如何对所述服务端的各目的服务器及路由服务器进行访问,所述目的服务器为所述客户端实际需要访问的服务器;
策略返回模块,用于向访问所述路由服务器的客户端返回所述访问策略。
2.如权利要求1所述的服务端,其特征在于,
所述策略生成模块包括:
实时生成模块,用于监测所述服务端当前的访问量,并根据所述当前的访问量为所述客户端生成实时访问策略;
所述策略返回模块包括:
第一返回模块,用于将为所述客户端实时生成访问策略返回给所述客户端。
3.如权利要求1或2所述的服务端,其特征在于,
所述策略生成模块包括:
预先生成模块,用于根据预先设定至少一种访问量情况,为各所述访问量情况生成对应的预先访问策略;
所述策略返回模块包括:
第二返回模块,用于监测所述服务端当前的访问量,并为所述客户端返回与当前的访问量匹配的所述预先访问策略。
4.一种客户端,其特征在于,包括:
路由访问模块,用于访问服务端的路由服务器;
策略获取模块,用于接收所述路由服务器返回的访问策略并将其更新至本地,所述访问策略用于指示客户端在后续过程中如何对所述服务端的各目的服务器及所述路由服务器进行访问,所述目的服务器为所述客户端实际需要访问的服务器。
5.如权利要求4所述客户端,其特征在于,还包括:
策略判断模块,用于判断本次获取到的所述访问策略与上次获取到的访问策略是否相同;
第一执行模块,用于当本次获取到的所述访问策略与之前执行的访问策略相同时,则跳过所述访问策略中已执行过的部分,继续执行未执行的部分;
第二执行模块,用于当本次获取到的所述访问策略与之前执行的访问策略不同时,则重新执行本次获取到的所述访问策略。
6.一种访问策略管理方法,其特征在于,包括:
生成访问策略,所述访问策略用于指示客户端在后续过程中如何对所述服务端的各目的服务器及路由服务器进行访问,所述目的服务器为所述客户端实际需要访问的服务器;
向访问所述路由服务器的客户端返回所述访问策略。
7.如权利要求6所述的访问策略管理方法,其特征在于,
所述生成访问策略包括:
监测所述服务端当前的访问量,并根据所述当前的访问量为所述客户端生成实时访问策略;
所述向访问所述路由服务器的客户端返回所述访问策略包括:
将所述实时生成访问策略返回给所述客户端。
8.如权利要求6或7所述的访问策略管理方法,其特征在于,
所述生成访问策略包括:
根据预先设定至少一种访问量情况,为各所述访问量情况生成对应的预先访问策略;
所述向访问所述路由服务器的客户端返回所述访问策略包括:
监测所述服务端当前的访问量,并为所述客户端返回与当前的访问量匹配的所述预先访问策略。
9.一种访问策略管理方法,其特征在于,包括:
访问服务端的路由服务器;
接收所述路由服务器返回的访问策略并将其更新至本地,所述访问策略用于指示客户端在后续过程中如何对所述服务端的各目的服务器及所述路由服务器进行访问,所述目的服务器为所述客户端实际需要访问的服务器。
10.如权利要求9访问策略管理方法,其特征在于,还包括:
判断本次获取到的所述访问策略与之前执行的访问策略是否相同;
当本次获取到的所述访问策略与之前执行的访问策略相同时,则跳过所述访问策略中已执行过的部分,继续执行未执行的部分;
当本次获取到的所述访问策略与上一次获取到的访问策略不同时,则重新执行本次获取到的所述访问策略。
CN201610179767.4A 2016-03-25 2016-03-25 服务端、客户端及访问策略管理方法 Active CN105872028B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610179767.4A CN105872028B (zh) 2016-03-25 2016-03-25 服务端、客户端及访问策略管理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610179767.4A CN105872028B (zh) 2016-03-25 2016-03-25 服务端、客户端及访问策略管理方法

Publications (2)

Publication Number Publication Date
CN105872028A true CN105872028A (zh) 2016-08-17
CN105872028B CN105872028B (zh) 2019-04-26

Family

ID=56626170

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610179767.4A Active CN105872028B (zh) 2016-03-25 2016-03-25 服务端、客户端及访问策略管理方法

Country Status (1)

Country Link
CN (1) CN105872028B (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109905312A (zh) * 2017-12-08 2019-06-18 北京新媒传信科技有限公司 消息推送方法、装置及系统
CN110071952A (zh) * 2018-01-24 2019-07-30 北京京东尚科信息技术有限公司 服务调用量的控制方法和装置
CN110166791A (zh) * 2019-06-12 2019-08-23 北京字节跳动网络技术有限公司 连接的建立方法、装置、设备及存储介质
CN111262865A (zh) * 2016-09-23 2020-06-09 华为技术有限公司 访问控制策略的制定方法、装置及系统
CN114693344A (zh) * 2022-03-14 2022-07-01 珠海格力电器股份有限公司 一种多端接入抽奖方法及系统

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101102288A (zh) * 2006-07-06 2008-01-09 阿里巴巴公司 一种实现大型即时通信的方法及系统
CN102143204A (zh) * 2010-11-26 2011-08-03 华为技术有限公司 一种内容分发网络中实现超文本传输协议重定向的方法、装置及系统
JP2013034096A (ja) * 2011-08-02 2013-02-14 Nec Corp アクセス制御システム、端末装置、中継装置及びアクセス制御方法
CN103118076A (zh) * 2013-01-11 2013-05-22 烽火通信科技股份有限公司 升级服务器集群系统及其负载均衡方法
CN103780580A (zh) * 2012-10-23 2014-05-07 中国电信股份有限公司 提供能力访问策略的方法、服务器和系统
CN104253870A (zh) * 2014-09-29 2014-12-31 广州华多网络科技有限公司 控制数据访问周期的方法和装置

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101102288A (zh) * 2006-07-06 2008-01-09 阿里巴巴公司 一种实现大型即时通信的方法及系统
CN102143204A (zh) * 2010-11-26 2011-08-03 华为技术有限公司 一种内容分发网络中实现超文本传输协议重定向的方法、装置及系统
JP2013034096A (ja) * 2011-08-02 2013-02-14 Nec Corp アクセス制御システム、端末装置、中継装置及びアクセス制御方法
CN103780580A (zh) * 2012-10-23 2014-05-07 中国电信股份有限公司 提供能力访问策略的方法、服务器和系统
CN103118076A (zh) * 2013-01-11 2013-05-22 烽火通信科技股份有限公司 升级服务器集群系统及其负载均衡方法
CN104253870A (zh) * 2014-09-29 2014-12-31 广州华多网络科技有限公司 控制数据访问周期的方法和装置

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111262865A (zh) * 2016-09-23 2020-06-09 华为技术有限公司 访问控制策略的制定方法、装置及系统
CN109905312A (zh) * 2017-12-08 2019-06-18 北京新媒传信科技有限公司 消息推送方法、装置及系统
CN109905312B (zh) * 2017-12-08 2021-07-23 北京新媒传信科技有限公司 消息推送方法、装置及系统
CN110071952A (zh) * 2018-01-24 2019-07-30 北京京东尚科信息技术有限公司 服务调用量的控制方法和装置
CN110071952B (zh) * 2018-01-24 2023-08-08 北京京东尚科信息技术有限公司 服务调用量的控制方法和装置
CN110166791A (zh) * 2019-06-12 2019-08-23 北京字节跳动网络技术有限公司 连接的建立方法、装置、设备及存储介质
CN110166791B (zh) * 2019-06-12 2021-10-29 北京字节跳动网络技术有限公司 连接的建立方法、装置、设备及存储介质
CN114693344A (zh) * 2022-03-14 2022-07-01 珠海格力电器股份有限公司 一种多端接入抽奖方法及系统

Also Published As

Publication number Publication date
CN105872028B (zh) 2019-04-26

Similar Documents

Publication Publication Date Title
CN105872028A (zh) 服务端、客户端及访问策略管理方法
US7672680B1 (en) Web services architecture system and method
US8296375B1 (en) Parallel management of load servers, cache servers, and feed servers
US20020140560A1 (en) Method and apparatus for providing information to a mobile consumer
US20110231517A1 (en) Smart download system for mobile devices with multiple data interfaces using enhanced HTTP proxy server
CN103765423A (zh) 收集与本地存储的数据文件相关联的事务数据
CN105049423A (zh) 权限管理系统、装置及方法
CN109743381B (zh) 客户端与服务端长连接交互方法及装置
CN102036115B (zh) 一种数字电视业务数据管理方法、服务器及终端
KR20060009737A (ko) 방송망과 지상망의 연동에 의한 방송 및 데이터 서비스제공 방법
JP6814695B2 (ja) 予約管理装置、予約管理方法、およびプログラム
US20180295469A1 (en) Method, apparatus and system for destination recommendation and selection
CN104809017A (zh) 应用程序分发控制、执行方法及其相应装置
CN101889470B (zh) 用于多连接的末端终端的内容提供系统、方法、业务服务器、存储单元、转发方法、应用服务器及蜂窝电话
CN102231157A (zh) 一种移动终端批量查看页面的方法和装置
CN111641693B (zh) 会话数据处理方法、装置及电子设备
JP2004145538A (ja) コンテンツ配信システム、コンテンツ配信方法、その記録媒体およびプログラム
US20100077080A1 (en) Communication terminal, service kiosk, and service providing system and method
CN115587860A (zh) 业务处理方法、装置、存储介质及电子设备
CN101594573A (zh) 动态综合移动广告展现方法、系统、客户端和网络设备
CN102685724A (zh) 一种内容定制方法,终端及系统
CN110059260A (zh) 一种推荐方法、装置、设备和介质
KR101328493B1 (ko) 통신단말기를 이용한 동영상 실시간 중계 장치 및 방법
US10929482B2 (en) Unified publication search and consumption interface
CN111194010B (zh) 通过无线电向目标数量设备发送数据的方法、系统及介质

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant