架构实战营毕业总结

整个架构实战营的课程是在教我们如何去设计并落地一个贴合自身业务的架构

在最后一章节告诉我们一个架构师如何提升自己的能力。

要设计和落地架构，那么就有两个步骤：设计和落地。

要设计合理的架构首先就要知道，什么是架构，为什么要架构，以及如何做架构设计。

架构的主要任务，是降低系统的复杂度，梳理清楚各个层次的角色之间的关系，以及运作规则。

架构设计先要进行架构的分析，架构分析主要分为三步骤：判断、拆分、取舍

• 【判断】的过程主要就是跟业务方或者利益干系人进行讨论和澄清需求的过程，在这个过程里必须明确我们这个系统的架构复杂度在哪些地方，以便于后面的拆分步骤的进行。

• 【拆分】步骤，就是要把前面的架构复杂度高的地方，加以拆分。根据业务的不同情况，我们可能需要设计一个高可用/高性能/可扩展的架构。

• 【取舍】步骤，就是要根据拆分之后所设计出的多种方案，根据不同的技术的优缺点和使用场景，加以取舍，选出相对最合适的一个方案，最后进行落地。当然在真正落地前，最好用 FMEA 法，对最终方案进行一个分析，看看是否有地方没有考虑周全，或者可以用提升架构质量的方式加以弥补的。

• 高可用的架构如何设计？

高可用分为两种：【计算高可用】和【存储高可用】

• 计算高可用简单的说就是服务不要挂掉即可，就算其中的个别个体宕机，整体也要能支持请求的响应。那么主要就是两个手段：任务分配、任务分解。

• 存储高可用的要求更高一些，不仅仅要求整体服务是活的，而且要求数据也要相对正确，至少要达到最终一致（BASE），需要我们明白 FLP 和 CAP 理论。这就要求我们要设计复制架构了。

• 复制架构有主备、主从、双机切换、集群选举等方式。

• 遇到数据量过大，我们还得考虑分片存储，也就是不同的数据分别存放在不同的机器上（这些机器为了保证高可用，也要进行主备、主从等复制架构设计）。那么一分片，就再引出了新问题，就是我们如何分片？请求要如何路由到正确的分片上？我们这些分片放到哪些机器上？是否要进行异地多活，如果要异地多活，那么是同城，跨城甚至是跨国？这些都与自己业务的需求相关联。

• 对于服务节点的状态进行判断决策（独裁、民主、协商），以及节点间的数据复制策略的设计（是命令同步、数据同步还是文件同步，是同步复制、异步复制、还是半同步、多数同步等）。

• 无论计算高可用还是存储高可用，最终都属于接口高可用，那么接口高可用要如何做？真的请求很多，超过我们系统负载了，如何解决？

• 主要是要解决两个现象：雪崩效应和链式效应

• 雪崩效应就是说请求太多了，那么我们的方案就是【限流】和【排队】，秒杀经常遇到这样的情形。

• 链式效应会导致一个节点故障引起整条请求链的故障，这里就要【降级】和【熔断】

• 高性能也分为两种：【单机高性能】和【集群高性能】

• 单机高性能分为计算高性能和存储高性能

• 计算高性能主要是依赖多线程/多进程、网络模型（TPC/PPC，Reactor），以及缓存。

• 存储高性能则是依赖存储模型的特性，如 B+树支持读多写少、可变的，而 LSM 是对于写多读少、不可变的数据支持得更好。

• 集群高性能跟上面的计算高可用类似，有两个手段：任务分配、任务分解。核心思路就是把一个大任务拆成小任务，分给多个人去做肯定比一个人快很多。例如负载均衡，CDN 缓存。

• 负载均衡和缓存其实也有各自对应的架构体系。

• 负载均衡架构一般有 4 层：DNS --> F5/LVS --> Nginx --> 网关集群 --> 服务集群。可以根据数据量去掉最贵的 F5/LVS 或者 nginx 这两层。

• 缓存架构里一般有：本地缓存（app 缓存），CDN，Web 容器缓存，应用缓存，以及分布式缓存（redis，memcached）CDN 最贵，一般可以不用。应用缓存实现复杂，容易出 bug，如无需要也可以不用。

• 而分布式缓存架构设计也可以有两种方式：缓存数据和缓存结果

• 缓存数据要解决数据一致性的问题

• 缓存结果则要解决数据新鲜度和刷新频率之间的平衡

• 缓存也会遇到三类问题：缓存穿透、缓存雪崩、缓存热点。

• 可扩展的主要目标是让系统【可理解】和【可复用】。

• 主要手段就是拆分和封装。

• 拆分可以达到可理解的目标，而且可以降低单个服务的内部复杂度，但是同时可能提升外部复杂度，所以要把握一个平衡。

• 封装主要为了达到可复用的目标，把变化多的部分封装起来，那么它变化的时候，不会影响到其他部分，将来其他业务用到这个复杂业务模块，也可以直接复用。

• 一个系统的复杂度其实分为业务复杂度和质量复杂度，两个复杂度是正交的。

• 业务和质量复杂度都低的系统，用一些框架就能解决，如 LAMP，SSH 等

• 高业务复杂度，低质量复杂度的，则要进行拆分，用 SOA，微服务等

• 低业务复杂度，高质量复杂度的，则对于性能的要求可能是很高的，就要进行集群、缓存、分片等

• 高业务复杂度，高质量复杂度的，则要融合所有模式。

• 说到微服务，那么就要涉及到，微服务如何拆分，需要哪些基础设施。如果是从头开始落地微服务，那么最先落地哪些基础设施，如果是将单体系统改造微服务，我们从哪里开始改造。以及中台是什么（业务中台和数据中台），要不要拆中台？