课程目录

01.什么是架构

√：了解抽象定义、问题、演进、例子。

02.企业级后端架构解析

->对企业中（后端）架构的剖析，看架构在企业里是一个什么样的“玩法”。

03.企业级后端架构挑战

->企业面临的（后端）架构挑战是什么？工作中如何解决？

04.后端架构实战

->用一个例子说明：架构中一个问题的产生到解决，的实践过程。

03. 企业级后端架构面临的挑战

3.0 企业级后端架构面临的挑战-问题

• 层次图：

• 挑战：

  • 基础设施层面
  • （如果同学们使用过“阿里云”或"“AWX”等云厂商服务，就会感觉它们好像是在提供“无限的资源”。我就算消耗再多的资源都可以承载起来用户的请求。但在基础设施的层面，我们的物理资源其实是有限的。而这和云资源看起来可以提供无限的资源其实是有矛盾的。
  • 这种有限体现在两方面）
    • 物理资源是有限的（）
      • 机器（）
      • 带宽（占运营商带宽，不是说扩就扩）
    • 资源利用率受制于部署服务 （机器虽然有一定的规模限制，但很多服务在机器上部署时有比较好虚拟化的设施，资源的利用率是不一定满的。比如机器部署了几百个上千个Pod，其实实际使用的可能只是很低的水位。但有些机器部署的服务的承载流量比较高，所以机器的利用率也比较高。所以资源的利用率受制于服务） （白色部分是可用资源，其实有很多buffer资源可以放出来做别的事情。但因为机器已经把所有资源都给了用户部署用户的虚拟化资源。所以机器看起来好像很满，实际上没有使用满）
  • 用户层面 （因为在云原生上使用时有很多微服务。原来单机服务时，所有服务都在一个进程里/机器里，那就不需要一个网络通信的开销。进程间通信/进程内通信都可以）
    • 网络通信开销大 （所以云的企业网络内部通信的开销会比较大）
    • 网络抖动导致运维成本提高 （随着网络通信越来越多，那么网络一旦出现轻微抖动，运维成本会比较高。“网络又出错啦”“网络又出问题啦，这可怎么办”“该怎么容灾、怎么处理”都会体现在运维成本里。）
    • 异构环境下，不同实例资源水位不均 （在底层基础设施层面，机器实际处理能力是不一样的。比如有些是比较旧的芯片CPU型号，有些是比较新的CPU型号。那么它在部署相同服务，承载相同请求时，CPU使用量是不一样的。所以在异构环境下，用户看到的使用CPU的量级也是不一样的。那么怎么把不同的实例资源实力抬平呢？这就是用户看到的问题）
  • 结合这样的问题，看看企业架构中是如何解决的呢？

3.1 企业级后端架构面临的挑战-离在线资源并池

• 层次图：

（首先，在企业资源利用率这块，有一个核心诉求：如何降低机器成本？“如何使用更少的机器提供更多弹性的资源？”这样在架构上才有一个更好的收入嘛->如何卖更多的虚拟机/从用户角度看：哇它能提供更多的资源=>这些就是从架构上带来的收益）

1. 核心收益（）
   • 降低物理资源成本（）
   • 提供更多弹性资源，增加收入（）
2. 解决思路：离在线资源并池

（那想拿到那么多收益，我们就是想：能不能把离线的任务和在线的任务做并池。也就是说原来离线的池子和在线的池子是分开的，哪个线就提供哪个的服务。比如在线的有：热门榜单啊、提供高并发高腾图的服务布置在在线池子上。离线啊就比如说做用户行为的分析、满意度分析等等。那把两个池子合在一起，看起来我们的资源量就更大了。

但因为它上面跑的服务所占的资源还是一定的，所以我们需要一些方案，在不同的时间点，不同的资源可以得到更好的分配。那么我们就需要分析在线、离线的业务特点）

• 在线业务特点：

  1. IO密集型为主（比如一个服务提供高并发的用户差距，那肯定是有很多很多请求要进来。这些服务主要忙碌于IO上）
  2. 潮汐性、实时性（比如凌晨少，晚高峰大。实时性就是对延时性比较敏感。比如刷榜单的时候不能让用户等10s才看到新的榜单，这是不能接受的）

• 离线业务特点：

  1. 计算密集型占多数 （比如我们需要做非常复杂的数据分析，比如说Spark，Map reduce等等。它们需要消耗非常多的计算资源、复杂的计算模型，任务可能需要花很长时间才能结束。所以可能资源稍微少一点，从原本需要5h才能跑完变成8h才行，其实这种也还好。所以我们结合不同形态架构的特点，可以做两种形态的架构优化。）
  2. 非实时性

（所以我们把在线池和离线池合并，结合应用的潮汐性，对资源做合理的调配。比如凌晨2点的在线诉求比较少，那我们就把在线资源的quarter降低。把这个没用上的位置让给别人来用。）

• 问题：同一个机器怎么做 离在线隔离？（包括容器也好，C group也好，都是我们真真正正在使用的。我们可以认为是离线的资源使用的是离线的进程，在线的资源使用的是在线的进程。那么一个机器假如有96个核心，那我们可以用类似容器化的方式，把在线资源和离线资源用C group用虚拟化的方式对CPU的核心做隔离。然后使不同的任务使用不同的CPU set。这样就能尽可能在CPU资源上不会相互影响，达到隔离效果。）

3.2 企业级后端架构面临的挑战-自动扩缩容

• 层次图：

1. 核心收益：（）

   • 降低业务成本（）

2. 解决思路：自动扩缩容

   • 利用在线业务潮汐性自动扩缩容（）

3. 问题：扩缩容依据什么指标？（）

3.3 企业级后端架构面临的挑战-微服务亲和性部署

• 层次图：

1. 核心收益：（）

   • 降低业务成本（）
   • 提高服务可用性（）

2. 解决思路：微服务亲和性部署

   • 将满足亲和性条件的容器调度到一台宿主机（）
   • 微服务中间件与服务网格通过共享内存通信（）
   • 服务网格控制面实施灵活、动态的流量调度（）

3.4 企业级后端架构面临的挑战-流量治理

1. 核心收益：（）

   • 提高微服务调用容错性（）
   • 容灾（）
   • 进一步提高开发效率，DevOps发挥到极致（）

2. 解决思路：基于微服务中间件 & 服务网格的流量治理

   • 熔断、重试（）
   • 单元化（）
   • 复杂环境（功能、预览）的流量调度（）

3.5 企业级后端架构面临的挑战-CPU水位负载均衡

• 层次图：

1. 核心收益：（）

   • 打平异构环境算力差异（）
   • 为自动扩缩容提供正向输入（）

2. 解决思路：CPU水位负载均衡

   • IaaS（）
     • 提供资源探针（）
   • 服务网格（）
     • 动态负载均衡（）