昆明的房产网站建设,做网站做百度竞价赚钱,淄博什么兼职的网站建设,wordpress主题语言包原文地址#xff1a;http://www.iteye.com/news/31472-------------------------------------------------------------架构因人而异#xff0c;不同的架构师大多会有不同的看法#xff1b;架构也因项目而异#xff0c;不同的项目需求不同#xff0c;相应的架构也会不同。… 原文地址http://www.iteye.com/news/31472 ------------------------------------------------------------- 架构因人而异不同的架构师大多会有不同的看法架构也因项目而异不同的项目需求不同相应的架构也会不同。然而有些东西还是通用的是所有架构师都需要考虑的也是所有项目都会有的需求比如API如何设计架构如何分层开发环境和生产环境如何分离这几年我负责研发过的App有餐饮类的、社交类的、智能家居类的、电商类的、新闻媒体类的等等。当有了一定的经验之后你总会有一些自己的心得体会。而以下内容就是根据我的这些经历提炼出来的关于以上几个问题方面的经验总结内容不多旨在抛砖引玉。 从API开始 一个App最核心的东西其实就是数据而数据的主要来源就是API。我之前负责的项目因为API的坑已经受过了不少苦因此之后对App项目的架构设计我都会先从API开始。 制定安全机制 设计API第一个需要考虑的是API的安全机制。我负责的上一个项目因为API的安全问题就被人攻击了两次。之后经过分析主要存在两个漏洞一是因为缺少对调用者进行安全验证的方式二是因为数据传输不够安全。那么制定API的安全机制主要就是为了解决这两个问题 保证API的调用者是经过自己授权的App保证数据传输的安全。 第一个问题的解决方案我主要采用设计签名的方式。对每个客户端Android、iOS、WeChat分别分配一个AppKey和AppSecret。需要调用API时将AppKey加入请求参数列表并将AppSecret和所有参数一起根据某种签名算法生成一个签名字符串然后调用API时把该签名字符串也一起带上。服务端收到请求之后根据请求中的AppKey查询相应的AppSecret按照同样的签名算法也生成一个签名字符串当服务端生成的签名和请求带过来的签名一致的时候那就表示这个请求的调用者是经过自己授权的证明这个请求是安全的。而且每个端都有一个Key也方便不同端的标识和统计。为了防止AppSecret被别人获取这个AppSecret一般写死在代码里面。另外签名算法也需要有一定的复杂度不能轻易被别人破解最好是采用自己规定的一套签名算法而不是采用外部公开的签名算法。另外在参数列表中再加入一个时间戳还可以防止部分重放攻击。 第二个问题的解决方案主要就是采用HTTPS了。HTTPS因为添加了SSL安全协议自动对请求数据进行了压缩加密在一定程序可以防止监听、防止劫持、防止重发主要就是防止中间人攻击。苹果从iOS9开始默认就采用HTTPS了。而关于在Android中如何使用HTTPSGoogle官方也给出了很多安全建议。不过大部分App并没有按照安全建议去实现主要就是没有对SSL证书进行安全性检查这就成为了一个很大的漏洞中间人利用此漏洞用假证书就可以通过检查从而可以劫持到所有数据了。因此为了安全考虑建议对SSL证书进行强校验包括签名CA是否合法、域名是否匹配、是不是自签名证书、证书是否过期等。 接口协议标准化 API返回的数据一般都是采用JSON格式进行传输。然而JSON的值只有六种数据类型 Number整数或浮点数String字符串Booleantrue 或 falseArray数组包含在方括号[]中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出错的问题而且变动不一定是修改了接口本身有可能是底层增加了一种新的数据结构接口把新数据也返回给客户端了但客户端旧版本是解析不了的从而就导致出错了。 为了解决接口的兼容性问题需要做好接口版本控制。实现上一般有两种做法 每个接口有各自的版本一般为接口添加个version的参数 整个接口系统有统一的版本一般在URL中添加版本号比如http://api.domain.com/v2。 平时小版本的更新就采用第一种方式我们的做法是根据不同版本号做不同分支处理。大版本的更新则用第二种方式这时候基本就是一套全新的接口系统了跟旧版本是相对独立的。 当版本越来越多时维护就会成为一个大问题我们没那么多精力去维护所有版本因此太旧的版本一般就不会再维护了。这时候如果有用户还在使用即将废弃的旧版本需要提醒用户升级到新版本。 架构分层 API的设计完成之后接下来我就会考虑App项目的整体架构了。整体如何架构我也曾经做过不少尝试。早期的时候Android就是将所有操作都放在Activity里完成包括界面数据处理、业务逻辑处理、调用API。后来发现Activity越来越臃肿代码越来越复杂很难维护。于是就开始思考如何拆分如何才能做到松耦合高内聚。 前面也说过一个App的核心就是数据那么从App对数据处理的角色划分出发最简单的划分就是数据管理、数据加工、数据展示。相应的也就有了三层架构数据层、业务层、展示层。它们之间的关系如下图数据层是三层中的最底层往下它接入API往上它向业务层交付数据。业务层夹在三层中间属于数据的加工厂将数据层提供上来的数据加工成展示层需要展示的数据。展示层处于三层中的最上层主要就是将从业务层取得的数据展示到界面上。 数据层 数据层是数据管理者主要任务就是封装API并将数据结果交付给上层中间会再加个数据缓存。整个主流程如下图 业务层向数据层请求数据数据层检查缓存中有没有请求需要的数据如果有缓存数据则直接返回缓存数据如果没有缓存数据则从网络API获取数据并将数据加入缓存然后返回数据。 调用网络API时还要判断网络状态根据不同状态做不同处理。如果网络不可用就无需发起请求了。网络可用时也要区分是连接WIFI还是连接移动网络。连接移动网络时一般需要限制调用比较耗流量的请求。曾经我们没有对移动网络状态下的请求进行限制结果测试时流量DuangDuangDuang地一下子就不见了十几M。连接WIFI时则无需设置这种限制而且还可以预先请求一些接口比如请求当前分页数据时可以将下一页的数据也预先请求。 缓存也需要缓存策略不同的接口需要做不同的缓存处理。首先缓存只适用于获取数据的接口对于修改数据的接口则不适用。其次不同接口缓存时间一般也不同对于很少变动的数据缓存时间可以设置长一些而频繁变动的数据缓存时间则比较短甚至不进行缓存。最后缓存数据因为比较多我们一般保存在数据库而对于调用频率高、最新的数据还会在内存中也拥有一份缓存不过缓存时间比较短。请求缓存数据时会先检查内存缓存中有没有有则直接将缓存的数据返回没有才从数据库获取。 那么如何将数据交付给业务层呢这是整个数据层模块与外部交互的部分当与外部交互的时候一般都要符合面向接口编程的原则因此只要提供开放的数据接口就可以了。对于接口的参数需要说明一下上面提到的参数有appKey、version、currentPage这几个还有签名sign、时间戳time其实可以分为两类系统参数和业务参数。像appKey、version、sign、time这些属于系统参数而currentPage或username之类的则属于业务参数。数据层开放的数据接口的参数只需要包含业务参数就可以了业务层并不需要关心系统参数是什么系统参数在数据层内部封装API时指定就可以了。 业务层 业务层是数据加工者主要就是从数据层获取数据然后经过业务逻辑处理后转化成展示层需要的数据。业务层因为夹在数据层和展示层中间起着承上启下的作用。也因此业务层很容易沦落为只是一个数据的中转站主要就是因为对业务层具体的作用和职责没有理解清楚。 这里用一个例子来说明业务层具体的工作吧就举个用户注册的例子。用户注册时界面上需要用户提供手机号、短信验证码、密码、确认密码。那么最简单的操作就是带上这些参数调用数据层的注册接口。好了问题来了注册接口并没有提供确认密码的参数。那好调用注册接口之前先判断下密码和确认密码是否一致不一致则返回错误提示给用户一致了才调用注册接口。好了第二个问题来了用户等网络请求等了一段时间后请求结果返回说手机号少了一位。下一次又等了一段时间这次又返回说手机号多了一位。就因为一个小错误要让用户等那么久用户肯定有意见。后台也有意见各种非法的请求都发过来是嫌服务器压力不够大啊。那好调用接口之前对这些参数做有效性检查吧手机号要规范短信验证码只能为六位数字密码不能少于六位。终于注册成功了第三个问题又来了注册接口是没有返回用户的accessToken的只有登录接口才会返回。让用户手动再登录一下这用户体验不太好啊。正确的姿势应该是注册成功后再自动调用一次登录接口如果因为网络问题第一次登录失败后面还需要再自动调用多一次如果还是调用失败才让用户手动登录。 上面的例子中对参数的有效性检查注册成功后的自动登录都属于业务逻辑的处理也就是说都是业务层的工作。 业务层交付给展示层的数据也是通过接口的方式不过和数据层交付给业务层时不同的是交付给展示层的数据应该是通过异步回调返回的。因为获取数据是一个比较耗时的任务通过异步回调才不会阻塞UI主线程。 展示层 展示层作为数据展示者它只要关心数据如何展示就可以了。不过数据如何展示却不是那么简单。展示层是三层架构中最复杂的一层了要考虑的东西远远多于其他两层涉及的东西包括但不限于界面布局、屏幕适配、图片资源、文本资源、颜色资源等等。在开发一段时间后展示层出现代码混乱是最常见的。因此做好展示层就需要保持高质量的代码。要保持高质量代码我觉得至少应该遵循几条基本的原则 保持规范性定义好开发规范包括书写规范、命名规范、注释规范等并按照规范严格执行保持单一性布局就只做布局内容就只做内容各自分离好每个方法、每个类也只做一件事情保持简洁性保持代码和结构的简洁每个方法每个类每个包每个文件都不要塞太多代码或资源感觉多了就应该拆分。 所谓无规矩不成方圆展示层的设计要从开发规范开始。一份好的开发规范是保证代码有较高的可读性的基础。iOS方面苹果已经有一套Coding Guidelines主要属于命名方面的规范。当我们制定自己的开发规范时首先就要遵守苹果的这份规范在此基础上再加上自己的规范。Android方面我也在我的博客中分享过一套Android技术积累:开发规范主要分为书写规范、命名规范、注释规范三部分。 最重要的不是开发规范的制定而是开发规范的执行。如果没有按照开发规范去执行那开发规范就等于形同虚设那代码混乱的问题依然得不到解决。 说到单一性面向对象设计中有一个基本原则就是单一职责原则它规定一个类应该只有一个发生变化的原因。保持单一性是减低耦合度的关键标准其目的就是各方面的解耦。而我这里说的单一性不只是规定类的单一也包括界面的单一、方法的单一、资源文件的单一等。 界面的单一首先是界面的布局和界面的数据应该分离。另外界面数据的获取和展示也应该分离。一句话保持界面的单一性就是要保持界面上每个维度都做好分离从界面的布局到数据的获取数据的检查数据的展示。 方法的单一则表现为一个方法是对一个行为的封装。行为又可以拆分为多个步骤每个步骤其实也是更细化的行为。因此方法嵌套方法是一种常态。那么保持方法的单一性关键不在于怎么定义这个方法的行为而在于这个行为要怎么拆分成更细的行为。举个例子通常在Activity的onCreate方法做初始化操作细分出来就分为了控件的初始化、逻辑变量的初始化、数据的初始化。数据的初始化又可以再细分数据的获取、数据的展示。每个细化的行为都应该封装为一个独立的方法这样才真正符合方法的单一性。 资源文件的单一主要是指Android的各类资源文件包括存放字符串的strings.xml存放字符串数组的arrays.xml存放颜色值的colors.xml存放尺寸值的dimens.xml等等。资源文件的单一是说所有相关的资源信息要在资源文件里定义并引用到代码或布局文件里而不是在代码或布局文件里直接定义。这样做可以很方便地做各种适配和修改比如支持国际化比如不同分辨率的屏幕用不同尺寸值。iOS则没有提供和Android一样的资源文件分离的机制但可以参考Android的做法自己去实现。 环境分离 每个App项目至少都会有两个环境测试环境和生产环境。多的甚至有四个环境开发环境、测试环境、预生产环境和生产环境。开发人员经常需要在环境之间切换测试人员也同样。经常出现测试人员今天需要测试环境的最新版本叫App开发人员打包一个给她明天需要切换到生产版本再叫App开发人员打包一个生产环境的给她。我们知道一个App在一台手机上要么只能是测试环境的要么只能是生产环境的。测试人员要测试两个环境只能不断替换不同环境的同个App这实在太麻烦了。为了解决此问题最好的方案就是环境分离不同环境有不同的App。 一个App的唯一标识Android是用包名iOS是用Bundle Identify。那么在一个系统想安装不同环境的App只要每个环境App的包名和Bundle Identify不同即可。比如生产版的包名和Bundle Identify命名为com.mydomain.myapp测试版的包名和Bundle Identify则命名为com.mydomain.myapp.beta这样Android和iOS都会识别为两个不同的App了。 不过只改包名和Bundle Identify是不够的应用图标和应用名称也要修改不然安装之后很难区分哪个App是哪个环境的。一般做法就是非生产环境的App图标就是在生产图标的基础上添加一个环境标签同时App的应用名称也是在生产的基础上添加环境后缀名。另外因为包名和Bundle Identify不同了微信、微博、百度地图等这些第三方平台也都需要为不同环境的App分别申请不同的appID。 实现上最笨的方法就是拷贝当前工程然后修改缺陷很明显维护成本很高。不过好在Android和iOS都有很方便的修改方式。 Android有了Gradle可以设置多个不同的Flavors每个Flavor都有一个applicationId属性其实就是App的包名。比如生产版和测试版的设置如下 Java代码 productFlavors { myapp { applicationId com.mydomain.myapp } myappBeta { applicationId com.mydomain.myapp.beta } } 这样其实就有两个App了。然后源代码新建一个和main同级的目录命名为myappBeta然后将图标、名称和第三方设置之类的和main保持一样的位置、文件名、属性等就可以替换成环境相关的了。 iOS则可以通过创建多个环境的Target来实现环境分离不同Target可以设置不同的Bundle Identify、Bundle display name、更换图标。另外每个Target也各自有自己的一份plist文件的环境变量和第三方设置之类的都可以设置在相应的plist文件里。 写在最后 至此关于App架构方面的经验总结就先讲这么多了。其中部分内容在我以往的博客上也已经有所体现有兴趣的读者可以前往我的博客了解并欢迎参与讨论。 本文刊载在《程序员》杂志2016年3期版权归《程序员》所有未经许可不得转载 查看图片附件 分享到 4 顶 1 踩 评论 共 4 条 请登录后发表评论 4 楼 hongsen.liu 2016-04-05 09:27 恩作者总结的非常好学习了 3 楼 冰糖葫芦 2016-04-01 23:18 yeak2001 写道 为什么要把关键的算法都写在客户端客户端里接受到的应该是加密过的appSecrect传输到服务端然后解密匹配。 冰糖葫芦 写道 请问原作者还在么我这关于API的安全机制有问题想请教下 1. 关于安全机制第二条安全传输使用Https我统一但对于一般团队来说https带来的成本开销还是挺大的。 2.关于第一条中对“调用者身份”的验证这条我们同样采用了改机制 a.根据appSecrect以及一些其他参数生成sign b.在接口中加入了timestamp来做过期校验防止同样参数一直请求 c.将业务参数按一定规则排序后生成data_sign(防止业务参数被篡改) 但是我们还是被攻击了为啥因为我们还有一个移动版页面而该移动页面使用angularjs实现那么所有的关键参数、算法都就被暴露在js中了这正是被攻击原因。 请问作者在这方面有啥建议么求交流 这个说法我不太赞同appSecret在这里的作用跟密钥作用类似试问密钥怎么能传输的我认为应该传输的是appkey而服务端用appkey来找到其secret并根据算法生成摘要来校验客户端传过来的签名参数(签名是客户端根据其appsecret生成因此客户端应对其妥善保管) 2 楼 yeak2001 2016-04-01 01:38 为什么要把关键的算法都写在客户端客户端里接受到的应该是加密过的appSecrect传输到服务端然后解密匹配。 冰糖葫芦 写道 请问原作者还在么我这关于API的安全机制有问题想请教下 1. 关于安全机制第二条安全传输使用Https我统一但对于一般团队来说https带来的成本开销还是挺大的。 2.关于第一条中对“调用者身份”的验证这条我们同样采用了改机制 a.根据appSecrect以及一些其他参数生成sign b.在接口中加入了timestamp来做过期校验防止同样参数一直请求 c.将业务参数按一定规则排序后生成data_sign(防止业务参数被篡改) 但是我们还是被攻击了为啥因为我们还有一个移动版页面而该移动页面使用angularjs实现那么所有的关键参数、算法都就被暴露在js中了这正是被攻击原因。 请问作者在这方面有啥建议么求交流 1 楼 冰糖葫芦 2016-03-30 22:37 请问原作者还在么我这关于API的安全机制有问题想请教下 1. 关于安全机制第二条安全传输使用Https我统一但对于一般团队来说https带来的成本开销还是挺大的。 2.关于第一条中对“调用者身份”的验证这条我们同样采用了改机制 a.根据appSecrect以及一些其他参数生成sign b.在接口中加入了timestamp来做过期校验防止同样参数一直请求 c.将业务参数按一定规则排序后生成data_sign(防止业务参数被篡改) 但是我们还是被攻击了为啥因为我们还有一个移动版页面而该移动页面使用angularjs实现那么所有的关键参数、算法都就被暴露在js中了这正是被攻击原因。 请问作者在这方面有啥建议么求交流
