如何高效的利用好资源，是企业面临的一个普遍的难题。业界数据中心的统计数据表明，企业整体平均资源利用率是不高的，一般小于15%。要提高资源利用率，企业一般面临以下挑战：

• 各个业务部门资源使用相互独立，没有资源并池，没有统一调度。
  
• 出于对性能、负载峰值以及业务未来发展保障等因素的考虑，业务部门一般倾向于多申请资源，通常是实际使用资源的3-5倍。
  
• 非核心应用碎片化的资源消耗导致了大量资源浪费。大量非核心应用为了满足高可用的要求，至少需要2-3台机器，而这些应用很多时候是长尾、低频调用的，甚至业务下线但服务器忘了释放，造成资源浪费。在阿里巴巴集团，非核心应用消耗的资源甚至超过了核心应用。
  
• 不同性质的应用没有共享资源，没有削峰填谷，集群整体资源利用率不高。
  

容器化是提高资源利用率的有效手段，但实施的复杂度较高。阿里巴巴集团通过全站容器化，统一调度和离在线混部来提升资源的整体利用率，涉及到容器性能的优化、租户隔离、底层服务器算力归一化、定制的资源统一调度和离在线混部等等。

Serverless 的目标让企业用更简单的方式提高资源利用率，降低成本。

以函数计算为例，企业不需要为闲置资源付费，而是根据实际使用的资源付费。这意味着大量测试、预发甚至生产环境，大量非核心应用碎片化资源的使用场景，使用 Serverless 后资源利用率会非常高。

如果从性能角度考虑，需要预留一些资源，函数计算的闲置资源费用也比服务器更低。函数计算内置了多 AZ 容灾能力，企业不需要为容灾准备冗余资源。函数计算支持百毫秒级别的弹性伸缩速度和丰富的伸缩规则，企业不需要为峰值负载预留资源。

当云服务演进为 Serverless 形态后，企业的使用门槛大大降低，Serverless 将让算力像电力一样普及。

Serverless 引领下一代应用架构

驱动研发模式升级

应用架构和研发模式的演变主要是由企业的业务发展诉求推动的。企业总是期望能够更敏捷的应对业务规模和复杂度的增长，更快的将产品推向市场，加快业务创新的速度，这就要求技术能支持大规模、复杂软件的快速迭代。

传统的企业级应用架构，通常是单体的，所有模块都耦合在一起，同时发布。这种单体架构应用在一开始是易于管理的，但随着业务发展，会带来巨大的复杂度。这种强耦合的架构带来开发、测试和运维过程中大量的冲突，拖慢了整个迭代速度。

例如整个应用的开发要求所有模块采用统一的语言和框架技术栈，如果一个基础库被多个模块共享，其中一个模块想要升级到新版本，则需要说服所有人同时升级，即便其他人并不需要新版本。所有模块的发布节奏被强行拉齐，一个模块的问题会影响整个应用的发布。

想要快速修复某个模块的线上问题也变得非常困难，因为这需要和其他模块正在进行中的变更合并，解决冲突，重新发布整个应用，运行所有测试，才能重新发布上线。单体应用架构已经不能满足软件研发效率的要求，被以微服务为主要特征的互联网分布式架构取代。

采用微服务架构后，应用程序由独立的服务组成。这些服务是松耦合的，通过 API 调用、事件触发或者数据流的方式交互。每个服务都完成一个特定的功能，独立开发、运行和发布。

微服务解决了单体架构的研发效率瓶颈，但是对应用的基础设施提出了非常高的要求。

例如，为了确保独立开发的微服务能够按预期协调配合，需要进行详尽的集成和端对端测试。测试环境中的应用部署次数通常是生产环境的10倍。如果应用基础设施不能快速提供独立的测试环境，那么大量的测试时间将消耗在环境稳定性问题的解决上。

根据阿里巴巴集团的研发统计数据，1人日的研发，通常对应5-7人日的测试。测试环境已经成为阿里巴巴集团研发提效的最大痛点。

微服务的松耦合，也对数据库使用、状态管理、问题诊断、应用交付流水线带来了很大的挑战。关于微服务的复杂度以及解决方案，业界已经有非常多的讨论，这里不再赘述。

以微服务为核心的互联网分布式架构，实施的复杂度较高，必须有很好的工具、平台的支撑，这是业界的共识。

除了微服务架构，企业也广泛使用反应式架构、事件驱动架构等模式，这些架构都带来了松耦合、敏捷开发等好处，但相应的落地复杂度也变高了。

事实上，业界在应用的构建、编排、运行、BaaS 服务、基础设施管理等每一方面，都提供了丰富的产品和解决方案，建立了庞大的生态。但企业要整合这些软件/服务，让它们弹性、稳定、相互集成良好，加速应用开发迭代，这绝非易事。