Python 为什么到现在也没有像 springcloud eureka 这样的微服务框架？怎样构架 Python 的微服务框架呢？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

推荐学习书目

› Learn Python the Hard Way

Python Sites

› PyPI - Python Package Index

› http://diveintopython.org/toc/index.html

› Pocoo

值得关注的项目

› PyPy

› Celery

› Jinja2

› Read the Docs

› gevent

› pyenv

› virtualenv

› Stackless Python

› Beautiful Soup

› 结巴中文分词

› Green Unicorn

› Sentry

› Shovel

› Pyflakes

› pytest

Python 编程

› pep8 Checker

Styles

› PEP 8

› Google Python Style Guide

› Code Style from The Hitchhiker's Guide

这是一个创建于 1957 天前的主题，其中的信息可能已经有所发展或是发生改变。

Python 的微服务都是要手动组装吗？ Python 微服务框架的最佳实践应该怎样构架呢？

Python

框架

构架

服务

20 条回复 • 2019-08-20 15:57:40 +08:00

lhx2008

2019-08-18 09:21:35 +08:00 via Android

K8S 全家桶欢迎你，不够强大还有 service mesh。eruka，zipkin 也是可以整合的

artandlol

2019-08-18 09:37:33 +08:00 via Android

py 的优势在机器学习，线上的微服务还是 Java，golang 的为主。

stanjia

2019-08-18 09:52:23 +08:00

py 的优势在于　 C 语法风格的 bash

Huelse

2019-08-18 10:02:21 +08:00

python 是计算密集型，java 这些是 io 密集型

微服务等很显然首选 io 啊

ipwx

2019-08-18 10:45:02 +08:00

除了企业开发程序员大多以 Java 和 Golang 为第一语言这个因素外，可能还因为 Python <3.5 没有内置 IO 密集的解决策略。2.7 时代只有一个巨难写的 Tornado。3.5+ 才加入了 asyncio，所以没有微服务框架也正常。

est

2019-08-18 12:06:58 +08:00

@ipwx
@Huelse

gevent 路过。。。

hhh798

2019-08-18 12:25:42 +08:00

有 Java 和 go，谁用 Python 呀，nodejs 都比 Python 强，就 Python 运维用用，培训班上课用用得了，还想啥呀

caqiko

2019-08-18 12:41:00 +08:00 via Android

个人感觉，py 太不适合作为工程语言了。

作为原型语言，胶水语言倒是很合适。

iPhoneXI

2019-08-18 12:47:40 +08:00 via Android

@nioncodotcom node js 除了写前段脚手架，还有人用吗

leishi1313

2019-08-18 13:17:20 +08:00 via Android

我寻思我用 Python 写 rest api 也可以是微服务啊，微服务只是个概念，达到业务分离的作用就够称为是微服务了，框架和语言都不是重点。
然后每次一探微服务就提 spring 的我就给他甩这个链接 github.com/GoogleCloudPlatform/microservices-demo

hantsy

2019-08-18 13:36:34 +08:00

Spring Cloud==> Microservice 1.0 国内开发人员依赖 Spring 太厉害了。
K8s ===> Microservice 2.0 现在容器编排几乎是 K8s 一家独大。

以前一个海外项目，Spring Cloud 开始有雏形（主要是集成 Netflix 那一套）的时候就开始试用（当然我们会写 POC 进行比较），结果我们放弃了几乎所有的 Spring Cloud 项目（除了日志跟踪），当时我们认为最大的问题，它将运维的一些东西全部集成到代码，性能上成问题，而且后期运维，扩展非常不方便。像 Service Discovery，Config，Load Balance，Circuit Breaker 这些可以说用容器方便的得多，将这些打包进 Service，本身就违背 Microservice 的初忠。每个 Service 本身就是应该集成在解决业务问题，对于用什么技术并不重要。