Koupleless 是一种模块化的 Serverless 技术解决方案
前言
大家好，我是老马。
sofastack 其实出来很久了，第一次应该是在 2022 年左右开始关注，但是一直没有深入研究。
最近想学习一下 SOFA 对于生态的设计和思考。
sofaboot 系列
SOFABoot-00-sofaboot 概览
SOFABoot-01-蚂蚁金服开源的 sofaboot 是什么黑科技？
SOFABoot-02-模块化隔离方案
SOFABoot-03-sofaboot 介绍
SOFABoot-04-快速开始
SOFABoot-05-依赖管理
SOFABoot-06-健康检查
SOFABoot-07-版本查看
SOFABoot-08-启动加速
SOFABoot-09-模块隔离
SOFABoot-10-聊一聊 sofatboot 的十个问题
1.1 简介与适用场景
什么是 Koupleless
Koupleless 是一种模块化的 Serverless 技术解决方案，它能让普通应用以比较低的代价演进为 Serverless 研发模式，让代码与资源解耦，轻松独立维护，与此同时支持秒级构建部署、合并部署、动态伸缩等能力为用户提供极致的研发运维体验，最终帮助企业实现降本增效。
随着各行各业的信息化数字化转型，企业面临越来越多的研发效率、协作效率、资源成本和服务治理痛点，接下来带领大家逐一体验这些痛点，以及它们在 Koupleless 中是如何被解决的。
适用场景
痛点 1：应用构建发布慢或者 SDK 升级繁琐
- 传统问题：
应用镜像化构建需 3-5 分钟，单机代码发布到启动需 3-5 分钟，开发者每次验证或上线需等待 6-10 分钟。SDK 升级需修改所有应用代码并重新构建发布，流程繁琐。 - Koupleless 方案：
使用 通用基座 与配套工具，将应用切分为 基座（沉淀公共 SDK）和 模块（业务代码包）。基座升级对业务无感，模块热部署实现 10 秒级构建发布 和 公共 SDK 升级无感。
痛点 2：长尾应用资源与维护成本高
- 传统问题：
企业 80% 的长尾应用 CPU 使用率低于 10%，造成 资源浪费。 - Koupleless 方案：
通过 合并部署 将多个应用合并到同一基座，复用基座内存（Metaspace 和 Heap），构建产物从数百 MB 瘦身至几十 MB，提升 CPU 使用率。
痛点 3：企业研发协作效率低
- 传统问题：
多人协作需统一时间窗口迭代开发，存在需求等待、环境抢占、迭代冲突等问题。 - Koupleless 方案：
将应用拆分为 基座 和多个独立 模块，模块可并行开发与热部署，单次构建+发布从 6-10 分钟缩短至十秒级。
痛点 4：难以沉淀业务资产提高中台效率
- 传统问题：
中台应用拆分独立部署带来高昂资源成本和运维负担。 - Koupleless 方案：
基座沉淀业务资产（API/SPI 定义、公共逻辑），模块直接调用基座能力，单次构建+发布缩短至 30 秒内。
痛点 5：微服务演进成本高
- 应用生命周期：
- 初创期：采用单体架构。
- 增长期：拆分为基座与模块，提升协作效率。
- 成熟期：模块拆分为独立应用。
- 长尾期：模块合并部署实现降本增效。
1.2 行业背景
应用研发与微服务存在的问题
应用架构从单体应用发展到微服务，结合软件工程从瀑布模式到当前的 DevOps 模式的发展，解决了可扩展、分布式、分工协作等问题，为企业提供较好的敏捷性与执行效率，带来了明显的价值。但该模式发展至今，虽然解决了一些问题，也有微服务的一些问题慢慢暴露出来，在当前已经得到持续关注：
基础设施复杂
认知负载高
当前业务要完成一个需求，背后实际上有非常多的依赖、组件和平台在提供各种各样的能力，只要这些业务以下的某一个组件出现异常被业务感知到，都会对业务研发人员带来较大认知负担和对应恢复的时间成本。
基础设施复杂、异常种类繁多
运维负担重
业务包含的各个依赖也会不断迭代升级，例如框架、中间件、各种 sdk 等，在遇到
- 重要功能版本发布
- 修复紧急 bug
- 遇到重大安全漏洞
等情况时，这些依赖的新版本就需要业务尽可能快的完成升级，这造成了两方面的问题：
对于业务研发人员
这些依赖的升级如果只是一次两次那么就不算是问题，但是一个业务应用背后依赖的框架、中间件与各类 sdk 是很多的，每一个依赖发布这些升级都需要业务同学来操作，这么多个依赖的话长期上就会对业务研发同学来说是不小的运维负担。另外这里也需要注意到业务公共层对业务开发者来说也是不小的负担。
对于基础设施人员
类似的对于各个依赖的开发人员自身，每发布一个这样的新版本，需要尽可能快的让使用的业务应用完成升级。但是业务研发人员更关注业务需求交付，想要推动业务研发人员快速完成升级是不太现实的，特别是在研发人员较多的企业里。
启动慢
每个业务应用启动过程都需要涉及较多过程，造成一个功能验证需要花费较长等待时间。
发布效率低
由于上面提到的启动慢、异常多的问题，在发布上线过程中需要较长时间，出现异常导致卡单需要恢复处理。发布过程中除了平台异常外，机器异常发生的概率会随着机器数量的增多而增多，假如一台机器正常完成发布（不发生异常）的概率是 99.9%，也就是一次性成功率为 99.9%，那么100台则是 90%，1000台则降低到了只有 36.7%，所以对于机器较多的应用发布上线会经常遇到卡单的问题，这些都需要研发人员介入处理，导致效率低。
协作与资源成本高
单体应用/大应用过大
多人协作阻塞
业务不断发展，应用会不断变大，这主要体现在开发人员不断增多，出现多人协作阻塞问题。
变更影响面大，风险高
业务不断发展，线上流量不断增大，机器数量也不断增多，但当前一个变更可能影响全部代码和机器流量，变更影响面大风险高。
小应用过多
在微服务发展过程中，随着时间的推移，例如部分应用拆分过多、某些业务萎缩、组织架构调整等，都会出现线上小应用或者长尾应用不断积累，数量越来越多，像蚂蚁过去3年应用数量增长了 3倍。
资源成本高
这些应用每个机房都需要几台机器，但其实流量也不大，cpu 使用率很低，造成资源浪费。
长期维护成本
这些应用同样需要人员来维度，例如升级 SDK，修复安全漏洞等，长期维护成本高。
问题必然性
微服务系统是个生态，在一个公司内发展演进几年后，参考28定律，少数的大应用占有大量的流量，不可避免的会出现大应用过大和小应用过多的问题。然而大应用多大算大，小应用多少算多，这没有定义的标准，所以这类问题造成的研发人员的痛点是隐匿的，没有痛到一定程度是较难引起公司管理层面的关注和行动。
如何合理拆分微服务
微服务如何合理拆分始终是个老大难的问题，合理拆分始终没有清晰的标准，这也是为何会存在上述的大应用过大、小应用过多问题的原因。而这些问题背后的根因是业务与组织灵活，与微服务拆分的成本高，两者的敏捷度不一致 。
业务发展灵活，组织架构也在不断调整，而微服务拆分需要机器与长期维护的成本，两者的敏捷度不一致，导致容易出现未拆或过度拆分问题，从而出现大应用过大和小应用过多问题。这类问题不从根本上解决，会导致微服务应用治理过一波之后还会再次出现问题，导致研发同学始终处于低效的痛苦与治理的痛苦循环中。
不同体量企业面对的问题
行业尝试的解法
当前行业里也有很多不错的思路和项目在尝试解决这些问题，例如服务网格、应用运行时、平台工程，Spring Modulith、Google ServiceWeaver，有一定的效果，但也存在一定的局限性：
- 从业务研发人员角度看，只屏蔽部分基础设施，未屏蔽业务公共部分
- 只解决其中部分问题
- 存量应用接入改造成本高
Koupleless 的目的是为了解决这些问题而不断演进出来的一套研发框架与平台能力。