01

回顾开源这五年

回想起 2018 年 4 月 19 日 SOFAStack 首次开源，当时的官宣文章中就提到了我们开源的初心：

期望通过逐步向社区开源 SOFA 中各个组件，从而一方面帮助更多机构和合作伙伴完成金融分布式转型，帮助大家更加快速构建稳定的金融级云原生的架构，另一方面也是期望 SOFA 在蚂蚁体系之外的更大场景下去应用，来进一步锻造改进这套体系，使其更加完善和稳固。

所以这几年我们也是围绕着这个初心把 SOFAStack 体系的各个产品逐渐开源，包括首批开源的 SOFABoot、SOFARPC、SOFAArk，以及后来的 SOFARegistry、SOFAJRaft、Seata 等。同时我们也孵化了 MOSN 社区，开源了云原生网络代理 MOSN 以及应用运行时 Layotto。这些产品也是代表着 SOFAStack 在金融级云原生领域的沉淀和积累，目前已经在上百家企业中生根发芽。

图 1 - 产品开源时间线

我们再来看几个数字，在这 5 年中，我们举办了 18 场 Meetup，开展了 32 场直播分享，目前在 GitHub 组织层面有 438 名贡献者以及 3W 的 Star。

图 2 - 开源 5 年的几个数字

除了在项目上收获了不少贡献者和 Star 外，我们也逐渐地对开源有了更为深刻的认识。

以开源指标为例，我们的初心是为了帮助更多机构和合作伙伴完成金融分布式转型，我们一开始最为关注的指标是用户数；但因开源的特殊性，我们无法直接获取实际的用户数，所以采用了 GitHub 的 Star 作为衡量指标。

我相信这也是很多开源项目常见的第一反应，后期大家其实也发现了一些问题。举例来说，有些开源项目为了完成指标，采取了点 Star 送礼物等行为。这些虽然没有在我们的项目上发生，我们仍觉得有违开源初心，就放弃了 Star 数作为核心的指标。

图 3 - Star 数作为衡量指标

另一个开源项目常用的衡量指标是贡献者数量，很多开源项目是没有商业公司支撑的。为了项目的长期发展，需要持续的吸引新的贡献者加入，从而为社区带来活力。

我们在放弃 Star 数指标后，把重心放在了贡献者数量上，会为新贡献者提供一些简单的任务，使他们能更快的融入社区，成为潜在的长期贡献者。

不过和 Star 指标类似，在过程中我们也发现其它社区中出现了一些不好的现象。比如故意留一些明显的 bug，或者提供一些修改错别字的任务来刷贡献者数量，我们认为这些也是有违开源初心的。

图 4 - Contributor 数作为衡量指标

那么，我们该如何对待开源呢？

我脑海中想起了 Envoy 作者 Matt Klein 在 Envoy 开源五周年时说的一句话：成功的开源软件就像创办一个企业。

图 5 - 成功的开源软件就像创办一个企业

其实开源项目和创业很类似，首先你需要有一个好的点子，然后去吸引人才一起加入来提升产品能力，再通过一些营销手段对项目做推广来获取客户，而后持续迭代改进。

对企业而言，员工和客户固然很重要，不过我认为最核心的还是产品，只有一个定位准确、解决实际问题的产品才能受到市场欢迎，从而获取资金维持公司的运营。

在开源项目上，用户对应着企业的客户，是提供场景的驱动力来源；贡献者对应着企业的员工，属于资源投入，是推动力来源；而产品才是真正能解决用户问题的，是整个开源飞轮中最为核心的部分。所以 Star 数和贡献者数量都只是过程指标，核心还是要提升产品力，不能本末倒置。

图 6 - 开源飞轮

02

展望下一个五年

聊完了过去五年的过程和收获，对 SOFAStack 而言，下一个五年的主要方向就比较明确：我们还是会着重放在产品力的提升上，希望能持续解决分布式场景中的核心问题。

那核心问题究竟是哪些呢？我想起了泛在计算的提出者 Mark Weiser 曾经说过的一句话：最卓越的技术是那些“消失不见的”技术。

图 7 - 消失不见的技术

对这个判断，我也是深以为然。在日常生活中，这类案例也是比比皆是：比如电，我们现在都是即插即用，以至于已经不感知电力背后的复杂基础设施，类似的还有水、煤气等。它们背后都有着复杂的基础设施在支撑，经过了数十年的技术发展之后，已经非常稳定可靠，交互也非常简单，所以这些技术就像是“消失不见”一样。

图 8 - 水电煤随开随用

然而在我们实际的研发场景中，业务研发对基础设施的感知还远没有达到无感的地步。

比如在研发态，我们除了要关注业务逻辑之外，还会经常被中间件 SDK 升级所打扰，在使用云产品时还得感知多云的差异。

在运维态，除了要关注发布时的业务表现，还要时刻去关注资源状况。在其容量不足的时候要申请资源做扩容，在业务低峰的时候要缩容服务来节约成本。

可以说，技术基础设施的存在感越强，研发运维的效率就越低，无法把精力集中在业务的创新上。

图 9 - 实际研发场景

那么，我们该如何才能让技术基础设施也消失不见呢？

我们知道对微服务而言，可以通过服务网格来解耦业务逻辑和 RPC 通用能力，从而实现独立演进、透明升级。

图 10 - Service Mesh 演进架构

项目地址：https://github.com/mosn/mosn

在实际场景中，除了微服务之外，业务往往还会使用其它的中间件能力。例如动态配置、消息、缓存、数据库等，如何降低这些中间件和业务应用的耦合是一个新的问题。另外，在多语言场景，我们仍然要为每种语言开发一套轻量 SDK 来实现通信协议和编解码逻辑，这部分也有很高的成本。所以我们如何进一步去降低多语言的支持成本是另一个亟待解决的问题。

为此，我们也是借鉴了 Dapr 的应用运行时思路，基于 MOSN 设计开发了 Layotto，在下层对接了各种基础服务；在上层为应用提供了统一的、具备各种分布式能力的 API。

开发者不需要再关心底层各种组件的实现差异，只需要关注应用本身需要哪些能力。比如调用 RPC、发送消息，然后通过 gRPC 调用对应的 API 即可。这样就可以彻底和底层基础服务解绑，同时也是极大地降低了多语言的支持成本。