分布式架构出现的最初目的，是要解决单台机器的性能成为整个软件系统的瓶颈的问题。分布式架构也会引入一些新问题（比如服务的安全、容错，分布式事务的一致性），因此对软件开发这件事儿来说，不去做分布式无疑是最简单的。

云计算的成功其实已经实现了相对意义上无限性能。

对基于云计算的软件系统来说，无论用户有多少、逻辑如何复杂，AWS、阿里云等云服务提供商都能在算力上满足系统对性能的需求，只要你能为这种无限的性能支付得起对应的代价。这样”无服务“概念也就产生了。

无服务架构特点

  • 后端设施，指数据库、消息队列、日志、存储等这一类用于支撑业务逻辑运行，但本身无业务含义的技术组件。这些后端设施都运行在云中，也就是无服务中的“后端即服务”
  • 函数，指的就是业务逻辑代码。这里函数的概念与粒度，都已经和程序编码角度的函数非常接近了，区别就在于，无服务中的函数运行在云端，不必考虑算力问题和容量规划，也就是无服务中的“函数即服务”

无服务的愿景

  1. 不用考虑技术组件，因为后端的技术组件是现成的，可以直接取用，没有采购、版权和选型的烦恼
  2. 不需要考虑如何部署，因为部署过程完全是托管到云端的，由云端自动完成
  3. 不需要考虑算力，因为有整个数据中心的支撑，算力可以认为是无限的
  4. 也不需要操心运维，维护系统持续地平稳运行是云服务商的责任，而不再是开发者的责任

虽然无服务架构的远期前景也许很美好，但无服务中短期内的发展，并没有那么乐观。为什么这么说呢？ 与单体架构、微服务架构不同，无服务架构天生的一些特点，比如冷启动、 无状态、运行时间有限制等等，决定了它不是一种具有普适性的架构模式。所以除非是有重大变革，否则它也很难具备普适性。

无服务架构的局限性

​ 无服务天生“无限算力”的假设，就决定了它必须要按使用量（函数运算的时间和内存）来计费，以控制消耗算力的规模，所以函数不会一直以活动状态常驻服务器，只有请求到了才会开始运行。这导致了函数不便于依赖服务端状态，也导致了函数会有冷启动时间，响应的性能不可能会太好。

前面第一节讲到，在首次对分布式的探索失败之后，大型软件的发展出现了两个方向，一个是以分布式为基础的探索，另一个以不分布式为目的的探索。如果说服务网格是在分布式道路上的探索的最新方向，那无服务架构就是在不分布式这条道路上的努力 。但这两条路线的边界也是越来越模糊，最终将会在云端的数据中心处交汇。

需要注意的是：无服务和微服务、云原生并没有继承替代的关系，因此也不能有无服务比微服务更加先进的想法

思考题

是否了解、接触过无服务架构？无服务目前在中国处于起步的发展阶段，阿里云、腾讯云的无服务计算框架，都给了普通用户相当大的免费额度，你愿意去试一下吗？