互联网系统架构演进之路

目标：

一、大型互联网系统架构演进之路

小网站：LAMP： linux+apache+mysql+php 一台服务器足以

-->访问量增加，性能变差，存储空间不足，则需要应用服务和数据服务分离。

不同的服务器承担不同的服务角色：并发处理能力和数据存储空间改善，性能提升

-->用户增多，数据库压力增大导致访问延迟，影响网站性能，用户体验受影响

使用缓存改善性能：

常用缓存组件：memcache, redis

-->用户增多，单一应用服务器能够处理的请求连接有限，网站访问高峰期，应用服务器性能变差(高并发)

使用应用服务器集群，改善网站的并发处理能力(分流，按需扩展)

为什么不用更强的服务器？

再强的服务器也有瓶颈；廉价的服务器集群可以按需扩展，节省成本资源

使用集群，必须使用负载均衡调度服务器(高性能，高并发)。

负载均衡的实现方式：

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

数据库读写分离：主从复制，主库写操作，从库读操作(需要数据访问模块)

数据访问模块怎么做？

在Mybatis中开发插件
Mycat -线程中间件
Sharding-JDBC

-->用户规模增大，发布地域越来越广，地域网络环境差别大，需要考虑如何保证用户的访问体验，不因访问慢而流失用户

CDN加速：内容分发网络，部署在运营商数据中心。适用于静态资源。原理：静态资源提前存放在地方运营商数据中心，用户通过网络访问资源时，请求会首先访问运营商，存在则直接使用
反向代理：缓存静态资源。部署在应用系统数据中心的最外层

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

-->单文件服务器、单数据库服务器，存不下日益增长的数据

分布式文件系统怎么做？分库分表怎么做？

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

NoSQL(分布式)：lucene(apache开源开发工具包，可集成), solr(lucene子项目，已开发好的搜索引擎平台，API直接调用), elasticsearch(基于lucene开发，搜索引擎平台)
搜索引擎(分布式)：mongodb, elasticsearch

-->网站越做越好，业务不断扩大，越来越复杂，应用程序将变得无比庞大，迭代周期越来越快，怎么应对快速的业务发展需要

-->业务规模不断增大，应用拆分越来越小，越来越多，应用见的关系越来越复杂，应用中存在大量相同的业务操作；后端的数据库要被成千上万台应用服务器连接，数据库连接资源不足

分布式服务(服务化)：配置中心服务器；

两种架构方式：

SOA(面向服务的架构)：service driented architecture(服务驱动体系结构)服务提供者/调用者--连接--Enterprise Service Bus - ESB(企业服务总线)，缺点：ESB会形成瓶颈；优点：服务相关管理可以在ESB上做
微服务：microservices architecture(微服务体系结构)。确定：互相依赖，资源占用治理；优点：服务可以做成负载均衡式的

服务框架：Dubbo, SpringCloud

配置中心：Dubbo Zookeeper, SpringCloud config, Disconf 百度, Config-toolkit 当当, Diamond 阿里

-->再往后，需要数据挖掘、分析、推荐等业务需求，庞大系统的监控、问题分析等需求

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

二、架构设计思想总结

三、架构设计误区

技术是用来解决业务问题的，而业务的问题，也可以通过业务的手段去解决。