apache · Ylikj · Nov 12, 2021
diff --git a/website/blog/2021/09/07/how-to-use-apisix-auth.md b/website/blog/2021/09/07/how-to-use-apisix-auth.md
@@ -16,7 +16,7 @@ tags: [Practical Case]
 
 身份认证在日常生活当中是非常常见的一项功能，大家平时基本都会接触到。比如用支付宝消费时的人脸识别确认、公司上班下班时的指纹/面部打卡以及网站上进行账号密码登录操作等，其实都是身份认证的场景体现。
 
-![概念理解](https://static.apiseven.com/202108/1631004418593-0a46f949-72aa-4cd4-8f38-1988327c92d6.png)
+![概念理解](https://static.apiseven.com/202108/1636724102237-61251450-2f3a-4ea7-8000-f38244943a20.png)
 
 如上图，Jack 通过账号密码请求服务端应用，服务端应用中需要有一个专门用做身份认证的模块来处理这部分的逻辑。请求处理完毕之后，如果使用 JWT Token 认证方式，服务器会反馈一个 Token 去标识这个用户为 Jack。如果登录过程中账号密码输入错误，就会导致身份认证失败。这个场景大家肯定都非常熟悉，这里就不做展开举例了。
 
@@ -42,7 +42,7 @@ tags: [Practical Case]
 
 如下图所示，左侧的图为我们展示了一种比较常见的传统身份认证方法。每一个应用服务模块去开发一个单独的身份认证模块，用来支持身份认证的一套流程处理。但当服务量多了之后，就会发现这些模块的开发工作量都是非常巨大且重复的。
 
-![Apache APISIX 身份认证](https://static.apiseven.com/202108/1631004492221-0721d933-705d-4875-b956-e94a11a45135.png)
+![Apache APISIX 身份认证](https://static.apiseven.com/202108/1636724138661-974559de-b3e6-4a80-8b2b-1d76ed72e5a8.png)
 
 这种时候，我们可以通过把这部分的开发逻辑放置到 Apache APISIX 的网关来实现统一，减少开发量。
 
@@ -52,7 +52,7 @@ tags: [Practical Case]
 
 ### 优点一：配置收敛，统一管理
 
-![Dashboard](https://static.apiseven.com/202108/1631004574541-87b607eb-2971-4c1d-a1d6-74cf4a5fdd42.png)
+![Dashboard](https://static.apiseven.com/202108/1636724182430-c382aa98-c505-4a0c-aef6-fb418f66be61.png)
 
 如上图是一张 APISIX-Dashboard 的界面截图，可以看到路由、Consumer 等数据信息。这里的 Consumer 可以理解为一个应用方，比如可以为应用专门去创建一个 Consumer 并配置相关的认证插件，例如 JWT、Basic-Auth 等插件。当有新的服务出现时，我们需要再创建一个 Consumer，然后将这部分配置信息给配置到第二个应用服务上。
 
@@ -62,7 +62,7 @@ tags: [Practical Case]
 
 Apache APISIX 作为一个 API 网关，目前已开启与各种插件功能的适配合作，插件库也比较丰富。目前已经可与大量身份认证相关的插件进行搭配处理，如下图所示。
 
-![API 网关认证插件](https://static.apiseven.com/202108/1631004738218-586e84af-a5ab-4714-845d-4d71b7ba79e3.png)
+![API 网关认证插件](https://static.apiseven.com/202108/1636724224725-174336eb-2ed4-41bd-b2d6-f7db716a6615.png)
 
 基础认证插件比如 Key-Auth、Basic-Auth，他们是通过账号密码的方式进行认证。
 
@@ -76,7 +76,7 @@ Authz-casbin 插件是目前 Apche APISIX 与 Casbin 社区正在进行合作开
 
 功能强大该如何理解，就是 Apache APISIX 中可以针对每一个 Consumer （即调用方应用）去做不同级别的插件配置。
 
-![配置灵活](https://static.apiseven.com/202108/1631004783828-3dd0056c-a6aa-4ab9-b902-7bd2ca545ffe.png)
+![配置灵活](https://static.apiseven.com/202108/1636724259306-9445bc6e-57cc-494c-bf62-8f64fee3bfe5.png)
 
 如上图，我们创建了两个消费者 Consumer A，Consumer B。我们将 Consumer A 应用到`应用1`，则后续`应用1`的访问将会开启 Consumer A 的这部分插件，例如 IP 黑白名单，限制并发数量等。将 Consumer B 应用到`应用2` ，由于开启了 http-log 插件，则`应用2`的访问日志将会通过 HTTP 的方式发送到日志系统进行收集。
 
@@ -92,45 +92,45 @@ Authz-casbin 插件是目前 Apche APISIX 与 Casbin 社区正在进行合作开
 
 创建路由，配置上游为 `httpbin.org`，同时开启 `basic-auth` 插件。
 
-![创建路由](https://static.apiseven.com/202108/1631004892467-71c93f8f-dc0e-47fe-a88f-943adb9edbff.png)
+![创建路由](https://static.apiseven.com/202108/1636724295220-2c0dbc80-dffa-40fc-93da-7406588b1f8f.png)
 
 #### 步骤二：创建消费者，配置身份信息
 
 创建消费者 foo。在消费者中，我们需要配置用户的认证信息，例如 `username` 为 foo，`password` 为 `bar`。
 
-![创建消费者](https://static.apiseven.com/202108/1631004937828-15ac5d8f-0e45-4c3d-94e8-2b180266b379.png)
+![创建消费者](https://static.apiseven.com/202108/1636724333976-b9b7d6f5-e31e-4c1e-860f-3d34f810f65e.png)
 
 #### 步骤三：应用服务携带认证信息进行访问
 
 应用携带 `username:foo` ,`password: bar` 访问 Apache APISIX。Apache APISIX 通过认证，并将请求 Authorization 请求头携带至上游 `httpbin.org` 。由于 `httpbin.org` 中 get 接口会将请求信息返回，因此我们可以在其中观察到请求头 `Authorization`。
 
-![请求携带](https://static.apiseven.com/202108/1631004973305-4b209f79-f7de-41a2-994e-8877a6624d99.png)
+![请求携带](https://static.apiseven.com/202108/1636724540228-501fa2fb-5d55-41bd-8c71-5e992ded9964.png)
 
 ### 中级：进阶玩法
 
 进阶模式下，是使用 Apache APISIX 与 OpenID-Connect 插件进行对接第三方认证服务。OpenID-Connect 是一种认证机制，可以采用该认证机制对接用户的用户管理系统或者用户管理服务，例如国内的 Authing 和腾讯云，国外的 Okta 和 Auth0 等。
 
-![第三方认证模式](https://static.apiseven.com/202108/1631005002268-7393b40e-1733-4e66-bc09-742be221efae.png)
+![第三方认证模式](https://static.apiseven.com/202108/1636724570439-dacecf6b-1579-4a1a-911e-b23628b91f25.png)
 
 具体操作如下，这里使用 Okta 云服务举例：
 
 #### 步骤一：创建 OpenID-Connect 应用
 
 在 Okta 控制台页面创建一个支持 OpenID-Connect 的应用。
 
-![创建](https://static.apiseven.com/202108/1631005022640-1e931b14-8175-47f3-bfb8-46e09cec616b.png)
+![创建](https://static.apiseven.com/202108/1636724607752-633a622f-b6d2-45cb-931c-04c790faef3f.png)
 
 #### 步骤二：创建路由，配置 OpenID-Connect 插件
 
 创建路由，配置访问的上游地址为 httpbin.org，同时开启 openid-connect 插件，将 Okta 应用的配置填写到 openid-connect 插件中。
 
-![配置插件](https://static.apiseven.com/202108/1631005045489-b637ef9a-c71c-440f-ae58-a93398a4c9dd.png)
+![配置插件](https://static.apiseven.com/202108/1636724646085-b83d585e-aacb-47f5-9f84-da363059f4c8.png)
 
 #### 步骤三：用户访问时，会跳转至登录页面。登录完成后，上游应用获取用户信息
 
 此时，当用户访问 Apache APISIX 时，会先重定向到 Okta 登录页面。此时需要在该页面填写 Okta 中已经存在的用户的账号密码。登陆完成之后，Apache APISIX 会将本次认证的 Access-Token，ID-Token 携带至上游，同时将本次认证的用户信息以 base64 的方式编码至 Userinfo 请求头，传递至上游。
 
-![APISIX 页面](https://static.apiseven.com/202108/1631005077846-0f877a03-ddcd-46f6-a38d-f046b4700058.png)
+![APISIX 页面](https://static.apiseven.com/202108/1636724684086-28cd8396-9176-40e9-b3f4-a1de6fcad90a.png)
 
 ## 高级：DIY 玩法
 
@@ -140,18 +140,18 @@ Authz-casbin 插件是目前 Apche APISIX 与 Casbin 社区正在进行合作开
 
 ### 方式一：自定义判断逻辑
 
-![判断逻辑](https://static.apiseven.com/202108/1631005112469-c04868b8-388e-4b81-abcc-d37b6a8951f5.png)
+![判断逻辑](https://static.apiseven.com/202108/1636724727061-05e3892e-9396-4d90-b157-2e9293a05564.png)
 
 通过请求头、参数等相关信息，来进行一些判断。通过这种做法，我们可以去实现自己的一些规则，比如说结合企业内部的一些认证，或者去写一些自己的业务逻辑。
 
 ### 方式二：发起认证鉴权请求
 
-![鉴权请求](https://static.apiseven.com/202108/1631005141578-f90cf948-4913-45cd-a28e-9e697ad197fe.png)
+![鉴权请求](https://static.apiseven.com/202108/1636724758815-f6c948ae-0c22-49b8-9be0-b94d9e93b5a3.png)
 
 通过 HTTP 库发起一个 HTTP 请求，我们可以利用第三方服务做一些认证、鉴权相关事情，然后解析返回结果。通过这种方式，我们可以做的事情就可以扩展很多。比如对接 Redis 或数据库，只要是通过 TCP 或 UDP 这种形式的，都可以通过 Serverless 插件进行尝试。
 
 ### 配置上传
 
 完成自定义代码片之后，我们创建路由，并将代码片配置到 Serverless 插件。后面再通过访问 Apache APISIX 获取相应的信息反馈，测试插件是否生效。
 
-![配置上传](https://static.apiseven.com/202108/1631005184917-bc620c0b-d4c6-43f5-8450-4f5b2b9549e1.png)
+![配置上传](https://static.apiseven.com/202108/1636724791422-fbcced8f-67b7-47c4-a856-d1f90fab83c5.png)
diff --git a/website/blog/2021/09/07/iQIYI-usercase.md b/website/blog/2021/09/07/iQIYI-usercase.md
@@ -32,7 +32,7 @@ tags: [User Case]
 
 ### 为什么放弃 Kong
 
-![Kong 的缺点](https://static.apiseven.com/202108/1630995514489-6f7b382a-ed2d-46ad-8ded-4dda42ed3bc8.png)
+![Kong 的缺点](https://static.apiseven.com/202108/1636724853252-017140ed-6bbf-47b4-a4dd-759c60bf2b0f.png)
 
 Kong 使用 PostgreSQL 来存储它的信息，这显然不是一个好方式。 同时在调研过程中我们查看了 Apache APISIX 与 Kong 的性能的对比，在性能优化方面 Apache APISIX 比 Kong 提升了 10 倍，这个指标是非常让人惊喜的。 同时我们也比较了一些主要的网关产品，Apache APISIX 的响应延迟比其它网关低 50% 以上，在 CPU 达到 70% 以上时 Apache APISIX 仍能稳定运转。
 
@@ -44,13 +44,13 @@ Kong 使用 PostgreSQL 来存储它的信息，这显然不是一个好方式。
 
 爱奇艺网关的总体架构如下图所示，包含域名、网关到服务实例和监控告警。DPVS 是公司内部基于 LVS 做的一个开源项目，Hubble 监控告警也是基于开源项目做的深度二次开发，Consul 这块做了些性能和高可用性方面的优化。
 
-![爱奇艺网关架构图](https://static.apiseven.com/202108/1630995637366-b42e408b-53ea-47fb-b282-e68042f13090.png)
+![爱奇艺网关架构图](https://static.apiseven.com/202108/1636724898321-3c834c43-c683-4925-a9de-2e082c4ddb66.png)
 
 ### 应用场景一：微服务网关
 
 关于网关这块，简单从控制面和数据面介绍一下。
 
-![网关细节图](https://static.apiseven.com/202108/1630995699492-bdc1c560-2c0a-4db0-82c9-2a5391941863.png)
+![网关细节图](https://static.apiseven.com/202108/1636724931134-01fe56eb-ee52-4b8d-b63c-fad26411f9cd.png)
 
 数据面主要面向前端用户，从 LB 到网关整个架构都是多地多链路灾备部署，以用户就近接入原则进行布点。
 
@@ -60,7 +60,7 @@ Kong 使用 PostgreSQL 来存储它的信息，这显然不是一个好方式。
 
 目前阶段，基于 Apache APISIX 调整后的 API 架构实现了一些基础功能，如限流、认证、报警、监控等。
 
-![微服务平台功能](https://static.apiseven.com/202108/1630995732178-1717dd1a-3cdf-4f34-aea2-9a26df1c37c1.png)
+![微服务平台功能](https://static.apiseven.com/202108/1636724964816-6746c3a5-7f2e-418c-8cb2-e9f2a8c1b04c.png)
 
 首先是 HTTPS 部分，爱奇艺方面出于对安全性的考虑，证书和密钥是不会存放在网关机器上，会放在一个专门的远程服务器上。之前使用 Kong 时我们没有在这方面做相关支持，采用前置 Nginx 做 HTTPS Offload，此次迁移到 Apache APISIX 后，我们在 Apache APISIX 上实现了该功能，从链路上来说就少了一层转发。
 
@@ -72,13 +72,13 @@ Kong 使用 PostgreSQL 来存储它的信息，这显然不是一个好方式。
 
 关于前面提到的服务发现，主要是通过服务中心把服务注册到 Consul 集群，然后通过 DNS 服务发现的方式去做动态更新，其中 QAE 是我们公司内部的一个微服务平台。简单举例说明一下更新后端应用实例时的大体流程。
 
-![服务发现流程](https://static.apiseven.com/202108/1630995762178-b807f5fe-8851-4f10-acdc-fbf1c372b12f.png)
+![服务发现流程](https://static.apiseven.com/202108/1636725007345-664c1337-a376-42e9-b6f8-f55bde61ee94.png)
 
 实例变更时，首先会从 Consul 中注销对应节点，并通过 API 网关 Controller 向网关发送更新 DNS 缓存的请求。缓存更新成功后，Controller 再反馈 QAE 平台可以停止相关后端应用节点，避免业务流量再转发到已下线节点。
 
 ### 应用场景四：定向路由
 
-![定向路由操作](https://static.apiseven.com/202108/1630995803596-e8d73d5d-29e0-4f66-b3bd-976d650bafcb.png)
+![定向路由操作](https://static.apiseven.com/202108/1636725041947-a0c744f3-8b55-41a3-8442-b002ba95cacf.png)
 
 网关是多地部署的，事先搭建好一整套多地互备链路，同时建议用户后端服务也是多地就近部署。随后用户在 Skywalker 网关平台上创建一个 API 服务，Controller 会在全 DC 网关集群上都部署好 API 路由，同时业务域名默认 CNAME 到统一的网关域名上。
 

diff --git a/website/blog/2021/09/13/china-mobile-cloud-usercase.md b/website/blog/2021/09/13/china-mobile-cloud-usercase.md
@@ -50,7 +50,7 @@ Apache APISIX features, functional plugins, and custom development capabilities
 
 The general SLA service level availability emphasizes two metrics: system mean time to failure and system mean time to repair failure. How to effectively lengthen the system mean time to failure? How to effectively reduce the system mean time to repair? These two questions are our key considerations. Apache APISIX has good traffic management and service management related capabilities in both fault isolation and self-healing.
 
-![SLA Service Level](https://static.apiseven.com/202108/1631500451210-60ba58d6-1fc4-4db6-b658-5e0066bb1c9b.png)
+![SLA Service Level](https://static.apiseven.com/202108/1636725196336-a2764f7c-f396-48a7-96c1-0a535b17b476.png)
 
 ## What Did We Change in Apache APISIX Data Plane?
 
@@ -64,11 +64,11 @@ By accessing Apache APISIX, we realize multi-domain certificate configuration fo
 
 Here we first give you a brief description of the current Object Storage EOS node management after accessing Apache APISIX. The entire object store is divided into a data plane and a control plane. The data plane mainly carries the I/O flow of the whole business. The business data is processed from APISIX’s Layer 7 traffic governance module as the entry point, through the APISIX back-end upstream Accesser, which is the main module for business interface processing.
 
-![Fuse Protection](https://static.apiseven.com/202108/1631500499020-4297de78-f9e3-45a5-8f57-2a55280bf7b0.png)
+![Fuse Protection](https://static.apiseven.com/202108/1636725240231-15d3ab58-acfb-4406-83d5-212fa73b74dc.png)
 
 The control plane has several main services, including the autopilot service Manager, the observable system Observer, and the chaos engineering fault injection module Checker. there is also an additional overall interaction orchestration system Orchestrator and a grayscale publishing platform Publisher.
 
-![Control Plane Services](https://static.apiseven.com/202108/1631500520579-1e40b538-377b-4356-b0f2-1038c0a798e4.png)
+![Control Plane Services](https://static.apiseven.com/202108/1636725303947-5abf20eb-0089-468e-a455-4def438c7576.png)
 
 In order to achieve request fusion protection, the data plane is connected to Apache APISIX to achieve the processing capability of request intervention. The observable system at the control plane is mainly built based on Prometheus, which collects indicators and alerts, and finally realizes the overall fusion protection at the back-end.
 
@@ -77,7 +77,7 @@ In order to achieve request fusion protection, the data plane is connected to Ap
 limit-conn key This plugin mainly supports remote_addr, server_addr, X-Forwarded-For, X-Real-IP, but cannot do full limit flow for north-south gateway traffic.
 In order to match our business requirements, we customize a constant constant as the range of imit-conn key. The right side of the above figure is the modified configuration after accessing Apache APISIX, and the constant constant constant key is used to achieve the function of global flow-limit.
 
-![Global Flow-limit](https://static.apiseven.com/202108/1631500546238-9fd5ebcf-d205-4d99-a34d-236d5589a7e6.png)
+![Global Flow-limit](https://static.apiseven.com/202108/1636725345469-6670e87f-446b-45b1-bade-6ffb6ef62852.png)
 
 ### Improvement 4: New Function Feature Switches
 
@@ -103,7 +103,7 @@ Combined with the Apache APISIX Layer 7 governance capabilities, we perform upgr
 
 Based on access.log, we have implemented a centralized log collection management method to collect APISIX logs and logs of other processes, and then perform a comprehensive analysis.
 
-![Log Tracking](https://static.apiseven.com/202108/1631500588620-9200d098-b4ac-4b9d-99f4-509f9fada70f.png)
+![Log Tracking](https://static.apiseven.com/202108/1636725376895-00b17857-066a-4cc7-95b0-c4aa22d9bf76.png)
 
 The configuration item on the right side of the image above uses the request-id plugin of Apache APISIX. Each request is assigned a request-id when it passes through APISIX, which is used in the business logic processing layer (Accesser) and the data persistence layer, which in turn filters out the log timestamps of the different components in the official Loki panel and helps to automate some analysis using AI later.
 
@@ -112,7 +112,7 @@ The configuration item on the right side of the image above uses the request-id
 The backend of the current load balancing is a seven-layer traffic governance layer based on APISIX implementation, which achieves multi-live capability by equal ECMP + BGP routing. We define three traffic types, each APISIX node receives service traffic and only hits the upstream service of this node to process (level0, purple line), similar to SideCar mode.
 If a node has a problem upstream, it will be forwarded to other upstream nodes in the same AZ for processing (green line). If all upstream nodes hang, the ability to invoke requests across AZs (level2, red line) is implemented based on Apache APISIX, which writes the requests to other AZs and finally achieves request scheduling across AZs.
 
-![Cross Available Zones Request Scheduling](https://static.apiseven.com/202108/1631500626933-473fdd62-dcee-42cc-93c2-93d83acd796c.png)
+![Cross Available Zones Request Scheduling](https://static.apiseven.com/202108/1636725410316-94f9a70a-acf5-4df9-a166-da6c96cd1878.png)
 
 ## Future Plans