CN109088909B - 一种基于商户类型的服务灰度发布方法及设备 - Google Patents

Abstract

本申请公开了一种基于商户类型的服务灰度发布方法及设备，该方法包括：接收目标客户的服务请求；根据所述服务请求确定所述目标客户的商户类型；将所述服务请求发送至所述商户类型对应的服务端，以使得所述服务端为所述目标客户提供服务。其中，可以根据所述服务请求获取所述服务请求的报文数据格式、所述服务请求所携带的所述目标客户的标识信息和所述目标客户的并发数历史经验值中的至少一项；根据所述三项中的至少一项确定所述目标客户的商户类型。本申请实施例中，基于商户类型，使用多种方式实现新服务的发布，可针对不同情况采用不同的服务发布策略，服务发布的风险低、效率高。

Description

一种基于商户类型的服务灰度发布方法及设备

技术领域

本申请涉及移动互联网技术领域，具体涉及一种基于商户类型的服务灰度发布方法及设备。

背景技术

现在的用户在互联网上使用各种各样的服务，例如QQ平台的各种服务等。这些服务每一次的版本发布，都会影响到数亿的用户，因此现在网络服务商在进行服务新版本的发布时，都会采用灰度发布的方法，即让一小部分的用户使用新版本的服务，大部分的用户继续使用老版本的服务，如果小部分的用户使用新版本的服务没有问题，再逐渐把其他的用户迁移到新版本的服务上来。

现有的服务灰度发布方法有以下两种：按服务器进行灰度发布，即服务进行新版本发布时，按照部署的服务器逐台进行发布；以及按用户号段进行灰度发布，将所有用户按用户号段(例如QQ号码六位、七位等)分为多个单元，服务进行新版本发布时，逐单元进行发布。如采用按服务器进行灰度发布，每台服务器承载的用户访问量依然是海量的，因此使用按服务器进行灰度发布的风险依然太大。如按用户号段进行灰度发布，如号段设置的过少，灰度发布的风险与按服务器灰度发布一样不能够得到很好的控制；如号段设置的过多，风险虽然得到了有效地控制，但逐单元进行发布可能导致灰度发布时间过长，影响灰度发布的效率。

为解决上述问题，有人提出了一种服务灰度发布方法，该服务灰度发布方法通过设定新服务的单位时间访问量，并使用单位时间访问量对新服务进行发布；接收新服务的客户反馈信息，以及如新服务的客户反馈信息正常，则通过增加新服务的单位时间的访问量的方式对新服务进行逐步发布。

然而，上述服务灰度发布仍然存在一定的问题，例如假定新服务的客户恰好是一个天量级客户，例如中国移动，那么它自身的用户并发数会非常大，远远超过最开始设定的新服务的单位时间访问量，那么往往其反馈信息会出现异常，导致新服务无法及时发布和推广。

发明内容

为解决以上问题，本申请通过解析报文获取商户号，并根据指定配置进行商户类型服务灰度的发布。

根据本申请的一个方面，提供了一种基于商户类型的服务灰度发布方法，包括：接收目标客户的服务请求；根据所述服务请求确定所述目标客户的商户类型；将所述服务请求发送至所述商户类型对应的服务端，以使得所述服务端为所述目标客户提供服务。

在一个示例中，所述根据所述服务请求确定所述目标客户的商户类型，包括：根据所述服务请求获取所述服务请求的报文数据格式、所述服务请求所携带的所述目标客户的标识信息和所述目标客户的并发数历史经验值中的至少一项；根据所述服务请求的报文数据格式、所述目标客户的标识信息和所述目标客户的并发数历史经验值中的至少一项确定所述目标客户的商户类型。

在一个可能的实施方式中，所述根据服务请求的报文数据格式确定所述目标客户的商户类型，包括：若所述报文数据格式包含企业域名，则确定所述目标客户的商户类型为企业用户；或者，若所述报文数据格式包含个人域名或不包含企业域名，则确定所述目标客户的商户类型为个人用户。

在一个可能的实施方式中，所述根据所述目标客户的标识信息确定所述目标客户的商户类型，包括：若所述标识信息为个人电话号码、身份证号码、和/或个人地理位置，则确定所述目标客户的商户类型为个人用户；或者，若所述标识信息是是企业电话号码、纳税识别号、社会信用代码、营业执照注册号、商号、和/或黄页号码，则确定所述目标客户的商户类型为企业用户。

在一个可能的实施方式中，所述根据目标客户的并发数历史经验值确定所述目标客户的商户类型，包括：若所述目标客户的并发数历史经验值为0，则确定所述目标客户的商户类型为个人用户；或者，若所述目标客户的并发数历史经验值大于0，则确定所述目标客户的商户类型为企业用户。

在一个示例中，所述目标客户的商户类型为所述企业用户，所述企业用户包括至少两类企业用户，所述确定所述目标客户的商户类型为企业用户，包括：根据所述目标客户的并发数历史经验值在所述服务的总访问量的占比确定所述目标客户的商户类型为所述至少两类企业用户中的一种。

在一个示例中，所述服务为新服务，所述新服务对应的商户类型包括所述目标客户的商户类型，所述方法还包括：接收所述目标客户的关于所述新服务的反馈信息；若所述反馈信息正常，则通过增加所述新服务对应的商户类型的方式对所述新服务进行逐步发布。

在一个示例中，所述接收目标客户的服务请求，包括：通过正向代理方式、反向代理方式或包过滤方式接收所述服务请求。

根据本申请的另一个方面，还提供了一种基于商户类型的服务灰度发布设备，包括：

一个或多个处理器、存储一个或多个程序的存储装置；

当所述一个或多个程序被所述一个或多个处理器执行时，所述一个或多个处理器实现如上所述的方法。

根据本申请的另一个方面，还提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上所述的方法。

本申请实施例可以基于商户类型，使用多种方式实现新服务的发布，可针对不同情况采用不同的服务发布策略，服务发布的风险低、效率高。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本申请的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本申请的一种基于商户类型的服务灰度发布方法流程图；

图2示出了本申请的一种基于商户类型的服务灰度发布设备的第一优选实施例结构图；

图3示出了本申请的一种基于商户类型的服务灰度发布设备的第二优选实施例结构图；

图4示出了本申请的一种基于商户类型的服务灰度发布设备的第三优选实施例结构图；

图5示出了本申请的一种基于商户类型的服务灰度发布设备的第四优选实施例结构图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施方式。虽然附图中显示了本公开的示例性实施方式，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

如图1所示，根据本申请的实施方式，提出一种基于商户类型的服务灰度发布方法，包括：

S1、接收目标客户的服务请求。

其中，本申请涉及的服务可以是收单服务，相对应的，该服务请求可以是收单服务请求。所述收单服务可以包括软件升级的服务、软件版本更新的服务等软件各种服务类型。

在一个示例中，可以采用正向代理、反向代理或包过滤方式来接收收单服务请求。

正向代理，是一个位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。客户端才能使用正向代理。

包过滤方式是指网络设备(路由器或防火墙)根据包过滤规则检查所接收的每个数据包，做出允许数据包通过或丢弃数据包的决定。包过滤技术(IPFiltering or packetfiltering)的原理在于利用路由器监视并过滤网络上流入流出的IP包，拒绝发送可疑的包。由于Internet与Intranet的连接多数都要使用路由器，所以Router成为内外通信的必经端口，Router的厂商在Router上加入IP过滤功能，过滤路由器也可以称作包过滤路由器或筛选路由器(Packet FilterRouter)。防火墙常常就是这样一个具备包过滤功能的简单路由器，这种Firewall应该是足够安全的，但前提是配置合理。然而一个包过滤规则是否完全严密及必要是很难判定的，因而在安全要求较高的场合，通常还配合使用其它的技术来加强安全性。

反向代理(Reverse Proxy)方式是以代理服务器来接受因特网(Internet)上的服务请求，然后将该服务请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给Internet上请求服务的客户端，此时代理服务器对外就表现为一个反向代理服务器。

通常的代理服务器，只用于代理内部网络对Internet的连接请求，客户机必须指定代理服务器,并将本来要直接发送到Web服务器上的http请求发送到代理服务器中。由于外部网络上的主机并不会配置并使用这个代理服务器，普通代理服务器也被设计为在Internet上搜寻多个不确定的服务器,而不是针对Internet上多个客户机的请求访问某一个固定的服务器，因此普通的Web代理服务器不支持外部对内部网络的访问请求。当一个代理服务器能够代理外部网络上的主机，访问内部网络时，这种代理服务的方式称为反向代理服务。此时代理服务器对外就表现为一个Web服务器，外部网络就可以简单把它当作一个标准的Web服务器而不需要特定的配置。不同之处在于，这个服务器没有保存任何网页的真实数据，所有的静态网页或者CGI程序，都保存在内部的Web服务器上。因此对反向代理服务器的攻击并不会使得网页信息遭到破坏，这样就增强了Web服务器的安全性。

反向代理方式和包过滤方式或正向代理方式并无冲突，因此可以在防火墙设备中同时使用这两种方式，其中反向代理用于外部网络访问内部网络时使用，正向代理或包过滤方式用于拒绝其他外部访问方式并提供内部网络对外部网络的访问能力。因此可以结合这些方式提供最佳的安全访问方式。

S2、根据所述服务请求确定所述目标客户的商户类型。

在一个示例中，可以根据所述服务请求获取所述服务请求的报文数据格式、所述服务请求所携带的所述目标客户的标识信息和所述目标客户的并发数历史经验值中的至少一项；并根据所述服务请求的报文数据格式、所述目标客户的标识信息和所述目标客户的并发数历史经验值中的至少一项确定所述目标客户的商户类型。

在一种可能的实施方式中，可以根据服务请求的报文数据格式确定目标客户的商户类型。例如，若所述报文数据格式包含企业域名，则确定所述目标客户的商户类型为企业用户；或者，若所述报文数据格式包含个人域名或不包含企业域名，则确定所述目标客户的商户类型为个人用户。

在另一种可能的实施方式中，可以根据目标客户的标识信息确定目标客户的商户类型。例如，若所述标识信息为个人电话号码、身份证号码、和/或个人地理位置，则确定所述目标客户的商户类型为个人用户；或者，若所述标识信息是是企业电话号码、纳税识别号、社会信用代码、营业执照注册号、商号、和/或黄页号码，则确定所述目标客户的商户类型为企业用户。具体地，每个服务请求都携带请求源的标识信息，例如如果请求源是个人，所述标识信息可能是电话号码、身份证号码、地理位置等等个人相关信息。如果请求源是企业，那么所述标识信息可能是电话号码、纳税识别号、社会信用代码、营业执照注册号、商号、黄页号码等等具有唯一性的信息。因此，识别上述标识信息，就可以识别请求的具体来源。

由上可以看出，当服务器识别出服务请求的报文数据格式和/或目标客户的标识信息后，就可以根据服务请求的报文数据格式和/或目标客户的标识信息对目标客户进行分类，也就是可以划分商户类型。

本申请中，划分商户类型的方法可以有很多，例如可以采用上面两种可能的实施方式，划分个人用户和企业用户两种商户类型。

此外，在实际操作中，个人用户的请求并发数要远远小于企业用户的请求并发数，因此还可以根据目标客户的并发数历史经验值来确定目标客户的商户类型。请求并发数指的是客户端在建立完连接后，单位时间内向服务器发出的请求连接数，单位是每秒多少个请求。

在又一种可能的实施方式中，若所述目标客户的并发数历史经验值为0，则确定所述目标客户的商户类型为个人用户；或者，若所述目标客户的并发数历史经验值大于0，则确定所述目标客户的商户类型为企业用户。

进一步地，如果目标客户的商户类型为所述企业用户，所述企业用户包括至少两类企业用户，则确定所述目标客户的商户类型，可以包括：根据所述目标客户的并发数历史经验值在所述服务的总访问量的占比确定所述目标客户的商户类型为所述至少两类企业用户中的一种。

例如，更为细致的，根据企业用户的请求并发数历史经验值，可以将企业用户进一步划分为多个类型，例如小企业、大中型企业、天量级企业等等商户类型，从而逐级逐步的实现新服务的发布。上述并发数历史经验值，可以根据过去一整年或者多年的统计平均经验值来决定，这样就更为科学更符合实际。现实中，小企业一年的请求并发数量通常是非常有限的，而某些大企业通常则是请求并发数大户(例如三大电信运营商等)。因此，本申请的商户类型的划分是根据客观实际，遵循自然规律的商户类型划分，而不是一种简单的人为设定，因此符合自然规律，属于可以保护的客体。

示例性地，请求并发数量水平的划分具体可为：低请求并发数量为服务器的总访问量的0％-n％，中请求并发数量为服务器的总访问量的n％-m％，高请求并发数量为服务器的总访问量的m％-100％；其中n的范围为10-20，m的范围为50-80。如预先设置的总请求并发数量较大，可适当的降低低请求并发数量或中请求并发数量，即n或m取较小的值，以缩短低请求并发数量或中请求并发数量的服务发布时间；如预先设置的总请求并发数量较小，则可适当的提高低请求并发数量或中请求并发数量，即n或m取较大的值，以更好的控制服务发布的风险。

可以理解的是，上述各种可能的实施方式描述了根据所述服务请求的报文数据格式、所述目标客户的标识信息和所述目标客户的并发数历史经验值中的一项确定目标客户的商户类型的实现过程，在实际应用中，也可以根据这三者中的两项或全部来确定目标客户的商户类型，本申请对此并不限定。

S3、将所述服务请求发送至所述商户类型对应的服务端，以使得所述服务端为所述目标客户提供服务。

具体地，若该服务为新服务，且新服务对应的商户类型包括目标客户的商户类型，则将该服务请求发送至新服务对应的服务端，以使得新服务对应的服务端为目标客户提供服务。又例如，若该服务为旧服务，且旧服务对应的商户类型包括目标客户的商户类型，则将该服务请求发送至旧服务对应的服务端，以使得旧服务对应的服务端为目标客户提供服务。

在一个示例中，该服务为新服务，新服务对应的商户类型包括目标客户的商户类型，本申请实施例还可以包括：接收目标客户的关于新服务的反馈信息；若所述反馈信息正常，则通过增加所述新服务对应的商户类型的方式对所述新服务进行逐步发布。

其中，上述服务端可以是收单服务站点。所述收单服务站点就是提供上述收单服务的服务器、服务终端、工作站等等。这个步骤可以由新服务站点和/或旧收单服务站点完成。对于每个不同商户类型的收单服务请求，最终由对应的收单服务站点完成与商户类型对应的收单服务。

例如，根据所述商户类型将所述收单服务请求引导到对应的收单服务站点。当划分好用户的商户类型后，就可以很容易的判断其对应的收单服务站点的类型。例如，对于个人用户或者小企业用户，可以将请求引导至新服务站点，该站点为该用户提供服务的更新，例如软件的版本升级等。而对于大企业用户，则将请求引导至旧的收单服务站点，即不对其服务进行更新，例如不升级其软件等。对于每个不同商户类型等级的收单服务请求，最终引导至不同的收单服务站点。

如此，通过以上方法，本申请实现了用户服务发布的差分化管理，实现了灰度发布的效果，并且降低了服务发布的风险，提高了服务发布的效率，防止出现天量级客户一开始就超过服务发布限制而导致灰度发布无法继续进行的情况。

本申请的服务灰度发布方法，基于商户类型，使用多种方式实现新服务的发布，可针对不同情况采用不同的服务发布策略，服务发布的风险低、效率高。

在上述的实施例中，提供了一种基于商户类型的服务灰度发布方法，与之相对应的，本申请还提供一种基于商户类型的服务灰度发布设备。本申请实施例提供的服务灰度发布设备可以实施上述图1所示的方法，该服务灰度发布设备可以通过软件、硬件或软硬结合的方式来实现。例如，该服务灰度发布设备可以包括集成的或分开的功能模块或单元来执行上述方法中的对应步骤。

根据本申请的另一个方面，还提供了一种基于商户类型的服务灰度发布设备，包括：

一个或多个处理器、存储一个或多个程序的存储装置；

当所述一个或多个程序被所述一个或多个处理器执行时，所述一个或多个处理器实现如上所述的方法。

根据本申请的另一个方面，还提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上所述的方法。

下面结合图2至图4对本申请提供的服务灰度发布设备进一步详细说明。由于装置实施例基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。

如图2所示，根据本申请的实施方式，提出一种基于商户类型的服务灰度发布设备，包括：

一种基于商户类型的服务灰度发布设备10，包括：

请求接收单元11，用于接收收单服务请求；所述请求接收单元11采用正向代理服务器、反向代理服务器或包过滤服务器。

灰度发布单元12，用于解析所述收单服务请求，获取商户类型，并根据所述商户类型引导所述收单服务请求到至少一个服务单元13；所述灰度发布单元12通过解析所述收单服务请求的报文数据格式和/或识别所述收单服务请求所携带的请求源的标识信息和/或目标客户的并发数历史经验值，进而对所述请求的来源进行划分，从而获取商户类型。

一个服务单元13，其提供与所述商户类型对应的收单服务。当所述请求来自个人或者小企业商户时，服务单元13提供新服务。当所述请求来自大企业商户时，服务单元13提供原有的收单服务。

本实施例的服务灰度发布设备，基于商户类型，使用多种方式实现新服务的发布，可针对不同情况采用不同的服务发布策略，服务发布的风险低、效率高。

如图3所示，根据本申请的实施方式，提出另一种基于商户类型的服务灰度发布设备，包括：

一种基于商户类型的服务灰度发布设备10，包括：

请求接收单元11，用于接收收单服务请求；所述请求接收单元11采用正向代理服务器、反向代理服务器或包过滤服务器。

灰度发布单元12，用于解析所述收单服务请求，获取商户类型，并根据所述商户类型引导所述收单服务请求到一个第一服务单元13或第二服务单元14；所述灰度发布单元12通过解析所述收单服务请求的报文数据格式和/或识别所述收单服务请求所携带的请求源的标识信息和/或目标客户的并发数历史经验值，进而对所述请求的来源进行划分，从而获取商户类型。

一个第一服务单元13，其提供与个人或者小企业对应的原有收单服务。一个第二服务单元14，其提供与大企业对应的新服务。当前一个等级商户的服务反馈信息正常时，则再放开对第二个等级商户的服务更新，从而实现对新服务进行逐步发布。

本实施例的服务灰度发布设备，基于商户类型，使用多种方式实现新服务的发布，可针对不同情况采用不同的服务发布策略，服务发布的风险低、效率高。

如图4所示，根据本申请的实施方式，提出又一种基于商户类型的服务灰度发布设备10，包括：

请求接收单元11，用于接收收单服务请求；所述请求接收单元11采用正向代理服务器、反向代理服务器或包过滤服务器。

灰度发布单元12，用于解析所述收单服务请求，获取商户类型，并根据所述商户类型引导所述收单服务请求到至少N个服务单元；所述灰度发布单元12通过解析所述收单服务请求的报文数据格式和/或识别所述收单服务请求所携带的请求源的标识信息和/或目标客户的并发数历史经验值，进而对所述请求的来源进行划分，从而获取商户类型。

一个第一服务单元13，其提供与个人或者小企业对应的原有收单服务。一个第二服务单元14，其提供与大企业对应的新服务。如此类推，总共设置N个服务单元，也就是设置N个商户类型。优选的，可以从1到N以此进行服务的发布。当前一个等级商户的服务反馈信息正常时，则再放开对后一个等级商户的服务更新，从而实现对新服务进行逐步发布。

本实施例的服务灰度发布设备，基于商户类型，使用多种方式实现新服务的发布，可针对不同情况采用不同的服务发布策略，服务发布的风险低、效率高。

此外，本申请还提供一种服务灰度发布系统，如图5所示，未使用基于商户类型服务灰度发布系统之前，用户请求通过反向代理发送到旧服务1～6，其中所有的请求根据IP随机HASH至旧服务1～旧服务6上。使用基于商户服务灰度发布方法和设备以后，用户请求经过反向代理转发至灰度发布单元，由灰度发布单元基于商户类型决定用户流量灰度至旧服务单元1～6还是新服务单元1～2。

旧服务站点A包含了6个主机：旧服务1～旧服务单元6。新服务站点B包含了2个主机：新服务单元1，新服务单元2。本实施例应用商户路由规则，例如商户号以8结尾的商户路由至新服务站点B，其余路由至旧服务站点A。商户X(商户号为12358)所有的服务请求被路由至新服务站点B，商户Y(商户号为12356)所有的服务请求被路由至旧服务站点A。

也就是说，本申请并不限于商户类型的等级顺序发布，也可以依据路由原则，根据商户号的尾号随机或有选择的将服务请求路由至新服务站点进行新服务的发布。

本实施例的服务灰度发布设备，基于商户号尾号，使用多种方式实现新服务的发布，可针对不同情况采用不同的服务发布策略，服务发布的风险低、效率高。

需要说明的是：

在此提供的算法和显示不与任何特定计算机、虚拟装置或者其它设备固有相关。各种通用装置也可以与基于在此的示教一起使用。根据上面的描述，构造这类装置所要求的结构是显而易见的。此外，本申请也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本申请的内容，并且上面对特定语言所做的描述是为了披露本申请的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本申请的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本申请的示例性实施例的描述中，本申请的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本申请要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本申请的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本申请的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本申请的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本申请实施例的虚拟机的创建装置中的一些或者全部部件的一些或者全部功能。本申请还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本申请的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本申请进行说明而不是对本申请进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本申请可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

以上所述，仅为本申请较佳的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (9)

1.一种基于商户类型的服务灰度发布方法，其特征在于，包括：

接收目标客户的服务请求；

根据所述服务请求确定所述目标客户的商户类型；所述商户类型包括个人用户和企业用户；

将所述服务请求发送至所述商户类型对应的服务端，以使得所述服务端为所述目标客户提供服务；

其中，所述根据所述服务请求确定所述目标客户的商户类型，包括：

根据所述服务请求获取所述服务请求的报文数据格式、所述服务请求所携带的所述目标客户的标识信息和所述目标客户的并发数历史经验值中的至少一项；

根据所述服务请求的报文数据格式、所述目标客户的标识信息和所述目标客户的并发数历史经验值中的至少一项确定所述目标客户的商户类型。

2.根据权利要求1所述的方法，其特征在于，所述根据服务请求的报文数据格式确定所述目标客户的商户类型，包括：

若所述报文数据格式包含企业域名，则确定所述目标客户的商户类型为企业用户；或者，

若所述报文数据格式包含个人域名或不包含企业域名，则确定所述目标客户的商户类型为个人用户。

3.根据权利要求1所述的方法，其特征在于，所述根据所述目标客户的标识信息确定所述目标客户的商户类型，包括：

若所述标识信息为个人电话号码、身份证号码、和/或个人地理位置，则确定所述目标客户的商户类型为个人用户；或者，

若所述标识信息是是企业电话号码、纳税识别号、社会信用代码、营业执照注册号、商号、和/或黄页号码，则确定所述目标客户的商户类型为企业用户。

4.根据权利要求1所述的方法，其特征在于，所述根据目标客户的并发数历史经验值确定所述目标客户的商户类型，包括：

若所述目标客户的并发数历史经验值为0，则确定所述目标客户的商户类型为个人用户；或者，

若所述目标客户的并发数历史经验值大于0，则确定所述目标客户的商户类型为企业用户。

5.根据权利要求4所述的方法，其特征在于，所述目标客户的商户类型为所述企业用户，所述企业用户包括至少两类企业用户，所述确定所述目标客户的商户类型为企业用户，包括：

根据所述目标客户的并发数历史经验值在所述服务的总访问量的占比确定所述目标客户的商户类型为所述至少两类企业用户中的一种。

6.根据权利要求1所述的方法，其特征在于，所述服务为新服务，所述新服务对应的商户类型包括所述目标客户的商户类型，所述方法还包括：

接收所述目标客户的关于所述新服务的反馈信息；

若所述反馈信息正常，则通过增加所述新服务对应的商户类型的方式对所述新服务进行逐步发布。

7.根据权利要求1至6中任一项所述的方法，其特征在于，所述接收目标客户的服务请求，包括：

通过正向代理方式、反向代理方式或包过滤方式接收所述服务请求。

8.一种基于商户类型的服务灰度发布设备，其特征在于，包括：

一个或多个处理器、存储一个或多个程序的存储装置；

当所述一个或多个程序被所述一个或多个处理器执行时，所述一个或多个处理器实现如权利要求1至6中任一项所述的方法。

9.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至6任一项所述的方法。

Images