一 : DISCUZ架构:积分系统代码分析三
3.下载附件积分增减
这一部分主要用到的就是attachment.php这个文件了，下面就来分析这个文件中与积分中有关系的代码：
| 以下为引用的内容： if(!$isimage) { $forum['getattachcredits'] = $forum['getattachcredits'] ? unserialize($forum['getattachcredits']) : array(); $getattachcredits = $forum['getattachcredits'] ? $forum['getattachcredits'] : $creditspolicy['getattach']; updatecredits($discuz_uid, $getattachcredits, -1); } |
这一段的意思是：当一个附件不是图像的时候，取出该论坛对于下载附件的积分设置，比方说是-5分，那么就调用updatecredits(global.func中定义)这个函数更新一下积分。
P.S.:相关函数分析：
updatepostcredits函数，定义于./include/post.func.php
| 以下为引用的内容： function updatepostcredits($operator, $uidarray, $creditsarray) { global $db, $tablepre, $discuz_uid, $timestamp;
$membersarray = $postsarray = array(); |
可以看到这个函数有三个传入参数，$operator表示加还是减，$uidarray表示会员的id数组，$creditsarray表示要加减的积分数组。调用方法如：
以下为引用的内容：
updatepostcredits('+', 1, 1);
表示给uid为1的会员加1个积分
二 : 系统分析师与系统架构师的区别
估计大家都知道软考中有个软件分析师与软件架构师，都是高级的。但对他们的具体含义不甚明了。
当软件规模比较小时，系统分析师所完成的工作是把真正的业务需求(这个需求不是指客户简单所说的哪1个功能，而是需要去挖掘的，可能是潜在的但又是系统必需的，条例清楚、逻辑清晰的业务功能，而且需求不仅仅只是来自业务上的，系统所依赖的运行环境也会产生一些需求)转换成计算机可理解、可实现、可计算的模型。但由于现在的系统规模越来越大，复杂程度越来越高，而且应用领域也越来越广，所以很难由1个工种的人来全面完成这项艰巨的任务。
在具体的软件设计过程中，现在把它分解为由系统分析师与软件架构师合作共同来完成这一任务。其中系统分析师侧重的是前一部分的工作，软件架构师侧重的是后一部分的工作。系统分析师的主要工作内容包括业务需求分析、系统需求分析、可行性分析以及建模等，其特点是更多地与行业专家、用户沟通，再及时与项目经理(项目管理师)、软件架构师以及老板商讨，分析项目具备的特点、成本、风险等，考虑实现的模型。系统分析师所面临的往往是有许多不确定性的事件，需要对这些不确定的事件进行分析、总结，使之得出1个相对可靠的确定性结论或实施方案模型。
软件架构师的主要工作内容就是在系统需求比较清晰的条件下进行系统总体的架构设计，当然它也可能会涵盖一些系统分析师的工作内容和软件设计师的内容，但其特点是确定性的东西会多一些，力求为系统找到或架构1个最优的模型，这里面虽然可能有很多创新的成分，但更重要的是如何充分运用现有的各种模型、结构、方案，并根据项目的特点，在各种方案中取长补短，找到1个最好的平衡点和结合点，使之最适合当前项目的解决方案。所以，软件架构师实际上是使系统细致化、完善化，为拥有更好的可靠性提供保障。
在实际的职责上，软件架构师比系统分析师所站的角度更高一些。在大规模的软件系统中，系统分析师可能就系统的某个子系统进行分析与设计，而软件架构师应该对整个系统的结构负责。
(1)项目管理师：掌握信息系统项目管理的知识体系，具备管理大型、复杂信息系统项目和多项目的经验和能力；能根据需求组织制定可行的项目管理计划；能够组织项目实施，对项目的人员、资金、设备、进度和质量等进行管理，并能根据实际情况及时做出调整，系统地监督项目实施过程的绩效，保证项目在一定的约束条件下到达既定的项目目标；能分析和评估项目管理计划和成果；能在项目管理进展的早期发现问题，并有预防问题的措施；能协调项目所涉及的相关人员。即项目管理师的主要职责是负责整个项目的实施和控制，协调各种资源(包括组织内部资源和客户资源)。
(2)系统分析师：熟悉应用领域的业务，能分析用户的需求和约束条件，写出信息系统需求规格说明书，制订项目开发计划，协调项目开发与运行所涉及的各类人员；能指导制订企业的战略数据规划，组织开发项目；能评估和选用适宜的开发方法和工具；能按照标准规范编写系统分析、设计文档；能对开发过程进行质量控制与进度控制；能具体指导项目开发。即系统分析师的主要职责是获取并分析用户的需求，形成规范化的文档，指导整个项目的开发，需要与客户不断的交流，熟悉应用领域的业务。
(3)系统架构师：能够根据用户需求，结合用户应用领域的实际情况，设计正确、合理的软件构架，维护系统构件及其接口，并确保系统构架具有良好的性能；能够对项目进行系统构架级的描述、分析、设计与评估；能够按照相关标准编写相应的设计文档；具有扎实的理论功底、广博的知识面，能够与系统分析师、项目管理师相互协作、配合工作。即系统架构师的职责是负责整体的、宏观的系统设计，重点在架构级别上。还要对架构进行描述、分析和评估，属于纯技术性的工作。
从考试难度来看，系统架构设计师是最有难度的，同时，架构设计师也是业界最缺的1个高端职位，因此，其含金量也将是最高的。而且，我个人估计，架构设计师证书的含金量会超过系统分析[www.61k.com）师，这是因为业界已经深刻认识到架构的重要性，且中小企业紧缺架构设计师。从考试大纲来看，系统架构设计师考试的试题题型和内容将与系统分析师的考试基本重叠或一致，只是内容稍微偏向于架构设计。
三 : Restful后台系统架构深入分析
APP后台系统架构说明书
编号：20140804
版本：V1.0
语言：中文
restful Restful后台系统架构深入分析
变更记录
填表说明：
1. 日期：文档变更的日期。[www.61k.com) 2. 版本：对应文档的版本号。 3. 变更说明：简单的变更说明。 4. 作者：文档编写与修改者.
restful Restful后台系统架构深入分析
目录
第一章 概述 ..................................................................................................................................... 5
1.1
1.2
1.3
1.4 编写目的 ....................................................................................................................... 5 读者对象 ....................................................................................................................... 5 参考文献 ....................................................................................................................... 5 术语与缩写解释 ........................................................................................................... 5
第二章 系统设计 ............................................................................................................................. 6
2.1 API设计 ....................................................................................................................... 6
2.1.1
2.1.2
2.1.3
2.1.4
2.1.5
2.1.6
2.1.7
2.2
2.2.1
2.2.2
2.2.3
2.2.4
2.2.5
2.2.6
2.2.7
2.3
2.3.1
2.3.2
2.3.3
2.3.4
2.4
2.5
2.6
2.7 Restful设计原则 ............................................................................................. 6 api的命名 ........................................................................................................ 6 安全性 ............................................................................................................... 6 api返回数据 .................................................................................................... 6 图片的处理(流媒体) ........................................................................................ 7 返回的提示信息 ............................................................................................... 7 在线api文档和测试 ....................................................................................... 8 Openfire简介 ................................................................................................. 9 XMPP运用范围 .............................................................................................. 9 处理多账号同时登陆 ....................................................................................... 9 一些常用的openfire插件 ............................................................................. 9 php的xmpp library ..................................................................................... 9 个人开发openfire插件 ............................................................................... 10 常见问题 ......................................................................................................... 10 重点 ................................................................................................................. 10 短信 ................................................................................................................. 10 邮件 ................................................................................................................. 11 短信方面 ......................................................................................................... 11 XMPP服务 .................................................................................................................. 8 短信、邮件、推送服务 ............................................................................................. 10 通讯的安全性 ............................................................................................................. 11 表情的处理 ................................................................................................................. 15 LBS服务 ..................................................................................................................... 15 项目管理 ..................................................................................................................... 18
restful Restful后台系统架构深入分析
（1）sprint 计划会议 ................................................................................................. 18
（2）日常开发 .............................................................................................................. 19
扩展：日志分析系统架构 / 数据分析系统 架构 / 实时日志分析系统架构
（3）每日例会 .............................................................................................................. 19
（4）测试和修bug ...................................................................................................... 20
（5）sprint 评审会议 ................................................................................................. 20
（6）sprint 回顾会议 ................................................................................................. 20
（7）及时反馈 .............................................................................................................. 20
2.8
2.9
2.10
2.11 数据库分表 ................................................................................................................. 21 动态通知 ..................................................................................................................... 22 数据增量更新 ......................................................................................................... 23 系统架构 ................................................................................................................. 28
1. Apns .......................................................................................................................... 28
2. Email .......................................................................................................................... 29
3. Coreseek ................................................................................................................... 29
4. Redis .......................................................................................................................... 29
5. Httpsqs ..................................................................................................................... 29
6. Xmpp ......................................................................................................................... 29
7. Monitor ..................................................................................................................... 29
restful Restful后台系统架构深入分析
第一章 概述
1.1 编写目的
本说明书用于明确要后台系统该架构的具体需求，规范的描述出APP后台系统架构要实现的各种功能和所要达到的性能，使用户和软件开发者双方对该软件的初始规定有一个共同的理解，并使之成为整个开发工作的基础。[www.61k.com]
1.2 读者对象
程序员、项目经理。
1.3 参考文献
提示：列出本文档的所有参考文献（可以是非正式出版物），格式如下：
[标识符] 作者，文献名称，出版单位（或归属单位），日期
1.4 术语与缩写解释
restful Restful后台系统架构深入分析
第二章 系统设计
从2011.11月开始接触Android开发，已经两年多了。（www.61k.com]接近三年的工作经验却一直徘徊在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中返回的数据中，正确值和空值的类型必须一样，举例，用户
restful Restful后台系统架构深入分析
名的字段是“realname": "xxx”,如果用户名为空，则应该返回“realname": ""。[www.61k.com）如果返回值是一个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) 当客户端需要某种尺寸的图片，由客户端告诉服务端图片的尺寸，服务端动态生成并缓存起来。
例如，客户端需要图片（http://www.baidu.com/img/bdlogo.gif）的80*80的尺寸，则在图片的路径加上宽和高的参数（类似于
寸并返回。
采用了这样的图片处理机制，数据库中只要有一个字段保存原图就行了，其它尺寸就由客户端告诉服务端动态生成。以后无论什么尺寸的图片，数据库中都不需要记录，数据库只有原图就行了。 CDN的机制） http://www.baidu.com/img/bdlogo.gif？w=80&h=80， 则服务器就生成80*80的尺
2.1.6 返回的提示信息
最科学的情况，服务端只返回信息代码，具体的文字提示由客户端决定。如果文字信息是由服务端返回，则最起码要区分2种信息：提示用户的信息，提示客户端程序员的信息。
restful Restful后台系统架构深入分析
这两者的区别：
1. 提示用户的信息是要在让客户知道的，提示客户端程序员的信息不需要让客户知道的。（www.61k.com)
2. 提示用户的信息文字很友好，客户不需要专业基础一看就知道是什么，提示客户端程序员的信息则很专业，例如告诉客户端少传了哪个参数？哪个参数有问题等等。
2.1.7 在线api文档和测试
我们网站的api在线测试文档，既是一份在线api文档，也是一个在线测试工具，极大方便沟通和测试。每次客户端程序员觉得某个api有什么问题，我们就是这个在线工具上讨论沟通的。客户端程序员最喜欢这个玩意了^-^。
上个图解一下馋（这个图是旧版的api，已经弃用了）：
负责做这个功能的同事专门写了篇博客详细介绍了这个在线api测试文档，还带有demo：可以参考网址：http://amuropikin.iteye.com/blog/1701537
2.2 XMPP服务
在app中有时候是需要添加聊天服务，在这里谈谈曾经开发聊天服务的经验：
restful Restful后台系统架构深入分析
2.2.1 Openfire简介
聊天服务端选的是Openfire，这是一个基于xmpp协议的聊天服务器（XMPP是一种基于XML的协议，它继承了在XML环境中灵活的发展性。(www.61k.com）因此，基于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，可用时间戳生成，如vim@gmail/1359956556，vim@gmail/1359956777。
b. 在后台 Admin Console> Server Manager > System Properties中，设置“route.all-resources”为true。
2.2.4 一些常用的Openfire插件
Subscription： 官方的描述是这样的：Automaticallyaccepts or rejects subsription requests。
http://download.csdn.net/detail/newjueqi/6024521: 一个保存openfire聊天记录的插件，当根据我的使用经验，这个插件是把全部聊天记录保存在一个表中，性能极差，只能勉强应付，法律规定要保存3个月聊天记录这个需求，在实际应用中没啥用。
2.2.5 Php的Xmpp Library
如果服务器是使用php，那么能使用的xmpp客户端就只有xmpphp，这个libary只提供了最基本的发送消息功能，很多常用的功能都没有提供，我根据开发经验把一些常用的xmpp功能开发出来，并整合到xmpphp中：
restful Restful后台系统架构深入分析
registerNewUser //注册一个新用户
addRosterContact //发送添加好友的请求
accept friend request //接受好友请求
deleteRosterContact //删除某个好友
roomMessage //发送群聊消息
createChatRoom //创建群聊
kickUserOutToChatRoom //把某个人剔除群聊
项目的地址： https://github.com/newjueqi/xmpp。(www.61k.com］
2.2.6 个人开发Openfire插件
在手机的聊天应用中，经常出现的一个需求就是把用户的离线消息通过推送系统推送到用户的手机上，为了实现这个功能，本人就开发了本插件，这个openfire 插件是拦截了发给openfire用户的离线消息，然后根据自身的业务逻辑推送到手机上。详细介绍：http://blog.csdn.net/newjueqi/article/details/18032925。
扩展：日志分析系统架构 / 数据分析系统 架构 / 实时日志分析系统架构
2.2.7 常见问题
openfire中发送某些特殊字符会断开xmpp连接的问题，解决方法请看：http://blog.csdn.net/newjueqi/article/details/18260197。
另外一个好消息，https://layer.com/，这个网站打算提供一个聊天平台，ios 和android 应用简单整合就能提供聊天服务，密切关注中。如果真的能实现，那么对于app提供聊天服务是个很好的选择。
但有几个问题：
1. 它现在还没正式上线。
2. 访问外国网站的风险。
3. 法律规定要保存3个月聊天记录。
2.3 短信、邮件、推送服务
在app的后端设计中，免不了消息的推送，短信，邮件等服务，下面就个人的开发经验谈谈这方面。
2.3.1 重点
最重要的是，各种推送一定要放在队列系统中处理，不然会严重影响api的响应时间。
2.3.2 短信
以前我们是用亿美软通的短信服务，但在三大运营商收紧了短信服务后，亿美软通的短信延迟非常厉害，后来我们找到了这家短信服务商 http://luosimao.com，这家发送短信
restful Restful后台系统架构深入分析
到联通，电信，移动手机很快就到了（直到2014.01.24）。(www.61k.com］
如果发送到移动的短信还没有改善，最后的后备方案：发送到联通，电信的短信使用国内的服务商，发送到移动的短信就只能使用国外的短信服务商（国外发短信到移动手机3毛一条，好贵啊！！！）
2.3.3 邮件
在一开始时使用服务器自身的postfix发送邮件的，但我们发现邮件被很多邮件服务商当成垃圾邮件了，而且没有重发机制，不能保证邮件的准确到达。
后来查了一下各大网站，发现知乎和github 都是使用http://www.mailgun.com/ 的邮件服务，看了一下文档，价格很公道，而且每月有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 安全性
在开发一个项目的时候，大家经常会忽略项目的安全性问题，有很多的安全性问题其实就是一个意识的问题，解决起来并不复杂，但是因为这些疏忽，却可能会给我们的
restful Restful后台系统架构深入分析
用户带来很大的风险。［www.61k.com］下面就列举一些在做项目的时候应该考虑的一些安全性问题。
2.4.1 通讯的安全性
在app的后台设计中，一个很重要的因素是考虑通讯的安全性。因此，我们需要考虑的要点有：
1. 在app和后台，都不能保存任何用户密码的明文。
2. 在app和后台通讯的过程中，怎么保证用户信息的安全性?
在app中，根据安全考虑，用户的操作分为两类：
1. 用户登录注册操作。
2. 用户的其他操作。
在第一点，用户登录注册操作中，是会出现用户密码，所以在这个过程中，必须要使用https通讯，保证通讯的安全。
在第二点，用户的其他操作，怎么保证这部分通讯的安全呢？
在我的设计中，是采用了公钥加私钥保证安全。用户的id是公钥，通过一定的算法对用户的id进行加密得到一个加密字符串是私钥。当用户登录或注册后，通过https把公钥加私钥返回给app客户端。这个过程如下：
restful Restful后台系统架构深入分析
2.4.2 密码保存
保存密码的第一准则是不能明文保存密码，之前CSDN密码泄露一事还记忆犹新。(www.61k.com］通常的做法是对密码进行不可逆加密，加密时不要使用MD5或者SHA系列的算法加密，现在对这两个算法的破解研究工作已经有了相当的进展。推荐使用bcrypt。
2.4.3 CI服务器的安全性
CI服务器和Build服务器经常是攻击者最完美的跳板，这些服务器几乎拥有你系统的所有权限（代码库，各个生产环境的访问权限等等）。请确保其安全。
2.4.4 校验客户端安全证书的“指纹”
当使用SSL时，我们需要验证安全证书的“指纹”来确认该证书是有目标网站颁发的
restful Restful后台系统架构深入分析
证书，这可以有效防止“中间人攻击”漏洞。（www.61k.com）
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 避免跨站脚本攻击
系统需要保证用户不能在页面中嵌入未经验证的信息。
restful Restful后台系统架构深入分析
2.4.14 避免泄露信息给第三方
目前很多系统倾向于泄露信息给第三方，比方说Google，Facebook，新浪微博等等。[www.61k.com]这些第三方会窃取很多用户信息。
2.4.15 设置数据清理策略
只在需要数据时才保存数据，数据生命周期结束就清理掉，贼是没办法偷你没有的东西的。
2.5 表情的处理
在app的应用中，文字中夹带表情是个很常见，那么，在后台处理表情的时间，我遇到过下面两个问题：
1. 表情在mysql的存储。
表情的utf8编码，有时是有4个字节的，所以在一般的utf编码是没法存储的，我在网上看到的一个常用的解决方案，是把mysql升级到5.5,然后把字符编码改为utf8mb4_general_ci。但在实践中，我发现了还有一个方法，适用于mysql 5.1,就是把含有表情的那个字段的类型变为blob, 没错，就是用二进制存储。
2. 当文字中夹带表情的处理
很多时候，如果文字中夹带表情，那么这些文字的处理就会出现问题，例如，如果一个用户的昵称带有表情，那么我怎么把这个昵称转换为拼音呢？在实际的开发中，我遇到了这个问题，先是找到了 https://github.com/iamcal/php-emoji这个转换表情的类库，但发现这个类库不支持ios6后新增的表情，最后没办法了，我写了个抓取程序，把 中ios6后新增的表情抓取出来，并写了个新的类库并开源了 https://github.com/newjueqi/converemojitostr，这个类库的作用就是把文字中夹带的表情替换为一个特殊的字符(默认是"#")。
2.6 LBS服务
在LBS的应用中，一个基本的需求是查找附近的用户，现在有两种做法：
1. 使用mysql的空间数据库，具体做法参考： 。
2. 使用geohash编码，这个是本文需要讨论的。
geohash编码，可以把球面上的经纬度转换成一个值，简单点来说就是把二维坐标转换成一维坐标。查找附近的时候，非常方便，用SQL中，LIKE‘w23yr3%’可查询附近的
restful Restful后台系统架构深入分析
所有地点。[www.61k.com）
geohash的详细介绍，可参考 http://www.wubiao.info/372 。
在以前的产品中，一个需求是查找用户附近的商铺，发现用mysql LIKE‘w23yr3%’这种方式检索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*”，则$geohashKeys = $this->cache->redis->keys('place:geohash:' . 能同时匹配werewfs,werewfw
restful Restful后台系统架构深入分析
$likeGeohash . '*');
}
3. 如果需要查找关键字或商铺的类型，则用把2中$placeIds 作为filter调戏 ，在coreseek中继续查找。［www.61k.com］ $hashlen = strlen($nowGeohash); if ($geohashKeys) { } return $placeIds; } $searchKeys = array(); //对坐标进行排序 foreach ($geohashKeys as $k => $v) { } if ($searchKeys) { krsort($searchKeys); //mget表示返回所有特殊keys的values $placeIds = $this->cache->redis->mget($searchKeys); $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;
restful Restful后台系统架构深入分析 扩展：日志分析系统架构 / 数据分析系统 架构 / 实时日志分析系统架构
2.7 项目管理
移动互联网行业是个快速发展的行业，需求不断变化，产品更新快。［www.61k.com)基于移动互联网的以上特点，在开发产品的过程中，我们放弃了传统的瀑布流开发模型，引入了精益的理念和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。
restful Restful后台系统架构深入分析
（2）日常开发
在每个Sprint backlog，后台和app的交互都是通过api，所以由后台先写好相关的api并编写假数据，先让app端可以顺利开展工作。（www.61k.com）
先编写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. 有什么工作需要其他同事配合。
restful Restful后台系统架构深入分析
注意，避免在会议上讨论问题，如果真的需要讨论，请在会议后和同事讨论，不要浪费整个团队的时间。(www.61k.com]
（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. 后台中，有个系统的账号。每个用户一注册就和这个系统账号自动加为好友，可以随时通过聊天功能向这个系统账号提问题。一般我们的产品经理会经常登录这个系统账号和用户真正交流的。
restful Restful后台系统架构深入分析
2.8 数据库分表
当项目上线后，随着用户的增长，有些数据表的规模会以几何级增长，当数据达到一定规模的时候（例如100万条），查询，读取性能就下降得很厉害，这时，我们就要考虑分表。（www.61k.com)（是否得考虑数据库报警？）
更新表数据时会导致索引更新，当单表数据量很大时这个过程比较耗时，这就是为什么对大表进行新增操作会比较慢的原因，并且更新表数据会进行表级锁或者行锁，这样就导致其他操作等待。
所以我们将大表拆分为多个子表，那么在更新或者查询数据的时候，压力会分散到不同的表上。由于分表之后每个表的数据较小，不管是查询还是更新都极大的提高了速度，即使出现最坏的“锁表”的情况，那其他表还是可以并行使用。
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 分表：
restful Restful后台系统架构深入分析
2.9 动态通知
在app中，例如在通知界面，当新通知的时候，需要显示有多少条通知，用户点击“获取新通知”后，就能看到新的通知。[www.61k.com)
那么在app端，怎么才能知道有多少条新通知？ （其实只要实现了推送、聊天等动态实现的技术有两种： 1. polling: app定时查询
2. push：服务器实时推送给app
polling就是app每隔一段时间向服务器查询，获取新通知。这种方法很容易实现，但通知也等于实现了。）
restful Restful后台系统架构深入分析
在app端缺点也很明显：
1. 无论有没有数据，都需要查询，增加了服务器的负担。［www.61k.com］
2. 发送请求消耗手机的流量和电量。
更好的实现方式是push，即当有新通知的时候，服务器主动向app 推送数据。
push机制的实现在项目中的实现：app集成聊天功能后就和聊天服务器保持了一个socket连接，所以能利用这个socket连接实现push功能。当应用服务器需要向一个app推送任何新的通知时，只要连接聊天服务器发送消息，该app就能接收到socket连接传来的消息。
2.10 数据增量更新
在新浪微博的app中，从别的页面进入主页，在没有网络的情况下，首页中的已经收到的微博还是能显示的，这显然是把相关的数据存储在app本地。
使用数据的app本地存储，能减少网络的流量，同时极大提高了用户的体验（想想，很多数据都能在app本地获取，显示的速度当然快）。使用了本地存储后，需要考虑的是数据的增量更新方案。
什么是数据的增量更新？假设，用户A的首页在数据表中是有40条数据，id1-40，app每次获取10条数据。第一次运行，app从数据表获取了 id1-10条数据同时存储在本地。假设用户离开了这个页面再回到首页，这时app需要再次从数据库中获取数据，由于之前已经有10条数据 （id1-10）存储在app本地了，那么现在需要从数据库中获取的10条数据就是从剩余的30条中数据获取（id11-40）后并保存在app本地。这 个就是增量更新的典型例子。
增量更新的原理是在数据库中，每条数据都必须有update_time这个值，记录数据最后更新的时间，当app从服务器获取了一次数据后（返回的数据必 须按时间排序，update_time最近的在第一条），记录下第一条数据的update_time，当再次获取数据就只需要获取上个时间点到访问服务器 这刻为止所更新的数据即可。
因为分页机制的存在，这个算法实现起来是挺多需要注意的地方，下面我举一个简化的例子详细说明： 一些假设：
1. app每次请求都带4个参数
http://test/api/timeline?count=3&page=1&since=1100&max=1200
count: 每页的显示条数（默认为3）
page: 当前页码（默认为1）
since: 时间戳，若指定此参数，则返回时间戳大于等于since的结果（应该是上次获取的最新数据的update_time）
restful Restful后台系统架构深入分析
max: 时间戳，若指定此参数，则返回时间戳少于等于max的结果（应该是发送时的时间）
在sql的查询时，使用条件 since<=update_time<= max
2. api 返回的数据包含
{
"size": 10, //实际返回的数据量（因为分页获取的缘故，所以经常少于total值） "total": 284, //应该返回的总数据量
扩展：日志分析系统架构 / 数据分析系统 架构 / 实时日志分析系统架构
"page": 1,
"count": 3,
"max": 0, //max为获取的最后一条数据的update_time
"since": 0
},
{ //返回的数据实体
data:.......
}
3. app存储的本地数据中的update_time是指服务器中的这条数据的更新时间，不是指app中这条数据的更新时间。（www.61k.com]
现在开始讨论：
（1）当app安装完毕后还没启动，服务器的数据表中的数据为3条，app存储的本地数据为空
（3）从（2）中发送请求后，api的返回数据，服务器的数据表中的数据，app存储的本地数据如下：
restful Restful后台系统架构深入分析
{
"size": 3, //实际返回的数据量
"total": 3, //应该返回的总数据量
"page": 1,
"count": 3,
"max": 1101,
"since":0
},
{ //返回的数据实体
data:.......
}
这里是策略的重点（1）： api返回数据中的max必须为最后一条数据的update_time
（4）现在的时间是11:20，用户点击了页面中“获取更多”的按钮，app应该从服务器的数据表中拉取数据，在发送请求前，服务器的数据表中的数据如下：
restful Restful后台系统架构深入分析
可看到，比起上次拉取数据的时候，服务器的数据表多了id为4,5,6,7的数据。(www.61k.com) 这时发送api请求，策略的重点（2）：当api的返回数据size=total时，since值比上次获取大一点，因为这 时数据已经获取完整了，没必要重复获取数据上次已经获取的数据（记得条件since<=update_time<= max 吗？）所以since值设置为1101+1=1102，max为现在的时间点：1120，请求的url如下：
http://test/api/timeline?count=3&page=1&since=1102&max=1120
发送请求后api的返回数据和app存储的本地数据如下：
api返回的数据
{
"size": 3, //实际返回的数据量（因为分页获取的缘故，所以经常少于total值） "total": 4, //应该返回的总数据量
"page": 1,
"count": 3,
"max": 1119,
"since":1102
},
{ //返回的数据实体
data:.......
}
这里是策略的重点（3）：在数据库中，update_time为1101~1120的数 据有4条，但由于分页的缘故，只获取了3条（从size和total参数可以判定），这意味着1101~1120这段时间的数据没有获取完整，app所获 取的最后一条数据的update_time是1119，服务器的数据表中剩下的没有被app获取的数据有两种情况：
a.update_time刚好是1119
b.update_time大于1119
restful Restful后台系统架构深入分析
由于我们没法判断属于哪种种情况，如果我们下次拉数据的时候 since大于1119，服务器的数据表中id为7的数据不会再获取，那么会造成app中丢失了id为7的数据，所以针对上次数据获取不完整的情况，下次 获取数据时since必须是等于1119，虽然有可能会获取重复的数据。（www.61k.com］
（5）现在的时间是11:30，用户点击了页面中“获取更多”的按钮，app应该从服务器的数据表中拉取数据，在发送请求前，服务器的数据表中的数据如下：
发送请求后api的返回数据和app存储的本地数据如下：
api返回的数据
{
"size": 3, //实际返回的数据量（因为分页获取的缘故，所以经常少于total值） "total": 3, //应该返回的总数据量
"page": 1,
"count": 3,
"max": 1120,
"since":1119
},
{ //返回的数据实体
data:.......
}
restful Restful后台系统架构深入分析
这是策略的重点（5）：api中返回数据中id为6的数据，在app的本地数据中已经存在，对于这条数据，app端应该放弃重复插入。（www.61k.com]
最后app存储的本地数据如下：
ok，整个增量更新的策略已经分析完毕了。在这个策略中，page参数几乎没用，之所以要保留，是为了兼容分页不带since,max的情况。对于这个增量更新的策略，请仔细理解策略的重点（1）（2）（3）（4）（5）的分析。
增量更新的策略，还要处理一个删除数据的同步问题。假设，在服务器的数据表要删除一条数据，怎么通知app本地也删除这条数据。我们的解决方案是服务器的 服务器的数据表中增加一个标识is_delete，当需要在业务逻辑上删除的时候，把这条数据的is_delete设为1，同时更新 update_time。当app增量更新检测到这条is_delete为1的数据，就在app本地数据中把这条数据删除。为了避免在服务器保存太多的数 据，在服务器设置一个crontab，定期把那些已经标识is_delete设为1已经一段时间的数据删除。
这个增量更新的策略，适用于需要分页显示的app页面。
2.11 系统架构
个人认为，在小型的创业团队中，特别是以应用产品为主，在架构后台的时候，需要集中精力解决自身业务上的问题，不是花时间解决第三方已经解决的问题，简单点来说，就是能用第三方服务就使用第三方的服务。基于这个原则，就有了下面的系统架构：
1. Apns/Apn
由于在apns中，无效的token会导致连接apns连接的失效从而使apns信息丢失。解决的方案是维护发送队列，当apns服务器返回错误的token后，把这个错误token后的消息重发。第三方推送很好了实现了这个技术方案，我们选择了百度云推送。
扩展：日志分析系统架构 / 数据分析系统 架构 / 实时日志分析系统架构
restful Restful后台系统架构深入分析
2. Email
要考虑邮件发送失败的重发问题，所以不再在服务器上搭建sendmail服务发送，选择了邮件服务商mailgun。［www.61k.com］mailgun还提供每个账号每月1万封邮件的免费额度，很适合创业团队。
3. Coreseek
一个基于Sphinx的全文检索引擎。在前面描述的LBS模块中，和检索用户昵称，商铺等搜索功能上需要用到。
4. Redis
一个支持多种数据结构的key-value数据库，在LBS模块，性能优化等多个方面都有广泛的用处。
5. Httpsqs
轻量级的消息队列。
6. Xmpp
采用了开源的openfire，当web服务需要向openfire通讯，有两种情况：
（1）实时的需求，例如注册的时候在聊天服务器注册一个用户，那么是直接连聊天服务器。
（2）如果是其它非实时的需求，例如通过聊天服务器向app发送一个更新通知，那么就在队列中处理。
7. Monitor
系统数据监控，采用了监控宝和云服务器提供的监控数据，能满足目前的需求了。 整个架构如下图：
restful Restful后台系统架构深入分析
扩展：日志分析系统架构 / 数据分析系统 架构 / 实时日志分析系统架构
四 : 系统分析师_架构设计师职位说明书
岗位描述：
1、负责系统及相关产品需求分析及架构设计;
2、对产品的整体系统架构负责，对产品的系统安全性设计负责，开发及相关设计文档编写;
3、负责相关请求的技术分析，负责制订相关的技术解决方案;
4、参与制定设计及实现规范，指导设计、实现及部署工作;
5、配合项目经理进行技术决策，进行技术风险评估;
6、负责对软件开发团队的技术指导。
任职资格：
1、软件工程、软件开发相关专业本科及以上学历;
2、3年以上工作经验，具有独立承担超过2年以上的软件项目系统分析和架构设计经验，有成功案例、大型系统软件架构设计经验优先;
3、掌握软件工程理论，精通至少一种软件工程方法，有较强的系统分析能力;
4、熟悉.net及java体系架构，精通主流的开源框架;
5、精通oracle,sqlserver等数据库的应用，有大型mis系统构建经验，具有相关应用开发经验及数据库规划能力;
6、了解最新的技术及发展趋向，网络知识经验丰富，懂得怎样衡量各种设计方法的利弊，懂得平衡各种开发局限的制约;
7、极强的文档撰写能力，良好的英文阅读能力;
8、逻辑分析能力、学习能力和创新能力强，具有团队合作精神，良好的语言表达及沟通能力。
本文标题：系统分析师架构师-DISCUZ架构:积分系统代码分析三61阅读| 精彩专题| 最新文章| 热门文章| 苏ICP备13036349号-1