幸运的是，针对这些普遍存在的难题，业界涌现了一系列优秀的开源技术组件和工具，让开发者可以更轻松的构建微服务应用。像 Spring Cloud 和 Dubbo 这样的技术框架，经过多年的发展，已经演化为微服务领域的通用标准，极大地降低了微服务的门槛，但这些技术框架依然没有办法解决其中两个最大的挑战，这两个挑战成为摆在开发者面前的两座大山。
资源利用率低的根本原因，在于以服务器为载体的应用架构中，开发者需要将构建好的程序包部署到服务器上，从而对多个用户事件进行响应。为了确保事件响应的及时性，需要让程序长驻于服务器上，而且尽可能保守的规划资源，以避免出现负载过重而导致服务崩溃的情况。在这个过程中，实际的负载在时间上分配并不均衡，从而导致整体的资源利用率偏低。
以 Spring Cloud 应用为例，如果需要部署一个新的应用，只需要 2 个步骤：
（1）告诉 SAE 这个应用需要多少个实例，并指定每个实例需要的 CPU / 内存规格。
（2）上传应用的 JAR 包 / WAR 包，并启动应用。
Serverless 技术存在多种形态，最典型的一种是 FaaS（Function as a Service，函数即服务），比如阿里云的函数计算（Function Compute，FC）产品。
让我们通过一个实际案例来进一步体会 SAE 如何帮助微服务应用降低资源成本。假设一个微服务系统包含 87 个应用实例，每个时间每天的平均运行时长为 8 小时，实例的配置为 2 Core + 4 GiB + 20 G 磁盘。
为什么称之为真正的**多活？**多活已经不是什么新鲜词，但似乎一直都没有实现真正意义上的**多活。一般有两种形式：一种是应用部署在同城两地或多地，数据库一写多读（主要是为了保证数据一致性），当主写库挂掉，再切换到备库上；
在权责方面，所有数据应该在源头统一，统一所有的数据基础层，并由一个团队负责和管控，其他团队无权复制数据基础层的数据。
目前正通过阿里云对外输出系列解决方案，包括通用数据中台解决方案、零售数据中台解决方案、金融数据中台解决方案、互联网数据中台解决方案、政务数据中台解决方案等细分场景。
容器镜像迅速成为了应用分发的工业标准。随后 Google 开源的 Kubernetes 因为其优秀的开放性、可扩展性和活跃的社区，在容器编排之战中脱颖而出，成为分布式资源调度和自动化运维的事实标准。
Serverless 理念及相关产品的推出已经走过差不多 7 个年头，在这个过程中云原生的技术也在不断成熟，包括Docker、 K8s 等。阿里云在 2018 年的时候就开始思考另一种 Serverless 形态，即 Serverless application，也就是 SAE 这款产品，其于 18 年 9 月上线，19 年商业化，至今也走过了 3 个年头。
