原创力文档- 1、原创力文档（book118）网站文档一经付费（服务费），不意味着购买了该文档的版权，仅供个人/单位学习、研究之用，不得用于商业用途，未经授权，严禁复制、发行、汇编、翻译或者网络传播等，侵权必究。。
- 2、本站所有内容均由合作方或网友上传，本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺！文档内容仅供研究参考，付费前请自行鉴别。如您付费，意味着您自己接受本站规则且自行承担风险，本站不退款、不进行额外附加服务；查看《如何避免下载的几个坑》。如果您已付费下载过本站文档，您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等，请点击“版权申诉”（推荐），也可以打举报电话：400-050-0827(电话支持时间：9:00-18:30)。
- 4、该文档为VIP文档，如果想要下载，成为VIP会员后，下载免费。
- 5、成为VIP后，下载本文档将扣除1次下载权益。下载后，不支持退款、换文档。如有疑问请联系我们。
- 6、成为VIP后，您将拥有八大权益，权益包括：VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 7、VIP文档为合作方或网友上传，每下载1次， 网站将根据用户上传文档的质量评分、类型等，对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
?一个社交App需实现的功能
用户关注的常规社交功能、活动、地理位置、探索功能、新鲜事、视频照片分享等等，需要提供的功能不胜枚举，所以从技术角度来说，开发者需要解决的问题也是异常复杂的。
当一款社交App发布之初，用户访问量比拟小，使用一台效劳器就能够支撑全部的访问压力和数据存储需求，但是互联网应用具有病毒式的传播特点。一款App很可能会面临一夜爆红的现象，访问量和数据量在短时间内呈现爆发式增长，这时候会面临的局面是每天上亿PV、数百万新增用户和活泼用户、流量飙升至每秒数百兆。这些对于一个只部署了简单后端架构的应用来讲是无法支撑的，会直接导致效劳器响应缓慢甚至超时，以及在顶峰期时效劳呈现瘫痪状态，使得后端的效劳完全无法使用，用户体验急剧下降。本文将会通过一个真实的案例来分享一个社交应用如何构建一个具备高伸缩性的后端系统。
社交App最初部署的后端架构解析
社交App在最初的时候，后端架构相比照拟简单，最初是部署在根底网络之上。最前面放置一台绑定了公网IP的nginx效劳器作负载均衡，后面放置3台应用效劳器来负责处理所有业务上的请求，最后面搭建一台MySQLDatabase数据库。
构建私有网络
随着产品的不断迭代、用户数的持续增长、数据量的积累，App就需要改良自己的后端架构，即开始构建私有网络。用户可以使用私有网络构建自己的网络拓扑——创立路由器和私有网络，将后续参加的用于运行内部效劳的主机放置在私用网络中，可以有效地和云平台其他用户主机，在网络上实现100%二层隔离。主机对外开放的仅仅只有80端口，这样系统平安性上多了一层保障。
在上面的架构图中，最前面的是防火墙，后面接负载均衡器，然后接路由器和私有网络，很多互联网应用都存在读多写少的情况，这个比例有时可以到达8:2，所以我们首先通过引入缓存分摊数据库读压力。其次，引入负载均衡器，替换最初架构中的nginxproxy，负责均衡器在这里其主要用于分发请求到后端多台应用效劳器，，当其中一台应用效劳器挂掉，负载均衡器可以进行自动隔离。
业务分区与扩展
App随着并发访问量和数据量不断增大，首先想到横向扩容Web效劳。水平扩容业务效劳器的前提是要保证每台效劳器都是无状态的，将session信息下放到缓存或数据库中存储，保证请求被负载到任何一台效劳器可以正常处理。
从上图中看到，在前一步「构建私有网络」之后，增加了一个新的私有网络来扩展网络层，这里可以利用自有映像功能，将原有的应用效劳器制作成模板，后续就可以基于这个模板快速启动新的主机。另外可以利用Auto-scaling〔自动横向扩展〕功能，根据后端效劳器的负载请求，动态调整效劳器的数量。
一个社交应用的后端会提供很多效劳请求接口，比方添加好友、刷新新鲜事、浏览页面等，可以通过日志分析每一个接口的耗时，将耗时长但非重要业务的请求分到单独的Web效劳器上进行处理，从而给主Web效劳器留出更多资源去处理关键业务的请求。
面向效劳的架构
随着产品功能的不断迭代，业务代码会越来越复杂，出现故障的可能性也在加大，当一个局部功能出现问题时，都会影响整个效劳的可用性。此时可以构建面向效劳的架构，将一个完整且庞大的效劳拆分为一个个的子效劳，效劳之间通过接口交互。如下列图所示：
社交App的效劳被拆分成了四个子效劳——新鲜事〔NewsFeed〕、用户资料〔Profile〕、广告〔Ads〕和探索〔Explore〕，不同的效劳之间通过消息通信框架〔例如ZeroMQ〕来进行交互。把一个大效劳拆分为几个小的子效劳的好处不言而喻，主要是：
故障隔离：子效劳出现故障不会影响全局，比方广告业务出现问题并不会让整个App不能使用，依然可以查看新鲜事等；
独立扩展：每一个被拆分出的子效劳有着不同的访问压力，比方新鲜事的调用相比一些二级页面的用户资料要高很多，所以前者会被分配更多的Web效劳器；
独立部署：一个大效劳的配置因功能过多会异常复杂，一旦被拆分就可根据不同的特性需求定制配置项，从而提高可管理性；
团队协作开发：开发者都有着自己精通的方向，从而提高开发效率；
抽象出数据访问：在后续进行数据层面〔数据库、缓存〕扩展时，可通过修改子效劳的DataService，实现对下层数据的透明。
数据库Replication
业务增长也会给数据库带来诸多问题，当最初架构中单台数据库〔数据库同时提供读和写〕缺乏已支撑起App访问压力时，首先需要做数据副本Replication。市面上常见的MySQL、MongoDB等数据库都提供Replication功能，以MySQL为例，从高层来看，Replication可分成三步：
Master将改变记录到二进制日志〔binarylog〕中〔这些记录叫做二进制日志事件，binarylogevents〕；
Slave将Mas
文档评论（0）