乔帮主的直播内容经精炼整理、分以下5篇:
一、分享介绍&架构三原则
二、云架构、架构的原始阶段和基础阶段
三、架构动静分离和分布式阶段
四、架构数据缓存阶段和两个维度拓展阶段
五、架构微服务阶段
数据缓存阶段:数据库缓存
当访问压力达到500万PV到1000万PV,虽然负载均衡结合多台 Web服务器,解决了动态请求的性能压力。但是这时候我们发现,数据库出现压力瓶颈,常见的现象就是RDS的连接数增加并且堵塞、CPU100%、IOPS飙升。这个时候我们通过数据库缓存,有效减少数据库访问压力,进一步提升性能。
在这个架构阶段采用的云产品,如左边架构图所示,相比上阶段,主要增加了云memcache或者云Redis。值得注意的是,数据库缓存,需要业务代码改造及支持。哪些热点数据需要缓存,这需要业务方面重点规划。并且云端数据库缓存,已不推荐在ECS中自行搭建Redis、memcache等,我们直接使用对应的云缓存产品即可。这阶段架构有两个技术特点跟大家分享:
一个是缓存五分钟法则:即如果一条记录频繁被访问,就应该考虑放到缓存里。否则的话客户端就按需要直接去访问数据源,而这个临界点就是五分钟。
第二个特点,缓存其实是在数据库层面,对数据库的读写分离中,对读的一定程度解耦。
接着到达架构扩展阶段:垂直扩展。
架构扩展阶段:垂直扩展
当访问量达到1000万PV到5000万PV,虽然这个时候我们可以看到通过分布式文件系统OSS已经解决了文件存储的性能问题,虽然通过CDN已经解决静态资源访问的性能问题。但是当访问压力再次增加,这个时候 Web服务器和数据库方面依旧是瓶颈。在此我们通过垂直扩展,进一步切分 Web服务器和数据库的压力,解决性能问题。“那何为垂直扩展,按照不同的业务(或者数据库)切分到不同的服务器(或者数据库)之上,这种切分称之为垂直扩展。”如左边架构图所示,在这个架构阶段采用的云产品,相比上阶段,主要增加了数据库层面的读写分离或者对应的切库。
这个阶段主要有三个技术特点:
第一点,业务拆分
在业务层,可以把不同的功能模块拆分到不同的服务器上面进行单独部署。比如,用户模块、订单模块、商品模块等,拆分到不同服务器上面部署。
第二点,读写分离
在数据库层,当结合数据库缓存,数据库压力还是很大的时候。我们通过读写分离的方式,进一步切分及降低数据库的压力。
第三点,分库
结合业务拆分、读写分离,在数据库层,比如我们同样可以把用户模块、订单模块、商品模块等。所涉及的数据库表:用户模块表、订单模块表、商品模块表等,分别存放到不同数据库中,如用户模块库、订单模块库、商品模块库等。然后把不同数据库分别部署到不同服务器中。
此阶段架构有两个注意点:
架构的中后期,业务的瓶颈往往都是集中在数据库层面。因为在业务层,我们通过负载均衡能够快速添加更多服务器进行水平扩容,很方便快速解决业务服务器处理的压力。而数据库怎么来做性能扩展,不是简单加几台服务器就能解决的,这往往涉及到复杂的数据库架构变更。垂直拆分,相对在业务上改动较少,并且数据库性能提升最为高效的一种方式,是我们中大型应用首要采用的架构方案。
接着到达架构分布式+大数据阶段:水平扩展。
架构分布式+大数据阶段:水平扩展
当访问量达到5000万PV及以上时,当真正达到千万级架构以*问量的时候,我们可以看到垂直扩展的架构也已经开始“山穷水尽”。比如,读写分离仅解决读的压力,面对高访问量,在数据库“写”的压力上面开始“力不从心”,出现性能瓶颈。另外,分库虽然将压力拆分到不同数据库中。但单表的数据量达到TB级别以上,显然已经达到传统关系型数据库处理的极限。如左边架构图所示,在这个架构阶段采用的云产品,相比垂直扩展阶段,主要增加了DNS轮询解析、非关系型数据库MongoDB、以及表格存储列数据库OTS。
此阶段有四个技术特点:
第一点,增加更多的web应用服务器
当后续压力进一步增大,在负载均衡后面增加更多的web应用服务器进行水平扩展。
第二点,增加更多的SLB
单台SLB也存在单点故障的风险,及SLB也存在性能极限,如七层SLB的QPS最大值为50000。我们可以通过DNS轮询,将请求轮询转发至不同可用区的SLB上面,实现SLB水平扩展。
第三点,采用分布式缓存
虽然阿里云memcache内存数据库已经是分布式结构,保障了存储在缓存中的数据高可用。但是使用缓存的业务场景是比较多的,我们不可能仅仅只是部署一个缓存服务,那么业务之间的使用可能存在相互影响。所以我们用多个云缓存,可以在代码层通过hash算法将数据分别缓存至不同的云缓存中,或者不同的业务场景直接连接使用不同的云缓存,来提高我们业务的健壮性。
第四点,Sharding分片和NoSQL
面对高并发、大数据的需求,传统的关系型数据库已不再适合,需要采用非关系型数据库NoSQL了。MongoDB和OTS作为NoSQL的典型代表,支持数据分片Sharding技术,根本上解决了关系型数据库面对高并发高存储量的痛点问题。
此阶段架构注意点:
大型应用中,海量业务数据的存储、分析给我们数据库提出巨大挑战。而传统关系型数据库明显已经力不从心,分布式数据库NoSQL是适用技术发展的未来趋势。有了海量业务数据的基础,我们可以结合云端MaxCompute大数据分析服务,来辅助业务进行价值创造。
虽然到达架构分布式+大数据阶段,基本上能满足绝大多数千万级架构的业务需求。但同时带来新的挑战:
第一个挑战,分布式架构下,在业务层面的扩展,业务后期迭代、维护管理、敏捷开发等问题。所以借助前面的“云对技术架构变革”的这个图我们再次来看看。其实最后到达了容器体系下,微服务架构阶段解决了分布式架构带来的业务层面扩展性问题。微服务是业务功能层面的一种切分,切分成一个单个小型的独立业务功能的微服务。多个微服务通过API Gateway提供统一服务入口,让微服务对前台透明,而每个微服务也可以通过分布式架构进行部署,这给我们研发灵活性、业务后期迭代带来了极大的扩展性,这是我们未来软件技术架构的主流。并且微服务,在云平台基础上结合Docker容器技术进行部署。能让业务、运维、架构在技术和非技术方面的稳定性、成本、效率、扩展等都能达到完美。
第二个挑战,Big Data所带来的离线计算问题。Big Data强调数据量,PB级以上,是静态数据。并且强调离线计算,结算结果并不是实时的,需要等到离线任务执行完毕才能汇总结果。随着企业数据需求不断变化,近年来对数据采集的实时性、对数据在线计算的实时性要求日益明显。现如今,基于Big Data海量数据的基础上 ,已经在逐步过渡到大数据实时计算分析的Fast Data时代了。Fast Data在数据量的基础上,意味着速度和变化,意味着客户可以更加实时化、更加快速地进行数据处理。
最终演变成为当前最热门的微服务、容器、Fast Data架构。
下一篇:架构微服务阶段