Go Engineer System Course 018 [Study Notes]

Getting Started with API Gateway and Continuous Deployment (Kong & Jenkins) corresponds to the course materials "Chapter 2: Getting Started with Jenkins" and "Chapter 3: Deploying Services with Jenkins", outlining the practical path for Kong and Jenkins in enterprise-level continuous delivery. Even with zero prior experience, you can follow the steps to build your own gateway + continuous deployment pipeline. Pre-class Introduction: What is an API Gateway? An API Gateway sits between clients and backend microservices...

Introduction to API Gateway and Continuous Deployment (Kong & Jenkins)

Corresponding to the documentation directories "Chapter 2: Introduction to Jenkins" and "Chapter 3: Deploying Services with Jenkins", this article organizes the practical path of Kong and Jenkins in enterprise-level continuous delivery. Even with zero foundation, you can follow the steps to build your own gateway + continuous deployment pipeline.

Pre-class Tour: What is an API Gateway

An API Gateway sits between clients and backend microservices, acting as the system's "unified entry point". It is responsible for receiving external requests, routing them to different backend services based on configuration, and performing a series of common capabilities at the entry layer (authentication, authorization, rate limiting, monitoring, protocol conversion, etc.), thereby simplifying client invocation processes and reducing coupling between services.

graph LR
    ClientA[Web 客户端] --> APIGateway[API Gateway]
    ClientB[移动端] --> APIGateway
    ClientC[第三方合作方] --> APIGateway
    APIGateway -->|路由/聚合| ServiceA[用户服务]
    APIGateway -->|协议转换| ServiceB[订单服务]
    APIGateway -->|安全控制| ServiceC[支付服务]

Core Responsibilities

  • Unified Entry and Routing: All requests first go to the gateway, then are forwarded according to rules such as path, domain, and Header.
  • Security Protection: Centralized handling of security policies such as authentication, authorization, rate limiting, IP whitelisting, and WAF.
  • Protocol and Format Conversion: Supports REST, gRPC, GraphQL, etc., unifying multiple protocols externally.
  • Observability and Operations: Collects logs, metrics, tracing, and provides resilience measures such as circuit breaking, retries, and caching.
  • Aggregation and Orchestration: Combines multiple backend interfaces to return customized responses, reducing client invocation complexity.

Why an API Gateway is Needed

  • Growth in Microservice Count: Clients do not need to care about each service's address and authentication method; the gateway exposes them uniformly.
  • Centralized Governance Policies: Rate limiting, circuit breaking, monitoring, and other policies are uniformly implemented at the gateway layer, avoiding redundant implementations across services.
  • Facilitates Evolution and Canary Releases: Achieves canary releases, A/B testing, and version switching through routing rules.
  • Enhances Security and Compliance: A unified entry point facilitates auditing and risk control.
sequenceDiagram
    participant Client as 客户端
    participant Gateway as API 网关
    participant Auth as 身份验证服务
    participant Order as 订单服务
    participant Billing as 计费服务

    Client->>Gateway: 请求 /v1/order
    Gateway->>Auth: 校验 Token
    Auth-->>Gateway: 返回用户信息
    Gateway->>Order: 调用订单详情
    Gateway->>Billing: 查询支付状态
    Gateway-->>Client: 聚合后的订单响应

Common products: Nginx + Lua, Kong, Tyk, APISIX, AWS API Gateway, Spring Cloud Gateway, etc.

Chapter 2: Kong Hands-on Introduction

Combine videos 2-1 to 2-6 to master common operations from installation to security hardening.

2-1 Kong's 8001, 8000, and 1337 Port Numbers

Kong opens multiple ports by default, each carrying different responsibilities. Understanding their roles first makes troubleshooting easier.

Port Protocol Role Common Operations
8000 HTTP External Proxy Entry Business requests go here
8443 HTTPS Proxy Entry (TLS) Expose HTTPS services
8001 HTTP Admin API Create Service/Route, view status
8444 HTTPS Admin API (TLS) More secure in production environments
1337 HTTP Dev Portal/Manager Visual configuration (Docker quick experience)
graph TD
    subgraph 业务面
        Client[客户端流量] --> Proxy[8000/8443 Proxy]
        Proxy --> UpstreamPool[上游服务]
    end
    subgraph 运维面
        AdminAPI[8001/8444 Admin API] --> KongCore[Kong 核心]
        Portal[1337 Manager] --> KongCore
    end
    KongCore --> Metrics[日志/指标输出]

Quick self-check commands:

# 确认端口监听状态
docker exec kong netstat -tnlp | grep 800
# 用 Admin API 获取节点信息
curl http://localhost:8001/

2-2 Basic Route Forwarding Configuration

The first thing to do when getting started is to correctly forward a URL to a backend service.

  1. Register Service: Define the upstream address and protocol.
  2. Create Route: Determine which requests hit the aforementioned Service.
  3. Verify Forwarding: Access the proxy entry via curl or a browser.
# 1. 注册服务
curl -X POST http://localhost:8001/services \
  --data "name=user-service" \
  --data "url=http://mockbin.org"

# 2. 绑定路由
curl -X POST http://localhost:8001/services/user-service/routes \
  --data "paths[]=/users" \
  --data "strip_path=true"

# 3. 访问 Kong 代理
curl -i http://localhost:8000/users

Common pitfalls: hosts, paths, methods are "AND" relationships; the more matching conditions, the lower the hit probability; ensure the client Host Header matches the route configuration.

2-3 Kong's Service, Route, Upstream

Service, Route, and Upstream form Kong's core abstractions. Understanding their relationships helps you flexibly combine traffic policies.

  • Service: Describes the backend application (protocol, domain, port, timeout).
  • Route: Defines how to match requests to a specific Service.
  • Upstream: Provides an "instance pool" for a Service, supporting load balancing and health checks.
  • Target: A specific instance (IP:Port) within an Upstream.
graph TD
    Client --> Route[Route: hosts/paths]
    Route --> Service[Service: http://orders.internal]
    Service --> Upstream[Upstream: order-upstream]
    Upstream --> TargetA[10.0.1.10:9000]
    Upstream --> TargetB[10.0.1.11:9000]
    Route -- Plugin 链 --> Plugins[认证/限流/日志]

Best practices:

  • Create a separate Upstream for each upstream service to facilitate subsequent rolling upgrades.
  • Plugins can be attached to Routes, Services, or globally; global policies have the lowest priority.
  • Use Tags to group resources for easier operational searching.

2-4 Kong Integration with Consul for Service Discovery and Health Checks

When backend instances change frequently, entrusting health checks to Consul can reduce manual maintenance burden.

  1. Prepare Consul: Start the Consul Agent and register your application instances (you can use a service.json file).
  2. Configure Service Discovery: Add a new host in the Kong Service in the format of service.consul, and enable service_discovery in KONG_DATABASE or kong.conf.
  3. Declare Upstream to use Consul:
curl -X POST http://localhost:8001/upstreams \
  --data "name=order.consul" \
  --data "service=orders" \
  --data "healthchecks.active.type=http"
  1. Consul maintains instances: When instances go online or offline, Consul automatically synchronizes, and Kong reads the latest health status.
graph LR
    Consul -->|服务健康| KongUpstream
    Jenkins -->|部署后注册| Consul
    KongProxy --> KongUpstream --> BackendPods[订单服务实例]

Tip: Ensure Kong and Consul are network reachable, and enable TTL or HTTP health checks in Consul.

2-5 Kong Configuration of JWT for Login Verification

The JWT plugin makes Kong a unified authentication entry point. The typical process is as follows.

  1. Enable the plugin and create a consumer:
# 添加一个消费者
curl -X POST http://localhost:8001/consumers \
  --data "username=mobile-app"

# 为消费者生成密钥对
curl -X POST http://localhost:8001/consumers/mobile-app/jwt
  1. Enable the JWT plugin on a Route or Service:
curl -X POST http://localhost:8001/services/user-service/plugins \
  --data "name=jwt" \
  --data "config.claims_to_verify=exp"
  1. Client constructs and carries the Token:
curl http://localhost:8000/users \
  -H "Host: api.example.com" \
  -H "Authorization: Bearer <签名后的JWT>"
sequenceDiagram
    participant Client as 客户端
    participant Kong as Kong 网关
    participant JWT as JWT 插件
    participant Upstream as 上游服务

    Client->>Kong: 带 Authorization 的请求
    Kong->>JWT: 校验签名、过期时间
    JWT-->>Kong: 校验通过/失败
    opt 校验通过
        Kong->>Upstream: 转发请求
        Upstream-->>Kong: 返回业务响应
        Kong-->>Client: 200 OK
    end
    opt 校验失败
        Kong-->>Client: 401 未授权
    end

Tip: Combining with key-auth or rate-limiting plugins can further differentiate access permissions and frequencies for different clients.

2-6 Kong Configuration of Anti-Crawler IP Blacklist

Common methods to combat malicious requests are "whitelist + blacklist + rate limiting".

# 开启 IP 限制插件
curl -X POST http://localhost:8001/services/user-service/plugins \
  --data "name=ip-restriction" \
  --data "config.deny[]=192.168.1.100" \
  --data "config.deny[]=203.0.113.0/24"

Combined approach:

  • Blacklist: Immediately add malicious IPs to the deny list upon discovery.
  • Whitelist: For admin backends and BFF interfaces, an allow list can be set, denying other sources by default.
  • Rate limiting: Use with rate-limiting or bot-detection plugins to smooth out traffic spikes.
  • Auditing: Deliver Kong logs to ELK/Loki to identify abnormal User-Agents and Referers.
graph TD
    ClientReq[请求] --> IPCheck[IP 限制插件]
    IPCheck -->|黑名单| Block[返回 403]
    IPCheck -->|通过| RateLimit[限流插件]
    RateLimit --> Backend[上游服务]

Deploying Services with Jenkins

Corresponding to videos 3-1 to 3-11, guiding you from Jenkins installation, plugin selection to Pipeline orchestration and release automation.

3-1 Pain Points of Continuous Integration in Agile Development

  • Frequent code merges, manual packaging, and manual releases are inefficient.
  • Significant differences in dependencies across environments often lead to "it works on my machine" issues.
  • Lack of unified quality gates, leading to missed tests and production rollbacks.
  • Deployment results lack traceability, making it difficult to quickly pinpoint failed nodes.

Agile development: We don't really know what to develop, let's take it one step at a time
User story: The boss said this feature needs to go live tomorrow, I don't care how it's implemented
Rapid iteration: The click-through rate of the last feature was too low, change the ad to full screen
User pain point: A user complained yesterday, adjust the ad
Embrace change: The boss has new ideas every day, everyone needs to adapt (don't blame me)
Continuous delivery: Every version has problems, always continuously delivered to testing, delivery interval 10 minutes
Pair programming: Too many bugs, go directly to the tester's desk to test and modify
Code review: You reviewed this code, you will be responsible if problems arise in the future
Flexible work: No fixed quitting time, you can only leave after fixing bugs
Four meetings: (Scrum Meeting) Starts at 9:00 AM every day, no chance to be late for work

The "joke-style" paragraph above satirizes common agile misconceptions in the industry: equating agile with no planning, treating user stories as temporary requirements, packaging rough releases as "rapid iterations", and even neglecting quality gates in the name of continuous delivery. True agile emphasizes:

  • Rhythmic Planning: Requirements still need to be sorted out, effort estimated, and deliverable goals synchronized externally before each iteration.
  • User Stories Focused on Value: Describes user roles, scenarios, and benefits, helping the team understand "why" something is being done, not just arbitrary feature commands.
  • Quality as a Prerequisite for Continuous Delivery: Automated testing, code reviews, and monitoring alerts are fundamental safeguards; frequent delivery is for quickly validating value, not for continuously "throwing defects to testing".
  • Embracing Change with Boundaries: Managing changes through product backlog and iteration rhythm, adjusting priorities when necessary instead of inserting ad-hoc tasks.
  • Scrum's Four Meetings (Planning, Daily Stand-up, Review, Retrospective) are for synchronizing information, identifying risks, and continuous improvement, not for formalistic check-ins.

Understanding these principles is essential to combine agile and continuous integration, allowing Jenkins pipelines to serve "continuous value delivery" rather than "continuous problem delivery".

3-2 Installing Jenkins and Disabling the Firewall

  1. Docker installation is the quickest:
docker run -d --name jenkins \
  -p 8080:8080 -p 50000:50000 \
  -v jenkins_home:/var/jenkins_home \
  jenkins/jenkins:lts
  1. Initialization Wizard: Follow the prompts to enter the unlock password, install recommended plugins, and create an administrator.
  2. Server Firewall: If using CentOS, you can first disable or allow port 8080.
sudo systemctl stop firewalld
sudo firewall-cmd --permanent --add-port=8080/tcp
sudo firewall-cmd --reload

3-3 Jenkins Building Service Deployment Process

sequenceDiagram
    participant Dev as 开发者
    participant Git as 代码仓库
    participant Jenkins
    participant Registry as 镜像仓库
    participant K8s as Kubernetes
    participant Kong

    Dev->>Git: 提交代码
    Git-->>Jenkins: Webhook/轮询触发
    Jenkins->>Jenkins: 编译 + 测试
    Jenkins->>Registry: 推送镜像/制品
    Jenkins->>K8s: 滚动更新
    Jenkins->>Kong: 调用 Admin API 刷新路由
    Jenkins-->>Dev: 通知结果(钉钉/邮件)

Key points of the process:

  • Use Credentials to store access keys for Git, Registry, and Kubernetes.
  • Timely emailext or robot notifications at failure stages facilitate immediate handling.
  • Use post blocks to specify different notification actions for success and failure.

3-4 Installing Common Jenkins Plugins

主题测试文章,只做测试使用。发布者:Walker,转转请注明出处:https://walker-learn.xyz/archives/4789

(0)
Walker的头像Walker
上一篇 Nov 24, 2025 00:00
下一篇 Nov 25, 2025 14:00

Related Posts

EN
简体中文 繁體中文 English
欢迎🌹 Coding never stops, keep learning! 💡💻 光临🌹