App架构设计经验谈:数据层的设计

一个App,从根本上来说,就是对数据的处理,包括数据从哪里来、数据如何组织、数据怎么展示,从职责上划分就是:数据管理、数据加工、数据展示。相对应的也就有了三层架构:数据层、业务层、展示层。本文就先讲讲数据层的设计。

数据层,是三层架构中的最底层,负责数据的管理。它主要的任务就是:

  1. 调用网络API,获取数据;
  2. 将数据缓存到本地;
  3. 将数据交付给上一层。

根据这三个任务,数据层可以再拆分为三层:网络层、本地数据层、交付层。

网络层

网络层主要就是对网络API的封装。关于API的设计,该系列的第一篇文章接口的设计已经讲过一些。关于如何封装,可以参考Android项目重构之路系列的架构篇和实现篇,其中接口层和本文的网络层是一样的。

还有一些在前面的文章中没有提及到的,在此做一些补充。

首先是不同网络状态的处理。当网络不可用时,则不应该再去调用API;当网络可用,但不是WIFI时,有些比较耗流量的操作也应该禁止,比如上传和下载大文件;当网络状态不同时,还可以采用不同的网络策略,比如,当网络为WIFI时,当前API可以返回更多更全面的数据,还可以预先加载相关联的其他API。

其次,为了节省流量,接口的设计上可以对数据进行简化。例如,对于一些列表类的接口,可以这么设计:只返回更新的部分,比如,上一次请求返回了10条按时间排序的数据,第一条数据为最新的,id为101,当发起下一次请求时,将101的id作为参数调用API,API查到该id,发现该id之后又新增了两条数据,API则只返回新增的这两条数据。

另外,为了保证程序的健壮性,调用API时,对入参的合法性检查也是很有必要的。而且,也应该定义好本地的错误码和错误信息,保证每个错误都能正常解析。

本地数据层

本地数据层主要就是做缓存处理,这需要设计好一套缓存策略。设计缓存策略时,有几个问题需要考虑清楚:

  1. 哪些需要缓存?哪些不需要缓存?
  2. 缓存在哪里?数据库?文件?还是内存?
  3. 缓存时间多长?

哪些需要缓存?

将所有数据都缓存是不明智的,不同的数据应该有不同的缓存策略,比如一个电商App,首页的商品列表数据应该缓存,而且缓存时间应该比较长,而每个商品的详情数据就没必要缓存或缓存时间很短。对于一份数据需不需要缓存,判断标准可以是:用户查看该数据的频率高不高?首页商品列表是用户每次启动都会看到的,而每个商品的详情用户最多只看几次。

缓存在哪里?

从内存读取数据是最快的,但内存非常有限。因此,内存一般只用来缓存使用频率非常高的数据。

文件缓存主要就是图片、音频、视频了。

数据库可以保存大量数据,主要就是用于保存商品列表、聊天记录之类的关系型数据。

然而,不管缓存在哪里,都需要限定好缓存的容量,要定期清理,不然会越积越多。

缓存时间多长?

首先,每份缓存数据都应该设置一个缓存的有效时间,有效期的起始时间以最后一次被调用的时间为准,当该数据长时间没有再被调用到时,就应该从缓存中清理掉。

缓存的有效时间应该设多长呢?可以短至一分钟,长至一星期甚至一个月,具体因数据而异。一般内存的缓存时间不宜太长,程序退出基本就要全部清理了。文件缓存可以设置保留一天或一个星期,可以每隔一天清理一次。数据库缓存再久一些也无所谓,但最好还是不要超过一个月。

交付层

交付层其实就是一个向上层开放的交互接口层,是上层向数据层获取数据的入口。上层向数据层请求数据,它是不关心数据层的数据是从缓存获取还是从网络获取的,它只关心结果,数据层能给到它想要的数据结果就OK了。因此,交付层主要就是定义一堆开放的接口或协议。

如果接口或协议非常多,那么,将接口或协议按照模块划分也是有必要的。比如微信,按模块划分有:IM、公众号、朋友圈、钱包、购物、游戏等等。模块之间应该尽量相对独立、松耦合。

写在最后

数据层如果再扩展,还可以再加入日志管理,这里就不再展开讲了。上面内容讲得也比较乱,有哪里讲得不好的地方欢迎吐槽。

原文发布于微信公众号 - Keegan小钢(keeganlee_me)

原文发表时间:2016-01-20

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏微信小开发

整合微信小程序的Web API接口层的架构设计

来源:伍华聪 cnblogs.com/wuhuacong/p/7267333.html 例如:《C#开发微信门户及应用--微信各个项目模块的定义和相互关系》介绍...

33110
来自专栏哲学驱动设计

Rafy 领域实体框架简介

按照最新的功能,更新了最新版的《Rafy 领域实体框架的介绍》,内容如下: 本文包含以下章节: 简介 特点 优势 简介 Rafy 领域实体框架是一个轻量级 OR...

1997
来自专栏韩伟的专栏

浅析海量用户的分布式系统设计(1)

为什么海量的用户访问,会让一个服务器端系统变得更复杂?本文就是想从最基本的地方开始,探寻服务器端系统技术的基础概念。

31.2K7
来自专栏杨建荣的学习笔记

运维系统重构的设计思路

最近要对已有的运维平台做重构工作,为什么要做重构,主要还是因为各种各样的原因,需要对已有的问题改进,修复历史遗留包袱。这个时间迟早都会来到,还不如自己自觉一点,...

1412
来自专栏服务端技术杂谈

扫盲贴-分布式数据一致性:两阶段提交,三阶段提交

分布式一致性 分布式系统中,为保证数据的高可用,通常将数据保留多个副本,这些副本放置在不同的物理机上。 什么是数据一致性 在数据有多副本的情况下,如果网络,服务...

5476
来自专栏携程技术中心

开源 | 携程Redis多数据中心解决方案-XPipe

作者简介 孟文超,携程技术中心框架研发部高级经理。2016年加入携程,目前主要负责Redis多数据中心项目XPipe。此前曾在大众点评工作,任基础架构部门通信团...

49110
来自专栏跨界架构师

做了「负载均衡」就可以随便加机器了吗?这三招来帮你!

        这篇是《分布式关注点系列》中「负载均衡」相关的内容最后一发了,后续也会继续讲「高可用」相关的其它主题,主要是限流、降级、熔断之类的吧,具体还没定...

1185
来自专栏.NET技术

关于分布式事务、两阶段提交协议、三阶提交协议

随着大型网站的各种高并发访问、海量数据处理等场景越来越多,如何实现网站的高可用、易伸缩、可扩展、安全等目标就显得越来越重要。

2072
来自专栏Java架构师学习

深入理解大型网站架构的核心——了解性能

1433
来自专栏python开发者

Web应用多账号系统设计及微信扫码登录实现

Web应用多账号系统设计及微信扫码登录实现 1   前言概述 公司对功能测试,性能测试,安全测试等等都做了比较好的自动化后,急需要一个MIS系统来统一管理这些结...

4706

扫码关注云+社区