互联网分布式系统架构演进之路

前言：

这是一篇学习心得的分享，告诉大家一个小系统是如何变得越来越复杂的。随着参与开发项目的增多，每天也在用很多app或者网站。那么大型网站一开始就是大型的吗？我们应该一开始就设计一个大型网站吗？可以带着这样的思考来一起阅读这篇文章。

正文：

一、初生

一个小网站刚做出来的的时候，往往都是没有什么人知道，所以单个服务器就可以满足需求。使用LAMP技术就可以。

二、成长（发展问题）

1.随着网站业务的发展，越来越多的用户访问，面临的问题：

• 性能越来越差
• 越来越多的数据导致存储空间不足

 解决方案：升级项目架构，应用服务与数据服务分离。(一个框框代表一个服务器)

 这样处理带来的好处：充分发挥不同类型服务器的特点

2.随着用户逐渐增多，网站再次面临挑战：

• 数据库压力太大导致访问延迟，进而影响整个网站的性能，用户体验受到影响！

 解决方案：使用缓存改善性能

本地缓存和远程分布式缓存的优缺点：

• 本地缓存速度极快，但是缓存的数据量有限，毕竟本地服务器内存有限
• 远程分布式缓存相对于本地缓存性能稍差一点（因为要进行一次网络访问才可以拿到数据），但是又要比从数据库直接读取数据快，相当于利用空间换取时间

3.随着用户逐渐增多，单一应用服务器面临新的问题：

• 能够处理的请求有限，网站访问高峰期，应用服务器成为整个网站的瓶颈

解决方案：应用服务器集群（分流）

 常用负载均衡实现的方式：

4. 使用缓存后，虽然大大减轻数据库的读压力，但是又同时引出了新的问题：

有一部分读操作（缓存访问不命中，缓存过期）和全部的写操作要访问数据库，当用户要达到一定规模后，数据库因为负载压力过高而成为整个系统的瓶颈。

解决方案：数据库读写分离

数据访问模块的作用？

单体应用的时候，只有一个数据库，我们在dao层写sql的时候不用考虑，这条sql去哪个数据库执行，因为就一个库，但是读写分离后如果再做数据库集群，就会有多个数据库，这时候我们在dao层不仅需要写业务代码还得兼顾考虑连接哪个库执行，就大大增加了开发的难度，所以这时候数据访问模块就可以为我们解决这个问题，让我们专注开发业务代码。

数据访问模块的实现?

5. 用户规模越来越大，发布地域越来越广，地域网络环境差别很大，面临问题：

如何保证用户的访问体验，不至于因访问慢而流失用户？

解决方案：反向代理和CDN加速

 反向代理和CDN加速有哪些好处：

• 加快用户访问响应速度
• 减轻后端服务器的负载压力

6.单文件服务器、单数据库服务器，面临的问题：

存不下日益增长的数据库

解决方案：分布式文件系统和分布式数据库系统

 分布式文件系统和分布式数据库系统的中间件：

7.随着业务的发展，数据的存储和检索需求越来越复杂，面临的问题：

• 存储的字段差异较大，骷髅表
• 复杂的文本检索

解决方案：使用NoSQL解决骷髅表、搜索引擎解决复杂的文本检索

 NoSQL、搜索引擎的中间件有哪些？

 8.网站越做越好，业务不断扩大，越来越复杂，面临的问题：

应用程序将变得无比庞大，迭代周期越来越快，牵一发而动全身，怎么应对快速的业务发展？

解决方案：业务拆分

 如大型电商网站会将首页、商铺、订单、买家等拆分成不同的产品线，分归不同的团队负责，分成不同的应用，独立部署。通过链接、MQ、是数据存储系统建立关联。

这时候需要引入消息中间件来做业务拆分：

 

9.业务规模不断增大，应用拆分越来越小，越来越多，面临的问题：

• 应用间的关系越来越复杂，应用中存在大量相同的业务操作
• 后端的数据库要被成千上万台应用服务器连接，数据库连接资源不足

解决方案： 分布式服务（服务化）

分布式服务化需要用的中间件：

 9.再往后，需要什么，面临的问题：

数据挖掘、分析、推荐等业务需求，庞大系统的监控、问题分析等需求。

解决方案：大数据技术、监控、日志分析系统

大数据技术、监控、日志分析系统的中间件：

 

 

总结：

技术的选择是具有阶段性的，当前阶段要优先考虑现阶段需要的技术，没有什么技术是一劳永逸的，随着网站发展要灵活应对。

今日分享一句话：其实在这个世界上，正常和不正常从来都是相对的。当我们看到一些与自己不同的人，就把他们归类于“不正常”时，这其实是一种狭隘的偏见。

我是阿达，一名喜欢分享知识的程序员，时不时的也会荒腔走板的聊一聊电影、电视剧、音乐、漫画，这里已经有10501位小伙伴在等你们啦，感兴趣的就赶紧来点击关注我把，哪里有不明白或有不同观点的地方欢迎留言！