安全可扩展的SaaS服务开放平台框架设计

，

(西南科技大学 计算机科学与技术学院,四川 绵阳 621010)

0 引言

开放是目前互联网的发展趋势，自2007年5月FaceBook正式开放其应用程序编程接口以来，各大平台也相继逐渐的开放了各自的API(Application Programming Interface)，建立了自己的开放平台。通过开放平台，不仅释放了平台的创造力，还能吸引第三方应用的用户，同时又丰富了用户体验，实现了三方共赢。SaaS(Software as a Service，软件即服务)服务作为一种新兴的软件模式在不断的发展和壮大，服务供应商提供给客户的服务种类也变得越来越丰富，其多租户(Multi-tenancy)[1-2]的特性，对于SaaS服务开放平台的安全性、并发性以及稳定性等方面也提出了越来越高的要求。

国内外著名的互联网企业都开放了其自己的开放平台，Google的OpenSocail就是其开放的第一步，FaceBook提出的F8开放标准，阿里巴巴集团的“大淘宝战略”也推出TOP开放平台，百度的“百度搜索开放平台”也开放了其搜索引擎，从技术架构上看，这些企业的开放平台都有其各自的技术特点和不同的框架。学术上也对开放平台的解决方案进行了许多的研究，朱蔚恒和周伟等人提出了一种开放平台架构模型，但是并未对稳定性和并发性作出深入的研究[3]。周巧也对开放平台系统进行了设计[4]，但是侧重于安全方面，对于性能及稳定性则没有深入讨论。虽然，现有开放平台有一些成熟的框架，但是在身份认证授权、灵活可扩展性及并发性能的处理方面，仍有待完善的地方，同时对于一些特定应用类型的开放平台框架，并不适用于SaaS服务开放平台。

由于不同业务类型对应的开放平台有其自身的架构特点，对于SaaS服务来说，常见的开放平台框架并不适用，需要提供一个适用于SaaS服务的开放平台框架。因此，基于SaaS服务对开放平台的需求，结合SaaS服务的特点，提出了一个安全可扩展的SaaS服务开放平台框架，并对其在安全性、稳定性等方面进行了分析。

1 开放平台技术研究

开放平台就是通过把网站的服务封装成一系列计算机易识别的数据接口开放出去，提供给第三方开发者使用，这种行为就叫做OPEN API，提供OPEN API的平台本身就被称为开放平台。SNS领域最具代表性的开放平台就是FaceBook的F8标准[5]，而国内电商平台中最具代表性的开放平台则是阿里巴巴的TOP(Taobao Open Platform)[6]，国内搜索服务最具代表性的开放平台则是百度搜索开放平台[7]。通过研究发现，它们虽然在技术架构上差异很大，但是涉及到的核心技术，则都包含了如下两个方面：

1)Oauth2.0[8]协议授权，主要是为应用提供一种标准的方式去访问受保护的资源。对于开放平台来说，这里的授权访问包括两个方面，一是客户端直接与服务端进行交互，没有用户参与的授权；另一种则是需要用户授权，客户端才能访问用户受保护的资源。Oauth协议为不同情况下的授权都提供的解决方案。

2)OPEN API架构风格，主要包含了RPC(Remote Procedure Call)和RESTful(Representational State Transfer)[9]。RPC即远程过程调用，它是一种通过网络向远程计算机程序请求服务，像调用本地服务一样调用服务。RESTful则是一种资源定位及资源操作轻量级的WEB服务架构风格，基于这个风格设计的软件更加简洁，更有层次，也更利于实现缓存等机制，所以这也是目前最流行的API风格。

由于开放平台是将服务接口直接对第三方的开发者提供，接口都是暴露在公网上，同时开发者的数量和API的调用频率等都有差异，开放平台在架构设计的时候，需要关注以下两个方面：

1)安全性。开放平台的开放API由于是对外提供给第三方开发者调用，所以必须是暴露在公网上，这导致的直接的问题就是开放平台的安全性问题，谷歌的开放API就曾经因为安全问题而在发布不久后就下架[10]。Oauth2.0自出现后，得到广泛关注，研究表明其框架在执行过程中存在令牌泄露，钓鱼攻击等威胁[11-13]，采用该协议的服务端存在 63.6%存在安全漏洞，作为客户端的网站也有 90.2%存在安全漏洞[14]。

2)稳定性。开放平台为不同的商家提供服务，API被大量不同的第三方进行调用，所以开放平台的稳定性直接决定了为第三方提供的服务质量。如果因为某一方的调用而影响其他用户的调用，对用户而言是不合理的。随着用户数量的增长，开放平台还必须支撑高并发情况下的API调用，保证在高并发情况下服务的稳定，对于并发超过平台上限的时候，还必须具备一定的限流策略，从多个方面保证平台的稳定性。

2 框架设计

通过对开放平台的研究，再结合SaaS服务对开放平台的需求，在保证安全性和性能以及稳定性的前提下，设计了一种安全可扩展的SaaS服务的开放平台框架，并对其做了性能和稳定方面的改进，为SaaS服务在搭建开放平台的时候提供一个参考依据。

2.1 整体框架结构

安全可扩展的开放平台框架由平台核心模块，辅助可配置的独立模块，及服务注册表和服务群组成，框架整体结构如图1所示。

图1 开放平台框架结构

平台核心模块主要由安全管理，流量管控，服务熔断，服务路由，负载均衡以及静态响应模块和可插拔的自定义模块组成，相较于传统的开放平台，提高了其扩展性，模块之间的松耦合也使得系统变得灵活可变。

其中安全管理模块负责开放平台的安全把控，通过对Oauth2.0授权流程的改进，增强了系统的安全性；流量管控模块负责在高并发情况下根据一定的策略对外部请求进行限流，保证了系统在高并发下达到系统上限时的稳定性；服务熔断模块的功能类似于电路总的保险丝，对下游的服务起到保护作用；服务路由模块负责对外部合法的请求进行转发，根据负载均衡模块提供的负载策略转发到下游服务；静态响应模块则负责在下游服务挂掉之后进行及时的响应。辅助可配置的独立模块则包含webhook响应，监控日志和授权组成，为核心模块提供安全保障和日志审计等功能。服务注册表用于维护下游API服务的基本信息，下游服务启动时，通过向开放平台发送自身的基本注册信息存储在注册表中，服务路由模块根据注册表中服务的信息，来对外部的请求进行转发。可扩展的后端服务群则是SaaS实际对外提供的服务Restful API集合，为租户提供实际的服务。

通过该框架设计，对于SaaS服务来说，第三方应用不用直接与具体服务的API进行通信，而是首先通过开放平台这个中间层，按照一系列的校验规则和路由策略，最终才到达后端服务，进行具体的业务处理。

2.2 关键模块及流程

开放平台自身通过维护一个注册表，来保证和后端的服务连接，当外部的HTTP/HTTPS请求进入开放平台后，根据请求的URL去注册表中找到对应的可用服务，然后将请求转发到具体的服务中。在转发以前，开放平台还会对请求进行一系列的安全校验以及管控，从而对内部服务达到一种保护和隔离的作用。

2.2.1 改进的Oauth2.0授权设计

如图1所示，系统的安全管理模块中设计独立授权服务模块，通过对Oauth2.0的研究，在标准Oauth2.0的基础上对其进行了改进，来对客户端进行授权，当客户端通过服务器的身份验证之后，为客户端颁发访问资源的令牌。客户端带着已授权的访问令牌，对API进行请求访问，开放平台首先会对请求进行安全性的校验，包括验证调用者的身份，访问资源的权限。对于不符合条件的请求，直接返回，不进行路由，避免攻击者恶意调用API。同时对于安全级别要求较高的资源，校验调用者是否有足够的权限对其进行访问。框架中包含了两种类型的授权:

1)没有用户参与，只对客户端访问API的情况进行授权。在Oauth2.0的客户端授权模式(client_credentials)的基础上，对其做了改进，引入了HMAC[15-16]摘要计算，避免了客户端在申请访问令牌token的时候在信道中直接传输客户端密钥SecretKey，有效的解决了密钥泄露的风险，增加了授权流程的安全性，改进后的授权流程如下图2所示。

图2 改进后的客户端授权流程

客户端想要访问开放平台的资源之前，需要到开放平台申请应用，开放平台对其进行身份认证，信息检查等之后，为客户端颁发应用ID和密钥，也就是AppKey和SecretKey。当客户端想要申请令牌的时候，就对AppKey和SecretKey以及其他附加参数做HMAC摘要计算，并以“算法”+“空格”+“AppKey”+“：”+“摘要值”的形式传递给授权服务器(Authorization Server)进行令牌申请。授权服务器通过解析出AppKey，再去寻找其对应的SecretKey，并以相同的方式计算出HMAC摘要，如果比较两个值一致，则颁发令牌，否则不颁发。由于在传输过程中传递的是hamc值，并不是客户端密钥，所以即使信息被截取，对于攻击者而言也是没有意义的，提高了授权流程中的安全性。

2)有用户参与的授权，当客户端需要访问用户受保护的资源时,需要得到用户自己的授权，从而授权服务器才能给客户端颁发令牌，也就是标准Oauth2.0中的授权码模式(authorization_code)。通过对标准授权码模式的授权流程的安全性分析，采用了基于信任机制的改进授权流程[17]，其授权流程如图3所示。

图3 改进的授权码模式授权流程

相比于Oauth2.0中的标准授权码模式流程中，图3中的授权流程引入了资源服务器(Resource Server)和授权服务器(Authorization Server)之间的同步信任机制，也就是在原有流程中增加了同步信任表，该信任表与安全节点相互配合可以防止客户端与授权服务器端，用户通信时被监听盗取令牌。当客户端申请资源的时候，资源服务器为其颁发一个pre-token令牌，同时授权服务器也会同步得到这个pre-token。当客户端得到用户授权后，去授权服务器申请资源的时候，会先去访问安全节点，安全节点检查是否存在pre-token 与用户对应,如果存在，则表明这个用户确实有资源请求的要求，允许该客户端访问授权节点，进而颁发访问令牌token。

2.2.2 高并发限流及熔断机制的设计

系统中流量管控模块设计了基于令牌桶算法[18]的限流策略，来实现对高并发下外部请求的流量控制。具体的设计思路就是根据令牌桶算法的特点，以一个恒定可配置的速度往桶里放入令牌，当HTTP请求到达时，如果该请求需要被处理，就从桶中取出一块令牌，路由的时候首先判断当前请求是否具有令牌，有则路由到下游API服务，没有则不进行路由。如果桶里没有令牌可取，那么后面的请求则需要排队等待，直到桶里有令牌才能进行后续操作。其流程图如图4所示。

图4 基于令牌桶算法的限流策略

如图4所示，令牌桶中当前持有的令牌数量为x，并且以每秒n个令牌的速率往桶中放入令牌，这个速率支持自定义配置。当每个外部请求到达流量控制模块，需要从令牌桶中取出一块令牌，然后路由模块才会将这些持有令牌的请求路由到下游API服务中。如果没有令牌，则不进行路由，直接返回。

在诺内特看来，“如果统治政权倾向于不顾被统治者的利益或者否认它们的正统性，那么它就是压制性的。”[2]因为，在这种法制模式下，最受关注的是权力的权威性及其形成的统治、管理秩序，为了实现这种秩序性核心价值，“刑法是法律官员关注的中心，是表现法律权威的典型方法。”[2]整体来看，中国古代历朝法制状况均系“言法必刑”“以刑为主”，由于其固有的强大威慑性，刑法成为治理手段的首选，其他的社会规范则退居其后，以致长期形成了社会治理刑法化的路径依赖。

当开放平台某个API请求过于集中而导致无法响应或是响应缓慢，如果没有设计合理的处理机制，最终将会导致整个下游API不可用。本框架中服务熔断模块设计了熔断保护机制，在外部请求和下游API之间起到了“保险丝”的作用，也提升了系统的稳定性。其工作流程如图5所示。

图5 服务熔断处理机制

图中外部请求进入开放平台对API-1，API-2，API-3进行访问时，API-2由于多次调用均失败(出现超时或者无法响应)，这时系统就会对API-2进行服务熔断，及时返回预设的静态响应结果。API-1和API-3由于没有被熔断，则返回正常的响应结果。为了保证服务熔断后能够重新连接并正常访问，该模块还设计了心跳检测机制，每隔一个时间间隔对API-2进行检测，如果能够正常响应，那么就关闭熔断，以保证API-2能够重新进行访问。

在负载均衡模块中，设计多组合方式的负载策略，该策略通过可配置的一个或者多个负载均衡策略的组合，选择相对合适的服务实例，对请求进行转发，实现平台内部的二级软负载。设计中默认的负载均衡策略包括：

1)选择一个并发请求最小的Server进行转发。

2)根据响应时间为每个服务的实例分配一个权重，响应时间越长，权重越小，被选中的可能性也越小。

3)以轮询的方式进行选择，对于同一个服务的每个实例，分配一个索引index，然后对index进行轮询，选择对应索引的服务进行转发。

配置多种负载均衡策略，为开放平台自身提供负载能力，降低了平台外部一级负载的压力，同时还支持设计自定义的负载策略，扩展负载均衡策略库，提高开放平台的性能。

2.2.3 基于注册表的可扩展性设计

可扩展性主要通过两个方面的设计来实现，一个是核心模块的可扩展性，另一个则是API服务的横向可扩展性。通过这两个方面的灵活设计，保证了开放平台在后续迭代和升级中可以灵活的进行扩展。

根据设计模式中单一职责的原则，每一个模块仅负责一个功能，各个模块之间没有相互依赖关系，它们都是独立的存在，降低了模块之间的耦合程度。通过各个模块的聚合，使得它们之间又相互协作，实现开放平台对于不同情境下的不同需求，保证了核心模块的可扩展性。另一方面，设计了一个长度可变的注册表，由于注册表中包含了每个API服务的名称，地址，多实例部署模式下各个实例对应的索引等信息，通过维护这个注册表，开放平台就能将外部请求路由到具体的服务中去。其中同步下线服务(cancel()方法)，同步注册服务(register()方法)，同步续约服务(renew()方法)三个方法代表了三个交互行为，通过这三个方法来维护后端服务和开放平台关联关系。当开放平台需要新增后端服务的时候，通过register()方法即可将服务添加到注册表中进行维护即可；当需要从注册表中解除关联关系，通过cancel()方法就能从开放平台注册表中下线该服务；同时还采用了心跳机制通过renew()方法来检测服务是否续约，以决定其是否满足继续存留在注册表中的条件。注册表的动态可变特性，满足了API服务的横向可扩展性。

3 安全可扩展开放平台安全性及性能分析

3.1 安全性分析

开放平台将一系列的服务数据接口对外开放，接口暴露在外部导致会存在诸多的安全性问题。因此，为保证开放平台安全性，本框架设计了安全管理模块，用于过滤那些恶意的无效的请求，防止恶意调用API造成平台接口的安全问题。对于外部请求做了严格的权限控制，只有当第三方调用者被授权之后，开放平台才会对这些请求进行路由。

在安全管理模块的基础上，设计了独立的授权模块，通过改进Oauth2.0中的一些安全问题,针对客户端授权和用户授权两种类型的授权流程进行了安全改进。在客户端授权流程中，根据HMAC算法的特点，加入了HmacSHA512摘要算法，对请求token时候的敏感数据做了加密处理，以“算法”+“空格”+“AppKey”+“：”+“摘要值”最为最终进行传递的数据，保证了客户端在申请token的时候不会暴露密钥，避免了客户端密钥被窃取的风险；在用户授权流程中，采用改进的Oauth2.0授权流程，引入了信任机制和安全节点，实现可信授权及节点的安全控制，防止了钓鱼攻击和信道监听而导致的安全隐患。

同时，实现监控模块，对第三方的调用记录进行实时的审计与监督，一旦发现异常的调用，可以及时采取相应的措施进行限制和禁用。因此，本框架从授权认证、接口信息加密处理及审计记录多个维度保证了开放平台的安全性问题。

3.2 稳定性与性能分析

为保证高并发的开放平台系统稳定性，从外部请求和内部服务两个方面来进行了改进。对于外部采取了限流的措施，通过限流管理模块，设计了基于令牌桶算法的限流策略，当外部请求的速率大于放入令牌桶中令牌的速率，导致桶中无令牌可用时，就进行流量限制，避免因过载而导致平台崩溃。为了防止个别API响应缓慢或无法提供服务时，由于大量的超时等待而导致整个开放平台堵塞，以及后端API来不及处理和响应大量的请求的情况出现，设计了服务熔断模块和负载均衡模块。多服务实例部署的方式能防止个别服务实例down掉的时候其他实例可以正常运行，以保证平台内部服务可以稳定的运行。

熔断机制在外部请求和API之间起到了保险丝的作用，对下游API进行保护的同时，当API无法响应或者响应超时的时候，实时的为客户端返回预设的静态响应，避免了客户端一直等待，对系统造成堵塞，影响开放平台整体的性能。载均衡模块设计了策略库，提供了默认的几种负载均衡策略，同时还支持扩充策略库。当外部请求进入的时候，负载均衡模块选择合适的负载策略，将请求分发到下游API服务实例上，避免了由于压力过大而出现某个服务实例崩溃的情况。

3.3 平台扩展性分析

对于一个SaaS服务的开放平台来说，必须要具备良好的扩展性，才能更好的支撑面向多租户的SaaS服务。针对传统SaaS开放平台扩展性不强的缺陷，在设计开放平台框架的时候，充分考虑了平台的可扩展性。根据设计模式中低耦合高内聚的设计原则，设计了多模块可组合的开放平台功能组件，保证了开放平台基础功能的可扩展性。通过自定义模块，可以根据实际需求，丰富开放平台的基础模块；为保证下游API能够方便的进行横向扩展，设计了注册表来维护下游API服务实例与开放平台的关联，使得下游API服务可以自由的进行扩展，这为SaaS扩展自身的业务提供了极大的便利。

4 总结

根据SaaS服务的特点和对开放平台的需求，设计了一个安全可扩展的OPBG框架，为SaaS服务搭建开放平台提供一个可参考的解决方案。兼顾了开放平台所需要的稳定性和高并发性，同时根据Oauth2.0标准授权流程中存在的安全隐患，对授权流程做了改进，提高了开放平台的安全性保障，松耦合的模块设计也提高了开放平台的灵活性与可扩展性。为SaaS服务开放平台提供一个基础的解决方案，还有一些有待改进的地方，比如对于一些热点数据进行特殊的处理，提高系统的效率。安全管理方面，对于访问控制策略和其他的安全限制及保障都有待提高和研究。