GAIA容器架构设计，基于Composite Containers，实现轻量级Function容器架构设计，基础设施容器下沉隔离解耦。
Function容器架构设计与传统的应用相比，Function容器架构设计提供了不同粒度的业务切分维度，原来大量的业务逻辑都沉淀在一个应用里面，带来了业务的耦合问题；而Function容器架构设计粒度，天然规避了应用维度带来的耦合问题。
通过Function容器架构设计粒度，可以很容易解决原来基于应用维度业务耦合的问题，但是如何才能与基础设施进一步解耦呢？下面我们通过当前的一些具体问题来进行讲解。
富容器化
l 容器内存在多个进程， 应用服务java/nodejs/…、Nginx、LogAgent、SunFire等等，都是一个个进程。
l 进程资源存在竞争，而且资源之间缺乏隔离，由此发生过很多非应用服务进程大量消耗CPU、内存，甚至影响整个业务服务可靠性的案例。
l 多个进程缺乏统一的生命周期管控，典型的如一个应用有Nginx+Java两个进程，Nginx进程退出了，但Java进程还在，对此应用而言，这个容器已经终止了服务。
l 对于设计模式而言，容器的职责要单一，但当前一个容器承载了太多的职责。
l 各种能力都聚集在同一容器内，数据链路及关系复杂、不清晰。
富应用化
l 中间件与领域服务对应用的侵入，大量的依赖升级需求需要研发人员的介入。
l 大量业务耦合在同一个应用里面，业务隔离性和稳定性问题比较突出。
单容器面对上述这些问题时已经是力不从心，仅靠Docker、RKT等容器是无法解决的；而多个容器的联合又会涉及跨容器的大量通信协作与资源的编排调度等问题。此时，Linux提供的Namespace和Cgroups能力就充分发挥了其灵活组合的威力，。通过Namespace和Cgroup与多个进程结合起来，即同一个Namespace多个进程共享主机名、PID、文件系统、网络接口，实现逻辑上一个节点多个容器的架构设计，而不同的容器间又具备隔离性。基于容器的分布式系统设计模式中，包括Sidecar、Ambassador、Adapter三种，可分别用于处理不同的应用场景。如图所示的是基于容器的分布式系统架构设计模式。
基于容器的分布式系统架构设计模式
对应于前面提到的问题，基于K8S的pod能力，我们接下来看一下GAIA的容器架构设计实现，如图。
GIGA容器架构设计
每个容器的职责都是单一的，一个容器只解决一件事情，应用的容器专门处理应用逻辑，运维监控的容器专门处理运维监控业务。天然具备隔离，不同容器间隔离，不同容器间细粒度控制CPU、内存、IO等资源。
进程统一基于容器级别的生命周期的探测和管理。基于Pod多容器的能力，基础服务这些中间件都可以下沉隔离，即 Service Mesh的核心理念，服务注册发现、限流、熔断、超时等基础能力都可以实现业务解耦。
GAIA对比基于JVM的FaaS容器，其核心差异是业务与基础设施实现容器化的解耦，容器化的隔离性与编排能力。
如图GAIA与传统应用架构设计的对比图示。
GAIA与传统应用架构设计对比图
对比总结，GAIA基于K8S pod多容器化的应用架构设计升级，实现业务逻辑与依赖的基础设施完全解耦。与普通应用的核心差异如下：
l 业务细粒度隔离性。
l 促进领域服务与应用服务分层。
l 请求链路：去中心化+RPC vs Sidecar。
l 研发方式：面向大量基础设施依赖 vs 专注Function/业务容器。
这些差异的本质，容器的单一职责、容器化资源隔离、容器化分层、以及容器化统一生命周期管理，是架构设计模式的基本原则的体现。
