gogrpc异步_搜狗workflow异步调度框架基本介绍篇

我们的项目于两天前开源啦&＃61;>w<&＃61;

目前文档、开源管理及其他方面都在摸索推进中&＃xff0c;我也按捺不住想要以开发者之一的名义&＃xff0c;写一系列个人博客&＃xff0c;让大家可以从方方面面了解到workflow的全部信息&＃xff5e;最官方的更新还是要以github为准&＃xff0c;欢迎大家关注我们的项目&＃xff0c;尝试使用并提出宝贵意见&＃xff1a;

项目主页的README里已经有非常详细的介绍了&＃xff0c;这里我来补充一些基本信息。本系列其他文章链接也会持续更新到这里&＃xff1a;

搜狗workflow异步调度框架 - 架构设计篇
搜狗workflow异步调度框架 - 性能优化上篇

一、 使用情况

Workflow在首席架构师谢爷带领我们三人小团队经历过一年多的打磨&＃xff0c;目前已经在搜狗公司内部广泛使用&＃xff0c;可以说是公司的后端C&＃43;&＃43;编程标准。搜狐集团也有其他兄弟团队在使用&＃xff0c;整体超过20多个团队&＃xff08;Q1的数字&＃xff09;用以重构&＃xff0c;基本性能提升好几倍&＃xff0c;轻松把cpu吃满&＃xff0c;也在搜狐集团2019年的1024极客项目评比中夺冠&＃xff0c;一路以来能够被认可真的是一件非常振奋人心的事情。

开源对我们来说只是刚刚开始&＃xff0c;这是一条充满挑战的道路。虽然我们team人很少&＃xff0c;但先前已经有越来越多的小伙伴参与到一起开发&＃xff0c;而且使用workflow的开发小伙伴也都提出非常宝贵的建议和为我们发现了很多问题。因此非常期待亮相于github的workflow未来可以拥有更多的可能性。

感慨完毕&＃xff0c;说回正题&＃xff5e;在公司内部容易被用户接纳和使用&＃xff0c;我认为得益于以下几个优点&＃xff1a;

1.1 极其优异的性能

我们这里说的性能&＃xff0c;不是单指如何跑满cpu、如何单独地让网络请求极速响应、或者说如何异步操作文件或其他设备&＃xff0c;而是所有这些资源都可以被其具体的调度器管理&＃xff0c;尽可能地全部都调度起来。

由于workflow是个框架&＃xff0c;除非是具体业务场景的前后对比否则很难给出benchmark&＃xff0c;因此具体业务报告不便透露。比较通用的一些测试结果可供大家参考&＃xff1a;

我们用基于workflow开发的Sogou RPC做了与brpc和thrift的吞吐和长尾benchmark&＃xff0c;大家可以参考这里&＃xff1a;Sogou RPC Benchmark&＃xff1b;

作为web server性能自然比nginx要好&＃xff0c;可以参考我先前的一篇用以改造异步调度QAT加速卡的小伙伴的测试&＃xff0c;还没细优化&＃xff0c;随便看看&＃xff1a;OpenSSL异步模式与Intel QAT加速卡(四) 新一代异步调度框架workflow&＃xff1b;

谢爷的习惯是喜欢把东西做到最简洁、把性能做到最极致&＃xff0c;因此项目对性能的每一个细节都不会马虎&＃xff0c;本人受益匪浅。但是我们团队接触开源比较少&＃xff0c;因此我个人非常希望能在性能优化方面学习到更多优秀的做法。

1.2 比其他C&＃43;&＃43;框架更友好的用户体验

我们给开发者用户接触到的是task&＃xff08;任务&＃xff09;和series&＃xff08;任务流&＃xff09;&＃xff1a;

• task由工厂创建、自行销毁&＃xff1b;
• series可以手动从工厂创建或者自动创建&＃xff0c;也是自行销毁。

用户再也接触不到连接池、线程池、包括想要做aio时的文件fd与各种异步通知机制。

从语言的发展来看&＃xff0c;go的出现与被喜爱是必然的&＃xff0c;原因之一就是天下苦C&＃43;&＃43;久矣&＃xff0c;而go的封装很高级很简约。虽然C&＃43;&＃43;后续也推出了各种新用法&＃xff0c;但不是所有用户都会升到更高的标准&＃xff0c;目前workflow的标准是C&＃43;&＃43;11。

而任务和任务流的概念在理解和易用性上简直甩开事件机制和用循环来做多次进入的开发模式十条街(后面这种模式我也不是想得很明白&＃xff0c;但发现OpenSSL的异步和grpc的异步server都是这种方式&＃xff09;。

关于aio的异步机制&＃xff0c;这里有一篇做mac的aio模块时对aio各种异步通知机制的拙见&＃xff0c;感兴趣的小伙伴可以看看&＃xff0c;并且欢迎给我指出错误&＃xff1a;异步I/O -- posix aio 从入门到放弃的吐血实践。

1.3 通信计算资源融为一体的解决方案

我们特别适用于重计算&＃xff0c;而搜索的绝大部分使用场景都是重计算的server&＃xff0c;而网络和计算都可以用workflow一并解决。

workflow认为一切资源都是可以异步调度的&＃xff0c;因此对于目前支持对接的资源&＃xff0c;我鶸鶸地归纳对比了如下表格&＃xff1a;

计算这里详细说一下&＃xff0c;原先检索模块开发小伙伴常常面临选择高吞吐网络框架的同时&＃xff0c;自己需要面对不同计算资源比例而划分不同大小的线程池。

然而每种计算具体资源需求比例是动态变化的&＃xff0c;重要性也不一样&＃xff0c;后端响应时长也是动态变动&＃xff0c;如果我们在初始化的时候创建若干个特定大小的线程池&＃xff0c;线程资源难以共用。

go内部的go routine调度就是用来解决这种事情的。那么C&＃43;&＃43;来说&＃xff0c;现在workflow可以和go一样解决全局计算资源共享和按需调度的需求了&＃xff0c;并且打通网络、磁盘等等其他资源。

1.4 代码架构层次良好&＃xff0c;易于拼装&＃xff0c;实现二次开发

workflow的世界里有三个原则&＃xff1a;

• 串行是由任务组成的
• 并行是由串行组成的
• 并行是一种任务

于是乎&＃xff0c;workflow是一套完备的、可以收敛一切循环和控制的任务流模型。

以下是我的一些个人解读&＃xff1a;

1. 由于可以串行&＃xff0c;我们就可以动态建流图&＃xff0c;并且无限执行下去&＃xff1b;
2. 由于可以并行&＃xff0c;并行的是各个串行流&＃xff0c;我们可以对多个并发执行的流在完成时做收敛&＃xff1b;
3. 并行本身是一种任务&＃xff0c;因此可以加到串行流图里&＃xff0c;即每个任务都可以是一个复合任务组装而成&＃xff0c;组装后提供给其他使用者使用&＃xff0c;而使用者不需要关心复合任务内部细节&＃xff0c;进一步组装。

当然workflow的其他优点很多&＃xff0c;这些是公司内部使用情况的一些总结&＃xff0c;其他的会陆续给大家介绍&＃xff5e;今天其他点也不太写得完了&＃xff0c;这里列个大概&＃xff0c;后续会更新哦&＃xff5e;

二、 workflow的定位与架构设计

搜狗workflow异步调度框架 - 架构设计篇

三、 性能优化的几点考虑

搜狗workflow异步调度框架 - 性能优化上篇

四、 workflow对资源的理解

五、 workflow对协议和算法的理解

六、 workflow对串并行任务的理解