CN103186413A - 一种邮箱服务的实现架构及其实现方法 - Google Patents

Abstract

本发明公开了一种邮箱服务的实现架构，包括前端、中间层和后台服务器；关键在于，所述中间层进一步包括通用网关接口(CGI)层和应用编程接口(API)层，且所述API层位于CGI层和后台服务器之间；其中，所述CGI层，包括多个对应邮箱基础服务的业务逻辑部分，用于完成业务逻辑功能的处理；所述API层，用于包括多个对应邮箱基础服务各资源接口的API，用于与后台服务器进行资源交互，并向上层应用提供所需的API。本发明还同时公开了一种邮箱服务的实现方法，采用本发明，能降低邮箱服务架构的耦合度，且能提高邮箱基础服务的通用性。

Description

一种邮箱服务的实现架构及其实现方法

技术领域

本发明涉及邮箱服务技术，特别是指一种即时通信系统中邮箱服务的实现架构及其实现方法。

背景技术

随着即时通信技术的发展，基于即时通信的各种增值业务越来越多、覆盖面也越来越广泛，比如即时通信邮箱服务。目前的即时通信邮箱服务是面向全国的海量服务，其覆盖的范围广、使用的用户多，且支持邮箱服务中各类服务的实现架构形成一个整体。由于邮箱服务的规模大、架构复杂，使得邮箱服务整个项目在开发、升级、以及架构调整方面，都会遇到耦合度过高的问题。具体来说，一方面，即使是进行小版本升级，由于整体架构的耦合度过高，代码模块需要全编译、全测试所有程序编码，这样，使得每个升级周期都会耗时过长；另一方面，针对不同来源的多个版本，在现有架构之下，必须同时升级，否则多套产品就必须独立部署、分别维护。另外，对于集成后的社区产品，由于未区分基础服务和上层服务，无法做到将个别基础服务拆分并嵌入使用，这样使得一些比较好的基础性应用无法从具体产品中剥离出来。

现有邮箱服务的实现架构包括三部分：前端模版、作为中间层的通用网关接口(CGI，Common Gateway Interface)层、以及后端的后台服务器(Server)，三部分的关联性比较强；并且，由于不同模块依赖于不同的库函数，且各个业务独立性不够，所以，库函数的变动会交叉影响到多个模块；因此，当后台Server升级时，就会影响到前端和CGI层。显然，在现有邮箱服务实现架构中，就算是后台Server很小版本的升级也会对整体架构产生影响。

发明内容

有鉴于此，本发明的主要目的在于提供一种邮箱服务的实现架构及其实现方法，能降低邮箱服务架构的耦合度，且能提高邮箱基础服务的通用性。

为达到上述目的，本发明的技术方案是这样实现的：

本发明公开了一种邮箱服务的实现架构，包括前端、中间层和后台服务器；所述中间层进一步包括通用网关接口(CGI)层和应用编程接口(API)层，且所述API层位于CGI层和后台服务器之间；其中，

所述CGI层，包括多个对应邮箱基础服务的业务逻辑部分，用于完成业务逻辑功能的处理；

所述API层，包括多个对应邮箱基础服务各资源接口的API，用于与后台服务器进行资源交互，并向上层应用提供所需的API。

上述方案中，所述前端包括前端模板引擎，所述前端模板引擎用于将后台服务器推送的数据解析为可读页面；所述后台服务器，用于存储或缓存数据，为前端和中间层提供所需数据。

上述方案中，所述API层包括的API为针对操作行为的接口。

本发明还公开了一种邮箱服务的实现方法，在邮箱服务架构的中间层设置API层，所述API层位于CGI层和后台服务器之间；该方法还包括：

将邮箱基础服务的资源接口和业务逻辑部分最大化分离，并将各个资源接口分别对应API；根据需要提取出邮箱基础服务中部分或全部资源接口对应的API，通过API调用方式提供给上层应用进行集成。

上述方案中，所述将各个资源接口分别对应API为：生成各资源接口对应的API，将分离出的业务逻辑部分和对应资源接口的API分别放置于CGI层和API层。

上述方案中，所述将邮箱基础服务的资源接口和业务逻辑部分最大化分离为：将单纯的功能点与逻辑点分开。

上述方案中，所述API层包括多个对应邮箱基础服务的各资源接口的API。

本发明提供的邮箱服务的实现架构及其实现方法，在现有架构的中间层增加设置应用编程接口(API，Application Programming Interface)层，API层位于CGI层和后台Server之间；并将邮箱基础服务的资源接口和业务逻辑部分尽量分离，业务逻辑部分和资源接口分别放置于CGI层和API层，仅由API层与后台Server进行资源交互，这样，最大程度的降低了邮箱服务架构中各部分的耦合度，可以避免后台Server的升级对前端和CGI层的影响，进而避免后台Server的微小升级对整体架构的影响。

本发明抽象并整理出对应各个邮箱基础服务资源接口的所有API，当运用于社区产品的应用时，可根据需要提取出部分或全部邮箱基础服务资源接口对应的API，通过API调用方式提供给上层应用进行集成，比如：在社区产品的应用中增加大附件的新功能，此时不需要单独重新开发，可直接将对应大附件功能的API以API调用方式提供给社区产品集成，来支持这一社区新功能的实现。本发明将现有邮箱服务架构进行了解耦，使整个邮箱服务架构变得更加独立与灵活；并且，可将邮箱基础服务中部分或全部资源接口通过API调用方式植入除社区产品以外的更多产品，提高了邮箱基础服务的通用性。

附图说明

图1为本发明邮箱服务实现架构的组成结构示意图；

图2为本发明邮箱服务实现方法的流程示意图。

具体实施方式

本发明的基本思想是：在邮箱服务架构的中间层设置API层，API层位于CGI层和后台Server之间；将邮箱基础服务的资源接口和业务逻辑部分最大化分离，并将各个资源接口分别对应API，根据需要提取出邮箱基础服务中部分或全部资源接口对应的API，通过API调用方式提供给上层应用进行集成。

这里，是利用API层作为中介，API层包括多个对应邮箱基础服务的各资源接口的API，使用所需的API完成与后台Server的资源交互，同时上层应用也可以通过调用需要的API方式实现所需的功能，如此，可使上层应用利用后台Server的资源完成所需的功能，而无需上层应用与后台Server之间进行直接交互或发生关联。

其中，所述API是预先定义的函数，用于提供应用程序与开发人员基于某软件或硬件的访问一组例程的能力，而又无需访问源码或理解内部工作机制的细节。

本发明邮箱服务的实现架构如图1所示，包括：前端10、中间层20和后台Server 30；其中，

所述前端10，包括前端模板引擎，所述前端模板引擎用于将后台Server推送的数据解析为可读页面；

所述中间层20，用于对后台Server推送的原始数据进行逻辑处理；所述中间层进一步包括CGI层201和API层202；具体的，

所述CGI层201，包括多个对应邮箱基础服务的业务逻辑部分，用于完成业务逻辑功能的处理，例如：将发送的邮件加上定时发送属性等等；

所述API层202，包括多个对应邮箱基础服务各资源接口的API，所述API是针对单纯操作行为的接口；

所述API层202，用于与后台Server 30进行资源交互，并向上层应用提供所需的API；

其中，所述操作行为可以是读邮件、写邮件、发邮件等，例如：从后台Server拿到邮件数据，通过发邮件接口推送出去；

这里，所述向上层应用提供所需的API具体是：向上层应用提供可调用的API，并由API提供固定的输入参数，换句话说就是，为上层应用提供可调用的所需功能对应的接口函数，调用时向相应API提供的固定输入参数赋值；之后，输出参数再供CGI层调用。

所述后台Server 30，用于存储或缓存数据，为前端10和中间层20提供所需数据。

本发明的实现架构中，所述CGI层包括的各个业务逻辑部分和API层包括的各资源接口的API，可以是预先将邮箱基础服务的业务逻辑部分和资源接口最大化分离得到的；也可以是在使用某个上层应用时同步将相应邮箱基础服务的业务逻辑和资源接口进行剥离得到的。

本发明邮箱服务的实现方法如图2所述，该方法的实现流程包括：

步骤201：在CGI层和后台Server之间设置API层，并将邮箱基础服务的业务逻辑部分和资源接口最大化分离；

其中，所述邮箱基础服务是指涉及邮箱服务的一些基础操作，如：发信、收信、邮件列表、文件夹列表等等，每种邮箱基础服务会对应资源模块；

这里，将所有资源模块进行梳理，并将资源接口与业务逻辑部分最大化分离，所述最大化分离是指将单纯的功能点与逻辑点分开，所述资源接口就是指功能点，例如：邮箱基础服务为只能发送100M以下的邮件，其中的功能点是发送邮件，逻辑点是判断邮件大小是否小于100M，相应的，最大化分离就是分为发送邮件的功能点和判断100M大小的逻辑点，发送邮件的功能点是资源接口，判断100M大小的逻辑点是业务逻辑部分，以此最大化的降低耦合度。

步骤202：生成各资源接口对应的API，将分离出的业务逻辑部分和对应资源接口的API分别放置于CGI层和API层；

这里，是将现有技术中资源接口和业务逻辑部分均写入CGI层的方式，改为将分离出的资源接口和业务逻辑部分分别写入CGI层和API层，即：将抽象的资源接口和涵盖业务逻辑的部分完全剥离，业务逻辑部分写入CGI层，对应资源接口的API放置于API层，每个API能完成对应资源接口的功能，如此，可保证提取资源的纯净性，从而只提供单纯的邮件基础服务的资源接口与后台Server之间的交互功能，例如：从后台Server得到某个用户的总邮件数。

在具体实现时，将资源接口输入、输出部分的参数进行梳理，并通过拟定的测试脚本方式进行控制，以确保稳定；所述拟定的测试脚本可根据业务上的输入、输出设计值编写。

本发明中，通过抽象接口即分离出功能点API的方式，实现阻隔业务逻辑部分与后台Server过强的耦合性。

步骤203：根据需要提取出部分或全部资源接口对应的API，通过API调用方式提供给上层应用。

这里，所述上层应用可以是社区产品，也可以是除社区产品以外的其他产品，均可通过调用方式将API提供给上层应用进行集成；其中，所述API是经过测试通过的稳定的应用接口，可通过独立的方式提供给上层应用；如此，就可以使其他产品复用已有产品如即时通信邮箱服务成熟、强大的后台服务，例如：漂流瓶应用、文件中转站应用等等。

具体来说，例如：已有产品是漂流瓶应用，从行为上讲，该应用就是推送一段信息发给接收者，其表现形式从视觉上看是一个漂流瓶操作，而抽象来看，该漂流瓶应用是一种发送信息的操作行为，那么，此时可使用发邮件的API，通过发邮件的API，可以将漂流瓶应用做更多表现，嵌入在其他产品中。

再例如：已有产品是文件中转站，文件中转站是一个大文件存储的API，实际就是一种存储的操作行为，可将存储行为放在邮箱中；也可以放在个人空间、网络硬盘产品中，等等。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (8)

1.一种邮箱服务的实现架构，包括前端、中间层和后台服务器；其特征在于，所述中间层进一步包括通用网关接口CGI层和应用编程接口API层，且所述API层位于CGI层和后台服务器之间；其中，

所述CGI层，包括多个对应邮箱基础服务的业务逻辑部分，用于完成业务逻辑功能的处理；

所述API层，包括多个对应邮箱基础服务各资源接口的API，用于与后台服务器进行资源交互，并向上层应用提供所需的API。

2.根据权利要求1所述的实现架构，其特征在于，所述前端包括前端模板引擎，所述前端模板引擎用于将后台服务器推送的数据解析为可读页面；

所述后台服务器，用于存储或缓存数据，为前端和中间层提供所需数据。

3.根据权利要求1或2所述的实现架构，其特征在于，所述API层包括的API为针对操作行为的接口。

4.一种邮箱服务的实现方法，其特征在于，在邮箱服务架构的中间层设置API层，所述API层位于CGI层和后台服务器之间；该方法还包括：

将邮箱基础服务的资源接口和业务逻辑部分最大化分离，并将各个资源接口分别对应API；根据需要提取出邮箱基础服务中部分或全部资源接口对应的API，通过API调用方式提供给上层应用进行集成。

5.根据权利要求4所述的实现方法，其特征在于，所述将各个资源接口分别对应API为：生成各资源接口对应的API，将分离出的业务逻辑部分和对应资源接口的API分别放置于CGI层和API层。

6.根据权利要求4或5所述的实现方法，其特征在于，所述将邮箱基础服务的资源接口和业务逻辑部分最大化分离为：将单纯的功能点与逻辑点分开。

7.根据权利要求4或5所述的实现方法，其特征在于，所述API层包括多个对应邮箱基础服务的各资源接口的API。

8.根据权利要求7所述的实现方法，其特征在于，所述API为针对操作行为的接口。

Images