《App后台开发运维与架构实践》第10章 App后台架构的演进

2019独角兽企业重金招聘Python工程师标准>>>

10.1 架构的核心要素

10.1.1 高性能

性能问题是驱动架构发展的最直接力量，因为性能问题是最容易被用户感知的，没有一个用户会忍受一个响应速度极慢的App。从App发出请求到App后台返回结果，这一过程如下所示。

每层都有相应的措施以提高系统的性能。

• App层

图片、音频、视频等静态资源，第一次下载后可以缓存到手机的SD卡；对于通知等内容，使用增量更新的技术，减少服务器的负担和使用的流量；根据App当前的网络环境下载不同的图片数据。

• 网络传输层

使用CDN技术，让用户在最近的机房下载静态资源，减少网络传输的时间；在应用服务器部署反向代理服务器、缓存热文件，使请求在到达应用服务器前返回静态资源，减轻服务器的负担，减少请求的时间。

• 应用服务层

在代码层面，改进算法，使用多线程和优化程序内存等优化方法；在语言层面，考虑使用Golang、Erlang等更适用于高并发场景的语言；通过异步操作把用户的请求发送到消息队列等待任务程序处理，减少请求的等待时间；将多台应用服务器组成一个集群，使用负载均衡软件把请求按一定的规则分发到每个应用服务器上，提高系统整体的处理能力；使用分布式缓存软件缓存用户的热点请求数据，加快服务器的响应时间，减轻数据库的负担。

• 文件服务层

使用MogileFS、TFS、FastDFS等软件架设一个分布式文件系统，提供整体的文件处理能力；使用七牛、又拍、UCloud的对象存储等第三方文件云存储服务，把文件存放在云服务器上，从而在架构上去掉文件服务器。

• 缓存层

使用Redis、Memcached或者云服务器的云缓存服务。

• 数据库层

数据库前加一层或多层缓存，挡住大部分的热点请求，使大部分的请求不穿透到数据库，减轻数据库的压力；对于MySQL数据库，可以使用读写分离、分表、分库等成熟的技术；对于NoSQL类型的产品，例如MongoDB，可以使用其原生的副本集、分片等机制，提升其性能；使用Facebook开源的FlashCache技术，把传统硬盘上的热数据缓存在SSD硬盘上，冷门数据保存在传统硬盘上。

10.1.2 高可用

高可用就是要保证为App提供7X24小时服务的App后台，服务器不能随便宕机，或者在一个服务器集群中，部分服务器宕机了也可以保证整个服务不受影响。保证App后台高可用的主要方法是冗余。

对于应用服务器而言，多台应用服务器组成一个集群，由负载均衡器把请求按照一定的策略分发到集群中的每个应用服务器，当负载均衡器检测到某台应用服务器宕机，就把该台应用服务器从集群中移除。保证负载均衡策略有效的核心是应用层必须是无状态的。所谓无状态，就是指任意一台应用服务器上不会保存用户的状态信息（例如，在某台应用服务器上保存用户已经登录的凭据）。用户的状态信息可以存储在缓存或数据库，供所有的应用服务器共同调用。

对于数据服务器（包括数据库、缓存、文件）而言，保证高可用需要对存储的数据进行实时备份，当数据服务器宕机后，立刻把数据的读写请求切换到备份服务器上，同时尽快修复宕机的服务器，以保障冗余。

10.1.3 可伸缩

可伸缩是指通过往集群中添加机器，应付不断增大的访问压力和数据存储需求。

应用服务器的可伸缩性是指当访问量增大后，往集群中添加服务器。数据存储的可伸缩性分为文件数据的可伸缩性（比如分布式文件存储软件FastDFS）、缓存数据的可伸缩性（通过改进的路由算法减少添加服务器造成的路由失效情况）、数据库的可伸缩性（关系型数据库的分布式处理系统MyCat实现分库，NoSQL数据库MongoDB使用分片策略就能实现可伸缩性）。

10.1.4 可扩展

可扩展性的核心是减少模块间的耦合度，每个模块都尽量少依赖其他模块，这样其中一个模块的变化对其他模块的影响减少。实现可扩展的方式如下：

• 消息队列：降低模块间的耦合程度。
• 分布式服务：把业务中可复用的模块抽离成一个独立的服务，对其他模块提供可复用的服务，通过分布式服务框架供其他模块调用。
• 开放式API：把自身的业务封装成开放式API供其他开发者调用。

10.1.5 安全性

安全性就是保证用户的核心数据不被非法人员盗窃。

10.2 架构选型的要点

10.2.1 用成熟稳定的开源软件

10.2.2 尽可能使用云服务

功能	可使用的云服务
项目管理工具	Teambition、Tower
代码管理工具	GitHub、码云
负载均衡	阿里云负载均衡服务SLB、UCloud负载均衡服务ULB
邮件服务	SendCloud、MailGun
消息队列	阿里云消息通知服务MNS
文件系统、图片处理	七牛、又拍云、阿里云对象存储OSS、UCloud对象存储UFile
Android推送、iOS推送	极光、个推、百度推送
聊天	融云、环信
监控	监控宝、云服务器自带的监控服务
缓存	阿里云开放缓存服务OCS、UCloud云内存存储UMem
关系型数据库	阿里云云数据库RDS、UCloud云数据库UDB
NoSQL数据库	阿里云开放结构化数据服务OTS、UCloud云内存存储UMem
搜索	阿里云开放搜索服务OpenSearch
分布式访问服务	阿里云企业级分布式应用服务EDAS
防火墙	阿里云云盾、UCloud防火墙
短信发送	阿里云短信服务、bmob、shareSDK、Luosimao
社交登录分享	shareSDK

10.3 架构的演进

App后台的架构是由业务规模驱动而演进的，App后台是为业务服务的，App后台的价值在于能为业务提供其所需要的功能，不应过度设计。

从一个项目的角度，当App访问量不大的时候去追逐高性能App后台的架构是舍本逐末，这时候的主要工作是快速搭建App后台，让App尽快上线给用户提供服务，验证商业模式的正确性，同时快速迭代产品。

当App访问量不断飞涨，这时要在保证快速迭代的前提下，同时也兼顾高性能和高可用。

当App访问量增长到一定阶段后，增长曲线会有所放缓，但业务变得更加复杂，对高性能和高可用的要求也更高，性能问题、模块间的耦合、代码的复杂性会更加突出和明显，这时要使用业务拆分、分布式服务调用，甚至是技术转型等问题。

转载于:https://my.oschina.net/lienson/blog/3036431