一、对于开发者来说, 他们一直面临的那些让人头疼的困难和问题, 竟然有可能被一个结合了多种技术优势的“混合框架”给打破局面吗?那些从事后端开发工作的人, 几乎所有人都曾经经历过那种让人感到无能为力的情形: 如果想要加快开发的节奏去选择使用Flask的话, 会发现性能方面不够充足如果想要追求高性能, 那么复杂的程度的话就会上升得更高。特别是当面对高并发请求这种情况的时候, 的性能够能不足的问题就像是一道障碍一样的存在, 大家只能在两个方向里面做选择, 一个方向是牺牲掉开发的效率来进行妥协, 另外一个方向是放弃转用Go或者Rust这两种语言, 在两难的情况下没办法的情况之下只能硬着头皮去扛下去。就在大家还在纠结那个叫做“鱼和熊掌不可兼得”的状况的时候, 有一款框架悄悄就变得非常流行了。这款框架的名字被省略了。它把另一个被省略的东西的简洁风格和Rust语言的性能揉在一起了。它声称在有GIL缺席这样的环境下面, 单个进程运行8倍数量的时候就能够很轻松地承受住一秒12亿次的请求这样的压力。这样一弄的话, 就直接碾压掉了Flask和另外一个被省略掉的东西。这真的是给开发人员带来好消息的完全肯定的事情, 他们总算是能够不用在提升开发速度以及提高程序性能这两个选项里面去只选择一个了, 可是如果静下心来仔细思考一下就会发现, 这个目前仍然处在早期试做实验那个阶段的技术框架, 它真的有这么神奇吗?它的这种同时结合了两种不同技术特点的特殊结构, 究竟算不算是真正的创新和打破常规的重大进步, 还是说这种宣传的效果比实际的应用效果要大得多而实用性却不足, 要知道在市场上存在太多非常多那种自己声称拥有非常高的性能表现的技术框架, 但是它们在最后往往都变成了完全没有多少人关注和使用的东西, 那么这款产品难道就一定能够成为那个特殊的例外情况吗。关键技术补充它是一款开源且免费的 Web 框架, 核心的底层代码是由 Rust 编写的, 而上面的上层部分又支持去编写各种业务逻辑, 当前这个工具已经在 PyPI 上线了, 对应的开源项目名称是 Slime。因为整个项目的状态还是处于早期阶段的实验期嘛, 所以那个地方的星标数量暂时还没有形成多大规模, 不过它现在已经具备了完整的基础功能, 正常用来进行 API 和后端服务的开发是完全没问题的, 各位开发者可以去免费下载下来使用, 也可以去贡献一下自己的代码。它的核心优势在于分工明确, 这个方式可以让 Rust 负责处理那些最消耗性能的网络请求, 然后让其他语言专注于简单并且容易编写的业务逻辑, 这样就完美的规避了性能上的短板, 同时也避开了 Rust 的开发复杂度问题。二、核心拆解到底是怎么工作的附实操代码这个项目的核心想法非常直白, 简单来说就是那句话: 要让Rust去做那些比较累的重型工作, 而让另一种东西去做那些比较轻松的轻型工作, 这样双方各自担任自己的角色, 互相补充对方的优势。它和那些传统的框架不一样, 传统的那些框架是全程都特别依靠运行环境的, 这个项目把最能影响性能的网络请求处理部分, 全权交给了Rust, 开发者方面, 他们就只需要使用自己已经习以为常的代码写法, 去把重要的业务逻辑编写好就可以了。核心架构拆解它的架构这个说法里面啊, 并没有那些特别复杂让人搞不懂的概念, 核心的要点基本上就是划分为两个部分, 整个逻辑梳理得是非常清楚地, 所以哪怕是刚刚入门的新手, 也能够在比较短的时间之内迅速地明白是怎么回事。1. Rust承担了那些非常吃资源的底层工作, 比如去处理网络上的请求、跑HTTP服务还有把模板渲染出来, 它就像是这个框架的骨架一样, 靠着Rust运行速度特别快的这个优点, 能够顶得住很多很多人同时访问的情况以及很大的负载压力, 把那些因为性能不够好而产生的麻烦问题解决掉了。2. 在业务实现方面, 开发者可以不用去学习Rust语言, 只须去编写接口逻辑、还有数据处理等等方面的这些属于业务的代码内容就行, 这种行为模式, 大体上就等同于是在构建一个框架里面的那些血肉组成部分, 这种做法, 它能够把那种简洁并且容易入门的上手优势给完整地保留下来, 由此就可以把开发的效率大幅度地提升上去。这种分工模式, 一方面避开了它本身的性能短板, 另一方面开发者也无需付出学习Rust的成本, 这基本上就是“花了一份精力, 就享有了两份优势”的状态, 而这也就是最让人吸引人的地方所在。当前支持的核心功能虽然这个状况还处于一个比较早的阶段, 但是它的功能已经变得非常齐全了, 能够涵盖绝大多数的后端开发出题目需要应对的场景, 具体所包括的内容如下所示:它支持处理器函数, 这样的话, 开发者就可以直接用代码来编写接口的相关逻辑了。该服务器是内置型的, 它使用的是由锈语言驱动的体系结构, 在性能表现方面大幅度超越了那些传统的框架。它支持那种有多个工作队列的模型, 可以让多核处理器的计算能力得到充分的利用。无论是同步处理器, 还是异步处理器, 都具备支持能力, 以此来适配不同的开发需求。它支持对表单数据进行提交操作, 它也支持文件的上传工作, 它还支持流式响应的处理功能, 它也支持签名的相关事项, 此外, 它还允许用户自定义设置请求头的内容。支持JSON数据格式, 还支持HTML网页代码, 同时也能支持原生响应方式, 这样就能实现模板渲染的效果, 还能把上下文信息给传递进去。•。它能够支持静态资源服务, 并且在开发模式下面对模板进行热重载, 从而使得开发体验得到提升。它具备支持功能, 能够应用状态管理, 实现数据压缩, 并且通过中间件插件来实现扩展操作。实操代码直接复制可用上手操作的难度非常低, 其语法结构跟Flask很接近, 新手人员也能够在短时间内掌握基本使用方法, 下面是属于最基础的入门级示例代码片段, 大家直接将其复制到本地环境中就可以立即执行。from slimeweb import Slime# 初始化Slime应用传入当前文件路径app Slime(__file__)# 定义路由GET请求路径为根目录app.route(path/, methodGET)def home(req, resp):# 返回纯文本响应return resp.plain(Hello World from slime)# 启动服务开启开发模式热重载if __name__ __main__:app.serve(devTrue)在运行完代码之后, 再去访问本地的服务器, 这样一来我们就能够看到“Hello World from slime”这个响应了。整个操作的过程和我们去使用Flask进行开发时的做法是完全没有区别的。虽然过程没有区别, 但是在性能上面却发生了质的提高。性能实测数据根据开发者在实际环境中进行的测试可以发现, 当使用的操作系统是Linux, 计算机配置包含8核心的中央处理器, 并且运行环境里面没有全局解释器锁的时候, 借助wrk这个压力测试工具来执行压测任务, 那个支持同步处理机制的程序框架的性能表现, 一下子就超越了的Flask以及其他的对比对象, 特别是在那些不存在全局解释器锁的运行条件下, 程序每秒能够处理的请求数量达到了120千次之多, 这一数据远远地超过了很多传统编程框架所能达到的性能上限状态。凭借如此出色的性能输出, 该方案完全有能力承担起中高并发场景下对于API接口开发以及后端系统服务运行的各项要求与负担。三、辩证分析的优势与短板看完再决定用不用这个情况是大家都能够看得到的, 就是说新技术的出现, 它确实给后端程序员在工作的时候提供了不一样的想法和办法, 而且它的长处是非常明显, 帮忙解决了很多程序员在工作当中遇到的让人头疼的问题。但是世界上没有哪一个开发工具是完全好的, 特别是在刚刚起步的那个阶段的技术体系, 肯定是有它自己的不足之处, 大家只有用公正客观的眼光去看待它的优点和缺点, 这样才能在工作中避免出问题。优势精准击中痛点性价比拉满它的核心优势, 就是准确解决了传统框架性能差的问题, 还有使用Rust进行开发比较困难的问题。这是为双重痛点做的精准回应。对于那些已经熟悉Rust的开发者来说, 他们不需要去学习新的编程语言。同样地, 那些对Rust还不熟悉的开发者们, 也就不用再去学习另外的新语言了。这样一来, 大家都能享受到使用Rust所带来的高运算速度和高效率的好处。而且整个开发过程中的工作效率, 完全没有受到任何影响或降低。这可以说, 是目前它拥有的最大的价值所在点。其次, 它的那个功能是非常全面的, 而且它也属于轻量级的产品, 它既没有出现那种臃肿的状态, 同时它还比Flask这个框架多了很多实用的功能, 使用者完全不需要去额外安装一大堆依赖包, 这样上手速度就快了, 部署起来也很简单, 所以它特别适合用来做API接口的快速开发, 也适合用来做小型的后端服务。与此同时它在没有GIL限制的环境下面, 性能表现得非常强劲爆发力是很足的, 这让它有能力去应对高并发的场景, 从而打破了大家原来认为它不适合高并发那个固有的想法。然而, 我们同样是需要进行一番思考的, 就是这样一种被大家称为混血的架构方式, 它难道就真的不存在什么让人担忧的隐患了吗?如果把核心的那些处理网络相关事情的工作全部交给Rust去干的话, 一旦就是在最底层出现了一些问题, 那么那些对于Rust并不熟悉的相关的开发人员, 他们就完全是没办法进行调试操作的, 这就有可能反过来导致了在后续的维护工作中产生更加高的成本负担。短板早期阶段仍有诸多局限目前来说, 这个项目还处在早期的试验阶段。这也是它存在的最为明显的不足之处。第一点原因是生态环境并没有得到充分的建设。当我们把它与Flask进行参照比较时能够发现它的第三方插件以及社区资源的数量是非常微小的。这就导致人们在遇到具体的技术问题时候很难寻找到应对的方案。这跟那些已经成熟的开发框架形成了鲜明对比因为成熟框架通常拥有极其丰富的教程资料并且具备庞大的社区支持体系。接着, 那个稳定性这个东西, 还得去验证一下。早期的那些版本, 多多少少都会有点毛病, 还会有性能上的起伏。虽然开发的人说, 能用, 也没问题, 但是在真正干活的地方, 特别是那种请求量大、要求不能停的那种环境里, 它的稳不稳定, 还得经过长时间的测试才知道。要是急着把它用到最重要的地方去, 可能会碰到一些没料到的麻烦事情。另外, 它还对环境有必须满足的一些条件。比方说, 它需要用禁用的方式处理GIL这个东西, 才能把性能发挥到最好的地步。但是, 如果这样去禁用GIL, 有可能会让一些库出现兼容性方面的问题。对于那些需要依靠特定库支撑的项目而言, 可能就没办法直接把它迁移过去这么一种情况是存在的。这就让人不得不去想一个问题了: 就是明明想要追求性能更好, 可却愿意付出牺牲部分兼容性和部分稳定性作为代价, 对于绝大多数做开发工作的人来说来说这个做法是不是真的具备足够的价值呢?四、这个现实意义的具体体现, 究竟能不能对后端所处的那些整体状况和力量对比关系, 产生那种可以称得上是改变的变动作用。这个框架的出现, 不只是说有了一个新产品问世。更关键的地方在于, 它提供了一种叫做 “Rust” 的混合方式的开发思路。这种思路给后端程序员的工作开辟了一条新的路径。从现实的角度来看, 它的实际意义远远超过了这个框架本身的价值。对于开发者来说, 它解决的问题是核心痛点, 这个痛点在于想要快速开发同时也想要高性能。尤其是对于小型的项目、还有创业的团队而言, 这种情况更是成立。他们能够用这种技术来快速迭代出产品。同时, 还能凭借 Rust 的性能来支撑业务的不断增长。在这样的情况下, 他们是不用在开发效率和性能这两个方面去做妥协的。因为这样就大幅地降低了开发成本, 也降低了技术门槛。就在这个生态系统里边存在的那种探索, 它打碎了那个性能并不怎么样的标签, 它还弄明白了并不是没有办法去用在并发数量特别高的一些场景里面, 要是把它和那些合适的底层支持给配合起来的话, 就能做到简洁以及好性能都同时具备这样一种状态, 这一种想法, 很有可能就会鼓动更加多的开发人员去进行那种混合架构的探寻, 并且会把这种生态变得更加的好。不过, 我们还是要保持一种非常清醒的认知状态, 因为指望能够把后面的那种整体态势给彻底改变掉, 这中间确实还有特别漫长的一段距离需要去跨越。就现在的实际情况来说, Flask这一个东西已经把主流市场给占住了, 它的那个生态环境是非常成熟的, 稳定下来的强度是挺高的, 而且底下还拥有一大批非常多的人数基础在里面。那么想要从这种局面里杀出一条路来脱颖而出, 那就必须得把自己身上的那些短处和缺点给好好解决了才行, 接着再把那个配套的功能环境完善好, 然后把整体的稳定性再往上提一提, 只有把这些事情都做完了, 才有可能赢得后面那群写程序的人更多的承认和看得起。毕竟, 开发者在挑选框架的时候, 不仅仅要看性能和开发的效率, 更看重生态和稳定性, 特别是在生产环境里面, “稳定并且可以使用”远比“性能非常突出”更重要一些。那么在未来, 凭借自己独特的优势, 有能力去动摇 Flask 和那个位置吗?五、互动话题你会用替代Flask/吗当看到了这个地方之后, 可以相信许多开发者的心里都已经产生了心动的想法了。因为他们既不需要去专门学习任何一门新的编程语言, 同时还可以收获到非常出色的性能表现。所以这个框架在各方面看起来都非常像是为了我们这些具体的使用者而进行单独设计和定制的专用工具。可是, 在进行了一系列的心跳加速之后。也难免会引发一些心里面的担忧和疑虑。主要的原因就是因为当前的这个项目整体还停留在比较早期的开发阶段之内。因此它的安全性保障以及周边的生态建设情况等等一系列要素方面。都还存在有必须继续加以完善和提升的必要空间。你可以来讲讲你自己的观点。你此刻正在使用的是什么类型的Web框架? 是因为Flask有着简洁的结构以及比较高的运行性能, 还是因为其他的一些框架特点? 采用Rust作为底层支持的这种混合开发模式, 是否真正吸引了你的注意力?在后续的软件开发工作中, 你会不介意冒险去尝试用新技术来进行项目构建吗, 还是会倾向于更加保守的等待态度, 直到该技术生态彻底成熟之后再决定正式投入应用。此外, 要是你本身就已经进行过体验的话, 那么就请你在评论的那个位置上把你的使用过的真实感受给分享出来, 去详细描述一下它在实际运行时的性能状况到底是一个什么样的水平, 再去讲讲看自己在使用的过程当中有没有遭遇过什么比较麻烦的坑或者障碍, 目的是为了帮助其他的开发者朋友们能够避开这些已经存在的陷阱和困难, 通过这种一起互相进行交流与深入探讨的方式, 最终才能实现让我们各位在接下来的开发工作道路上面尽可能少地走一些不必要的弯路这一良好结果。