hypc's blog

当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时， 仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。

降级的最终目的是保证核心服务可用，即使是有损的。但是有些服务是无法降级的（如加入购物车、结算）。

在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级。

页面降级

在大促或者某些特殊情况下，某些页面占用了一些稀缺服务资源，在紧急情况下可以对其整个降级，以达到丢卒保帅；

页面片段降级

比如商品详情页中的商家部分因为数据错误了，此时需要对其进行降级；

页面异步请求降级

比如商品详情页上有推荐信息/配送至等异步加载的请求，如果这些信息响应慢或者后端服务有问题，可以进行降级；

什么是缓存穿透

缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的， 并且出于容错考虑，如果从存储层查不到数据则不写入缓存， 这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。

如果有人利用这个（些）不存在的key频繁地攻击我们的应用，也会造成雪崩效应。

解决思路

1. 使用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中， 一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。

2. 另一个粗暴的方式是将数据库查询到的空值也进行缓存，但缓存过期时间会很短，远低于正常缓存过期时间。

什么是缓存雪崩

缓存雪崩可能是因为数据未加载到缓存中，或者缓存同一时间大面积的失效，或者缓存服务器宕机， 从而导致所有请求都去查数据库，导致数据库CPU和内存负载过高，甚至宕机。

解决思路

1. 针对缓存已经失效的情况，可以采用加锁计数，或者使用合理的队列数量来避免缓存失效时对数据库造成太大的压力。 这种办法虽然能缓解数据库的压力，但是同时又降低了系统的吞吐量。

2. 分析用户行为，尽量让缓存失效时间分布均匀，可以用来避免缓存在同一时间大面积失效的情况。 也可直接在原有缓存时间上增加一个随机值。

3. 可以使用主备或集群的方式来应对缓存服务器宕机的问题。但此时需要处理事务问题，如update时可能会读到脏数据。

常见的模式有分为两大类：Cache-aside以及Cache-as-SoR。

SoR(system-of-record)：记录系统，或者可以叫做数据源，即实际存储原始数据的系统。

Cache：缓存，是SoR的快照数据，Cache的访问速度比SoR要快，放入Cache的目的是提升访问速度，减少回源到SoR的次数。

Cache-aside

访问记录系统（SoR）的应用程序代码应首先查询缓存，如果缓存包含数据，则直接从缓存返回数据，绕过SoR。 否则，应用程序代码必须从记录系统获取数据，将数据存储在缓存中，然后返回它。写入数据时，必须同时更新缓存以及记录系统。

读取值的伪代码

1
2
3
4

v = cache.get(k)
if v == null:
    v = sor.get(k)
    cache.put(k, v)

写入值得伪代码

1
2
3

v = new V()
sor.put(k, v)
cache.put(k, v)

Kubernetes Pod是平凡的，它门会被创建，销毁（生老病死），并且他们是不可复活的。 每个Pod都有自己的IP地址，但是在部署中，一段时间内运行的Pod集可能与稍后运行该应用程序的Pod集不同。

这会导致一个问题：如果某些Pod（称为『后端』）为集群内的其他Pod（称为『前端』）提供功能， 前端如何找出并跟踪要连接的IP地址，以便前端可以使用工作负载的后端部分？

答案是：Service

在Kubernetes中，Service是一个抽象，它定义了一组逻辑Pod和一个访问它们的策略（有时这种模式称为微服务）。 服务所针对的Pod集合通常由选择器确定。

例如，一个运行3个副本的无状态图像处理后端。那些复制品是可替代的 - 前端并不关心它们使用哪个后端。 虽然组成后端集的实际Pod可能会发生变化，但前端客户端不应该知道这一点，也不需要自己跟踪后端集。 服务抽象地实现了这种解耦。

有关更多信息，请参阅Service。

Pod是Kubernetes应用程序的基本执行单元 - Kubernetes应用程序中，创建或部署的Kubernetes对象模型中最小和最简单的单元。 Pod表示在群集上运行的进程。

Pod封装了应用程序的容器（或者，在某些情况下，多个容器），存储资源，唯一的网络IP以及管理容器应该如何运行的选项。 Pod表示部署单元：Kubernetes中的单个应用程序实例，可能包含单个容器或者是少量紧密耦合并共享资源的容器。

Docker是Kubernetes Pod中最常用的容器运行时，但Pods也支持其他容器运行时。

Kubernetes集群中的Pod可以以两种主要方式使用：

• 运行单个容器：one-container-per-Pod模型是最常见的Kubernetes用例；在这种情况下， 您可以将Pod视为单个容器的包装，而Kubernetes直接管理Pod而不是容器。

• 运行多个需要协同工作的容器：Pod可以封装由多个共址容器组成的应用程序，这些容器紧密耦合并需要共享资源。 这些共处一地的容器可能形成一个统一的服务单元 - 一个容器从共享卷向公众提供文件，而一个单独的“sidecar”容器刷新或更新这些文件。 Pod将这些容器和存储资源作为单个可管理实体包装在一起。

每个Pod都用于运行给定应用程序的单个实例。如果要水平扩展应用程序（例如，运行多个实例），则应使用多个Pod，每个实例一个。 在Kubernetes中，这通常被称为复制。复制Pod通常由称为Controller的抽象创建和管理。

有关更多信息，请参阅Pod Overview。

传统部署时代：早期，组织在物理服务器上运行应用程序。 无法为物理服务器中的应用程序定义资源边界，这会导致资源分配问题。 例如，如果在物理服务器上运行多个应用程序，则可能存在一个应用程序占用大部分资源的情况，因此其他应用程序将表现不佳。 解决方案是在不同的物理服务器上运行每个应用程序。但是由于资源未得到充分利用，这并没有扩展，组织维护许多物理服务器的成本很高。

虚拟化部署时代：作为解决方案，引入了虚拟化。它允许您在单个物理服务器的CPU上运行多个虚拟机（VM）。 虚拟化允许应用程序在VM之间隔离，并提供一定程度的安全性，因为另一个应用程序无法自由访问一个应用程序的信息。 虚拟化可以更好地利用物理服务器中的资源，并且可以实现更好的可扩展性，因为可以轻松添加或更新应用程序，降低硬件成本等等。 每个VM都是在虚拟化硬件之上运行所有组件（包括其自己的操作系统）的完整计算机。

容器部署时代：容器类似于VM，但它们具有宽松的隔离属性，可在应用程序之间共享操作系统（OS）。 因此，容器被认为是轻质的。与VM类似，容器具有自己的文件系统，CPU，内存，进程空间等。 当它们与底层基础架构分离时，它们可以跨云和OS分发进行移植。

Kubernetes是一个开源容器编排引擎，用于容器化应用的自动化部署、扩展和管理。

概述

要使用 Kubernetes，你需要用 Kubernetes API 对象 来描述集群的 预期状态（desired state） ： 包括你需要运行的应用或者负载，它们使用的镜像、副本数，以及所需网络和磁盘资源等等。 你可以使用命令行工具 kubectl 来调用 Kubernetes API 创建对象，通过所创建的这些对象来配置预期状态。 你也可以直接调用 Kubernetes API 和集群进行交互，设置或者修改预期状态。

一旦你设置了你所需的目标状态，Kubernetes 控制面（control plane） 会促成集群的当前状态符合其预期状态。 为此，Kubernetes 会自动执行各类任务，比如运行或者重启容器、调整给定应用的副本数等等。 Kubernetes 控制面由一组运行在集群上的进程组成：

• Kubernetes 主控组件（Master） 包含三个进程，都运行在集群中的某个节上，通常这个节点被称为 master 节点。 这些进程包括：kube-apiserver、kube-controller-manager 和 kube-scheduler。

• 集群中的每个非 master 节点都运行两个进程：

  • kubelet，和 master 节点进行通信。
  • kube-proxy，一种网络代理，将 Kubernetes 的网络服务代理到每个节点上。

灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。 在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B， 如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。 灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

灰度发布流程

PCI DSS (支付卡行业数据安全标准) 旨在促进并增强持卡人的数据安全，便于统一的数据安全措施在全球范围内的广泛应用。 PCI DSS 为意在保护帐户数据的技术和操作要求提供了一个基准。 PCI DSS 适用于参与支付卡处理的所有实体 — 包括商户、处理商、收单机构、发卡机构和服务提供商。 PCI DSS 还适用于存储、处理或传输持卡人数据 (CHD) 和/或敏感验证数据 (SAD) 的所有其他实体。