Flag Boot：基于范畴论的新一代极简开源微服务框架

Flag Boot：基于范畴论的新一代极简开源微服务框架2022 年 11 月，智源北京人工智能研究院开源了 Flag Boot。Flag Boot 是一个基于 Scala 开发的轻量级的高并发微服务框架，为类型安全、服务治理等常见问题，给出了简洁且可扩展性强的解决方案。同时，它使用了基于范畴论的 Cats/Cats_Effect 等框架，针对抽象代数运算有天然支持。

本期直播，InfoQ《极客有约》邀请到了清华大学交叉信息研究院助理教授袁洋和博士生杨景钦来给我们分享 Flag Boot 开源的二三事。

以下为对话全文，经编辑。

InfoQ：首先有请两位嘉宾老师做一下自我介绍。

袁洋：我在清华交叉信息研究院主要研究的方向是智能医疗，关注的主要是人工智能的可解释性，同时也在做人工智能的理论研究。

杨景钦：我是清华大学交叉信息研究院博士二年级学生。现在研究的方向和袁老师一样。

InfoQ：本期直播的主题围绕 Flag Boot 项目来进行，请两位老师详细介绍一下 Flag Boot 是一个什么样的项目？

杨景钦：Flag Boot 是一个基于 Scala 开发的轻量级、高并发的微服务框架，为类型安全、服务治理等问题，给出了一些简单、可扩展性非常强的方案，并且它使用了基于范畴论的框架，如 Cats/Cats Effect 等，针对抽象代数运算有着天然的支持。

袁洋：最初我们的研究方向和做 Flag Boot 这样的开源框架没有太大的关系。我到清华半年左右的时候，和杨景钦就开始着手来做智慧医疗项目，这是一个很大的项目，我们较长远的目标是做人工智能辅助诊断系统。之前也有很多不同的团队探索过人工智能辅助诊断系统，比较有名的是 IBM 的沃森医生，但并没有获得最后的成功，所以我们当时也在想怎么才能把这个项目做好。

“工欲善其事，必先利其器”，我们认为一定要把基础的工具搭好。如果要把辅助诊断系统做好，就需要把医疗就诊全流程中的各个环节都打通，并描述清楚。我们最终选择并学习了 Scala 语言，以 Scala 语言作为底层支撑，来更好地描述整个过程。因为 Scala 语言虽然在国内了解的朋友不是很多，但它相对于 Java 或者其他语言而言，对程序员理论有更好的支持，所以它非常适合搭建一些很大型的系统。其实从它名字上也可以看出来，Scala 其实是 Scalable 的简称。

做了两年多之后，我们积累了相当多的经验。之前我们主要用的是 Akka，在 Scala 社区也是非常流行的。但后来我们发现这里面有一些问题。主要是，我们在做的是辅助诊断系统，需要把医疗诊断的全流程以一种较偏数学、偏理论的方式刻画出来，这就是为什么我们后来接触到范畴论，因为范畴论是做这件事的一个很好的工具。但是我们发现 Akka 整个生态体系来做范畴论不是很方便。

我和杨景钦最后发现 Cats/Cats Effect 之类的比较适合做这件事。Cat 是 Category 的缩写，其实是一个双关语，既代表猫也代表范畴论。所以我们就想把这两个包拿过来做底层支撑，之后又发现虽然这两个包很好，但是并没有一个很好的框架能够和包有比较好的无缝贴合，相当于有工具，但还没有使用工具的环境。所以我们就想为 Cats/Cats Effect 做一个比较好的环境，既可以给我们的团队用，也可以给 Scala 的爱好者用。这就是我们想做 Flag Boot 的原因。

InfoQ：Flag Boot 项目大概有多少人参与，2022 年这个项目的侧重点在哪些方面？

袁洋：我们的项目最初是清华里面的一个科研项目，主要是我组里的学生在参与。去年 9 月份我们开始和智源合作，有一些全职的工程师参与到里面。现在我们整个团队在智源大约有十几个人，包括前后端工程师、产品经理等，主要做辅助诊断系统这方面的具体实践之类的。后端做 Flag Boot 这方面代码的，加上我的学生一共是 5 个人。

InfoQ：Flag Boot 项目在研发过程中，发生过什么有意思的小故事可以分享下？

杨景钦：我说一个个人的事情。我是以写 C++ 出身的，很早之前打过一些算法竞赛，拿过一些奖，在刚开始接触微服务架构的时候，就不可避免地需要用到 Java 和 Scala。但是最初因为各种各样的原因，我认为这两个语言和 C++ 很相似，并没有觉得里边有什么很值得我去细细看的一些内容，等遇到不会的再去查，看一下怎么把基于 C++ 的想法翻译成 Scala 或者 Java 的代码就可以了。

后来发生一件事情，我们在早期做测试时，在代码里边会有一些对 type 的变量，我们发现当对一些 type 的变量进行改动之后，整个代码编译出来的结果可能不会有任何变化，因为它编译里面的东西可能和 type 根本没有关系。但仅从运行情况来看，它最后出的错看上去非常普通，就好像是我的代码在什么地方写错了一样，调了非常久都完全不知道错在了哪里。最后查了很多才发现这种 type 其实在 Java 里面叫类型擦除，它在打完包之后类型就没有了，相当于代码没有任何问题，只是在编译的时候，中间进行了一些奇怪的优化，才导致了这样的结果。

通过这件事我才真正感觉 Java、Scala 这种语言，和 C++ 有着本质的区别。所以后来就花了更多的精力去研究这两种语言，它们在类型上面到底做了什么样的事情，最后才对类型安全有了一个更深的了解，并且可以去做一些设计。

袁洋：我之前是做机器学习理论算法设计的，也做过竞赛，回国之后我决定要做智能医疗，即使用几年时间，也要把一个比较大的、复杂的系统搞出来，但我之前并没有太多搞复杂系统的经验。

后来在读博士以及博士后期间，除了发论文，有一段时间是用 Scala 来做一些系统、软件，但真正开始搭系统是最近这三年时间，期间我也是不断去摸索。因为我以前不是做 system 的，所以更多的是从理论角度来想事情，比如要实现某个功能，我会把它看作一个函数，它的输入是什么，输出是什么，函数作用是什么。基于这个角度，我想到了需要先把整个系统要处理的各类数据的类型先定义清楚，然后再定义每个数据从 a 到 b 应该经历哪些。

这个过程很漫长，在这个过程中我慢慢意识到了函数式编程和程序语言理论的重要性，之后整个团队也开始研究程序语言理论。过程中我发现程序语言理论好像是基于范畴论的，其实我以前根本没学过范畴论，但是在做系统时发现必须要了解范畴论的内容，有些事情才可以往前推。

但在这个过程中不断出现一些问题，我在解决时发现有些问题应该用范畴论的思想去解决，有些问题应该用程序语言的思想去解决。反过来，范畴论的很多想法又可以帮助我更好地去理解人工智能理论里面的一些问题。

Flag Boot 相当于是我们这两年探索的一个小成果，虽然它比较简单，但是对我们来说其实是件很不错的事情。而且在暑假的时候，我在清华给姚班的同学开了一门前后端系统设计的课程，杨景钦是我们的课程助教。在这个过程中我发现同学们接受起来很快，于是让同学们从 0-1，用三个礼拜做了一个功能很完备的健康宝。

InfoQ：Flag Boot 是什么时候开源的？

袁洋：在智源的 Flag 生态系统里面，它大概是 2022 年 11 月初开源的，但我们没有宣传，所以大家可能并不知道。我们做了一些测试，有很多人问我们是不是要对标 Spring Boot，答案是 Spring Boot 的生态做得非常好，而且做了很多年，有很多 Java 程序员的支持，所以我们肯定无法和那么大的生态去比较。但如果你是 Scala 的爱好者或者初学者，想要用 Scala 来做一些比较有趣的应用，可能比较适合用我们这个框架。或者想要做一个稍微大一点的项目，想选一个好的架构，我认为 Scala 比 Java 要精简、优美很多，而且可扩展性很强。

InfoQ：Flag Boot 的整体架构，以及迭代更新的情况如何？

杨景钦：现在它是一个很轻量级的代码，在非常少的代码函数下，整体架构要做的事也就比较简单，比如每一个服务向外暴露了一些接口，我们对接口有一个统一的控制，统一去收发。之后内部对于多个同时接入的请求，有一个异步控制器，相当于只有一个 API 进来，然后我们在内部把它处理掉，在处理的时候可能需要用到服务治理以及和数据库进行一些比较方便的连接等之类的其他模块。

目前的框架迭代有三次比较大的更新。第一次，我们最初用的是 Akka 做了最早的一个版本，然后在袁老师的强烈建议下，引入了范畴，这是一次整体的重构。后来因为我们已经引入了范畴，就可以拥抱更近一点的框架，然后我们把 Akka 从里边拿掉了，这是第二次。最后一次是对接口的管理，以及服务治理等这种模块，做了一次比较大的优化。

袁洋：从架构上来说，我们是一个很简单的架构，整个框架并不大，代码行数大概 3000 多行，可以从头到尾看清楚所有的东西是怎么做的。因为 Scala 比较简单，比如实现同一个功能，用 Java 写需要的代码行数可能是 Scala 的三倍。

另外，我们微服务框架的不同之处在于，里面用了很多范畴的概念，其中有一个叫 Monad。简单来讲 Monad 是个盒子，里面可以装各种各样的东西，可以把它看成类似于薛定谔装猫的盒子一样。如果没有 Monad，很多时候会不受控制，比如一个 Spring Boot 框架，或者其他微服务框架，当一个请求进来时，就需要处理这个请求，然后又会接二连三触发更多请求，不能完全受控制。

我们是这样处理的，我们整个框架用到范畴论，也用了基于 Cats Effect 里面的一个叫做 Monix.Task 的包，所谓的 Task 就是一个盒子，来了一个请求之后，我先不处理请求，而是先把请求装到盒子里。比如想知道 user 的名字是什么，来了一个 API 请求，我不会去看数据库，而是先把它装到盒子里，然后再看如果要处理这个请求，下一步应该做什么。比如应该去和数据库沟通，或者应该进行一些简单的预算，暂时也先不去做这些事，而是再用另外一个盒子把要做的事记下来，只有当盒子全部定义清楚之后，再返回去开始运行。

这样做的好处在于，可以有更好的调度策略，所有的事情都在控制之下，不至于来了 API 之后手忙脚乱。得益于这些优化，从效率上来看，我们比 Spring Boot 快很多。

InfoQ：Flag Boot 针对类型安全、服务治理存在的问题，提出了简洁且可扩展的解决方案。您能详细讲讲，以往在类型安全、服务治理等方面存在哪些问题呢？

杨景钦：并不是说原来的模式有很大的问题，服务治理还好，只是原来可能在微服务中要做类型安全会比较麻烦。类型安全的作用是，在编译的时候发现绝大部分的潜藏问题，做得越好在编译的时候就能够发现更多的可能会出现的 bug，并且能够提前优化掉在上线之后才发现的 bug。

另外，也并不是说类型安全有多麻烦或者说做不了，只是它现在做的东西不是特别简洁。举例来说，对于一个 API，在调用的时候，正常情况下它需要返回的是某一个特定类型的返回值。当某一个服务的 API 的返回类型，出于一些原因比如没有设计好或者其他原因，发生变化的话，我们希望能够去提醒其他所有的服务，对它的处理就应该有变化，比如你把字符串当成 double 去处理肯定是不对的。我们的框架就能够比较方便地去做到这一点。

总结来说，我们的 Type Safe 在做的事情是，当某一个服务比如它的 API 接口有变化，其他所有使用的 API 服务在编译的时候就会发现这是有问题的，类型会有变化，然后在编译的时候会针对一些很危险的操作给出警告。

袁洋：杨景钦主要说的是从实现上面，它很多东西可以更简洁、更方便，但是 Java 也是一个强类型的语言，所以 Java 也可以做，只是可能稍微复杂、麻烦一点。我从另外一个角度来给大家分享一下我们框架的好处。

我很早就接触了 Scala，大概是在博士二年级，我 2014、2015 年去推特实习的时候，推特全用 Scala，当时我觉得 Scala 并没有什么用处，用 C++ 和 Java 就足矣。在去年的暑假我在上前后端类型安全系统实践课时，我迫使同学们必须要用 Scala，告诉大家类型安全很重要，做任何东西都必须用类型安全方式来做，让同学们做一个很复杂的类型出来。后来发现虽然他们整个应用做得非常漂亮，该有的功能都有，但确实他们很少用到我觉得比较好的一个复杂类型，他们认为地址不用 string 表示，用 address 来表示，就叫类型安全。

后来我进行了反思，当在进行一些相对比较简单的应用时，有可能不会对类型安全给自己带来的帮助有非常深的感触。因为我们在做的辅助诊断系统是一个很复杂，相对比较大的系统，这个时候就会感受到类型安全的重要性，它能够给整个系统提供很好的支撑。

另外一个是范畴论。范畴论描述了 Mathematical Structures，是来刻画一些数学的 Object 彼此之间的关系的。比如一个人生病了，其实这里面包含很多信息，例如病因是什么，进行了哪些治疗，有哪些地方不舒服，先后关系是什么以及历史记录等等。现在我们去看医生，大部分医生是用电脑写病历，虽然是电子化了，但并不是形式化。就算是形式化，部分医院的电子系统往往也只是把这些条目并排放在一起，并没有把这些信息以很好的结构化的方式连在一起。如果没有连在一起，让机器学习去学就很难把它学得非常好，很多数据或者信息就会被浪费掉。

而我们提的框架现在大家不一定能够马上看出来，因为可能还没有这样的需求，但是至少我们团队有这个需求，对于一个非常复杂的东西，内在有很复杂的结构时，也许用范畴论，用 Scala、Cats/Cats Effect 效果会比较好。

InfoQ：Flag Boot 对于其他语言爱好者怎么容易地去使用？

杨景钦：我们现在只提供了 Scala 的 API，所以目前这个阶段如果需要使用，确实需要具备 Scala 最基本的语法知识才可以。当然有一个好处是我们的门槛比较低，只要知道 Scala 最基本的知识，能把 Scala 用到和 C++ 差不多的程度，就可以用 Flag Boot 框架去做很多事情。我们后面也计划提供 Java 的 API 之类的，只不过可能还需要一段时间。

袁洋：我们去年暑期上课的同学是刚刚升大二的本科生，他们有一半之前没有搞过竞赛，有的都没有写过代码，我是第一个礼拜给他们上三堂课，讲一下这个东西要怎么做，然后杨景钦给一个样例，让他们三个人组队，用三个礼拜写几千行到一两万行的代码，也都可以做出来，所以门槛没有想象得那么高。

我想说的是大家需要为自己未来 20 年去想，编程每 10 年可能就变得不一样了。我有个专门做程序语言理论研究的朋友，他说未来应该是让更少的、更优秀的程序员，用更少的代价来实现更强大的功能。还有个朋友在 Amazon 工作，他看 Amazon 的源代码，发现 10 年前程序员用同样时间实现的功能和 10 年之后相比要少很多，应该是因为 10 年之后有了更多、更强大的工具。所以我认为大家还是要不断地学习更强大的工具，而 Scala 有作为这种强大的工具的潜力。

InfoQ：对于正在学习或者使用 Scala，以及对 Scala 这门语言有强烈爱好的人，能够用 Flag Boot 去做哪些事情？

袁洋：能做的事情和 Spring Boot 差不多，可以拿它做任何事情。经常有人会问想用 Scala 做一个东西，应该怎么开始，但其实没有一个初始化的脚手架让大家来开始。

大家基本上只能够看 Scala 的 Tutorial 做一个“Hello World”，再复杂的比如做一个网页的服务器，就会觉得很困难。之前有人用 Play Framework，但我们觉得它没有我们的工具精简和高效。杨景钦用了两个小时做了一个很高效的、高并发的健康宝查询功能之类的应用。

InfoQ：Flag Boot 是一个轻量级的框架，代码量比较少，而且代码简洁，少有晦涩的代码，隐式代码等，要做一款代码简洁的应用并不容易，您有什么经验可以分享下吗？

杨景钦：我个人觉得最关键的是技术选型。一方面，如果技术选型选择好，开始写代码的时候就会非常舒服，很多事情框架会去做，自然而然写的代码就短了。比如选择了特别好的框架，所有东西就可以用框架里面的包，可能一行就可以写完一个功能。另一方面，如果最初技术选型没有选好，后面就会容易进行很多的重构，如果没有全身心从头到尾进行重构，会发现到中间时代码变得越来越多。重构一个框架其实是一个先变多再变少的过程，但是如果前面的坑太大，大家有可能会在变多的过程中走不出去。

另外，写代码的时候要多想，“Think twice，code once”。以前参加算法竞赛，比如一场考试 5 个小时，可能有 3.5 个小时在想，只有 1 个小时左右是在写代码，想清楚之后，代码的量就不会很大。当然也分情况，如果是以代码行数作为发工资的标准或者 KPI，可能多凑一点行数也是好的。还有一点，即使刚开始很痛苦，也要保持一个重构的习惯，其实只要经常重构，代码会越来越好看。

袁洋：杨景钦说得很有道理，简单来说就是“谋定而后动”。先想清楚到底要实现什么功能，这个功能有的时候不要从面向过程的角度去想，第一步要做什么，第二步要做什么，第三步要做什么，而是要把它想象成是一个什么到什么的映射，什么到什么的函数。

这其实都在类型系统里面，如果所有东西都没有类型是件很痛苦的事情。如果有类型系统，会发现比如把大象装进冰箱分三步，第一步打开冰箱，第二步把大象塞进去，第三步关上冰箱就真的很简单。但前提是要把什么是大象，什么是冰箱，什么是放进这些基本操作搞清楚，搞清楚之后代码自然而然就会非常清晰、简洁。

这其实是一个范畴的思想，范畴论是一个很优美的学科，它是数学里面一个虽小但是很核心的分支。如果把代数、几何、代数拓扑、分析等等各种学科，用范畴的语言来表达，会发现以前很复杂的、可能需要两三页的证明，在范畴里面可能就两三句话，因为你把很多东西都抽象掉了，只保留了它的结构。还会发现这两三句话不仅可以证明原来很复杂的一个定理，还可以同时证明很多定理。这件事情映射到程序员里面，就相当于一个很小的、只有三行的函数，可以同时来做很多不同的事情，做很好的代码复用。但前提是需要不停地重构，不断地锻炼，去想而不是去写。

InfoQ：从原理来看，为什么 Flag Boot 会更快？

袁洋：我举个例子，比如去火车站营业厅买票，以往是有 10 个窗口相当于 10 个线程，如果突然涌进来 1000 个人，整个厅里全是人，大家会不停地拥挤，办事速度会很慢。而用 Monad 会这么做，同样是 1 个大厅里有 10 个窗口，不同的是我会在大厅旁边再准备一个大厅供大家排队；然后有一个专门的负责运行管理的人来负责叫号，他会决定每个人该去哪个窗口。

但是我想说 Monad 比这个重要很多，它作为一个盒子的思想不仅可以用在线程调度上面，还可以用在很多别的地方。为了更好地理解 Monad 这个概念，我觉得最好的一个方法就是看范畴论或者程序语言理论里面的定义，顺着定义去理解可能会更好。

杨景钦：对于怎么在线程上面进行调度，我用另外一个视角来看待这个问题。因为我们现在拿很多盒子去封，其实盒子不一定只是一个字条，字条上面还会有一些批注。盒子会有不同的类型，比如同一段代码，有的盒子上面写的是一个读操作，有的是一个写操作。比如分布式数据库的一些优化里，我们需要把读和写分开考虑，因为读和写对于资源的占用过程不一样。同理，我们原来的技术里边，把一段代码去异步地做，我们是在它外面套一个 thread，然后直接喊它到一个别的地方去 run 一下，它就在异步上面去做，至于它怎么做并没有去管。

现在我们是对它做了范畴论的包装，然后在 Cats Effect 的框架里，在包装的过程当中会自动给这些盒子里的一些代码段，打上读、写或者其他等等一些标签，它自己内部在用 Fiber 的概念对线程进行调度时，会参考这些标签上面的内容，并且以此来优化它的调度策略。当然具体的实践是 Cats Effect 的框架写的，我们只是在它外面又做了一层封装。

袁洋：我们只是个搬运工或者粘贴工，把很多包以一个比较好的方式粘起来，让它比较好用，适合初学者。

InfoQ：在可扩展性方面，Flag Boot 表现如何？

杨景钦：其实严格上来说，我们并没有对用户使用的机器技术做任何限制，从理论上来说，几乎所有其他框架和 Flag Boot 都是兼容的。

举一个对于用户使用的技术有比较强烈限制的例子，比如 Akka 公司最近推出一个基于 Scala 写的比较小众的微服务框架叫 Lagom，从可扩展性上面来看，它基本上把用户使用的所有技术站都限制在了 Akka 支持的一些框架上，如果他们不支持这个框架就用不了。因为他们所有的优化都是从 Actor 这个模型出发的，要想用这个框架，首先要跟 Actor 兼容。然而众所周知，他们的 Actor 和 Java 的 thread 等是非常冲突的, 只能是一个支持 Actor 模型的框架才能够在他们的框架里去用。

我们不存在这个问题，因为我们做的最本质的事情是对逻辑进行了一个范畴论的封装，并且交由一些框架去进行异步处理，我们并没有对要包装的代码有多大的限制。所以我们在 Flag Boot 里基本上可以用所有的其他框架，甚至可以用 Spring Boot。

另一方面，我们虽然用的是 Scala，这个语言听上去很怪异，可能它的生态环境没有很好，但是 Scala 兼容了 Java 的所有框架，Java 所有框架都可以在 Scala 里边用，所以可扩展性还是挺强的。但是我们现在的问题是只提供了 Scala 的 API，最后的开发是基于 Scala 开发的，等我们也提供了 Java 的 API 之后，这个事情就能变得更好。

袁洋：我们的代码是比较显式的，所有实现的东西我们都是显式实现，并没有用宏，也没有像 Spring Boot 用注解。有相关计算机背景的同学，如果知道基本的一些程序开发方式，其实就可以拿过来直接用，而且能看明白我们到底在做什么。

InfoQ：针对人工智能辅助诊断系统，Flag Boot 框架的应用效果如何？

袁洋：我们用的还行，效率和并发挺高，但是我们又没有对比。杨景钦之前做了一些简单的、高并发的实验，可以介绍一下。

杨景钦：那个实验是我们搭一个服务，然后去疯狂地请求，做 HTTP 的性能测试。我们做了几个测试，一个是模拟所有的请求都是非常快的，基本上请求完之后立刻返回，因为这个逻辑写起来很简单，在不同的框架上面没有任何区别。和 Spring Boot 比，我们比较快，大概有 2-3 倍吞吐量的优势，没有快很多。

另一个是我们去试了一下比较大的延迟的测试，比如每个请求过来，我们需要先让它在内部运行 100 毫秒，再返回。这种情况下发现，我们的框架在比较大的并发压力下，大概有 5 倍还要往上的一个吞吐量。

袁洋：它主要框架是因为它是原生异步，不会有饥饿的情况，不会有一个东西一直卡着，然后调度出现问题，大家调度起来会非常方便。

有线上观众说这本质是一个智能的任务调度系统，我认为不是。今天主要在讲调度的事情，是因为可能观众比较感兴趣，问得比较多。调度其实只是这个框架的一个比较好的特点，因为它用了范畴论，用了 Monad 调度起来比较方便，但核心是，它是一个类型安全的支持复杂类型的系统。

现在看可能还不是很清晰，我个人认为再过 10 年我们来看这个事情，会觉得对一个大型的软件系统来说，一个强有力的类型安全的支持是非常重要的。很强的类型系统做很多事都很方便，可能看具体的代码会发现确实很方便，但是可能在交流的时候很难说清楚。

InfoQ：与 Spring Boot 框架相比，Flag Boot 主要的不同是更快吗，还有什么其他优势？

袁洋：我举个不太合适的极端例子，大家都知道汇编，原则上所有东西都可以拿汇编做，但汇编和一个新的框架比如 Spring Boot 的区别是什么？可能关注更多的不是更快，也不是 Spring Boot 或者 Flag Boot 有什么功能是汇编实现不了，也不是汇编写起来更费劲，代码会更长等等，其实关注的是这个更加 intuitive，有更强的可扩展性，它在这上面可以做更多很强大的事情，速度不一定是最关键的事情。我们在编程的时候，一定要先做对再做快，如果做得不对，做再快也无济于事。

杨景钦：我们与 Spring Boot 相比，主要的是我们有更简洁的 Type Safe，以及代码的可读性更强一点。对于 Spring Boot 比较熟悉的人来说，代码确实会好读一点，但是对于刚用不久的人来说，还是比较难以看懂，因为 Spring Boot 是利用注解去进行编程的，它里面有很多可能需要去查很多资料才能够弄懂的注解。而我们没有加注解，也基本上没有用到任何的红。我们做得所有处理，都在代码里面，大家可以直接看到。只要能看懂 Scala，就能看懂其他人到底在做什么。除了 Type Safe 以及代码的可读性强之外，还有一些性能上的小优势，以及我们框架是原生异步的。

InfoQ：Flag Boot 这个项目在明年有什么规划？

杨景钦：第一，我们现在是基于 Scala 2 写的，Scala 2.13 或者 2.12，接下来要做的事情是把我们的框架向上迁移到 Scala 3。第二，是 Java 的 API。第三，是在分布式计算里边的一些支持，相当于是其他的功能。

袁洋：我还希望这个框架在我们那个项目里面用的时候看看有什么反馈，有什么地方可以再改进。

InfoQ：请老师分享一下在马上过去的这一年里，微服务框架的发展情况如何？

杨景钦：我觉得微服务框架现在是一个百花齐放的状态，其实有很多的地方都开始做微服务框架，可能背后的原因有很多。另外，现在有很多搞 AI 的人，他们做出来一点成果，比如做出来可以让大家玩的东西，像之前的 AI 作画者，去运用一些简单的类似于 Flag Boot 或者 Spring Boot 等等这种框架，快速去构建一个 Web 服务，然后交由用户去运行。这是一个背景，然后在这个基础上，我在 2022 年看到很多的框架，比如 Spring Boot、Play，还有一些别的厂商自己在用的框架等等，大家做得东西还是挺多的。

大家关注的点以及要处理的问题也都有不一样的地方。比如 Spring Boot 考虑要加更多新功能，让大家用我们这一个框架可以做到所有的事情。还有一些框架可能想的是让用户在用这个框架时，能够养成一套非常良好的代码审美，更偏向于让最后写出来的代码非常好看。还有的可能希望要干掉微服务里边的分布式的一致性问题，要让多个服务去达成共识等等。整体来说，大家都在朝着各自的方向去做，处在一个百花齐放的状态。

袁洋：我们团队在做辅助诊断系统的时候，除了做框架，还做了很多其他的技术选型。我在 2012 年读博士的时候，听说未来 10 年程序语言理论会发展得最迅速，当时我并不了解程序语言理论。今年这一年到底怎么样，可能我没有那么清楚，但是现在回过头来看这 10 年涌现了很多新的程序语言，虽然有的还没有来得及成为主流，但是新的程序语言基本上都是强类型的，支持很多基本的程序语言理论里面需要支持的东西。

所以我觉得一个总的趋势是语言新的框架，它们可能会有自己的各种特点，但是一定不变的是，它们越来越需要和程序语言理论聚合，因为根据过去十年或者十几年的经验，证明了程序语言理论是对的，是符合软件开发需要的经验。

袁洋，清华大学交叉信息研究院助理教授

杨景钦，清华大学交叉信息研究院博士  NOI CCPC ACM/ICPC 金牌

文章版权归极客邦科技 InfoQ 所有，未经许可不得转载。

你也「在看」吗？ 👇