App架构经验总结(一)

原文链接:http://keeganlee.me/post/architecture/20160303 版权声明:本文刊载在《程序员》杂志2016年3期,版权归《程序员》所有,未经许可不得转载


架构因人而异,不同的架构师大多会有不同的看法;架构也因项目而异,不同的项目需求不同,相应的架构也会不同。然而,有些东西还是通用的,是所有架构师都需要考虑的,也是所有项目都会有的需求,比如API如何设计?架构如何分层?开发环境和生产环境如何分离?这几年,我负责研发过的App,有餐饮类的、社交类的、智能家居类的、电商类的、新闻媒体类的等等。当有了一定的经验之后,你总会有一些自己的心得体会。而以下内容就是根据我的这些经历提炼出来的关于以上几个问题方面的经验总结,内容不多,旨在抛砖引玉。

从API开始

一个App,最核心的东西,其实就是数据,而数据的主要来源,就是API。我之前负责的项目,因为API的坑已经受过了不少苦,因此,之后对App项目的架构设计我都会先从API开始。

制定安全机制

设计API第一个需要考虑的是API的安全机制。我负责的上一个项目,因为API的安全问题,就被人攻击了两次。之后经过分析,主要存在两个漏洞:一是因为缺少对调用者进行安全验证的方式,二是因为数据传输不够安全。那么,制定API的安全机制,主要就是为了解决这两个问题:

  1. 保证API的调用者是经过自己授权的App;
  2. 保证数据传输的安全。

第一个问题的解决方案,我主要采用设计签名的方式。对每个客户端,Android、iOS、WeChat,分别分配一个AppKey和AppSecret。需要调用API时,将AppKey加入请求参数列表,并将AppSecret和所有参数一起,根据某种签名算法生成一个签名字符串,然后调用API时把该签名字符串也一起带上。服务端收到请求之后,根据请求中的AppKey查询相应的AppSecret,按照同样的签名算法,也生成一个签名字符串,当服务端生成的签名和请求带过来的签名一致的时候,那就表示这个请求的调用者是经过自己授权的,证明这个请求是安全的。而且,每个端都有一个Key,也方便不同端的标识和统计。为了防止AppSecret被别人获取,这个AppSecret一般写死在代码里面。另外,签名算法也需要有一定的复杂度,不能轻易被别人破解,最好是采用自己规定的一套签名算法,而不是采用外部公开的签名算法。另外,在参数列表中再加入一个时间戳,还可以防止部分重放攻击。

第二个问题的解决方案,主要就是采用HTTPS了。HTTPS因为添加了SSL安全协议,自动对请求数据进行了压缩加密,在一定程序可以防止监听、防止劫持、防止重发,主要就是防止中间人攻击。苹果从iOS9开始,默认就采用HTTPS了。而关于在Android中如何使用HTTPS,Google官方也给出了很多安全建议。不过,大部分App并没有按照安全建议去实现,主要就是没有对SSL证书进行安全性检查,这就成为了一个很大的漏洞,中间人利用此漏洞用假证书就可以通过检查,从而可以劫持到所有数据了。因此,为了安全考虑,建议对SSL证书进行强校验,包括签名CA是否合法、域名是否匹配、是不是自签名证书、证书是否过期等。

接口协议标准化

API返回的数据,一般都是采用JSON格式进行传输。然而,JSON的值只有六种数据类型:

  • Number:整数或浮点数
  • String:字符串
  • Boolean:true 或 false
  • Array:数组包含在方括号[]中
  • Object:对象包含在大括号{}中
  • Null:空类型

我遇到过的,关于API的坑有大部分就是因为JSON数据和实体对象转化时出错导致的,而且是各种各样的错误都有,其中不乏有一些很奇葩的错误。

最麻烦的就是处理Date类型,因为JSON本身没有Date类型,因此,JSON库将Date类型的数据序列化时会转为String。这时,不同环境,不同平台,以及用不同的JSON解析库,转换后的结果经常会不同。比如,你在开发机上可能得到的结果是”2016-1-1 17:11:11”,但放到服务器后结果却变成了“Jan 1,2016 5:11:11 PM” ,客户端进行反序列化时无疑会失败。后来,我取消了所有Date类型,统一采用时间戳表示,就再没有转化的烦恼了。

另外,接口的开发人员有时候会将一些数据错误地转换为了String,导致客户端使用时因类型错误而异常。例如,本来是数字的1,被转成了”1”,客户端做运算时就会出错,或用switch判断时也会出错,或其他无法转换的情况发生时;例如,为空时JSON正确地表示应该是null,但如果转为了String就变成了”null”,那问题就来了,我遇到的因为这个错误的转换导致的程序奔溃已经好几次了,第一次的时候,查了一整天才定位到问题所在。

还有,因为接口的开发人员不同,很多时候还会出现不同接口同一个意思的参数名称却不同。比如,对于有分页数据的接口,一般都有当前页的参数,A开发人员可能将参数命名为currentPage,第一页是从0开始;B开发人员在另一个接口则命名为currPage,第一页却从1开始;C开发人员在另一个接口又命名为presentPage,第一页又是从0开始。客户端的开发人员看到也是醉了。

每个技术团队一般都会有一份接口协议文档,主要内容包括每个接口的描述、入参、输出结果等,但一般并不严谨,很多地方没有统一标准,从而容易出现很多坑。因此,有一份统一标准且严格执行的接口协议非常重要。协议的内容除了规定每个接口,包括接口中每个数据具体的数据类型,还需要规定一套共用的数据字典,以及其他需要统一定义的信息,比如签名算法等。一旦有了这份统一标准且严格执行的接口协议,很多问题都将迎刃而解。

接口版本控制

我们已经不止一次因为接口发生变动而导致旧版本的App出错的问题,而且变动不一定是修改了接口本身,有可能是底层增加了一种新的数据结构,接口把新数据也返回给客户端了,但客户端旧版本是解析不了的,从而就导致出错了。

为了解决接口的兼容性问题,需要做好接口版本控制。实现上,一般有两种做法:

  1. 每个接口有各自的版本,一般为接口添加个version的参数;
  2. 整个接口系统有统一的版本,一般在URL中添加版本号,比如http://api.domain.com/v2。

平时小版本的更新,就采用第一种方式,我们的做法是根据不同版本号做不同分支处理。大版本的更新,则用第二种方式,这时候,基本就是一套全新的接口系统了,跟旧版本是相对独立的。

当版本越来越多时,维护就会成为一个大问题,我们没那么多精力去维护所有版本,因此,太旧的版本一般就不会再维护了。这时候,如果有用户还在使用即将废弃的旧版本,需要提醒用户升级到新版本。

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

原文发表时间:2016-03-03

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏平凡文摘

怎样编写高质量的Java代码

1713
来自专栏SeanCheney的专栏

深入理解Python异步编程(上)

彻底理解异步编程是什么、为什么、怎么样。深入学习asyncio的基本原理和原型,了解生成器、协程在Python异步编程中是如何发展的。

7382
来自专栏nothing

游戏服务端开发的逻辑解耦思路

最开始的代码库中,主循环收到协议后,通过手写的路由关系转交给对应的业务逻辑类实现。

2533
来自专栏web前端教室

前端开发就是这样,“看似简单的东西,反而会很复杂。”

今天的零基础前端课讲到了一个tab地址切换的菜单,就下面这个东西, ? 第一眼看起来超级简单,无非是点击上面的title显示下面的菜单,然后点省市区把内容选上去...

2226
来自专栏做全栈攻城狮

Python实战:Python爬虫学习教程,获取电影排行榜

Python应用现在如火如荼,应用范围很广。因其效率高开发迅速的优势,快速进入编程语言排行榜前几名。本系列文章致力于可以全面系统的介绍Python语言开发知识和...

1425
来自专栏小尘哥的专栏

小程序(1)-入坑

老板想要一个小程序的东西,作为实诚却又没干过小程序开发的程序猿,二话不说,撸起袖子,开整。

1595
来自专栏Python中文社区

使用Python分析nginx日志

使用Python分析nginx日志 专栏作者:熊球 ♚土木工程毕业,现从事web后端开发方面的工作,擅长python,flask框架等。 博客:codechat...

31010
来自专栏腾讯数据库技术

Linux调度原理介绍和应用(前篇)

3744
来自专栏java一日一条

怎样编写高质量的Java代码

怎样辨别一个项目代码写得好还是坏?优秀的代码和腐化的代码区别在哪里?怎么让自己写的代码既漂亮又有生命力?接下来将对代码质量的问题进行一些粗略的介绍。也请有过代码...

1671
来自专栏python开发者

python自动化测试(4)-使用第三方python库技术实现

python自动化测试(4)-使用第三方python库技术实现 1   概述 关于测试的方法论,都是建立在之前的文章里面提到的观点: 功能测试不建议做自动化 接...

2955

扫码关注云+社区

领取腾讯云代金券