073. 互联网系统架构演进之路

1. 互联网技术演进之路

1. 初生

• 无名的网站 -> 访问量低，一台服务器满足需求。

• 典型的技术 LAMP：Linux + Apache + MySQL + PHP

2. 发展问题

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

3. 应用服务和数据服务分离

• 服务器对应不同的硬件需求
  • 应用服务器：需要更快更强大的 CPU（处理大量的业务逻辑）
  • 数据库服务器：需要更快的硬盘和更大的内存（快速磁盘检索和数据缓存）
  • 文件服务器：需要更大的硬盘（存储大量用户上传的文件）
• 不同的服务器承担不同的角色
  • 并发处理能力。
  • 数据存储空间。

4. 发展问题

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

5. 使用缓存改善性能

• 缓存
  • 本地缓存（能存的数据量较少，并且会与应用程序争夺内存）
  • 远程分布式缓存

6. 发展问题

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

7. 应用服务器集群

• 负载均衡
  • 软件：Apache、Nginx、Reverse-proxy、pWEB、LVS
  • 硬件：F5
  • DNS 负载均衡

8. 发展问题

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

9. 数据库读写分离

• 数据访问模块
  • 在 Mybatis 中开发插件
  • Mycat
  • Sharding-JDBC

10. 发展问题

• 用户规模越来越大，发布地域越来越广，地域网络环境差别很大，面临问题：如何保证用户的访问体验，不至于因访问慢而流失用户？

11. 反向代理和 CDN 加速

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

12. 发展问题

• 单文件服务器、单数据库服务器，面临问题：存不下日益增长的数据。

13. 分布式文件系统和分布式数据库系统

• 适合存储小文件、图片的分布文件系统
  • FastDFS
  • TFS
• 数据访问模块
  • Mycat
  • Sharding-JDBC

14. 发展问题

• 随着业务的发展，数据的存储需求和检索需求越来越复杂，面临的问题：
  • 存储的字段差异较大，骷髅表。
  • 复杂的文本检索。

15. 使用 NoSQL、搜索引擎

• 搜索引擎：lucene、solr、elasticsearch
• NoSQL：mongodb、elasticsearch

16. 发展问题

• 网站越做越好，业务不断扩大，越来越复杂，面临的问题：应用程序将变得无比庞大，迭代周期越来越快，牵一发而动全身，怎样应对快速的业务发展需要？

17. 业务拆分

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

18. 发展问题

• 业务规模不断增大，应用拆分越来越小，越来越多，面临问题：
  • 应用间的关系越来越复杂，应用中存在大量相同的业务操作。
  • 后端的数据库要被成千上万应用服务器连接，数据库连接资源不足。

19. 分布式服务（服务化）

• 服务化的两种架构方式

• 服务框架：Dubbo、SpringCloud
• 配置中心：Dubbo、SpringCloud config、Disconf（百度）、Config-toolkit（当当）、Diamond（阿里）

20. 发展问题

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

21. 大数据技术、监控、 日志分析系统

• 大数据：Hadoop、Spark
• 系统监控：Zabbix、ElasticSearch+beats+Kibana
• 集中式日志分析系统：ELK

2. 架构设计思想总结

• 分而治之。
• 随网站所需灵活应对。
• 业务发展驱动技术发展，技术发展反哺业务。
• 软件系统的价值在于它能为用户提供什么价值，在于网站能做什么，而不在于他是怎么做的。

3. 架构设计的误区

• 一味追随大公司的解决方案。
• 为了技术而技术。
• 企图用技术解决所有问题。