Restful后台系统架构深入分析word精品文档25页.doc

如有侵权，请联系网站删除，仅供学习与交流Restful后台系统架构深入分析【精品文档】第 25 页APP后台系统架构说明书编号：20140804版本：V1.0语言：中文文件状态：草稿保密级别：绝密文件标识：需求规格说明书项目名称：APP_FRAMEWORK当前版本：1.0作 者：罗林审 核：张尹路完成日期：2014年9月变更记录日期版本变更说明作者2014-08-041.0创建罗林填表说明：1. 日期：文档变更的日期。2. 版本：对应文档的版本号。3. 变更说明：简单的变更说明。4. 作者：文档编写与修改者.目录第一章 概述51.1编写目的61.2读者对象61.3参考文献61.4术语与缩写解释6第二章 系统设计62.1API设计72.1.1Restful设计原则72.1.2api的命名72.1.3安全性72.1.4api返回数据72.1.5图片的处理(流媒体)82.1.6返回的提示信息82.1.7在线api文档和测试92.2XMPP服务92.2.1Openfire简介92.2.2XMPP运用范围102.2.3处理多账号同时登陆102.2.4一些常用的openfire插件102.2.5php的xmpp library102.2.6个人开发openfire插件112.2.7常见问题112.3短信、邮件、推送服务112.3.1重点112.3.2短信112.3.3邮件122.3.4短信方面122.4通讯的安全性122.5表情的处理142.6LBS服务142.7项目管理16（1）sprint 计划会议17（2）日常开发17（3）每日例会18（4）测试和修bug18（5）sprint 评审会议19（6）sprint 回顾会议19（7）及时反馈192.8数据库分表192.9动态通知212.10数据增量更新222.11系统架构271. Apns272. Email283. Coreseek284. Redis285. Httpsqs286. Xmpp287. Monitor28第一章 概述1.1 编写目的本说明书用于明确要后台系统该架构的具体需求，规范的描述出APP后台系统架构要实现的各种功能和所要达到的性能，使用户和软件开发者双方对该软件的初始规定有一个共同的理解，并使之成为整个开发工作的基础。1.2 读者对象程序员、项目经理。1.3 参考文献提示：列出本文档的所有参考文献（可以是非正式出版物），格式如下：标识符 作者，文献名称，出版单位（或归属单位），日期1.4 术语与缩写解释缩写、术语解 释第二章 系统设计从2011.11月开始接触Android开发，已经两年多了。接近三年的工作经验却一直徘徊在JavaWeb和Android之间，总是找不到进步的方式。一直独立开发，在接近一年多app相关的系统架构、api设计，先后在两个创业公司中工作，经历过手机网页端，android客户端，iphone客户端，其中的乐与苦，得与失，仰首问天有谁知？我觉得是时候来个总结，把相关的技术和心得记录下来。2.1 API设计 2.1.1 Restful设计原则Restful风格：RESTfu设计原则,它被Roy Felding提出（在他的”基于网络的软件架构“论文中第五章）。而REST的核心原则是将你的API拆分为逻辑上的资源。这些资源通过http被操作（GET ,POST,PUT,DELETE）。但现在看，一般的操作只有两种：GET ,POST。这个设计原则最简单的应用就是根据object而不是页面来设计api。最开始的时候，app的一个页面需要什么数据，api就返回什么数据。结果随着 app的UI不断改版，需要的数据不断变化，不停地修改api，最后当api的改动会影响以前的版本的时候，只能写一个新的api版本，最后弄得api中 有很多_V2，V3这样的标志，恶梦!后来在网站的重构过程中，就根据object来设计api，但根据object来设计，又有一个问题，一个大object可能包含很多小object，是一个api返回全部小object，还是分为多个api返回？根据业务和技术，带宽等仔细考虑吧。2.1.2 api的命名其中一个原则，一看api名字就知道这个api是干啥。在创业团队中，一般就只有一两个人负责后台，当你要负责几十甚至上百个api，你就知道不能“望名知api”是个什么样的痛苦。2.1.3 安全性参考【2.3通讯的安全性】。2.1.4 api返回数据app客户端的语言 java 和object-c都是强类型语言，所以怎么处理空值显得特别重要，不合理的设计很容易造成app的闪退。从后台的角度来说，api中返回的数据中，正确值和空值的类型必须一样，举例，用户名的字段是“realname": "xxx”,如果用户名为空，则应该返回“realname": ""。如果返回值是一个array，空数据则返回一个空array，绝对禁止null值。对于客户端，必须用个全局的函数来处理所有api的返回数据，需要有一个机制：对于某个客户端需要数据，如果api中缺失，客户端自动补上并给予默认值。这个机制在我们的实践中大大减少了app的闪退。同时，在数据库设计的时候，一个合理的设计必须是所有字段都有默认值，不应该允许null值。null在大量的语言和数据库中，会带来无穷的问题。对于这个数据库设计原则，我以前不太明白，现在经历了一年的api设计后，终于懂得。如果客户端是php，还有一个问题，php中数组和字典都是array，但在java 和object-c中是不一样，这个问题一定要注意。2.1.5 图片的处理(流媒体)在不同版本的app中，各种不同尺寸的手机中，同一张图片显示的尺寸可能是不一样，如果每次都需要用返回原图，然后在客户端处理，则极大浪费网络资源。而如果是后台处理好图片才返回，则又是一个挑战，怎么有效保存和裁剪多种图片尺寸呢？例如，一开始头像只需要返回60*60的尺寸，后来在新的版本需要返回70*70, 又出了一个新版本，需要返回80*80, 每次增加一个新的尺寸，怎么在数据库上记录下来。这个问题在一开始做api的时候没考虑，后来不得不用了一个极端的方法，每增加新的图片尺寸，就在数据库中增加一个新的字段，保存并生成新的图片尺寸，结果最后数据库的头像字段有"avatar","avatar_60_60","avatar_70_70","avatar_80_80"，这种极度恶虐的设计。最后，针对图片，我们才用了这样的策略：a) 客户端本地缓存图片，只有没有合适的图片，才去服务器取。b) 当客户端需要某种尺寸的图片，由客户端告诉服务端图片的尺寸，服务端动态生成并缓存起来。例如，客户端需要图片（ 则服务器就生成80*80的尺寸并返回。采用了这样的图片处理机制，数据库中只要有一个字段保存原图就行了，其它尺寸就由客户端告诉服务端动态生成。以后无论什么尺寸的图片，数据库中都不需要记录，数据库只有原图就行了。2.1.6 返回的提示信息最科学的情况，服务端只返回信息代码，具体的文字提示由客户端决定。如果文字信息是由服务端返回，则最起码要区分2种信息：提示用户的信息，提示客户端程序员的信息。这两者的区别： 1. 提示用户的信息是要在让客户知道的，提示客户端程序员的信息不需要让客户知道的。2. 提示用户的信息文字很友好，客户不需要专业基础一看就知道是什么，提示客户端程序员的信息则很专业，例如告诉客户端少传了哪个参数？哪个参数有问题等等。2.1.7 在线api文档和测试我们网站的api在线测试文档，既是一份在线api文档，也是一个在线测试工具，极大方便沟通和测试。每次客户端程序员觉得某个api有什么问题，我们就是这个在线工具上讨论沟通的。客户端程序员最喜欢这个玩意了-。上个图解一下馋（这个图是旧版的api，已经弃用了）：负责做这个功能的同事专门写了篇博客详细介绍了这个在线api测试文档，还带有demo：可以参考网址：2.2 XMPP服务在app中有时候是需要添加聊天服务，在这里谈谈曾经开发聊天服务的经验：2.2.1 Openfire简介聊天服务端选的是Openfire，这是一个基于xmpp协议的聊天服务器（XMPP是一种基于XML的协议，它继承了在XML环境中灵活的发展性。因此，基于XMPP的应用具有超强的可扩展性。经过扩展以后的XMPP可以通过发送扩展的信息来处理用户的需求，以及在XMPP的顶端建立如内容发布系统和基于地址的服务等应用程序。而且，XMPP包含了针对服务器端的软件协议，使之能与另一个进行通话，这使得开发者更容易建立客户应用程序或给一个配好系统添加功能。Gtalk，网易泡泡，Facebook聊天等都是基于xmpp，具有广泛的包容性）。网页上的聊天，使用的是strophe.js ，有一本书XMPP高级编程：使用JavaScript和jQueryXMPP高级编程：使用JavaScript和jQuery是基于这个strophe.js，里面的例子对于初学xmpp具有极大的参考价值。2.2.2 Xmpp运用范围xmpp除了可以提供聊天服务，还可以充当消息服务器，例如有什么消息需要推送到客户端却不希望使用推送工具，xmpp也是个选择。2.2.3 处理多账号同时登陆有时候同一个账号需要在不同的客户端同时登陆服务端，例如，网页端和ios会出现用同一个账号登陆聊天服务器的情况，为了保证两个客户端都能收到聊天消息，需要做下面两个处理：a.相同的账号需要使用不同的resource，可用时间戳生成，如vimgmail/1359956556，vimgmail/1359956777。b. 在后台 Admin Console> Server Manager > System Properties中，设置“route.all-resources”为true。2.2.4 一些常用的Openfire插件Subscription： 官方的描述是这样的：Automaticallyaccepts or rejects subsription requests。 一个保存openfire聊天记录的插件，当根据我的使用经验，这个插件是把全部聊天记录保存在一个表中，性能极差，只能勉强应付，法律规定要保存3个月聊天记录这个需求，在实际应用中没啥用。2.2.5 Php的Xmpp Library如果服务器是使用php，那么能使用的xmpp客户端就只有xmpphp，这个libary只提供了最基本的发送消息功能，很多常用的功能都没有提供，我根据开发经验把一些常用的xmpp功能开发出来，并整合到xmpphp中：registerNewUser /注册一个新用户addRosterContact /发送添加好友的请求accept friend request /接受好友请求deleteRosterContact /删除某个好友roomMessage /发送群聊消息createChatRoom /创建群聊kickUserOutToChatRoom /把某个人剔除群聊项目的地址： 2.2.6 个人开发Openfire插件在手机的聊天应用中，经常出现的一个需求就是把用户的离线消息通过推送系统推送到用户的手机上，为了实现这个功能，本人就开发了本插件，这个openfire 插件是拦截了发给openfire用户的离线消息，然后根据自身的业务逻辑推送到手机上。详细介绍：2.2.7 常见问题openfire中发送某些特殊字符会断开xmpp连接的问题，解决方法请看：另外一个好消息， 和android 应用简单整合就能提供聊天服务，密切关注中。如果真的能实现，那么对于app提供聊天服务是个很好的选择。但有几个问题：1. 它现在还没正式上线。2. 访问外国网站的风险。3. 法律规定要保存3个月聊天记录。2.3 短信、邮件、推送服务在app的后端设计中，免不了消息的推送，短信，邮件等服务，下面就个人的开发经验谈谈这方面。2.3.1 重点最重要的是，各种推送一定要放在队列系统中处理，不然会严重影响api的响应时间。2.3.2 短信以前我们是用亿美软通的短信服务，但在三大运营商收紧了短信服务后，亿美软通的短信延迟非常厉害，后来我们找到了这家短信服务商 ，这家发送短信到联通，电信，移动手机很快就到了（直到2014.01.24）。如果发送到移动的短信还没有改善，最后的后备方案：发送到联通，电信的短信使用国内的服务商，发送到移动的短信就只能使用国外的短信服务商（国外发短信到移动手机3毛一条，好贵啊！）2.3.3 邮件在一开始时使用服务器自身的postfix发送邮件的，但我们发现邮件被很多邮件服务商当成垃圾邮件了，而且没有重发机制，不能保证邮件的准确到达。后来查了一下各大网站，发现知乎和github 都是使用 的邮件服务，看了一下文档，价格很公道，而且每月有1万封的免费邮件额度，非常适合创业型的公司。2.3.4 短信方面在这方面，我考虑的重点是：在创业初期，能用第三方就尽可能多使用第三方的服务，自身只处理业务逻辑本身，快速的开发产品。android篇：android方面，我们使用过3种消息推送机制：1. 极光推送，现在放弃了。我们使用的过程中，发现极光的机制有点古怪，一般来说，一个app在极光服务器中是固定一个id，但在极光中是通过广播来通知app这个id，而且在文档中居然说明这个id会不定期变化。2. openfire服务器。app通过连接openfire服务器来获取各种消息，但是openfire有个机制，当app连接openfire后空闲就自动断开，没法保持连接的的稳定性，而修改这个openfire的机制成本太高了，后来也放弃使用openfire。3. 百度推送。已现在使用一段时间的情况来说，推送及时快速，挺满意百度的推送服务。iphone篇：apns是iphone推送的不二选择。但如果自身开发apns的服务，会遇到无效token而需要重发，这样需要维护一个队列并建立重发机制，考虑到项目的时间和研发成本，最后也是使用了百度推送的服务。当用户在iphone上卸载了app后，device token会失效，所以应该定期访问苹果的feedback服务器，把无效的token去掉。2.4 安全性在开发一个项目的时候，大家经常会忽略项目的安全性问题，有很多的安全性问题其实就是一个意识的问题，解决起来并不复杂，但是因为这些疏忽，却可能会给我们的用户带来很大的风险。下面就列举一些在做项目的时候应该考虑的一些安全性问题。2.4.1 通讯的安全性在app的后台设计中，一个很重要的因素是考虑通讯的安全性。因此，我们需要考虑的要点有：1. 在app和后台，都不能保存任何用户密码的明文。2. 在app和后台通讯的过程中，怎么保证用户信息的安全性?在app中，根据安全考虑，用户的操作分为两类：1. 用户登录注册操作。2. 用户的其他操作。在第一点，用户登录注册操作中，是会出现用户密码，所以在这个过程中，必须要使用https通讯，保证通讯的安全。在第二点，用户的其他操作，怎么保证这部分通讯的安全呢？在我的设计中，是采用了公钥加私钥保证安全。用户的id是公钥，通过一定的算法对用户的id进行加密得到一个加密字符串是私钥。当用户登录或注册后，通过https把公钥加私钥返回给app客户端。这个过程如下：2.4.2 密码保存保存密码的第一准则是不能明文保存密码，之前CSDN密码泄露一事还记忆犹新。通常的做法是对密码进行不可逆加密，加密时不要使用MD5或者SHA系列的算法加密，现在对这两个算法的破解研究工作已经有了相当的进展。推荐使用bcrypt。 2.4.3 CI服务器的安全性 CI服务器和Build服务器经常是攻击者最完美的跳板，这些服务器几乎拥有你系统的所有权限（代码库，各个生产环境的访问权限等等）。请确保其安全。 2.4.4 校验客户端安全证书的“指纹” 当使用SSL时，我们需要验证安全证书的“指纹”来确认该证书是有目标网站颁发的证书，这可以有效防止“中间人攻击”漏洞。 2.4.5 随机生成密码 不要对所有账户设置同一个密码，一锅端就不好了，使用密码管理软件为每一个账户生成一个独立的密码。当前比较推荐的是1Password，期待有更好的密码管理软件诞生。 2.4.6 使用安全系数更高的随机数生成类库 要想得到真正的随机数是很困难的，尤其是要满足安全领域的随机数标准，语言自带的一般随机数生成算法很难满足需要，所以JDK还提供了SecuredRandom这样的类，Ruby中也有SecureRandom这样的模块。 2.4.7 总是使用HTTPS和HSTS 如无值得信服的理由，所有的请求都应该使用加密协议 2.4.8 不要使用“安全问题”找回密码 一个桶能装多少水是有最短的那块木板决定的，一个安全系统的安全性也是有最薄弱的环节决定的。不要让安全问题成为你的那块短木板。 2.4.9 不要限制密码长度 通过密码长度来保证安全性的时代已经结束了，让用户使用"Pass Phrases"是一个不错的主意。 2.4.10 允许对密码或者密码短语使用更直观的复杂度控制 使用更有效，直观的方法帮助用户增加密码或者密码短语的难度。而不是简单的必须有大小写，必须超过8位等这些生硬的条件。 2.4.11 避免缓冲溢出 在弱类型语言中，最常见的安全性问题就是缓冲溢出，这也是最常见的一种远程攻击方法，一般有四种防范方法： * 通过操作系统使得缓冲区不可执行，从而阻止攻击者植入攻击代码。 * 写正确的代码 * 利用编译器的边界检查来实现缓冲区的保护。 * 在程序指针失效前进行完整性检查 2.4.12 避免注入攻击 所有的用户输入必须经过验证和清理才能传递给下游，最常见的就是SQL注入攻击。2.4.13 避免跨站脚本攻击 系统需要保证用户不能在页面中嵌入未经验证的信息。2.4.14 避免泄露信息给第三方 目前很多系统倾向于泄露信息给第三方，比方说Google，Facebook，新浪微博等等。这些第三方会窃取很多用户信息。 2.4.15 设置数据清理策略 只在需要数据时才保存数据，数据生命周期结束就清理掉，贼是没办法偷你没有的东西的。2.5 表情的处理在app的应用中，文字中夹带表情是个很常见，那么，在后台处理表情的时间，我遇到过下面两个问题：1. 表情在mysql的存储。表情的utf8编码，有时是有4个字节的，所以在一般的utf编码是没法存储的，我在网上看到的一个常用的解决方案，是把mysql升级到5.5,然后把字符编码改为utf8mb4_general_ci。但在实践中，我发现了还有一个方法，适用于mysql 5.1,就是把含有表情的那个字段的类型变为blob, 没错，就是用二进制存储。2. 当文字中夹带表情的处理很多时候，如果文字中夹带表情，那么这些文字的处理就会出现问题，例如，如果一个用户的昵称带有表情，那么我怎么把这个昵称转换为拼音呢？在实际的开发中，我遇到了这个问题，先是找到了 http:/punchdrunker.github.io/iOSEmoji/table_html/ios6/index.html中ios6后新增的表情抓取出来，并写了个新的类库并开源了 2.6 LBS服务在LBS的应用中，一个基本的需求是查找附近的用户，现在有两种做法：1. 使用mysql的空间数据库，具体做法参考： 。2. 使用geohash编码，这个是本文需要讨论的。geohash编码，可以把球面上的经纬度转换成一个值，简单点来说就是把二维坐标转换成一维坐标。查找附近的时候，非常方便，用SQL中，LIKEw23yr3%可查询附近的所有地点。geohash的详细介绍，可参考 http:/www.wubiao.info/372 。在以前的产品中，一个需求是查找用户附近的商铺，发现用mysql LIKEw23yr3%这种方式检索geohash性能上的瓶颈很大，检索130万行的数据，平均花费了8秒，这是响应速度是无法忍受的。后来经过不断优化，确定了如下使用coreseek+redis+mysql解决方案，一下子就把响应速度减少到平均1 秒，这个方案的如下：1. 用每个商铺的坐标值计算geohash，把geohash作为key，商铺的作为value，放到redis的set集中。$this->cache->redis->select(1);/不能使用0，因为这里有大量的数据，需要独立。$this->cache->redis->set('place:geohash:'.$geohash,$place_id);2. 根据用户的坐标，在redis中查找附近的商铺id<?php * 获取附近的地标公共处理方法 * param $lat * param $lng * param $n geohash值的长度，一般来说，当n=6,是获取当前附近1千米范围内的用户 function getLocalPlace($lat, $lng, $n) $lat = (float) $lat; $lng = (float) $lng; $nowGeohash = $this->geohash->encode($lng, $lat); $likeGeohash = substr($nowGeohash, 0, $n); $placeIds = array();$this->_loadDriver('cache', array('adapter' => 'redis'); /不能使用0，因为这里有大量的数据，需要独立$this->cache->redis->select(1); /*表示模糊匹配，例如有key werewfs,werewfw,那么使用“werewf*”，则能同时匹配werewfs,werewfw$geohashKeys = $this->cache->redis->keys('place:geohash:' . $likeGeohash . '*');$hashlen = strlen($nowGeohash);if ($geohashKeys)$searchKeys = array();/对坐标进行排序foreach ($geohashKeys as $k => $v) $v = ltrim($v, 'place:geohash:');for ($i = $n; $i < $hashlen; $i+) $compare_hash = substr($nowGeohash, 0, $i);$cur_hash = substr($v, 0, $i);if ($compare_hash != $cur_hash)$nofst = str_pad($i - 1) . $k, 6, '0');$searchKeys$nofst = 'place:geohash:' . $v;break 1;if ($searchKeys)krsort($searchKeys);/mget表示返回所有特殊keys的values$placeIds = $this->cache->redis->mget($searchKeys);return $placeIds;3. 如果需要查找关键字或商铺的类型，则用把2中$placeIds 作为filter调戏 ，在coreseek中继续查找。2.7 项目管理移动互联网行业是个快速发展的行业，需求不断变化，产品更新快。基于移动互联网的以上特点，在开发产品的过程中，我们放弃了传统的瀑布流开发模型，引入了精益的理念和Scrum这个敏捷开发框架，下面谈谈实施过程中的一些经验。Scrum简介：Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发周期包括若干个小的跌代周期，每个小的的跌代周期称为一个Sprint，每个Sprint的建议长度2到4周。在Scrum中，使用产品Backlog来管理产品或项目的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum的开发团队总是先开发的是对客户具有较高价值的需求。在每个Sprint中，Scrum开发团队从产品Backlog中挑选最有价值的需求进行开发。 Sprint中挑选的需求经过Sprint计划会议上的分析、讨论和估算得到一个Sprint的任务列表，我们称它为Sprint backlog 。在每个迭代结束时，Scrum团队将交付潜在可交付的产品增量。 我们的Sprint backlog是大概4周的时间，其中包括2天的sprint 计划会议,2.5周的开发，每日例会穿插在开发时间里，1周的测试改bug，1天的sprint评审会议和sprint回顾会议。（1）sprint 计划会议在开sprint 计划会议前，产品经理必须所要实现的产品需求（产品Backlog）以用户故事的形式确定下来，并画好原型图，UI应该要出设计稿（在sprint 计划会议前出设计稿很重要，因为设计对估算时间影响非常大）。产品经理同时确定各个产品需求的优先级。开sprint 计划会议期间（一般是2天），开发团队的成员不应该做任何的开发工作，把全部精力都放在把产品需求变为一个个开发任务，并对开发任务估算时间。估算时间有几点注意：1. 对于需要使用的新技术，要估算学习和调研的时间。2. 根据统计，每个程序员每天的有效工作时间是5个小时左右，其他时间都被沟通，喝水，休息，上洗手间等占据，所以如果某个任务估算超过5个小时，那就代表了这个任务完成需要超过一天的时间。3. 对于开发任务，估算尽可能的细，一般来说，每个任务的估算不应该超过5个小时，如果超过5个小时，就应该再把这个任务细分。只有尽可能细的估算任务，总的时间是大概精确地，因为估算时间是一个正态分布，有的任务估算的时间偏大了，有的时间任务估算的时间偏小了，估算越细，总体下来估算还是准确了。最后，根据产品经理的优先级和开发人员的估算时间，确定最终的开发任务和优先级，即完成Sprint backlog。（2）日常开发在每个Sprint backlog，后台和app的交互都是通过api，所以由后台先写好相关的api并编写假数据，先让app端可以顺利开展工作。先编写api和假数据，有两个好处：1. 能对整个开发计划有个总体的规范。2. 相当于是TDD（测试驱动开发）。遇到问题的时候，必须要及时找相关的人员沟通。但这样有个问题，如果开发人员正在开发，被打扰可能会被决定很不爽，为了保证沟通的效果，可以：1. 如果真的不是非常紧急，可以等相关的人员休息的时候再沟通。2. 解决一个问题，先梳理情绪，再梳理人际关系，最后才是问题本身。多微笑，别苦着脸，平时待人以善，说好话，存好事，做好事，沟通的时候只针对问题，不针对别人的不良情绪。3. 可以试一下番茄工作法。但根据我们自身的实践经验，效果不理想。在创业开发团队中，scrum master 一般是由技术总监担任的。团队外部的沟通，必须统一通过scrum master。即如果市场部，运营部对开发团队有任何要求，必须要经scrum master同意后由scrum master传递进开发团队内部。团队内部的沟通，由团队成员自己解决，如果有重大的决策，必须经scrum master同意。通过scrum master遮蔽外部对开发团队的影响。在团队建设中，定期的团体活动是个很好的主意，我们一般是周四下午集体去打羽毛球。通过团体活动，不但能加强团队的凝聚力，而且运动后，整个人沉闷的感觉都消失了，变得神清气爽，活力十足。在一个Sprint backlog中，需求不能变更，UI确定后原则上只能做小修改。 （3）每日例会在每天的例会前，每个团队成员应该更新自己的任务列表，包括：1. 昨天完成了哪些任务，每个任务使用了多少时间，没完成的任务估算还需要多少时间。2. 更新总的剩余开发时间 例会一般是产品经理和开发团队的成员都要参加，如果可以的话，让运营人员和市场人员也参加，这样可以使每个成员都公司的产品有个整体的了解。每个人在例会上说下面3方面的事情：1. 昨天做了哪些工作。2. 今天准备做哪些工作。3. 有什么工作需要其他同事配合。注意，避免在会议上讨论问题，如果真的需要讨论，请在会议后和同事讨论，不要浪费整个团队的时间。 （4）测试和修bug 开发完成，就进入测试和修bug的阶段。如果人手不足，可以使用交叉测试的方式，即android开发人员测试iphone的app，iphone开发人员测试android的app，后台，运营，UI等人员看情况分配测试任务。针对每个bug，应该有3部分：1. 问题描述和重现步骤2. 测试人员3. 负责解决这个bug的人员（这个人员一般由技术总监指定）  （5）sprint 评审会议 一般是全体人员都参加，在测试和修bug后。iphone的演示有个收费的工具，可以把iphone的屏幕通过电脑放到投影仪，android上没有哪个好用的工具！当时我们的方法是android演示的时候，用iphone的摄像头对着android机，通过iphone的收费工具在投影仪上看。 （6）sprint 回顾会议 每个成员都要参加，每个成员都要提两点：1. 在这轮sprint中值得表扬的点2. 在这轮sprint中做得不好的地方这个过程走两轮，即每个成员都要说2次。注意，当一个成员提出自己的意见时，其它成员不作任何的批评。 （7）及时反馈在精益的理念中，很重要的两点是快速反馈和快速迭代。快速迭代是通过scrum这个敏捷开发框架实现了，但快速反馈呢？产品投入到市场后，怎么快速收集用户的反馈呢？ 我们采用的方法：1. 建立相关的qq群，收集意见。2. 在app中，有个意见反馈的功能，能把反馈的意见发送到服务器。3. 后台中，有个系统的账号。每个用户一注册就和这个系统账号自动加为好友，可以随时通过聊天功能向这个系统账号提问题。一般我们的产品经理会经常登录这个系统账号和用户真正交流的。2.8 数据库分表当项目上线后，随着用户的增长，有些数据表的规模会以几何级增长，当数据达到一定规模的时候（例如100万条），查询，读取性能就下降得很厉害，这时，我们就要考虑分表。（是否得考虑数据库报警？）更新表数据时会导致索引更新，当单表数据量很大时这个过程比较耗时，这就是为什么对大表进行新增操作会比较慢的原因，并且更新表数据会进行表级锁或者行锁，这样就导致其他操作等待。所以我们将大表拆分为多个子表，那么在更新或者查询数据的时候，压力会分散到不同的表上。由于分表之后每个表的数据较小，不管是查询还是更新都极大的提高了速度，即使出现最坏的“锁表”的情况，那其他表还是可以并行使用。1. 分表的策略分表有多种策略：(1) 按用户id分表，例如id为1-10000在表1，id为10001-20000在表2。(2) 插入的时间分表。(3) 按每个表固定记录行数拆分。在项目，由于这个表是保存用户的通讯录，为了保证一个用户的所有通讯录数据都保存在同一个表，选择的分表方式就是（1），按用户id分表。2. 分表策略确定下来了，还有一个非常严重的问题，因为现在用户的数据都分散在不同的表中，之前的业务功能如何保证呢？比如说我要插入一条记录、更新一条记录、删除一条记录、查询统计数据，现在要怎么处理呢?如果分表的存储引擎是MyISAM，这里有一种很简单的处理方法。利用merge存储引擎将拆分的表合并成一张表。当然了，如果使用InnoDB，也能通过alter table命令把InnoDB变为MyISAM。MERGE存储引擎可以将N个子表联合在一起,看成是一个整表,实际上还是N个真实的子表。当分表的时候，还要一个问题，因为我们是在线上项目中分表的，需要考虑怎么样使分表的操作对用户的影响最少。3. 实例假设有表contact，存储了9000个用户的通讯录数据，平均一个用户有联系人100个，那么这个表的规模就达到了90万条数据，我们需要对这个表分表。下面的脚本演示了怎么在不关闭mysql服务的情况下对contact 分表：2.9 动态通知在app中，例如在