作为程序员的你是否经常面临如下对话场景
产品经理：“这个需求非常紧急，只改动一点点，加个字段透出来，须在**前上线”。
我们的回答：
1、“我正在升级一个三方依赖包/中间件，这个发布还要一段时间，还要等这个发布完稳定一段时间后再说”
2、“这个修改，需要拉分支修改，然后要编译、打包、部署，再测试验证，研发交付过程就需要1小时起”
3、......
这里面有两个问题 ：
一是：“应用”承载多业务服务，并与基础设施依赖紧密耦合，“应用”负重前行。
二是：应用的编译打包与部署分别是程序员的尿点、烟点，业务交付流程成本高。
▐ 分析思考
为解决业务耦合和扩展性问题，我们有了微服务；微服务由应用去承载，多个服务/同领域服务在一个应用里面，导致应用切分粒度与灵活性一直是挑战，典型的场景是会再进行服务分组，自然也会有大量的应用拆分的情况，同时应用里面包含了各种三方依赖/ 中间件，这些自然与应用强耦合；
为解决微服务部署问题，我们有了容器化部署方案。基于容器的部署解决方案，里面除了应用也承载 metric、logagent 等大量非业务的组件，并与业务缺乏隔离性；
我们的现状是富容器+富应用，是否有新的机制，可以实现业务和基础设施隔离解耦。
云计算以及 IaaS、PaaS、CaaS 等理念得到普及，硬件网络等基础设施下沉到通用平台，不断降低业务落地技术门槛。从上图可见，从 IaaS 到 PaaS ，业务需要关注的内容不断的在减少，但“应用”仍是一个非常庞大的载体，如何让业务更专注于业务逻辑自身， FaaS 是最优选项
在微服务和容器化的背景下，为解决业务与服务化基础能力耦合问题，产生了 service mesh ；FaaS 与 mesh 的结合，刚好优雅的解决业务与基础设施的耦合问题
业务交付过程，是不断的代码提交、编译、打包、部署的过程，研发人员需要清晰知道并机械的完整参与整个过程，既然如此能否实现代码修改即交付，把代码提交、编译、打包、部署乃至自动化验证对开发交付过程透明呢？
▐ 我们的答案
轻量级function容器 + 基础设施容器下沉隔离解耦（Composite Containers）
所见即所得（What You See Is What You Get ），function版本化交付运行。
这张典型的分层图，通过技术的不断的标准化，降低开发复杂性，提高业务研发运营效率，是技术演进的核心价值体现；当下云原生概念火热， K8s 、 service mesh 等技术不断的将业务依赖的基础设施下沉隔离，技术理念的认知也得到更新，此时正是 FaaS 技术新的机遇， GAIA 正是基于这样的背景产生，我们做的 2 件事情，即定义面向 function 的容器规范，定义面向 function 的研发过程。
▐ GAIA 容器架构
基于 Composite Containers ，实现轻量级 function 容器，基础设施容器下沉隔离解耦。
通过 function 粒度，很容易解决原来基于应用拆分粒度问题，但如何与基础设施进一步解耦呢？我们看当前的一些具体问题。
★ 富容器化：
容器内存在多个进程，应用服务 Java/nodejs/... 、 nginx 、 logagent 、sunfire...
进程资源存在竞争缺乏隔离，发生过很多非应用服务进程大量消耗 cpu 、内存，影响整个业务服务可靠性的案例。
进程缺乏统一生命周期管控，每个进程都要自我保障，典型的如 nginx 跪了， Java 进程还在，对应用而言其实整个容器已经终止服务；或者日志采集的服务已经停止了，造成了数据监控的丢失。这些进程是组合构建一个服务能力。
从设计模式而言，容器的职责要单一，但当前一个容器承载太多。
各种能力都在同一容器内，数据链路以及关系不清晰。
★ 富应用化：
中间件与领域服务对应用的侵入，有多少依赖的升级需求需要业务研发响应。
单容器面对这些问题已经力不从心，不是仅 docker、rkt 等容器可以解决；而多个容器直接一起，又涉及跨容器大量的通讯协作与资源编排调度等问题，这时候 linux 提供的 namespace 和 cgroups 能力就发挥其灵活组合的威力，常规理解一个容器与 namespace 和 cgroups 一一对应，更进一步把 namespace 和 cgroups 与多个进程结合起来，即同一个 namespace 下，共享主机名、 PID 、文件系统、网络接口，但不同的进程通过 cgroups 隔离资源，把相关联的几个进程通过这种形式组织起来，即实现逻辑上一个单节点多容器组合，但不同的进程间又具备隔离性， K8s 的 pod 即支持按 Composite Containers 实现。基于容器的分布式系统设计模式里面，对单节点多容器的模式，包括 sidecar 、 ambassador 、 adapter 三种，可分别处理不同的应用场景。
对应前面的问题，基于 K8s 的 pod 能力，我们看 GAIA 的容器架构实现。
每个容器的职责单一，一个容器只解决一件事情，应用的容器专门处理应用逻辑，运维监控的容器专职处理
隔离天然具备，分不同进程容器级别的cgroups隔离，对不同的容器细粒度控制 cpu 、内存、 IO 等资源
统一基于容器级别的生命周期的探测和管理
基于 pod 多容器的能力，基础服务这些中间件都可以下沉隔离，即 service mesh 的核心理念，服务注册发现、限流、熔断、超时等等基础能力可实现业务解耦
整个容器的架构清晰化，底层为监控、日志模块，上层为业务容器，每块能力定义自己的数据链路
对比基于 JVM 的 FaaS 容器，核心差异是业务与基础设施仍在应用和容器里面耦合在一起，同时容器的隔离性与编排能力。
我们看 GAIA 与传统应用架构对比：
基于 K8s pod 实现，业务逻辑依赖的基础设施完全解耦下沉
业务细粒度隔离性
促进领域服务与应用服务分层
请求链路：去中心化 +RPC vs Sidecar
研发方式：面向大量基础设施依赖 vs 专注 Function / 业务容器
本质关键：
容器级的架构分层
容器级的单一职责
容器级的资源隔离
容器级的统一生命周期
▐ GAIA研发流程
所见即所得（ What You See Is What You Get ）， function 版本化交付运行。
业务研发落地过程划分3个阶段，即设计（ design ：含业务需求分析、技术方案选型、架构设计、详细设计、领域建模等）、实现（ code ）、交付（ delivery ），前两者与业务的复杂性紧密关联，也有很多工程理论在探索，在交付阶段经历的过程基本确定，都会经历代码提交、编译、打包、部署、测试几个阶段，然后从测试环境交付到生产环境，有些公司会有 CI/CD 实践，基于 Function 如何去实现呢？与传统应用的差异如何呢？
基于 function 的版本化交付运行，我们重新定义了研发过程，并进行领域建模。
基于容器规范的自动化编译打包，修改触发
部署版本化 reversion
关联 trigger ，基于 alias 在不同 reversion 版本之间流量发布实现研发交付阶段对开发透明，所见即所得
▐ GAIA 实战
我们以闲鱼详情为例，从端到端完整业务落地，对比与传统研发方式差异
★ 传统研发
开发：
创建应用、创建工程脚手架、代码分支管理
Aone需求，git分支，idledetail应用研发
应用日常、预发发布
mtop Max平台API配置发布
详情android开发
详情iOS开发
发布：
应用创建机器资源、单元化等逻辑
Idledetail发布
Max API发布
API去中心化
金丝雀能力缺乏
android端构建发布
iOS构建发布
运维：
机器资源伸缩
ssh 日志grep
基础设施依赖升级
......
★ GAIA研发
开发：
Fn业务逻辑，日常预发秒生效
详情flutter跨端
发布：
线上发布Fn
旧API流量迁移
flutter动态发布
运维：
平台化托管
从两者对比，仅研发阶段，GAIA 的研发过程大幅简化，对提升研发效率有很大价值，我们测算验证全新构建一个应用服务的耗时是达到几小时级别，单纯的修改逻辑落地也是小时起；而 GAIA 可以实现快速开发，日常、预发环境修改秒级生效，实现业务快速迭代。
▐ 总结
GAIA基于Composite Containers定义容器规范，实现业务容器轻量化，结合mesh理念确定业务与基础设施新的隔离边界；同时基于function的版本化重新定义了交付流程，实现研发所见即所得，业务交付效率得到突破；当下已经在闲鱼、淘宝业务中落地
理念需要成熟的技术能力与环境支持，FaaS在业界有很多先驱，当下容器、微服务、K8s、service mesh成熟带来了新的机遇
技术不断的标准化，降低业务交付的复杂性，提高业务研发运营效率
极致的研发运维效率，支持业务高速迭代是永远的追求，也是技术演进的业务价值体现
GAIA是基于技术环境成熟后新的serverless实践，未来资源与流量一体的弹性伸缩，基础设施透明化，业务研发0运维。
One More Thing
淘宝基础平台部-基础服务团队,欢迎在容器、K8s、serverless、service mesh上感兴趣的同学，一起探索技术、创新突破，为阿里乃至业界创造新价值，简历投递 kobe.sunq@taobao.com
在看点这里
扫一扫
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
