共计 4385 个字符，预计需要花费 11 分钟才能阅读完成。
文|宋顺（GitHub ID：nobodyiam)
SOFAStack 社区开源负责人蚂蚁团体高级技术专家
本文 3861 字 浏览 11 分钟
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 即可。这样就能够彻底和底层根底服务解绑，同时也是极大地升高了多语言的反对老本。
图 11 – Layotto 架构
我的项目地址：https://github.com/mosn/layotto
通过服务网格和利用运行时，咱们解决了研发态对中间件 SDK 降级、多云差别感知等累赘，咱们再来看下如何通过 Serverless 技术来升高运维态的累赘。
咱们晓得业务研发个别是从需要到设计、开发、测试，最初公布生产的一个循环过程，其中不少业务还会呈现多个迭代并行开发的场景。然而公布生产要求是串行的，就会导致迭代堵车的景象，后一个迭代必须得等前一个迭代发完能力开始公布，整体效率比拟低。
除此之外，随着业务重要性的晋升，公布流程也会变重，公布周期短则几个小时，长则几天甚至几周也不足为奇。同时，业务逻辑的减少也会导致利用启动变慢，启动一个零碎往往须要几十分钟，导致利用扩容等操作响应缓慢。
图 12 – 研发迭代模式
咱们通过剖析，发现不少利用代码实质上是能够分成两层的。一层是公共逻辑和外围模型，这部分是比较稳定的，很少有变动。另一层是基于公共局部之上的逻辑，咱们把它形象为模块，模块和业务逻辑严密相干，变动也较为频繁。
因而咱们首先思考把代码拆分成基座和模块，在基座代码库中积淀通用逻辑，为模块提供计算撑持，同时为每个模块也创立独立的代码仓库。
在运行时通过 SOFAArk 技术实现基座和模块在同一个过程中开展，同时开发了热部署的能力从而模块能够独立于基座运维。
这样，咱们就辨别了基座开发者和模块开发者。基座开发者和传统的利用开发没什么区别，而模块开发者因为不再须要关注容量、资源，同时能够独立于基座运维，实现了 Serverless，具备了疾速迭代和疾速伸缩能力。
这个计划也存在一些有余：比方因为依赖 SOFAArk，所以次要针对 Java 场景，另外因为多个模块是在同一过程中运行，因而隔离性较差，会相互影响。
图 13 – SOFAArk 热部署
我的项目地址：https://github.com/sofastack/sofa-ark
因为 Serverless 计划存在上述提到的技术栈、隔离性等问题，在覆盖面上还是有一些盲区。联合业界的实际，咱们决定持续向 FaaS 迈进。
图 14 直观地展现了利用研发粒度的演变过程：最早从单体利用到微服务，是把粒度升高到服务级别，从而解开了业务团队之间的耦合。
咱们当初是持续把粒度升高到函数级别，以此来实现快写快发、免运维，从而进一步晋升研发和运维效率。
图 14 – 利用粒度演变
图片起源：https://www.cloudflare.com/zh-cn/learning/serverless/glossary/function-as-a-service-faas/
思考到函数粒度是十分小的，FaaS 的利用范畴是绝对无限的。咱们认为上面这些场景是比拟适宜 FaaS 研发模式的：
- 碎片化需要场景：例如 BFF，大多是胶水代码，逻辑简略，不过需要变动快，通过函数实现组装式开发，从而助力业务翻新
- 事件驱动场景：例如音视频转码，大多是 CPU 密集型，对解决工夫不是特地敏感，而且有着比拟显著的波峰和波谷
- 中台业务场景：例如算法平台，它的的算子逻辑比拟独立，然而参加研发人数多，所以代码逻辑不可控，须要更好的隔离能力
图 15 – FaaS 实用场景
目前咱们也在公司外部摸索 FaaS，整体产品架构如图 16 所示，将来咱们也会逐渐地去开源相应的组件。
- 触发源反对 RPC、HTTP、Message、Cron 等
- 冷启动采纳了 Cache pool、Fork 等技术实现减速，对简略的 Node.js 和 Java 函数能够实现几百毫秒冷启动
- 提供了 Layotto 作为 Sidecar 帮忙函数轻松拜访各类 BaaS 服务，同时具备欠缺的治理能力
图 16 – SOFA Function 产品架构
03
致谢
最初，值此 SOFAStack 开源五周年，还是要对大家表示感谢。
首先，我要感激所有 SOFAStack 我的项目的贡献者们，无论是提交代码、撰写文档、解答问题，还是组织流动、流传理念，正是因为有了你们的不懈努力和无私奉献，才让 SOFAStack 可能不断完善和提高，使更多用户受害。
图 17 – SOFAStack 的贡献者
其次，我要感激所有抉择应用 SOFAStack 产品的合作伙伴和用户们，无论是金融机构、互联网企业还是集体开发者，正是因为有了你们的信赖和反对，才让 SOFAStack 可能在各种简单的场景中失去验证和利用，继续晋升产品能力。
图 18 – SOFAStack 的用户
最初，我还要感激所有关注和关怀 SOFAStack 社区的敌人们，正是因为有了你们的激励和期待，才让 SOFAStack 社区持续保持生机。
那让咱们放弃初心，一起把 SOFAStack 社区建设得更凋谢、更乏味！
理解更多 …
Layotto Star 一下
https://github.com/mosn/layotto