想成为一个合格的架构师，经历系统流量从10万到10亿，一定会面临以下九大场景，80个架构问题。
画外音：
（1）文章较长，建议收藏；
（2）文章底部有视频版本；
【第一章：技术选型】
创业初期架构方案怎么选型？
（1）要考虑业务的需求与特点，初期往往“快速实现”更重要，此时系统的特点是请求量小，数据量小，服务器资源也非常有限；
（2）这个阶段最重要的选型依据是：合伙人熟悉什么技术栈，使用什么技术栈；
（3）第一版往往采用ALL in one架构；
（4）这个阶段研发主要在写CURD业务逻辑，引入DAO和ORM能极大提高工程效率；
画外音：什么是ALL in one架构？
如果硬要问我，会选择什么技术栈，我会二选一：
PHP体系（Linux，Apache，MySQL，PHP）
或者
Java体系（Linux，Tomcat，MySQL，Java）
使用开源框架组件还是自研？
我的观点是：
（1）早期不建议自研；
（2）随着规模的扩大，要控制技术栈；
（3）要浅浅的封装一层；
（4）适当的时候，造一些契合业务的轮子；
画外音：为什么要控制技术栈？为什么要封装一层？
什么情况下要进行容量评估？
至少在三种情况下，要进行容量评估：
（1）新系统上线；
（2）临时运营活动；
（3）系统容量有质变性增长；
系统层面，要评估哪些重要指标？
主要评估网络带宽、CPU、内存容量、磁盘容量、磁盘IO等资源指标，系统层面主要看吞吐量指标。
画外音：容量设计五大步骤是啥？
创业初期，系统层面存在瓶颈的时候，优化原则是什么？
（1）最低成本，初期最大的成本是时间成本；
（2）用“钱”和“资源”快速解决系统问题，而不是过早的系统重构；
（3）将ALL in one架构升级为伪分布式架构，是此阶段的最佳实践；
伪分布式的核心是什么？
伪分布式的本质是单机变多机，但又不是真正的高可用，其核心是垂直拆分：
（1）业务垂直拆分；
（2）代码垂直拆分；
（3）数据库垂直拆分；
（4）研发团队垂直拆分；
画外音：伪分布式的优化细节是啥？
【第二章：接入层架构】
如何解决接入层的扩展性问题？
引入反向代理。
最常见的反向代理是什么？
Nginx。
引入反向代理之后，要解决什么新的问题？
（1）集群负载均衡；
（2）反向代理高可用；
画外音：有哪些常见的负载均衡方法？如何保证反向代理高可用？
站点流量从小到大，接入层架构如何演进？
整体可以分为五个阶段：
（1）有反向代理技术之前，单体架构要解决扩展性问题，可使用DNS轮询架构；
（2）有反向代理技术之后，初期可以使用反向代理解决扩展性问题；
（3）然后，需要升级为高可用反向代理架构；
（4）多级反向代理，引入LVS&F5进一步扩充性能；
（5）想要无限性能，必须用DNS轮询架构；
画外音：每个阶段的逻辑与细节到底是怎么样的？
Session，是接入层架构非常关注的问题，如何保证Session一致性？
通常有四种方案：
（1）客户端层解决；
（2）反向代理层解决；
（3）web-server层解决；
（4）后端服务层解决
画外音：每种方案细节又是怎么样的？
CDN，是接入层不得不谈的问题，CDN架构有哪些要了解？
引入CDN架构，至少要考虑这五个问题：
（1）什么样的资源适合静态加速；
（2）CDN的架构是怎么样的；
（3）CDN是怎么实现“就近访问的”；
（4）如何保证源站和镜像站数据的一致性；
（5）资源更新，是推还是拉？
画外音：学CDN，千万不要去百度“斯塔尔报告”。
TCP接入，架构上要考虑哪些问题？
至少要考虑这四个架构设计点：
（1）TCP如何快速实现接入；
（2）TCP如何快速实现扩展，以及高可用；
（3）TCP如何快速实现负载均衡；
（4）TCP如何保证扩展性与耦合性的平衡；
画外音：有没有综合方案，系统性解决负载均衡 + 高可用 + 可扩展 + 解耦合等一系列问题？
在互联网公司发展早期，为了产品快速迭代，最常使用的架构是什么？如果此时业务发展很快，系统成了瓶颈，架构优化的方向是什么？
用最短时间，以对代码最小的冲击，极速扩充系统性能。早期系统容易“白屏”，如何快速的提升用户体验，消除白屏？动静分离，是“静态页面与动态页面，分开不同的系统访问”的架构设计方法。如果静态页面访问这么快，动态页面访问这么慢，能否将“原本需要动态生成的页面，提前生成静态页面”？可以，这是“页面静态化”技术，能够100倍提升访问速度。读写分离，使用数据库分组架构，一主多从，主从同步，读写分离。画外音：读写分离，水平切分都是使用数据库集群，有什么异同？后台运营系统，复杂的SQL语句对数据库性能影响较大，怎么办？画外音：前后端分离，前台后台分离，是一回事么？如何快速实施前台与后台分离？（4）按接口划分服务（需要轻量级进程等语言层面支持）；不要以为，引入一个RPC框架就是“微服务架构”了，微服务架构要解决很多问题。至少要解决高可用，无限性能扩展，负载均衡等众多架构基础问题。每一层解决高可用问题的方案不一样，涉及虚IP，反向代理，集群，连接池，数据库分组，缓存冗余，故障转移等诸多技术。每一层解决高可用问题的方案不一样，涉及Scale up，Scale out，DNS轮询，反向代理，连接池，水平切分等诸多技术。哪一个组件，和高可用，无限性能扩展，负载均衡相关？一个数据库分组集群，主从同步，读写分离，能不能在主库和从库建立不同的索引？写库高可用，两个写库相互同步数据，自增ID可能冲突导致数据不一致，有什么优化方案？（1）为每个写库指定不同的初始值，相同的增长步长；（3）一个写库提供服务，一个写库作为高可用影子主；（3）在从库有可能读到旧数据时，选择性读主（非常帅气的方案）；底层表结构变更，水平扩展分库个数发生变化，底层存储引擎升级，数据库如何平滑过度？绝大部分情况，还是应该使用缓存服务，缓存的使用，有什么注意点？（2）如果缓存挂掉，可能导致雪崩，此时要做高可用缓存，或者水平切分；（3）调用方不宜再单独使用缓存存储服务底层的数据，容易出现数据不一致，以及反向依赖；（4）不同服务，缓存实例要做垂直拆分，不宜共用缓存；Cache Aside Pattern的细节是什么？读缓存最佳实践是：先读缓存，命中则返回；未命中则读数据库，然后设置缓存。缓存的本质是“冗余了数据库中的数据”，可能存在什么问题？具体要怎么淘汰，保证缓存与数据库中数据的一致性呢？画外音：纯KV场景，为什么memcache会更快呢？配置文件，是互联网架构中不可缺少的一环。依赖（调用）某个下游服务集群，将下游集群信息放在自身配置文件里是一种惯用做法，该做法可能导致什么问题？
（2）下游痛：不知道谁依赖于自己，难以实施服务治理，按调用方限流；除了配置中心，消息总线MQ也是互联网架构中的常见解耦利器。上游实时关注执行结果时，通常不使用MQ，而使用RPC调用。（3）上游关注结果，但执行时间很长，例如跨公网调用第三方服务；（2）第二步，个性数据访问，自己家的数据自己管理；画外音：数据库耦合，当数据库成为瓶颈时，增加数据库实例也难以拆分扩容，非常头疼。（2）杜绝底层switch case不同业务类型的业务逻辑代码；（3）个性化代码上浮，公共代码下沉，是更古不变的架构解耦准则；画外音：架构复杂时，微服务是好事，但拆分不彻底反而会有坑。上述复用和封装，在系统架构上的呈现，就是“分层”。每次都要连接数据库获取数据，编码非常低效，有什么痛点？（4）通过游标遍历结果集，拿到每一行，分析行数据，拿到每一列；（3）不同垂直业务之间有需要共性业务，代码要冗余很多次；PC/H5/APP多端业务，编码非常低效，有什么痛点？（1）大部分业务逻辑相同，只有少量展现/交互不一样；（4）PC/H5/APP多端相同的逻辑存在大量代码拷贝；大数据量，高并发量的微服务架构，编码非常低效，有什么痛点？（3）有时候要多个库拿数据，然后到内存排序，例如跨库分页需求；可以看到，架构分层，对研发效率的提升，与复杂性的屏蔽，至关重要。负载均衡、数据收集、服务发现、调用链跟踪。这些非业务的功能，一般是谁实现的呢？
（1）互联网公司一般会有一个“架构部”，研发框架、组件、工具与技术平台；（2）业务研发部门直接使用相关框架、组件、工具与技术平台，享受各种“黑科技”带来的便利；框架、组件、工具与技术平台的使用与推广，往往会遇到以下一些问题：（1）业务研发团队，需要花大量时间去学习、使用基础框架与各类工具；（2）架构部，对于“黑科技”不同语言客户端的支持，往往要开发C-client，Python-client，go-client，Java-client多语言版本；（3）架构部，“黑科技” client要维护m个版本， server要维护n个版本，兼容性要测试m*n个版本；（4）每次“黑科技”的升级，都需要推动上下游进行升级，这个周期往往是以季度、半年、又甚至更久，整体效率极低；（1）一个进程实现业务逻辑（不管是调用方，还是服务提供方），biz，即上图白色方块；
（2）一个进程实现底层技术体系，proxy，即上图蓝色方块；画外音：负载均衡、监控告警、服务发现与治理、调用链…等诸多基础设施，都放到这一层实现。（1）biz和proxy共同诞生，共同消亡，互为本地部署，即上图虚线方框；（2）biz和proxy之间，为本地通讯，即上图黑色箭头；（3）所有biz之间的通讯，都通过proxy之间完成，proxy之间才存在远端连接，即上图红色箭头；这样就实现了“业务的归业务，技术的归技术”，实现了充分解耦，如果所有节点都实现了解耦，整个架构会演变为：整个服务集群变成了网格状，这就是Service Mesh服务网格的由来。Service Mesh的行业开源最佳实践是什么？画外音：具体envoy，mixer，citadel，pilot和galley的职责与细节，见《大专栏》。前面所有章节讲的都是单机房架构，单机房架构的特点是什么？架构分层之间，是同连接，即：站点，服务，数据全部单元化，仅连接同机房。（2）如果不能“单元化”，跨机房的数据同步存在较大延时；站点，服务，数据做不到全量单元化，做不到“只”连接同机房，但可以“最小化”跨机房连接，整个架构，可以只有两个地方跨机房：机房区分主次，落地性强，对原有架构冲击较小，业务几乎不需要进行单元化改造。18次直播回看，以及《架构师训练营》，系统性的详聊了上面这80个问题，感兴趣的同学可以扫码看细节。20年口罩期间，我录制的一个架构实践课，讲述流量从10万到10亿增长过程中，架构师将要面临的典型场景，会遇到什么架构问题，如何思考这些问题，如何解决这些问题。福利2：原价1699（20年找团队录的），现价巨折只需XXX，扫码你就知道了；重点提醒：学习过程中一定要“加群”，任何问题，随时群内沟通交流。
