目录
1.前言
在互联网诞生的初期只有少量的人能够上网，将服务部署在一台主机上就足够支持客户的访问，但是对着互联的发展使用人数 激增，单机架构已经承受不住大量的用户并发访问，为了解决这个问题架构开始不断的演进。
2.八大架构
2.1单机架构
应用服务和数据库服务使用一台主机
架构图
技术案例
Tomcat 是由 Apache 软件基金会下属的 Jakarta 项目开发的一款开源的轻量级 Web 应用服务器
用户想要查看商品
首先用户使用app或者浏览器访问网站的域名，经过dns转化找到服务器ip地址，使用ip地址访问到tomcat，tomcat访问数据库，数据库返回商品的信息给tomcat，一级一级返回给用户。
架构分析
优点：因为只有一台主机，所以部署简单，成本低。
缺点：有严重的性能瓶颈，数据库和应用服务相互竞争资源。
架构瓶颈：服务器太少了。
2.2应用数据分离架构
架构图
应用服务和数据库服务使用不同的服务器，服务器之间通过网络连接。
技术案例
访问商品的流程和单机架构相同，只不过mysql不在一个服务器上。
架构分析
优点：成本相对可控，性能比单机架构有提升，数据与应用分离数据容灾能力提升。
缺点：性能瓶颈，仍无法面对海量数据场景。
架构瓶颈：在大量并发访问的场景下，首先吃紧的一定是应用服务器。
2.3应用服务集群架构
架构图
引入了负载均衡，应用以集群方式运作。
因为一个应用服务扛不住了，所以由多个应用服务以负载均衡的方式一起运作。
技术案例
Nginx/LVS:负载均衡器，将应用服务均匀的分发给下层的tomcat.。
LVS大概能抗住10万级的并发，Nginx大概能抗住万级的并发，Tomcat大概能抗住千级的并发。
一个LVS可以管理10个Nginx，10个Nginx可以管理100个Tomcat。
dns：也是有负载均衡功能的，经过配置之后，将域名均衡的转为不同LVS服务器的地址。
用户想要查看商品
首先用户使用app或者浏览器访问网站的域名，经dns转化为第一个LVS服务器的ip或者是第二LVS服务器的ip,通过ip地址访问LVS服务器，LVS通过负载均衡算法选择下层的Nginx服务服务器，Nginx服务通过负载均衡算法选择下层的tomcat，tomcat访问mysql，mysql返回数据给tomvat，然后一层一层返回给用户。
架构分析
优点：满足高可用不会因为一个站点挂掉整个服务器挂掉，应用服务具备一定的高性能，支持横向扩展。
缺点：数据库仍是单点没有搞可用，数据库成为性能瓶颈，硬件成本增加，运维成本增加。
架构瓶颈：只有一个存储服务器，抗不住海量数据的场景。
2.4读写分离架构
架构图
将数据库读写操作分散到不同的节点上，搭建数据库主从集群，一主一从，多主多从都可以，主库负责写操作，从库负责读操作
技术案例
mycat/tddl：是一款开源的分布式数据库中间件可以将数据库读写分流。
用户想要查看商品
首先用户使用app或者浏览器访问网站的域名，经dns转化为第一个LVS服务器的ip或者是第二LVS服务器的ip,通过ip地址访问LVS服务器，LVS通过负载均衡算法选择下层的Nginx服务服务器，Nginx服务通过负载均衡算法选择下层的tomcat，访问mycat数据库中间件将读操作负载均衡的分流到mysql从库中。
用户想要添加商品
同上。。。。。。。访问mycat数据库中间件将写操作负载均衡的分流到mysql主库中，写完毕后将数据同步到读库中。
架构分析
优点：数据库读写性能提升，数据库有从库，可用性间接提高。
缺点：服务器成本进一步增加，热点数据的频繁获取导致数据库负载还是很高，当数据同步挂掉会出现数据不一致的问题。
架构瓶颈：有热点被频繁读取的时候数据库的负载仍然扛不住。
2.5冷热分离架构
架构图
引入的缓存数据库，将热点存储到缓存数据库中，实现热点数据的快速响应。
技术案例
redis：缓存数据库
用户想要查看热点商品
首先用户使用app或者浏览器访问网站的域名，经dns转化为第一个LVS服务器的ip或者是第二LVS服务器的ip,通过ip地址访问LVS服务器，LVS通过负载均衡算法选择下层的Nginx服务服务器，Nginx服务通过负载均衡算法选择下层的tomcat，获取redis中的热点数据，一层一层返回。
用户想要查看冷门商品
首先用户使用app或者浏览器访问网站的域名，经dns转化为第一个LVS服务器的ip或者是第二LVS服务器的ip,通过ip地址访问LVS服务器，LVS通过负载均衡算法选择下层的Nginx服务服务器，Nginx服务通过负载均衡算法选择下层的tomcat，首先访问redes发现热点数据中没有再访问mycat数据库中间件将读操作负载均衡的分流到mysql从库中，一层一层返回。
架构分析
优点：显著的降低了数据的访问，对性能提升非常明显。
缺点：服务器成本增加，带来一系列缓存问题缓存击穿，缓存雪崩等，业务体量上升之后单库，单表体量过大导致查询速度变慢
架构瓶颈：数据库单库，单表体量过大导致查询速度变慢
2.6垂直分库架构
架构图
将数据库的数据进行拆分，分布式查询，分布式存储，分布式处理，分布式数据库。
技术案例
Greenplum/tidb/tdsql:分布式数据库
用户查看商品信息
首先用户使用app或者浏览器访问网站的域名，经dns转化为第一个LVS服务器的ip或者是第二LVS服务器的ip,通过ip地址访问LVS服务器，LVS通过负载均衡算法选择下层的Nginx服务服务器，Nginx服务通过负载均衡算法选择下层的tomcat，tomcat访问Greenplum分布式数据库，将数据一层一层返回。
架构分析
优点：数据库吞吐量大幅度提升数据再也不是瓶颈。
缺点：跨库join、分布式事务等问题，这些需要对应的去进行解决，目前的mpp都有对应的解决方案，应用服务代码耦合度太高，改一行代码就需要重新发布。
架构瓶颈：应用服务耦合度太高
2.7微服务架构
架构图
微服务是一种架构风格，根据业务板块划分代码，使单个应用职责更加清晰。
技术案例
Spring Cloud 是一系列框架的集合，它基于 Spring Boot 构建，用于快速构建分布式系统中的一些常见模式
查看商品是哪个用户发布的
首先用户使用app或者浏览器访问网站的域名，经dns转化为第一个LVS服务器的ip或者是第二LVS服务器的ip,通过ip地址访问LVS服务器，LVS通过负载均衡算法选择下层的Nginx服务服务器，Nginx服务通过负载均衡算法选择下层的springcloud商城的主服务，访问商品的微服务，商品的微服务还会访问用户的微服务，一起去resdis集群中查找如果信息存在就返回，不存在就去冷库分布式数据库中查找，一层一层返回。
架构分析
优点：
1.灵活性高：服务独立测试、部署、升级、发布
2.独立扩展：每个服务可以各自进行扩展
3.提高容错性：一个服务问题并不会让整个系统瘫痪；
4.新技术的应用容易:支持多种编程语言，不同微服务可以使用不同编程语言，使用相同的网络协议即可。
缺点：
1.运维复杂度高：业务不断发展，应用和服务都会不断变多，应用和服务的部署变得复杂，同一台服务器上部署多个服务还要解决运行环境冲突的问题，此外，对于如大促这类需要动态扩缩容的场景，需要水平扩展服务的性能，就需要在新增的服务上准备运行环境，部署服务等，运维将变得十分困难
2.资源使用变多：所有这些独立运行的微服务都需要需要占用内存和 CPU
3.处理故障困难：一个请求跨多个服务调用，需要查看不同服务的日志完成问题定位
架构瓶颈：运维太困难
2.8容器编排架构
架构图
借助容器化技术(如docker)将应用/服务/环境打包为镜像，通过容器编排工具(如k8s)来动态分发和部署镜像，服务以容器化方式运行
技术案例
docker:应用/服务/环境打包为镜像
k8s:态分发和部署镜像，服务以容器化方式运行
架构分析
优点：
1.部署、运维简单快速：一条命令就可以完成几百个服务的部署或者扩缩容
2.隔离性好：容器与容器之间文件系统、网络等互相隔离，不会产生环境冲突
3.轻松支持滚动更新：版本间切换都可以通过一个命令完成升级或者回滚
缺点：
1.技术栈变多，对研发团队要求高
2.机器还是需要公司自身来管理，在非大促的时候，还是需要闲置着大量的机器资源来应对大促，机器自身成本和运维成本都极高，资源利用率低，可以通过购买云厂商服务器解决。
扫一扫
65
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
