大型互联 企业平台开放技术实践

转自：程序架道 ID: xindongbook17

本篇文章一共分为四个部分，分别是开放生态、开放 关、开放授权和开放安全。为什么要做开放，开放的技术实现有哪些，主要是开放 关和授权，同时我们开放了以后肯定还需要安全，需要开放的安全保障。

我们在接下来的叙述中，要有一个开放的业务模型来作为基础，这点很重要不然不太好理解开放生态里面包括的这些角色。现在，下面这幅图展示的这个业务模型中的角色有企业、独立软件服务商(ISV)、商家，商家在企业平台上面开一个店铺，比如京东商城上的第三方卖家，他们的店铺。这里面的流程是这样的，商家会在他们的店铺上发布商品，最终用户，就是比如我们这些个体最终的消费者来购买商家的商品，这样的行为都会产生数据到企业平台上面；ISV会通过企业平台的开放接口来开发商家所需要的软件并发布到服务市场上面售卖；商家从服务市场去购买这些软件，比如购买了一款管理商品的软件，那么后续商家就可以使用这款软件更有效率的来管理他的店铺里面的商品，上新、更改图片、更改描述、上下架等等操作。

选取一种IO线程模型，一般情况下我们通过WEB服务器接收一个请求，然后由一个线程来处理解析REQUEST请求的参数，继而继续进行后续的业务逻辑处理，类似下图所示。比如默认的WEB服务器中的SERVLERT机制下也是这样处理的，这样会带来一个不好的方面就是，现在这个接收REQUEST的请求线程和处理业务逻辑的线程是同一个，业务处理简单或者业务耗时极快没有问题，当然这都是理想状态下，真实的生产环境中，我们基本不会有这样简单的事情发生的，都会需要去继续做一次RPC调用，比如请求数据库，请求第三方接口服务等等。那么在IO请求线程和业务处理线程是同一个的这样的情况下，如果业务处理突然变得很慢了，前方的用户请求量又继续增加，就会不断的创建线程，极端情况下就会堆满整个CPU，也就是上面我们说过的可能会发生雪崩。我们利用servlet3的异步化机制，就可以实现IO请求线程和业务处理线程分开，这样会直接带来一个最大的好处是，使得我们可以将业务线程去隔离分组，接下来还会重点介绍。我们还是先继续说servlet3异步的使用，异步了之后会带来吞吐量的提升吗strong>想当然的理解会，其实不然，这还少要看接收请求之后是如何处理的，如果仍然是同步调用的RPC，那么吞吐量在servlet3异步和不适用异步是没有多大区别的，因为响应的时间要取决于这段同步的RPC的时延。另外我们可能还会遇到threadlocal的问题，如果原先的系统中有使用threadlocal来传递上下文参数，在我们使用servlet3异步化之后就失效了，因为发生了线程切换了，这个时候可以有两种方法来解决，一种是做代码的改造通过传递参数的方式来实现，另外一种方法是将一些通用变量放在HttpServletRequest的Attribute里，异步上下文中保持了对HttpServletRequest的引用，然后通过一些工具类直接从HttpServletRequest提取所需要的参数值。

再来说下管道，我们这里用的是管道技术这个词语，这样可以方便表现它的实现的技术特点，实际上它更是一种思想，一种管道的思想，管道我们很容易理解像图中展示的这样，一段接着一段的连接起来的。每一个请求进入 关系统开始都会经过这样每一段的管道，比如处理黑白名单的，处理降级限流的，可以看出所谓的管道实际上是我们把这样的功能处理形象化成了管道，如下图所示，具体实现上则可以将这样的功能定义为一个Pipe类，然后将这个Pipe类在包装成一个实现了Runnable的Task，再将这个Task交给事先定义好的ThreadPool线程池来处理。这些Pipe类都是提前开发好的，事先都会给每一个API方法分配一定数量的管道，通过使用Map对象来存储API的method名称跟管道的对应关系，这样当每个API方法被请求的时候都会经过这些管道来处理，如果想去掉某个管道直接通过配置来卸载掉就可以了。所以我们也看出来管道技术的特点一个是顺序性，另外一个是具备热插拔特性，当然这些的前提是我们事先要定义并实现好这些管道。

在整个Oauth2的授权流程中，有两个关键词一个是code授权码，就是最开始的时候拿到这个授权码以后，你才能继续往下；另外一个是accestoken访问码，就是必须通过这个访问码才可以获取到用户的资源。在整个Oauth2的环境下一共有四种授权类型，今天我们着重要讲述的是步骤最多也是最安全的一种授权码方式，详细步骤如下图所示。资源拥有者去使用ISV的软件，ISV的软件需要通过重定向的方式跳转到平台所提供的授权页面，这也是我们常说的发生了第一次重定向，此时如果该用户没有登录则需要登录，如果已经登录那么点击授权动作之后会请求平台的授权服务器，授权服务器会再次重定向到ISV软件的URL地址上，此时这个URL会带着一个code码返回，紧接着ISV会通过后端post的方式把code码重新传回授权服务器，授权服务器会返回一个accestoken，这样经过图中所示的6个步骤的操作，ISV软件便拿到了accestoken访问码，继而可以继续访问资源服务器了，这便是整个Oauth2下的授权码流程，我们日常生活中在大型的平台上所使用的第三方软件，比如微信里的小程序，它们的工作方式几乎都是采用的Oauth2的流程。详细Oauth2介绍可参看这篇文章

《大话Oauth2.0(二)、标准流程下的Oauth2组件及通信》

有了Oauth2就能解决越权的问题吗，答案是，否。授权在开放平台的环境下只是解决了ISV软件获取数据的”合法性”，并不能够解决越权的问题，因为上文我们也提到了开放 关和开放授权，其中开放授权从技术的落地上来讲是放在了开放 关里面去验证的，但是开放 关所依赖的服务，比如订单服务、商品服务等，如果这些服务没有做数据归属的判断，仍然无法解决越权的问题。举个例子来讲，还是通过订单ID获取订单数据，ISV的软件传入了订单ID和accestoken两个字段，在经过开放 关的时候开放 关将accestoken置换成了pin，传给了订单服务层，但是订单服务层如果不去做验证这个订单ID对应的订单信息是否是该pin下的，那么就发生了水平越权，如果此漏洞被利用则直接能够获取到所有商家的订单，因此订单服务还需要做数据归属判断才可以避免该安全问题。整个流程如下图所示。