完整社交APP需求分析原型设计整体架构前端后端架构

一个社交App需实现的功能

用户关注的常规社交功能、活动、地理位置、探索功能、新鲜事、视频照片分享等等，需要提供的功能不胜枚举，所以从技术角度来说，开发者需要解决的问题也是异常复杂的。

当一款社交App发布之初，用户访问量比较小，使用一台服务器就能够支撑全部的访问压力和数据存储需求，但是互联网应用具有病毒式的传播特点。一款App很可能会面临一夜爆红的现象，访问量和数据量在短时间内呈现爆发式增长，这时候会面临的局面是每天上亿PV、数百万新增用户和活跃用户、流量飙升至每秒数百兆。这些对于一个只部署了简单后端架构的应用来讲是无法支撑的，会直接导致服务器响应缓慢甚至超时，以及在高峰期时服务呈现瘫痪状态，使得后端的服务完全无法使用，用户体验急剧下降。本文将会通过一个真实的案例来分享一个社交应用如何构建一个具备高伸缩性的后端系统。

社交App最初部署的后端架构解析

社交App在最初的时候，后端架构相对比较简单，最初是部署在基础网络之上。最前面放置一台绑定了公网IP的nginx服务器作负载均衡，后面放置3台应用服务器来负责处理所有业务上的请求，最后面搭建一台MySQL Database数据库。

构建私有网络

随着产品的不断迭代、用户数的持续增长、数据量的积累，App就需要改进自己的后端架构，即开始构建私有网络。用户可以使用私有网络构建自己的网络拓扑——创建路由器和私有网络，将后续加入的用于运行内部服务的主机放置在私用网络中，可以有效地和云平台其他用户主机，在网络上实现100%二层隔离。主机对外开放的仅仅只有80端口，这样系统安全性上多了一层保障。

在上面的架构图中，最前面的是防火墙，后面接负载均衡器，然后接路由器和私有网络，很多互联网应用都存在读多写少的情况，这个比例有时可以达到8:2，所以我们首先通过引入缓存分摊数据库读压力。其次，引入负载均衡器，替换最初架构中的nginx proxy，负责均衡器在这里其主要用于分发请求到后端多台应用服务器，，当其中一台应用服务器挂掉，负载均衡器可以进行自动隔离。

业务分区与扩展

App随着并发访问量和数据量不断增大，首先想到横向扩容Web服务。水平扩容业务服务器的前提是要保证每台服务器都是无状态的，将session信息下放到缓存或数据库中存储，保证请求被负载到任何一台服务器可以正常处理。

从上图中看到，在前一步「构建私有网络」之后，增加了一个新的私有网络来扩展网络层，这里可以利用自有映像功能，将原有的应用服务器制作成模板，后续就可以基于这个模板快速启动新的主机。另外可以利用Auto-scaling （自动横向扩展）功能，根据后端服务器的负载请求，动态调整服务器的数量。

一个社交应用的后端会提供很多服务请求接口，比如添加好友、刷新新鲜事、浏览页面等，可以通过日志分析每一个接口的耗时，将耗时长但非重要业务的请求分到单独的Web服务器上进行处理，从而给主Web服务器留出更多资源去处理关键业务的请求。

面向服务的架构

随着产品功能的不断迭代，业务代码会越来越复杂，出现故障的可能性也在加大，当一个局部功能出现问题时，都会影响整个服务的可用性。此时可以构建面向服务的架构，将一个完整且庞大的服务拆分为一个个的子服务，服务之间通过接口交互。如下图所示：

社交App的服务被拆分成了四个子服务——新鲜事（News Feed）、用户资料（Profile）、广告（Ads）和探索（Explore），不同的服务之间通过消息通信框架（例如ZeroMQ）来进行交互。把一个大服务拆分为几个小的子服务的好处不言而喻，主要是：

•故障隔离：子服务出现故障不会影响全局，比如广告业务出现问题并不会让整个App不能使用，依然可以查看新鲜事等；

•独立扩展：每一个被拆分出的子服务有着不同的访问压力，比如新鲜事的调用相比一些二级页面的用户资料要高很多，所以前者会被分配更多的Web 服务器；

•独立部署：一个大服务的配置因功能过多会异常复杂，一旦被拆分就可根据不同的特性需求定制配置项，从而提高可管理性；

•团队协作开发：开发者都有着自己精通的方向，从而提高开发效率；

•抽象出数据访问：在后续进行数据层面（数据库、缓存）扩展时，可通过修改子服务的Data Service，实现对下层数据的透明。

数据库Replication

业务增长也会给数据库带来诸多问题，当最初架构中单台数据库（数据库同时提供读和写）不足已支撑起App访问压力时，首先需要做数据副本Replication。市面上常见的MySQL、MongoDB等数据库都提供Replication功能，以MySQL为例，从高层来看，Replication可分成三步：

1.Master将改变记录到二进制日志（binary log）中（这些记录叫做二进制日志事件，binary log events）；

2.Slave将Master的binary log events拷贝到它的中继日志（relay log）；

3.Slave重做中继日志中的事件，将改变反映它自己的数据。

具体实现该过程的第一部分就是Master记录二进制日志。在每个事务更新数据完成之前，Master在二进制日志记录这些改变。MySQL将事务串行的写入二进制日志，即使事务中的语句都是交叉执行的。在事件写入二进制日志完成后，Master通知存储引擎提交事务。

下一步就是Slave将Master的binary log拷贝到它自己的中继日志。首先，Slave开始一个工作线程——I/O线程。I/O线程在Master上打开一个普通的连接，然后开始binlog dump process。Binlog dump process从Master的二进制日志中读取事件，如果已经跟上Master，它会睡眠并等待Master产生新的事件。I/O线程将这些事件写入中继日志。

SQL slave thread处理该过程的最后一步。SQL线程从中继日志读取事件，更新Slave的数据，使其与Master中的数据一致。只要该线程与I/O线程保持一致，中继日志通常会位于OS的缓存中，所以中继日志的开销很小。

此外，在Master中也有一个工作线程：和其它MySQL的连接一样，Slave在Master中打开一个连接也会使得Master 开始一个线程。复制过程有一个很重要的限制——复制在Slave上是串行化的，也就是说Master上的并行更新操