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。

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

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