1.python微服务框架排行榜
2.开源推荐：.NET 6 + Abp框架一个轻量级微服务库
3.JeecgBoot商业版源码下载
4.一文读懂PaaS、微服务平FaaS，台网运行微服务应该选择哪个？
python微服务框架排行榜
1、站源Django
Django是码微一个开放源代码的Web应用框架，由Python写成。服务采用了MTV的平台火影世界源码出售框架模式，即模型M，开源模板T和视图V。微服务平它最初是台网被开发来用于管理劳伦斯出版集团旗下的一些以新闻内容为主的网站的，即是站源CMS(内容管理系统)软件。
Django与其他框架比较，码微它有个比较独特的服务特性，支持orm，平台将数据库的开源操作封装成为python，对于需要适用多种数据库的微服务平应用来说是个比较好的特性。不过这种特性，已经有其他库完成了，sqlalchemy.
2 、Flask
Flask是一个使用 Python 编写的轻量级 Web 应用框架。其 WSGI 工具箱采用 Werkzeug ，模板引擎则使用 Jinja2 。Flask使用 BSD 授权。易卡发卡源码
Flask也被称为 “microframework” ，因为它使用简单的核心，用 extension 增加其他功能。Flask没有默认使用的数据库、窗体验证工具。
Flask 很轻，花很少的成本就能够开发一个简单的网站。非常适合初学者学习。Flask 框架学会以后，可以考虑学习插件的使用。例如使用 WTForm + Flask-WTForm 来验证表单数据，用 SQLAlchemy + Flask-SQLAlchemy 来对你的数据库进行控制。
3 、Tornado
Tornado是一种 Web 服务器软件的开源版本。Tornado 和现在的主流 Web 服务器框架(包括大多数 Python 的框架)有着明显的区别：它是非阻塞式服务器，而且速度相当快。
得利于其 非阻塞的方式和对epoll的运用，Tornado 每秒可以处理数以千计的连接，因此 Tornado 是实时 Web 服务的一个 理想框架。不过现在与众多的框架比较，Tornado已经被抛在了后面，mac烧写源码Django已经超过了它，更不说其他框架了，只能说Tornado使用纯python开发的性能还是不能与其他框架借助于cython开发的性能相比。
开源推荐：.NET 6 + Abp框架一个轻量级微服务库
介绍
轻量级微服务库，基于.NET 6 + Abp框架，帮助快速转化现有项目为面向服务体系结构，实现模块间的松耦合。此库借力于RabbitCloud与jimu项目，集其精华。
特点与实现
快速启动网关（客户端）GatewaySample，仅需调整Startup.cs文件，将AddAbp替换为AddSoaClient，同时删去UseAbp与UseSoaClient。
GatewaySampleWebHostModule.cs文件中，增加SoaClientModule模块依赖。
在网关中整合各微服务抽象层、权限与本地化资源，实现服务间的无缝对接。
微服务（服务端）Service1，通过修改Program.cs与Service1HostModel.cs文件，添加SoaServerModule模块依赖，c 安装步骤 源码构建Service1Manager类并实现IService1Manager接口。
配置细节请参阅配置说明与定时任务文档，完整示例在Sample项目中。
开发工具与资源
利用Roslyn Syntax Tool辅助开发，项目源码位于GitHub上的MatoApps/Soa库。
项目转自林晓lx的博客，详情请访问链接：cnblogs.com/jevonsflash。
JeecgBoot商业版源码下载
JeecgBoot是一款低代码平台，基于SpringBoot2.x、SpringCloud、Ant Design & Vue、Mybatis-plus、Shiro、JWT等技术，支持微服务架构。通过强大的代码生成器，一键生成前后端代码，助力快速提高开发效率，节省成本，并保持代码灵活性。该平台引领低代码开发模式，源码时代和黑马涵盖OnlineCoding、代码生成及手工MERGE，适用于Java项目，解决%的重复工作，使开发团队更多关注业务逻辑。
JeecgBoot开源项目不仅功能强大，还提供了全面的技术文档支持，便于开发者快速上手。选择JeecgBoot的原因在于其超越传统商业平台，结合低代码开发与灵活编码的优势，提高开发效率，降低开发成本，同时保持代码的灵活性和可定制性。
JeecgBoot平台拥有丰富的功能模块，包括但不限于数据管理、权限管理、任务调度、工作流、报表、大屏展示等功能。这些模块覆盖了开发过程中的关键需求，满足不同类型业务场景的需求。
项目提供了丰富的系统截图，直观展示了PC端、手机端、PAD端的界面风格与功能实现，以及报表效果和大屏效果。这些直观展示有助于开发者和用户快速理解平台的使用方法和应用场景。
如果您有任何疑问或建议，欢迎在项目页面进行反馈。同时，欢迎给项目star以支持和鼓励开发团队的持续努力。
一文读懂PaaS、FaaS，运行微服务应该选择哪个？
大家好，我是小碗汤，今天分享一篇PaaS vs FaaS的对比选择，欢迎兄弟们留言讨论~
我们都知道微服务是分布式进程，必须独立发布、部署和扩展。乍一看，平台即服务(PaaS)和函数即服务(FaaS)，又称无服务器。这两种云计算模型也能够在软件开发过程中，提供非常短的交付时间，从而促进创新和持续研究。
然而，当深入研究它们的技术细节时，会很快意识到它们并不总是适用在相同的场景。
PaaS
Platform-as-a-Service(平台即服务)是一种云模型，你提供源代码，平台将打包、发布、供给、部署、运行、监控和扩缩微服务。我能想到的最好的例子是Cloud Foundry， Heroku和谷歌 App Engine。
你的应用程序在 PaaS 上至少有一个实例在运行。当需要通过SSE (Server-Sent-Events)、Websockets或RSocket实现通知推送时，这很方便。还有很多其他的好处，例如：及时处理传入的请求，在内存中保存数据(也称为进程内数据缓存)，实现断路器模式处理部分故障，或者利用连接池来调节工作负载和减少响应时间。
FaaS
Function-as-a-Service(函数即服务)指的是计算模型，在这个模型中，你的代码将被平台打包，并作为一些可配置事件(如 HTTP 请求、消息到达、文件上传)的结果，在有限时间内按需运行，之后可能随时被处理。这里的优秀代表有AWS Lambda， Azure 函数和谷歌云函数。
我们可以用大量的functions来组装应用程序，但每个functions需要单独配置和部署。这就是为什么FaaS有时被称为纳米服务。
考虑下面的图表，比较了使用无服务器框架(Lambda + API 网关)实现的项目和使用纯 Node.js 实现的项目之间的代码行。对于添加到软件系统中的每一个重要的功能，当使用无服务器架构时，维护项目所需的配置代码行数将以陡峭的线性速度增长。简而言之，从短期来看，无服务器架构的前景似乎不容乐观。
经验
我已经看到一些同事和公司倡导将FaaS作为一种方法，以避免构建和维护大量容器镜像以及跨各种环境协调的痛苦。
我非常同意将管理基础设施的负担，从开发人员身上抽象出来的想法。然而，我们已经看到 PaaS 和 FaaS 都能够代表开发人员处理无差别的繁重工作，包括打包、部署和自动伸缩应用程序，以及管理安全、路由和日志聚合。
没有必要仅仅为了避免大规模运行容器所带来的复杂性而采用 FaaS
如果您的目标仅仅是提高开发人员的体验，那么您可能会发现，与 FaaS 相比，PaaS 以更低的复杂性和更少的侵入性来满足需求。我相信这一理念是数字平台模式越来越多人采用的原因。
数字平台是自助服务 API、工具、服务、知识和支持的基础，是一个引人注目的内部产品。自主交付团队可以利用平台以更快的速度交付产品特性，减少协调。
总结
现在炒作 Serverless 似乎接近尾声，可以查看为何 Serverless 停滞不前和Serverless 未实现的潜力
我认为，每一种模式都有各自的优点和缺点。在将我们的工作负载迁移到云上时，似乎总是没有万能的解决方案。混合的方法可能会帮助我们获得最好的结果。
我目前的立场是:
所以您在做决定之前先考虑自己的需求和环境，无论跟风或是什么原因，甚至可以做一些体验，这是这两种云计算模型提供的最大好处之一。
