这是我参与「第五届青训营 」笔记创作活动的第8天。

挑战

• 基础设施层面

  • 在用户的角度，云提供的资源是无限的。然而，云背后的物理资源是有限的，像服务器的机器和带宽都是有限的。
  • 资源利用率受制于部署服务，在云端，用户使用资源的利用率往往不能达到很高，主机的资源有可能很长一段时间会处于空闲的状态。如下图，pod 为主机中的虚拟主机资源，黑色部分为已使用的资源，此时可用资源剩余很多。

• 用户层面

  • 上了云原生微服务后，服务之间的通信开销较大
  • 微服务看起来没有那么美好，抖动导致的运维成本较高
  • 异构的物理环境应该对用户是透明的，不同实例的资源水位不一致

离在线资源并池

核心收益

• 降低物理资源成本
• 提供更多的弹性资源，增加收入

解决方案

使用离在线资源并池，将在线服务和离线服务合并在一个资源内，并根据在线业务和离线业务的特点，比如在线业务的潮汐性离线业务的非实时性，可以对在线资源和离线资源进行灵活地调配。 在线业务

• IO 密集型为主
• 潮汐性、实时性 离线业务
• 计算密集型占多数，比如 Spark、MapReduce 等
• 非实时性，这些应用对于实时反馈的敏感没有很大的影响。

在一台机器上实现资源隔离 使用 cgouops 或者虚拟化的方式对 CPU 的核心做隔离，不同的任务使用不同的 cpu-set 达到一个 cpu 的隔离效果

在资源需求量大的时候，需要有较高的资源负载，而在资源需求量小的情况下，则不需要很多资源，如果说一直保持着一定量的资源，会导致资源浪费带来的成本。 以上的动态调整称作为自动扩缩容，其利用在线业务潮汐性自动扩缩容。如此用户在高峰期时，业务也是比较稳定的，在低谷期时，也不会感受到资源的浪费。 扩缩容的指标：

• CPU 的指标：TP50 等指标
• 内存利用率：对于一些对内存需求量比较高的服务来说，可以和 CPU 的指标一起考虑。
• IO 利用率：对于 IO 的隔离是比较困难的，可行性上比较困难。
• Qts：服务的并发请求数, 这个数据其实也是比较难统计的，所以可行性较低。

TP50：指在一个时间段内（如 5 分钟），统计该方法每次调用所消耗的时间，并将这些时间按从小到大的顺序进行排序，取第 50%的那个值作为 TP50 的值； 配置此监控指标对应的报警阀值后，需要保证在这个时间段内该方法所有调用的消耗时间至少有50%的值要小于此阀值，否则系统将会报警。

微服务亲合性部署

微服务之间的通信成本较高，并且如果两个微服务之间的联系很紧密，网络通信很多，那么需要进行微服务亲和性部署。 核心收益：

• 降低业务成本
• 提高系统可用性

解决方案： 两个微服务在 DevOps 开发中看上去是两个不一样的服务，但是在运行时将网络通信紧密（亲和性较高）的服务根据资源编排调度的方案（资源池共享），将两个服务放在一台宿主机中。其中中间件和服务网格之间、两个服务之间的中间件使用共享内存实现 IPC 进程间通信，而这两个服务与其他服务通过服务网格的数据面进行 RPC 通信。另外为了防止本地 A 容器和远程 A 容器收到 B 容器的流量差异过大，需要使用服务网格的控制面实施灵活、动态的流量调度。 如此以来，亲和性较高的两个服务之间减少了网络通信的开销，导致整体的网络开销减少。即在形态上是微服务架构，而在通信上是单体架构。

流量治理

核心收益

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

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

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

水位负载均衡

核心收益

• 打平异构环境算力差异，对于 CPU 不同的宿主机、CPU 性能不同的宿主机运行一个服务时，可能会存在差异，需要让用户尽可能不感知这一种差异。
• 在自动扩容的情况下，需要有一个评判指标，那么在异构环境下，他们的评判标准也会受到影响，则尽可能屏蔽差异，减少自动扩容时的误差。

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

• IaaS 层面：在被调用的宿主机上设置一个资源探针，该探针会反馈宿主机的资源使用情况到负载均衡层。负载均衡层会根据 B 容器所在的宿主机的服务能力，调整 A 对 B 调用时的权重，服务能力强的能够被更多次调用。
• 服务网格：实现动态负载均衡。