Android互动平台的分布式服务器结构设计——以创意者互动平台为例

周宇航 邱雷 谢凡殊

摘要：随着数据规模的越来越大，传统的集中式系统越来越难以满足需求，与此同时，分布式管理系统得到了广泛的应用。分布式系统相对单体应用而言，可以支持更高的并发访问量，并且可以根据业务极其灵活地调整节点数量，一个节点出现故障时也不会影响整个系统的运行。与集中式系统相比，分布式系统的性价比更高、处理能力更强、扩展性也更好。

关键词：互动平台;分布式服务器;MySQL;Spring;Android

中图分类号：TP311.5         文献标识码：A       文章编号：1009-3044（2018）35-0059-02

1 背景

目前，市场上各种应用的互动平台很多，但并没有专门针对用户个性化创作的互动交易平台。该课题组设计实现了一个基于Android的创意者互动平台，主要是为用户和商户搭建一个互动交易App环境。在互动平台上，帮助用户把自己的创意、设计提供给商户;帮助商户把创意融入DIY制作中，实体化用户的创意。

1.1 创意互动平台设计方案

创意互动平台主要面向用户为设计师、个体商家以及追求定制个性化商品的消费者。设计师可以在平台里售卖自己的设计稿;而个体商家可以买下这些设计稿后，做定制或是批量定制生产，将实体商品上架后供广大消费者选购。

平台实现的主要功能如下：1）用户的登录与注册;2）设计师发布自己的设计稿并定价;3）商家购买已上架且未被选购的设计稿;4）商家将设计稿批量生产为实体商品并定价上架;5）用户选购实体商品;6）用户之间通过私信进行联系;7）平台方举办活动或比赛，号召用户参与，加强平台与用户之间的黏性;8）用户之间互相关注;9）用戶在个人界面中修改自己的昵称及个性签名;10）用户为自己喜欢的设计稿、实体商品点赞;11）用户收藏自己喜欢的商家。

1.2 创意者互动平台的优点

该平台给予了设计师和商家一个方便的联系渠道，让设计师能够将自己想要的商品作为设计稿进行售卖，并且让商家可以通过用户的点赞来选购更具人气的设计稿进行批量或是定制生产。平台不但可以提高设计师设计稿的曝光率，也能让商家更清楚地明白怎样的设计稿是更具有市场的。这样的交易平台打破了以往商家供货——消费者选购的单一模式，而是变成了消费者选择自己心仪的设计稿——商家购买设计稿并做出实体商品供货——消费者进行选购的模式。

1.3 服务器需求

对于创意互动平台来说，网络服务是很重要的一环，而网络服务就离不开服务器的支持。服务器响应速度不够，网络服务就慢。服务器的响应速度可以通过提高单个服务器性能或者增加服务器数量实现，当然，更主要是从软件层面优化服务器端软件结构达到提高响应速度的目的。

同时，在对服务器端做性能优化的时候，还要考虑到服务器端程序的易维护性和可扩展性，编写出健壮稳定的服务器端代码。

2 平台基础结构设计

分布式资源共享服务器与传统集中式系统的区别在于：资源和程序可以不位于一个服务器上，而是分散到多个服务器。分布式服务克服了传统集中式系统会导致中心主机资源紧张与响应瓶颈的缺陷，可以方便应对突发流量高峰。

在高并发时，有很多的请求同时发送到服务器等待处理，会导致用户长时间得不到响应，尤其在用户请求的资源有数量限制时，用户不能知道请求是否成功，甚至用户请求到的资源数量超出实际数量，导致数据的一致性出错。这时候就需要有一个消息队列，有序的处理用户的请求，并且在流量高峰时堆积用户请求，防止业务服务器负载过高不能响应。

服务器端和客户端的交互采用了语言无关的Http协议和JSON数据格式，服务器端为客户端提供RestAPI用于请求数据，同时使用消息队列和分布式服务解决高并发问题。通过这些定义良好的接口和中间件， 服务器可以方便地实现扩容和替换组件实现。

2.1 Rest API

项目采用C/S结构，Android客户端通过Rest API向服务器请求数据。Rest API为客户端提供了统一的访问接口，方便添加其他客户端或网页应用。

2.2Json数据交换格式

JSON（JavaScript Object Notation）是一种轻量级的数据交换格式。JSON采用完全独立于语言的文本格式，这些特性使JSON成为理想的数据交换语言，易于阅读和编写，同时也易于机器解析和生成。

2.3 数据库选择和使用

MySQL是一个开源的关系型数据库，也是最流行的关系型数据库之一，因其速度、可靠性和适用性而备受关注。

2.4 消息队列

消息队列是一个容纳被发送的等待阅读的消息的区域，一旦一个消息被阅读，这个消息将会被从队列中移除。在该项目中，消息即客户端的Http请求。

3 平台的实现

3.1 服务器的主体框架实现

服务器端使用标准MVC设计模式。Controller层处理客户端的网络请求;Model层执行数据库的增删改查并为Controller层提供接口;View层负责将Controller层返回的信息以一定的形式展现。在这个项目中，View层实际上是Android客户端，Android客户端解析服务器返回的JSON字符串并展示相应的界面。

服务器程序的核心是SpringWebMvc框架。通过SpringWebMvc框架可以很简单地配置handler mapping，然后可以专注于编写处理网络请求的Controller逻辑。同时SpringWebMvc框架将模型和视图分离开，服务器端程序和视图解耦，便于扩展新的客户端模式。Spring的DI和AOP也极大地简化了服务器端程序的开发过程。

3.2 服务器和客户端数据交换的实现

在服务器端配置一个JSON消息转换器， Controller层并不直接返回客户端需要的数据模型， 而是返回一个Java对象，由消息转换器将Java对象转换成客户端需要的信息格式。比如，客户端向服务器请求JSON格式的数据，服务器端便使用JSON消息转换器将Java对象转换成JSON字符串返回给客户端;客户端需要XML格式的数据，服务器端便使用XML消息转换器将Java对象转换成xml返回给客户端。Controller不必关心客户端需要什么类型的数据，只需要将数据以Java对象的形式返回即可，由消息转换器将Java对象转换成客户端需要的格式。

3.3 服务器的数据库实现

服务器使用MySQL数据库，并通过在Spring中集成Hibernate框架访问数据库。通过操作Java对象实现数据库的增删改查，几乎没有直接编写SQL语句，减少了数据库访问的出错概率。

JDBC数据库连接池使用c3p0，不在每一次访问数据库时创建新连接，而是通过c3p0连接池重用数据库连接，避免了频繁的数据库连接初始化和释放，极大地减少了系统的響应时间。并且，根据预先的占用超时设定，可以强制回收被占用连接，避免数据库连接操作中的资源泄露。

3.4 服务器的业务逻辑实现

服务器收到消息后，由Spring的前端控制器DispatcherServlet将请求转发给相应的Controller，Controller中的方法将业务逻辑委托给一个或多个服务对象进行处理，并将处理完的信息，即模型数据发送回DispatcherServlet。

3.5 服务器的分布式实现

服务器分为业务服务器、数据库服务器、Session服务器和文件服务器四个部分。业务服务器处理网络请求;数据库服务器存储各项数据;Session服务器存储用户会话;文件服务器使用CDN为用户提供高速上传和下载文件服务。

业务服务器将每个用户的会话存储在Session服务器中（Session服务器中运行一个Redis数据库用于存储用户会话），在用户的每次网络请求中，通过Session服务器验证用户身份和权限。服务器Model层对数据库的增删改查操作则是使用数据库服务器中运行的MySQL数据库。文件服务器通过CDN不仅为用户提供了高速上传和下载服务，也极大地降低了业务服务器压力。

4 结束语

基于该文所配置的分布式服务器，成功地实现了一个基于Android的创意者互动平台。该文从创意者互动平台的需求分析，到服务器设计，再到实现做了详细的描述，整体完成了平台的分布式服务器结构实现。服务器端严格按照MVC设计模式，多层次分离，主要功能之间解耦，为更新和扩展提供了良好的代码基础。服务器各个功能以组件的形式设计，每个组件都可以单独替换，并且这些设计对客户端透明，服务器端的组件替换和性能优化不需要修改客户端。使用语言无关的JSON数据交换格式，也使客户端可以有多种不同平台的实现。

参考文献：

[1] Craig Walls. Spring实战[M].4版.北京： 人民邮电出版社， 2016.

[2] 李刚. 轻量级JavaEE企业应用实战[M].4版.北京： 电子工业出版社， 2014.

[3] Eric Freeman. HeadFirst设计模式：中文版[M].北京： 中国电力出版社， 2017.

[4] Kirk Knoernschild. Java应用架构设计：模块化模式与OSGI[M].北京：机械工业出版社， 2016.

[5] Ben Forta. MySQL必知必会[M].北京：人民邮电出版社， 2009.

[通联编辑：谢媛媛]