QQ 1285575001
Wechat M010527
技术交流 QQ群599020441
纪年科技aming
1.设计app架构
1.梳理app业务流程
2.整理业务流程可能遇到的问题
3.根据问题，探讨可执行的解决方案
4. app后台 初步架构 ：3中所有技术进行有机融合
api编写：
1.api的作用（功能）
2.api需要输入的参数
3.api返回的数据
2.服务器选择
1.传统的IDC
在传统的IDC，要加cpu或内存，流程如下:
1.和客户经理商商谈所需硬件的价格
2.汇款过去，等IDC的财务确认
3.确认后，等待IDC安排工作人员升级硬件
这个流程走一次，最少也要1至2天。延迟了1至2天升级硬件，怎么保证可以快速应付爆发的业务
2.云服务器
升级硬件:
1.在用户后台选择需要的硬件配置
2.通过网络支付
3.重启服务器，升级就完成了。如果只是升级带宽，甚至不用重启。
整个过程合起来不用5分钟，简单，快捷，方便。
而且，现在的云服务器提供商，除了服务器外，还提供下面的服务：
负载均衡
云数据库
云内存存储
这些服务在app上线初期，在一台服务器上自己搭建就行了，
但随着app的发展，这些服务都需要部署在不同的服务器。
规模的增大，也要面对高可用，高并发，监控报警等问题。
这些问题如果都要后端人员处理，那要疯了，后端就那么一两个人，既要保证平时的开发任务，又要做复杂的运维管理。
后端人员也不是全能，一般后端人员是专注于开发，运维稍逊一筹。
这时，就能体会到云服务的优点，由云服务器的提供商来负责运维。
高可用，高并发，监控报警这些都靠云服务器的提供商来保障，就能大大减轻运维方面的压力和人员的开支。
3.选择
在网络上经常被问到，需要选择什么样的服务器配置，这个问题，没法回答。
这需要在综合考虑用户量，业务逻辑综合考虑的。
给个建议，最初硬件配置可以差点，
随时监控主机，发现负载高了，才升级硬件配置也不迟
3.app后台
1.app后台要慎重考虑网络传输流量，主要做api设计，图片处理上
2.移动手机弱网络环境
3.手机电量有限
4.app流程
1.项目业务逻辑
2.产品原型
3.UI效果图
4.研发阶段
5.测试反馈
6.市场推广与市场运营
项目开发管理
app后台
1.api接口
2.业务逻辑思维导图
app后台角度，api返回的数据中正确值和空值的类型必须一样，禁止返回null值;
app客户端，当api返回数据缺少某个数据时，app客户端自动补上这个数据并赋值；
数据库设计，所有字段都有默认值，不允许Null值；
产品中常用的null值需求是用Null表示数据未填写，如用“1”表示男性，“0”表示女性，Null表示用户未填写性别；
数据库选择
1.MySQL、Redis、MongoDB读写数据区别
Redis是存放在服务器端内存中，内存用满之后需要扩容，
就只能使用Redis的分布式方案，为防止丢失，可调整Redis配置文件，
按一定策略把数据持久化传到硬盘中。
MongoDB同时使用了硬盘和内存，
其使用了操作系统提供的MMAP（内存文件映射）机制进行数据文件的读写，
MMAP可以把文件直接映射到进程的内存空间中，这样文件就会在内存中有对应的地址，
这时对文件的读写是可以操作内存进行的，而不需要传统的如fread、fwrite文件操作方式。
MySQL的数据放在硬盘中，MySQL的缓存是查询的结果，而不是缓存数据。
2.MySQL、Redis、MongoDB查找数据的区别
Redis的数据基于“键值对”存储，查找数据，直奔主题，读写速度快。
MongoDB和MySQL，每组数据都有一个id（或者可以为每组数据建立索引），
查找数据分两种，知道id或索引，不知道id或索引，
前者效率高，后者效率低。
3.MySQL、Redis、MongoDB查找数据的区别
Redis数据只存放在服务器端内存中，由于内存价格高，所以内存存储数据成本高，
app后台开发中，读写频率高的数据一般放在Redis中
（当然这部分数据也可放在MySQL或MongoDSB中，Redis中国的数据是以缓存的形式存在的，数据更新时，两部分数据都要更新以保持数据统一性）。
MongoDB使用场景：
网站数据：
MongoDB非常适合实时的插入、更新与查询，并具备网站实时数据存储所需要的复制及高度伸缩性；
大尺寸、低价值的数据；
高伸缩性的场景；
存储地理坐标的数据；
MongoDB不适用场景：
高度事物性的系统：如银行或会计系统，涉及金钱的操作不支持；
传统的商业智能应用；
需要SQL的问题：虽然MongoDB支持类似于SQL的查询，但它的查询比起MySQL来有一定的差距；
MySQL适用场景：
事物性的系统：如转账；
需要复杂的SQL问题；
消息队列
消息队列把大量的并发请求变成串行的请求，来减轻服务器的压力。
app后台中，发送邮件、发送短信、推送消息等任务都适合在消息队列中完成；
使用分布式服务实现业务复用
远层服务：
把重复实现的模块独立部署为远程服务，新增的业务调用远程服务所提供的功能实现相关的业务，不依赖于里面的具体实现代码。
当远程业务发生变化时，只要接口传人的参数和返回值不变，就不会影响到调用远程服务的业务。
后台核心技术
短信平台选择（价格，短信的到达率和延时），先试用，在选用！
为建立可靠的短信服务，app后台必须要接入最少两个短信平台，当前短信平台不可靠时，切换到另一个平台；
5.表情
Openfire中发送表情引起连接断开的问题
xmpp断开连接，是由Openfire中代码引起的，app后台加个codePoint判断即可；
6.高效更新数据
推拉结合和数据增量更新是实现高效获取数据的关键；
7.数据增量更新策略
使用app本地存储，需考虑数据增量大更新方案；
当app从服务器获取一次数据时，记录获取最新数据的update_time，
当再次获取数据就只需要获取update_time到访问服务器这刻为止所更新的数据。
8.获取APK和IPA文件中的资源
文件系统
尽量使用成熟可靠的云服务和开源软件，自身只专注于业务逻辑；
架设文件系统涉及文件的分布式存储、图片水印、图片缩放、及CDN等方面，
小团队可用第三方云存储平台；
app后台应用最广泛的系统
1.基本系统优化
app后台的Linux系统如果是采用默认安装或机房工作人员帮忙安装，
运维人员需要对其进行优化，以获得更高的性能和安全性。
开启自动服务优化；
Linux的交换区：交换区是硬盘上的一块空间，在内存不足的情况下，
操作系统先把内存中暂时不用的数据存储到硬盘的交换区，腾出内存来让别的程序运行。
阿里云服务器上的Linux系统是默认没有设置交换区（Swap），
由于开启Swap分区会导致硬盘IO性能下降，
因此阿里云服务器初始没有设置Swap，如需要开启Swap，可使用相应的命令开启。
2.故障案例分析
Nginx-app后台HTTP服务的利器
Nginx与Apache类似，其是一个高性能的HTTP和反向代理服务器，也是一个imop／pop3/smtp代理服务器。
Nginx高性能主要是使用了epoll和kqueue网络I／O模型，而Apache使用的是传统的select模型。
处理大量请求时，epoll模型远远大于select模型；
理解：select 模型处理（如客人进店点菜，服务员全程跟着）
epoll模型处理（如客人进店点菜，在需要的时候服务员才跟着）
http配置；
https配置：
下载app配置：在浏览器下载；
性能统计：可开启Nginx的统计模块；
MySQL-app后台最常用的数据库
1.MySQL基本架构
服务层：大多数基于网络的客户端／服务端工具都有这一层，这一层主要处理连接和安全验证；
核心层：这层处理MySQL的核心业务；
查询、分析、缓存和内置的函数
内建的视图，存储过程，触发器
存储引擎层：存储引擎负责数据的存储和提取。
核心层通过存储引擎的API与存储引擎通信，这样就遮蔽了不同存储引擎的差异，
使得这些差异对上层查询是透明的。
存储引擎之间不会相互通信，只是简单的响应上层查询。
建议选择MySQL社区版，足够业务需求；
2.软件优化
1.正确使用MyISAM和InnoDB存储引擎
MyISAM和InnoDB存储引擎是MySQL最常用的存储引擎；
MyISAM基于ISAM（索引顺序访问方法），支持全文索引，但并非是事物安全，不支持外建，
使用表级锁。
每个MyISAM存3个文件：FRM文件存放表结构，MYD文件存放数据，MYI存放索引。
InnoDB是事务型存储引擎，其支持行锁，InnoDB的行锁也不是绝对的，
如果他在执行一个更新的语句是没法确定更新的范围，也会锁表。
InnoDB支持回滚、崩溃恢复、ACID事物控制，
InnoDB存储他的表和索引在一张表空间，表空间可包含多个文件。
支持外建，是事务安全型的；
2.正确使用索引
3.避免使用select*
“select*”从数据库中返回的数据更多，降低了查询速度；
过多的返回结果会增大服务器反给app端的数据的传输，
网络不好的情况下，过大的传输会造成请求失败；
4.建议数据库上所有字段都设置为NOTNULL，必须有默认值；
3.硬件优化
1.增加物理内存
2.增加应用缓存
3.用固态硬盘代替机械硬盘
4.SSD硬盘+SATA硬盘混合存储方案
4.架构优化
1.分表
项目用户增长，数据庞大，就要分表：将大表拆分为多个子表，
在更新或查询数据的时候，压力会分散到不同的表上。
由于分表之后，每张表的数据变小，查询或更新会有很好的提升；
水平拆分：把一张表的数据分别保存在不同的表中；
垂直拆分：把一张表的字段保存在不同的表中；
2.数据库优化
使用数据库读写分离策略；
读写分离是把对数据库的读和写操作分开对应于主／从数据库服务器；
3.分库
数据规模变大，当读写分离也不能满足系统性能要求的时候要考虑分库，
分库即把不同的数据表部署在数据库集群上；
4.SQL慢查询分析
SQL慢查询是指超过一定时间的SQL查询语句，把这些语句记录到查询日志，以便分析其原因，以进行优化。
5.云数据库
Redis-app后台高性能的缓存系统
1.Redis
业务场景需求：
Redis就是满足上面需求的开源Key-Value内存存储系统；
特点：
2.Redis常用数据结构及应用场景
2.1string-存储简单的数据
2.2hash-存储对象的数据
2.3list-模拟队列操作
如短信发送：
2.4set-无序且不重复的元素集合
2.5sorted set - 有序且不重复的元素集合
3.内存优化
3.1监控内存使用情况（命令redis-cli info）
3.2优化存储结构
- hash存储，当hashmap成员达到不同数时，采用不同的形式存储数据
- （<512用ziplist存储，>512用hashmap存储;）
- ,hashmap成员长度（<64用ziplist存储，>64用hashmap存储）
- set使用了intest的结构来节省内存
3.3限制使用的最大内存
设置maxmemory的参数来限制Redis使用的物理内存
当Redis使用的内存达到了限制值，任何write操作会触发“数据清除策略”，配置文件“maxmemory-policy”来采用特定的“数据清除策略”
3.4设置过期时间
可设置Key超时时间（命令EXPIRE key seconds）
超过超时时间后，删除不用的Key及数据，达到内存优化；
集群
4.1客户端分片
4.2Twemproxy
4.3Codis
4.4Redios3.0集群采用了p2p模式，完全去中心化
4.5云服务器上的集群服务
4.6持久化
Redis是一个支持持久化操作的内存数据库，通过持久化机制把内存中的数据保存在硬盘文件。
当Redis重启后通过把硬盘文件重新加载到内存，就能达到恢复数据目的。
4.7故障排除
查看Redis错误日志；
MongoDB-app后台新兴的数据库
1.MongoDB
2.高可集用群
2.1主从
MongoDB采用双机主从备份，主节点的数据会自动同步到从节点，
当主节点宕机后，切换到从节点继续提供服务。
2.2副本集
副本集使用多台机器做同一份数据的同步和异步，从而使多台服务器拥有同一份数据的多个副本。
一台服务器作为主节点提供写入服务，多台服务器作为副本节点提供读取服务，
实现读写分离和负载均衡。
当主节点宕机后，可把副本节点提为主节点或将其他节点改为主节点，继续服务。
2.3分片
集群中大量的数据读写请求分散到多个集群处理，在MySQL中称为数据库分片；
2.4.LBS- 地理位置查询
2.5MongoDB3.0
app后台架构剖析
1.聊天app后台架构
1.1移动互联网的网络特性
1.2协议
基于版本号的消息协议
1.3文件发送
1.4聊天架构
社交app后台架构
社交的核心功能是Feed；
2.1基本表结构
常见的Feed架构就是把数据存储在MySQL中，
热点数据（一般说最近3天数据）存储在缓存
（常见的缓存有Redis和Memcached，微博用的Memcached），
务必让绝大数请求通过缓存直接返回，只有少量的请求穿透缓存落到数据库。
微博中公开的微博采用了拉模式，私密性微博采用了推模式；
2.3数据库的架构演进
单机部署 ——> 读写分离，从一主一从到一主多从——>分表分库
2.4社交app后台数据库在业务层实现分表分库的方案
2.5缓存架构的演进
分布式缓存
主从缓存结构
LBS-app后台架构
推送服务器的后台架构
4.1Android推送
由于android系统没有限制，当app进入后台也能运行服务，所以android可以基于长连接作推送；
app连接推送服务器流程：
后台推送消息到app流程：
app获取离线消息流程：
4.2iOS推送
APNS原理：
app后台架构的演进
app发送请求后台运行：
1.高性能
app层：
网络传输层：
应用服务层：
文件服务层：
缓存层：
数据库层：
2.高可用
宕机后的负载均衡：
高可用备份：
数据服务器宕机：
3.开发服务器、工具
4.架构演进
4.1单机部署
app后台极简化架构：
4.2分布式部署
4.3架构拆分
业务平稳期：
