通过 Python+Nacos实现微服务,细解微服务架构

简介: `shigen`是一名擅长多种编程语言的博主,致力于分享技术成长和认知。他尝试将Python服务构建为微服务架构,模仿Java领域的微服务设计。通过Nacos服务发现和注册,实现了Python Flask应用的微服务化,包括网关、用户中心、鉴权和文档服务。代码示例展示了服务注册、心跳维持、HTTP接口以及网关的代理和认证逻辑。此实现促进了服务安全调用,增强了对数据的保护。通过这种方式,`shigen`揭示了Python+Nacos实现微服务的细节,鼓励读者深入理解微服务工作原理。

shigen坚持更新文章的博客写手,擅长Java、python、vue、shell等编程语言和各种应用程序、脚本的开发。记录成长,分享认知,留住感动。
个人IP:shigen

背景

一直以来的想法比较多,然后就用Python编写各种代码脚本。很多的脚本都是通过Python的Flask框架实现,如[file-server],然后部署到云服务器。但是这样只提供一个端口就可以通过http访问,无异于在互联网上裸奔。而且这样的服务有很多个,一直在想如何实现一个统一认证然后就可以访问这么多的服务。在Java领域最常见的设计就是使用微服务架构,把每个服务拆分出来,然后通过网关统一拦截、验证、分发流量。蹭了一张架构图(发现飞书的模板已经很好了):

微服务架构设计

那我的Python服务为什么不能设计成微服务架构呢,当然,还没听说过谁家的Python服务是微服务架构的,姑且一试。

代码实现

考虑到大家的技术栈就是Java,以下的python代码将省略部分细节。

有了之前python flask如何注册到nacos踩坑的经验,这次明显顺利的多了。现在本地搭建nacos环境,并支持http访问,推荐docker-compose的方式搭建:shigen/spring-cloud-platform

因为我的Nacos版本是2.0+的,官方的nacos-sdk-python是这样描述的:

Supported Python version:

Python 2.7 Python 3.6 Python 3.7

Supported Nacos version

Nacos 0.8.0 ~ 1.3.2

于是就使用的是官方的API:Open API 指南

我的服务模块是这样细分的:

microservices-demo/
├── nacos/
├── api-gateway/
│   └── app.py
├── user-service/
│   └── app.py
├── auth-service/
│   └── app.py
└── document-service/
    └── app.py

也就是分成了四个模块:网关、用户中心、鉴权中心、文档中心。接下来就是服务的注册和调用。我们以最简单的auth-service为例:

NACOS_URL = os.getenv(
    "NACOS_URL", "http://localhost:8848/nacos/v1/ns/instance")
SERVICE_NAME = "auth-service"
SERVICE_IP = socket.gethostbyname(socket.gethostname())
SERVICE_PORT = 5002
NAMESPACE = "python"

# 发送到Nacos服务注册接口
def register_service():
    payload = {
        "serviceName": SERVICE_NAME,
        "ip": SERVICE_IP,
        "port": SERVICE_PORT,
        "namespaceId": NAMESPACE,
    }
    response = requests.post(f"{NACOS_URL}", params=payload)

# 每5秒发送一次心跳
def send_heartbeat():
    while True:
        payload = {
            "serviceName": SERVICE_NAME,
            "ip": SERVICE_IP,
            "port": SERVICE_PORT,
            "namespaceId": NAMESPACE,
        }
        response = requests.put(f"{NACOS_URL}/beat", params=payload)
        time.sleep(5)

# 密码验证,获得token
@app.route('/auth', methods=['POST'])
def authenticate():
    pass

# 验证token
@app.route('/verify', methods=['POST'])
def verify_token():
    pass

# 服务启动类
if __name__ == '__main__':
    register_service()
    heartbeat_thread = threading.Thread(target=send_heartbeat)
    heartbeat_thread.daemon = True
    heartbeat_thread.start()
    app.run(port=SERVICE_PORT)

不用尝试读懂代码,很简单:在服务启动的时候注册到nacos,完了就是定时的向nacos发送心跳。@app.route('/auth', methods=['POST'])表示提供一个POST请求方式的/auth接口,然后启动服务:

服务启动

服务启动成功之后,可以看到控制台打印的日志信息。同时提供http访问接口。测试的方式如下:

curl --location 'http://127.0.0.1:5002/auth' \
--header 'Content-Type: application/json' \
--data '{
    "username": "user",
    "password": "pass"
}'

其他的几个服务也如法炮制。最终Nacos服务注册表如下:

服务列表-20240610094917590.(null))

在网关这一块可能稍微有一点区别,复习前面提到的网关的作用:流量的拦截和转发、认证拦截、负载均衡......这里我的网关服务设计如下:

NACOS_URL = os.getenv(
    "NACOS_URL", "http://localhost:8848/nacos/v1/ns/instance")
NAMESPACE = "python"


def get_service_url(service_name):
    try:
        response = requests.get(
            f"{NACOS_URL}/list?serviceName={service_name}&namespaceId={NAMESPACE}")
        data = response.json()
        if data and data['hosts']:
            service = data['hosts'][0]
            # return f"http://{service['ip']}:{service['port']}"
            # 这里是本机调用测试
            return f"http://localhost:{service['port']}"
    except Exception as e:
        print(f"Error getting service URL: {e}")
    return None


@app.route('/<service_name>/<path:path>', methods=['GET', 'POST', 'PUT', 'DELETE'])
def proxy(service_name, path):
    service_url = get_service_url(service_name)
    if not service_url:
        return jsonify({"error": "Service not found"}), 404

    # 认证逻辑
    if service_name != "auth-service":
        token = request.headers.get("Authorization")
        if not token:
            return jsonify({"error": "Missing token"}), 401

        auth_url = get_service_url("auth-service")
        if not auth_url:
            return jsonify({"error": "Auth service not found"}), 500

        verify_response = requests.post(
            f"{auth_url}/verify", json={"token": token})
        if verify_response.status_code != 200:
            return jsonify({"error": "Invalid token"}), 401

    url = f"{service_url}/{path}"
    response = requests.request(
        method=request.method,
        url=url,
        headers={key: value for key,
                 value in request.headers if key != 'Host'},
        data=request.get_data(),
        cookies=request.cookies,
        allow_redirects=False
    )

    return (response.content, response.status_code, response.headers.items())


if __name__ == '__main__':
    app.run(port=8080)

这里其实就是请求来了之后,从nacos上拉取服务列表。这个服务列表就是服务名称和对应的服务所在机器的IP(service-name和对应的IP集合)。然后选取对应服务所在的机器之一作为目标机器(这里选用的是第一台机器),从请求头中获得token,进行验证和调用。token校验失败则打给认证服务,重新进行登录验证。为此,我还对比了一下Spring Cloud + Nacos的设计:
image.png

Nacos的API实现的是springframework.cloud.client.discovery的接口,意味着统一的标准:

package com.alibaba.cloud.nacos.discovery;

public class NacosDiscoveryClient implements DiscoveryClient {

        private static final Logger log = LoggerFactory.getLogger(NacosDiscoveryClient.class);

        /**
         * Nacos Discovery Client Description.
         */
        public static final String DESCRIPTION = "Spring Cloud Nacos Discovery Client";

        private NacosServiceDiscovery serviceDiscovery;

        public NacosDiscoveryClient(NacosServiceDiscovery nacosServiceDiscovery) {
                this.serviceDiscovery = nacosServiceDiscovery;
        }

        @Override
        public String description() {
                return DESCRIPTION;
        }

        @Override
        public List<ServiceInstance> getInstances(String serviceId) {
                try {
                        return serviceDiscovery.getInstances(serviceId);
                }
                catch (Exception e) {
                        throw new RuntimeException(
                                        "Can not get hosts from nacos server. serviceId: " + serviceId, e);
                }
        }

        @Override
        public List<String> getServices() {
                try {
                        return serviceDiscovery.getServices();
                }
                catch (Exception e) {
                        log.error("get service name from nacos server fail,", e);
                        return Collections.emptyList();
                }
        }

}

其中的serviceName和serviceId其实是同一概念,意味着我们可以通过服务名获得全部的部署服务的实例信息,实现自定义的负载均衡调用。这里的原理和我直接从Nacos的API中获得服务列表,默认选取第一台机器进行调用的设计如出一辙。

对于以上的Python代码段,可能文字描述有不详细或者不当之处,借助魔法进行进一步的完善:

这段代码实现了一个反向代理服务器,其主要功能是根据服务名称将请求转发到不同的服务,并在转发前进行认证。具体功能如下:

  1. 服务发现:代码通过访问 NACOS(一个服务发现和配置管理平台)来获取目标服务的 URL。NACOS 提供了服务注册和发现的功能,代码中通过 get_service_url(service_name) 函数实现这一功能。
  2. 请求转发:当接收到一个请求时,根据 URL 中的 service_name 和 path,代码会将请求转发到相应的目标服务。转发时,保留了原始请求的 HTTP 方法、头信息、数据和 cookies。
  3. 认证检查:对于非 auth-service 的请求,代码会检查请求头中是否包含 Authorization token。如果没有 token 或 token 无效,则会返回错误响应。具体步骤如下:
    1. 检查请求头中是否包含 Authorization token。
    2. 如果没有 token,返回 401 错误(未授权)。
    3. 如果有 token,向认证服务(auth-service)发送请求,验证 token 的有效性。
    4. 如果 token 无效,返回 401 错误。
  4. 错误处理:代码包含了基本的错误处理逻辑,例如当服务 URL 无法获取或认证服务不可用时,返回相应的错误响应。

通过这些功能,该反向代理服务器能够在微服务架构中充当中间层,路由请求并提供统一的认证机制。

这样下来,我们调用服务只需要直接走网关了,其它的服务端口也不用放行,极大程度上保证了数据的安全。此时,我们需要这样调用服务:

登录

curl --location 'http://127.0.0.1:8080/auth-service/auth' \
--header 'Content-Type: application/json' \
--data '{
"username": "user",
"password": "pass"
}'

服务调用

curl --location 'http://127.0.0.1:8080/document-service/documents' \
--header 'Authorization: xxx'

总结

之前微服务的开发中,可能我们借助Spring Cloud部分组件、Nacos,在项目中加上依赖配置,稍微改一下配置文件,服务就可以正常的调用了。其中依赖的SDK如何的工作,可能只是停留在理论上,缺少实操。这次的这个案例很好的展示Python+Nacos如何实现微服务,并从中细解微服务结构和服务之间的调用原理。是不是觉得Nacos其实也不过如此哈,没什么牛掰、独特之处,其实都是草台班子。

与shigen一起,每天不一样!

目录
相关文章
|
17天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
15天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
16天前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
35 1
服务架构的演进:从单体到微服务的探索之旅
|
14天前
|
消息中间件 监控 安全
后端架构演进:从单体到微服务####
在数字化转型的浪潮中,企业应用的后端架构经历了从传统单体架构到现代微服务架构的深刻变革。本文探讨了这一演进过程的背景、驱动力、关键技术及面临的挑战,揭示了如何通过微服务化实现系统的高可用性、扩展性和敏捷开发,同时指出了转型过程中需克服的服务拆分、数据管理、通信机制等难题,为读者提供了一个全面理解后端架构演变路径的视角。 ####
37 8
|
15天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
42 5
|
16天前
|
Kubernetes 负载均衡 Cloud Native
云原生架构下的微服务治理策略
随着云原生技术的不断成熟,微服务架构已成为现代应用开发的主流选择。本文探讨了在云原生环境下实施微服务治理的策略和方法,重点分析了服务发现、负载均衡、故障恢复和配置管理等关键技术点,以及如何利用Kubernetes等容器编排工具来优化微服务的部署和管理。文章旨在为开发者提供一套实用的微服务治理框架,帮助其在复杂的云环境中构建高效、可靠的分布式系统。
32 5
|
16天前
|
负载均衡 监控 Cloud Native
云原生架构下的微服务治理策略与实践####
在数字化转型浪潮中,企业纷纷拥抱云计算,而云原生架构作为其核心技术支撑,正引领着一场深刻的技术变革。本文聚焦于云原生环境下微服务架构的治理策略与实践,探讨如何通过精细化的服务管理、动态的流量调度、高效的故障恢复机制以及持续的监控优化,构建弹性、可靠且易于维护的分布式系统。我们将深入剖析微服务治理的核心要素,结合具体案例,揭示其在提升系统稳定性、扩展性和敏捷性方面的关键作用,为读者提供一套切实可行的云原生微服务治理指南。 ####
|
17天前
|
监控 持续交付 Docker
Docker 容器化部署在微服务架构中的应用有哪些?
Docker 容器化部署在微服务架构中的应用有哪些?
|
17天前
|
监控 持续交付 Docker
Docker容器化部署在微服务架构中的应用
Docker容器化部署在微服务架构中的应用
|
17天前
|
安全 持续交付 Docker
微服务架构和 Docker 容器化部署的优点是什么?
微服务架构和 Docker 容器化部署的优点是什么?