App后台开发运维——架构设计

在这里插入图片描述


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架构拆分
在这里插入图片描述
业务平稳期:
在这里插入图片描述

  • 2
    点赞
  • 30
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

amingMM

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值