简单分享开放平台的设计理念和思路

以前的一个电商开放平台，里面的设计思路和理念拿出来和大家分享一下

该平台统一各大电商服务提供方的服务，进行编排后提供为开放的API为各个业务产品服务。

在设计平台架构时，主要考虑以下几个因素：

1. 高并发和高吞吐量，我们采用分段式的架构，段与段之间采用同步非阻塞方式的通信方式，并且在http协议接入部分采用异步servlet方式。
2. 整个平台的可用性，这其中包括以下几个方面
   1. 整个系统的健壮可靠（QoS），包括流量控制、超时处理、重试、排队
   2. 资源最大化利用率，基于业务区分，不同的业务复杂度可能不一样，需要的资源会不一样，比如可以设置某个服务的处理线程数量
   3. 可伸缩，保证每一段都是可以伸缩的，无状态，负载均衡
3. 支持业务的动态部署更新，模块化

下面介绍一下平台的架构。 整个平台分为三段（接入、业务编排、接出），段与段之间采用分布式的部署方式，采用同步非阻塞NIO的通讯方式（Mina）。

接入段： 协议接入采用Jetty6 异步servlet，continuation安全认证，

1. 参数的MD5加密
2. 应用方需要申请一个应用key
3. 用户完成和第三方的绑定《用户名称和他对应的第三方的access key保存在开放平台中》
4. 用户《应用的使用者》需要事先登录该平台，获取开放平台的access key<加密解密>

流控，每个用户都需要申请流量，有流量的限制，可以防止对平台非预期的大的冲击

数据拆包封包，协议数据和平台标准数据格式的转换

业务编排段(路由)：

1. mina nio socket协议访问(线程池，根据业务来设置)
2. 服务容器<服务名称，编排逻辑---标准格式>，包括服务名称， 服务上下文，输入和输出定义，逻辑实现(服务上下文到逻辑输入的映射，输出参数到服务上下文的映射)

接出段：

1. 流量排队控制，由于无法保证第三方提供的服务质量，所以需要考虑这个控制
2. 超时控制，同上
3. 重试，同上
4. 数据拆包封包（安全内容，协议数据组装等）
5. 协议接出，以第三方的协议调用第三方的服务

服务的业务开发，是以单独的包的形式部署，每一个服务可以动态的上线、下线，并且有自己的classloader。

段节点的伸缩扩展，由于http请求是通过Nginx做负载均衡分发请求到接入段，所以接入段的扩展和可用性由nginx来保证；其他两个段利用zookeeper做节点的状态管理，调用方做监听，并进行轮询调用服务节点做负载均衡。