每个服务独立占用一个容器，将服务、依赖包、操作系统、监控运维所需的代理打包成一个镜像。这种模式促成了 Service Mesh 的发展，让 Service Mesh 实现起来更容易。
过往 Kubernetes 上主要运行着无状态的 Web 应用。随着技术演进和社区发展，越来越多有状态应用和大数据 / AI 应用负载逐渐迁移到 Kubernetes 上。Flink、Spark 等开源社区以及 Cloudera、Databricks 等商业公司都 开始加大对 Kubernetes 的支持力度。
实现最佳性能功耗比和性能价格比的另一个重要方向是支持异构硬件。由于 x86 处理器的性能越来越难以提升，而在 AI 等对算力要求极高的场景，GPU、FPGA、TPU(Tensor Processing Units)等架构处理器的计算效率更具优势。随着异构硬件虚拟化、资源池化、异构资源调度和应用框架支持的成熟，异构硬件的算力也能通过 Serverless 的方式释放，大幅降低企业使用门槛。
边缘人工智能对于管理不断增长的数据量和减轻业务网络日益增长的压力至关重要。在边缘处理数据而无需将数据传输到云端，使设备更强大、更通用、更灵敏、更安全，并有助于合规性。”
微服务思想以及相关的技术为 IT 架构的发展带来了一系列深刻的变革：
易于开发和维护：一个应用只会关注一组特定的业务功能，通过服务拆分，能减少应用之间的耦合度，让开发和维护更加简单。
在应用生命周期管理以及服务治理方面， Kubernetes 提供了比较完善的实现机制，通过构建 Deployment 资源，配合 proStop 和 postStart 脚本，能比较方便的实现滚动发布以及应用的优雅上下线。虽然在灰度发布的过程中，依然没有办法直接对流量进行精细粒度控制（引入 Service Mesh 技术能增强流量控制力，不在本文讨论范围），但相比简单的发布脚本，已经有了飞跃性的提升。
Serverless Kubernetes 架构虽然能适配所有的业务场景，但对于开发者而言，构建一整套 Kubernetes 体系，需要掌握一系列跟 Kubernetes 相关复杂的概念，有着非常陡的学习曲线。而且 Kubernetes 生态中各种组件的搭建，再加上网络层与存储层的适配，都涉及非常复杂的工作。
对于开发测试环境而言，SAE 的机制弹性能力能体现得更加淋漓尽致，得益于 SAE 出色的资源调度能力，可以一键启停一整套微服务应用。即便仅对一项简单的新功能进行冒烟测试，也完全可以新启一套完整而隔离的测试环境来进行。
14位的计数序列号，序列号即一系列的自增Id，可以支持同一节点同一秒生成多个Id，14位的计数序列号支持每个节点每秒单机产生16384个Id。
同时单机消费的第二个问题就是单点。所以我们要实现Failover。这里我们采用Raft协议进行多机选主以及对主的请求。当单机挂掉之后，其余的机器会自动选出新的Leader执行同步任务。
