乔帮主的直播内容经精炼整理、分以下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架构。
下一篇：架构微服务阶段
