4.1.1-1. 互联网系统架构演进之路

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. 架构设计的误区

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