1.5 互联网核心架构的演变

移动互联网的普及，使C端客户有了爆发性的增长，原有的面向企业内部的系统，现在要面向互联网受众，对系统的要求有了根本性的改变，系统的复杂度大幅提高。最直观的体现是在软件工程中组织结构分工更细，责任更加明确。在早期的软件开发过程中，一个好的项目骨干甚至可以承担从需求调研到界面设计、技术开发等全部工作，而现在的互联网软件开发包括了前端工程师、后端工程师、产品设计师等等不同的工种。在技术架构上也经历了类似的历程。系统架构从早期的大包大揽的单体架构，逐渐演变到基于微服务的架构，乃至应用云的架构。系统架构的演变过程见图1-5。

如图1-5所示，系统架构的演变经历了如下过程。

■ 最早期的应用是以CS架构为主的，稍后逐渐发展为BS架构。BS架构在服务端是一个大包大揽的all in one的架构，所有的服务功能在一个应用内。

■ 单体应用出现性能问题时，通过水平复制应用，在前端通过Nginx进行反向代理，实现负载均衡。

■ 单个应用的复制解决不了问题，此时将巨大的单体拆分成多个系统，多个系统间通过服务调用协同解决问题，所以又提出了面向服务的架构。

■ 随着系统服务数量的增多，需要通过服务治理手段，管理企业系统内部各应用间的互联互通，这就形成了以ESB为核心的架构。

■ 随着移动互联网的发展，产生了微服务的架构。微服务架构就是技术架构更加专业化、精细化的表现，是在业务服务化的基础上对服务的更加精细化管理的架构。

■ 微服务架构采用侵入性设计，不支持多语言，因此产生了Service Mesh（服务网格）架构，通过抽象出负责网络通信的“Sidecar”，将业务逻辑与服务治理完全分隔。

■ 云原生架构，完全基于云平台的弹性计算能力的架构，应用系统在最初就基于云进行设计，并在云上以最佳方式开发、测试、部署和维护。

1.5.1 Monolith单体架构

一个单体应用系统是以一个单个单元的方式来构建的。一个BS架构的应用系统经常包含三个主要部分：客户端用户界面、数据库和服务端应用系统。服务器端所有的功能打包在一个WAR包里，部署在一个JEE容器（Tomcat，JBoss，WebLogic）中，基本没有外部依赖（除了容器）。单体架构强调内部垂直分层，如MVC结构，包括展示层、控制层、数据层。该系统的任何改变，都会涉及构建和部署上述服务端应用系统的一个新版本。

单体架构有很多好处：处理用户请求的所有逻辑都运行在一个单个的进程内，因此能使用编程语言的基本特性，把应用系统划分为类、函数和命名空间；容易测试，在开发人员的笔记本电脑上就可以运行和测试这样的应用系统；容易部署，直接打包为一个完整的包，复制到Web容器的某个目录下即可运行；容易扩展，通过负载均衡器运行许多实例，将这个单体应用进行横向扩展。

单体应用系统可以被成功地实现，但是随着越来越多的功能被部署到服务端，对于大规模的复杂应用，单体架构应用会显得特别笨重。软件变更受到了很大的限制，应用系统中一个很小的变更，也需要将整个单体应用系统进行重新构建和部署，编译时间过长，回归测试周期过长，开发效率降低。单体架构也不利于更新技术框架，除非你愿意将系统全部重写。随着时间的推移，单体应用逐渐难以保持良好的模块化结构，这使得它越来越难以将一个模块的变更产生的影响控制在该模块内，当对系统进行扩展时，不得不扩展整个应用系统，而不能仅扩展该系统中需要更多资源的那些部分。

1.5.2 Microservice微服务架构

单体架构在扩展时无法实现对业务的精细化管理。如图1-6所示，一个应用中，在同一个WAR包中打包了数个业务，其中某个业务的负载已经达到了90%，而同一应用下的其他三个组成的负载较低。因此添加一个额外的应用实例虽然可以将需要扩容的业务的负载降低到45%，但是也使得其他各业务的利用率更为低下。解决之道就是Microservice，即微服务架构。

Martin Fowler在ThoughtWorks提出了Microservice的架构，对Microservice是这样定义的：Microservice体系结构风格是一种将单个应用程序开发为一组小型服务的方法，每个服务都在自己的进程中运行，并与轻量级机制（通常是HTTP）通信。这些服务是围绕业务能力构建的，可以通过完全自动化的部署机制进行独立部署。对这些服务的集中管理是最低限度的，这些服务可以用不同的编程语言编写，并使用不同的数据存储技术。

如图1-7所示，在开始阶段使用Microservice架构模式开发应用的效率低于Monolith。但是随着应用规模的增大，基于Microservice架构模式的开发效率将明显上升，而基于Monolith模式开发的效率将逐步下降。

在开发初期，Microservice的复杂性会导致开发效率较低，随着规模的扩大，由于Microservice架构模式中依赖的子服务已经完成，开发过程通常只需要关注自身的业务逻辑即可提高开发效率。而随着Monolith模式中应用的功能逐渐变大，增加一个新的功能会影响到该应用中的很多方面，因此其开发效率会越来越低。

Microservice背后的理念是将大型、复杂且历时长久的应用在架构上设计为内聚的服务，这些服务能够随着时间的流逝而演化。服务分割的粒度是面向服务架构中首要考虑的因素。如果一个服务的粒度太小，会导致频繁的调用，导致服务的嵌套调用，使调用过程中网络消耗占比较高，得不偿失。服务粒度太大，又失掉灵活性。在Microservice架构模式中，需要站在最终用户的视角分割服务，一个服务需要能够独立地完成特定的业务逻辑，至少是某个独立资源的CRUD操作。例如在电子商务网站中，需要一个创建订单服务，一个查询订单服务，一个取消订单服务等。Microservice的最好例子就是UNIX的各种命令，如find、grep等。

Microservice这个术语强烈建议服务应该是很小的，一个原子服务不应该消耗很多的资源，如不应在一个原子服务中进行跨库操作。在涉及用户交互时，常常为了减少前端的调用，需要提供一个组合服务，负责组装多个原子服务。组合服务可能涉及多个数据库的操作，使用分布式事务存在较大风险，一般情况下可以考虑使用数据最终一致性的方案。

其他Microservice架构需要考虑的基本问题包括：服务提供者如何注册服务，消费者如何找到服务提供者；服务消费者与服务提供者之间如何通信，是同步还是异步，采用什么样的协议；在一个服务的多个实例间如何进行负载均衡，消费者实现还是服务提供者实现，都有哪些负载均衡策略；怎样保证系统健壮，将坏服务的影响降到最低，实现限流、熔断、降级等机制；从服务的消费、调用乃至嵌套调用过程中如何跟踪服务的调用过程，判断服务消耗时间，做好服务监控。

显而易见，Microservice模式带来了较大的架构复杂性。在《Introduction to Microservices》这篇文章中对Microservice的优点和缺点有系统的描述。

Microservice架构的优点包括复杂度可控、独立按需扩展、技术选型灵活、容错和可用性更高。

■ 通过分解巨大的单体式应用为多个服务方法解决了单体应用的开发维护等复杂问题。在功能不变的情况下，应用被分解为多个可管理的分支或服务。每个服务都有一个用RPC或者消息驱动API定义清楚的边界。每个服务都更容易开发、理解和维护，提供了模块化的解决方案。

■ 这种架构使得每个服务都可以由专门开发团队来开发，带来了组织结构的自主性。开发者可以自由选择开发技术，提供API服务。当然，许多公司试图避免混乱，只提供某些技术选择。这种自由意味着开发者不需要被迫使用某项目开始时采用的过时技术，他们可以选择现在的技术。甚至，因为服务相对简单，即使使用新技术重写以前的代码也不是很困难的事情。

■ Microservice架构模式使每个微服务都能独立部署。开发人员不需要协调部署本地服务的变更。这些变化可以在测试后尽快部署。例如，UI团队可以执行A/B测试，并快速迭代UI更改。Microservice架构模式使连续部署成为可能。

■ Microservice架构模式使每个服务都可以独立调整。可以根据每个服务的实际需求来调整服务实例的数量，也可以使用最符合服务资源要求的硬件。

Microservice的主要缺点是精细化管理产生的复杂性，包括服务间通信成本、数据一致性、系统部署依赖、集成测试规模、多服务运维难度、性能监控等问题。

■ 开发人员需要选择和实现基于消息传递或RPC的进程间通信机制。此外，他们还必须编写代码来处理部分故障，因为请求的服务器提供者可能响应很慢或不可用。

■ Microservice应用是分布式系统，由此会带来固有的复杂性。开发者使用RPC或者消息传递机制实现进程间通信，需要处理消息内容重复和信息顺序混乱等问题。

■ Microservice的另一个挑战是分区数据库架构。在基于微服务的应用程序中，常常需要更新不同服务所拥有的多个数据库，使用分布式事务通常不是一个好的选择，最后不得不使用最终一致性的方法。

■ 测试Microservice应用程序也更复杂。测试一个基于微服务架构的应用也是很复杂的任务。相比单体应用，同样的服务测试需要启动和它有关的所有服务，测试需要覆盖不同服务间的可靠性等问题。

■ 在Microservice架构模式下，应用的改变会波及多个服务。例如，假设要完成一个案例，需要修改服务A、B、C，而A依赖B，B依赖C。在单体式应用中，只需要改变相关模块，整合变化，就部署好了。相比之下，微服务架构模式就需要考虑相关改变对不同服务的影响。例如，需要更新服务C，然后是B，最后才是A，幸运的是，许多改变一般只影响一个服务，而需要协调多服务的改变很少。

■ 部署基于Microservice的应用程序也更复杂。单一应用程序只需要简单地部署在负载平衡器后面的一组相同的服务器上。每个应用程序实例都配置有相同的基础元数据（如数据库和消息代理的主机和端口）。相比之下，微服务应用通常由大量服务组成。每个服务将有多个运行时实例。更多的部件需要进行配置、部署、扩展和监控。此外，还需要实现服务发现机制，使服务能够发现需要与之通信的任何其他服务的位置（主机和端口）。传统的基于手动操作的方法无法扩展到这种复杂程度。因此，成功部署微服务应用程序需要开发人员更好地控制部署方法，并实现高水平的自动化。

1.5.3 Microservice与SOA

1.SOA架构

面向服务的架构（Service Oriented Architecture，SOA）是指系统由多个服务组成，服务通常以独立的形式存在于操作系统进程中，各个服务之间通过网络进行调用，服务之间通过相互依赖最终提供一系列的功能。

2.SOA主要解决的问题

业务系统集成化：整体解决企业系统间的通信问题，通过引入ESB、技术规范、服务规范等技术，把原先散乱并且无规划的网状系统结构，梳理成规整且可治理的星形系统结构。

业务功能服务化：把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生，把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用。

3.SOA与ESB

SOA一般使用ESB（企业服务总线）作为核心架构，ESB是将传统的单点集成转化为总线式集成的核心部件，它集成不同系统不同协议的服务，连接服务节点，通过信息的转化和路由使服务互联互通，是企业内部业务系统间业务协同和数据集成的高速公路。ESB一般采用集中式转发请求，适合大量异构系统集成。通过把系统里的集成逻辑单拉出来，放到ESB中部署，并与应用系统适配，让应用系统变得只有自己的业务逻辑，应用系统简单、轻薄。但所有的服务上增加了一个ESB总线作为沟通的渠道，对于较大的并发，会将瓶颈推到ESB总线上。很多时候，ESB总线都采用MQ消息队列服务异步处理来缓解压力。

ESB的主要功能包括：格式转换、协议转换、服务代理、服务编排、安全控制、系统监控、路由转发等。ESB产品的代表有：JBoss ESB，Mule，Camel等中间件。JBoss的ESB组件见图1-8。

4.Microservice与SOA

技术架构都是业务驱动的，SOA与Microservice是不同时代需求背景的产物。

大型企业内部信息系统关系错综复杂，需要对服务进行编排集成，因此产生了以ESB为核心的SOA架构。如图1-9和图1-10所示，Apache的路由中间件Camel支持50种集成模式、80多种协议规范与通信连接、19种数据格式和15种语言。

微服务是互联网场景下产生的，解决的是互联网背景下的高并发、快迭代的问题。微服务是SOA的传承，是SOA组件化架构思想的推进，但更强调分布式应用的强健壮、适用于高并发场景。Microservice的主要功能包括服务注册和发现、服务网关、服务监控、负载均衡、安全控制等。例如使用Microservice中的服务注册和发现能力，子业务系统可以通过注册中心很快找到对应的服务，但实际访问仍然是点对点的服务调用，适合并发及压力比较大的情况。Microservice中间件的代表包括：Dubbo，HSF，Spring Cloud，Motan等。

SOA与Microservice都着重于服务治理的功能。SOA着重强调规范管理、服务重用和系统协同。SOA中一般提倡ESB，服务规范，WS等概念。尝试将应用集成，强调服务组合和编排能力，一般采用中央管理模式来确保各应用能够交互运作。

Microservice以提高服务性能、提供服务健壮性、实现服务自治为主要目的。Microservice倾向于降低中心消息总线（类似于ESB）的依赖，采用分布式的去中心化设计，去掉大一统的ESB，服务间轻通信（REST），不强调服务规范。Microservice不再强调服务组合和编排能力，实践证明服务组合和编排能力会导致较重的系统架构。微服务架构强调限流容错，着重于分散管理与自动化部署，单体应用要打散为多个独立自治并可以在独立进程中运行和管理的微服务模块。ESB与Microservice在架构上的区别如图1-11所示。

1.5.4 Servicemesh服务网格架构

Microservice架构采用了非中心化的设计，但需要提供客户端组件和服务端组件。客户端组件嵌入在服务消费者应用程序中，负责从注册中心及时获得最新的服务提供者地址，并做负载均衡。服务端组件需要在启动时向注册中心注册自己并定期报告心跳。微服务的架构如图1-12所示。

在《Pattern：Service Mesh》这篇文章中对微服务架构的缺点和演变进行了解析（见https://philcalcado.com/2017/08/03/pattern_service_mesh.html）。

微服务架构需要在服务消费者进程和服务提供者进程中嵌入代理，这些基础架构相关的逻辑是与业务架构耦合在一起的，是一种侵入式设计，如图1-13所示。Spring Cloud的Eureka注册中心和Ribbon客户端代理，Dubbo的注册中心和客户端都是这种模式的体现。这种设计无法支撑多语言环境，业务架构和基础架构不能单独演进。

为了解决这个问题，需要将这些入侵业务架构的功能抽象出来，作为一个独立的功能。这个独立的服务被称为Sidecar，这种模式叫作Sidecar模式，如图1-14所示。Sidecar模式是一种将应用功能从应用本身剥离出来，作为单独进程的方式。该模式允许我们向应用无侵入式地添加多种功能，避免了为满足第三方组件需求而向应用添加额外的配置代码。就像边车加装在摩托车上一样，在软件架构中，Sidecar附加到主应用（或者叫父应用）上，以扩展/增强功能特性，Sidecar与主应用是松耦合的。对每个微服务节点，都需要额外部署一个Sidecar来负责业务逻辑外的公共功能，所有的出站入站的网络流量都会先经过Sidecar进行各种处理或者转发。微服务的开发不需要考虑业务逻辑外的问题。

在图1-15中，线条代表了服务间的通信，线条串起来的方块为Sidecar，Sidecar旁边的方块为服务。所有的Sidecar都是一样的，只需要部署的时候使用编排工具即可方便地为所有节点注入Sidecar，服务之间通过SideCar发现和调用目标服务，从而形成服务之间的网络状依赖关系，Service Mesh（服务网格）因此得名。

Service Mesh最早由开发Linkerd（最早实现Service Mesh理念的产品）的Buoyant公司（前Twitter基础设施工程师创办）提出，Buoyant公司的CEO William Morgan定义Service Mesh的概念如下：

A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It's responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.

即：服务网格是一个专门处理服务通信的基础设施层。它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送。在实践中，它是一组和应用服务部署在一起的轻量级的网络代理，并且对应用服务透明。

通过服务网格可以完成以下事项。

■ 支持多语言，为异构（微）服务框架/平台提供融合发展的可能。

■ 为单体应用向微服务架构演进提供渐进的途径。

■ 业务开发聚焦于业务逻辑本身，业务开发时无需关心安全、灰度、限流、熔断等通用的技术内容。

■ 基础架构和业务架构可以独立演进。

■ 对（异构）微服务架构应用实现更为有效的全局一体化监管控。

图1-16是服务网格框架Istio的示例图（https://istio.io/docs/examples/bookinfo/）。一个bookinfo视图，业务逻辑由productPage microService实现，productPage又调用了detailService和不同版本的ReviewsService，ReviewsService又调用了RatingsService，这些不同的服务采用了不同的语言编写。在应用服务网格框架Istio后，在每个Service侧按照Sidecar模式部署了服务代理，既整合了不同语言的服务，又保证了各个服务的独立演进。

1.5.5 Cloud Native云原生架构

1.云原生的由来

云原生（Cloud Native）的概念，由来自Pivotal的Matt Stine于2013年首次提出。2015年Matt Stine提出了云原生架构应该具备的特征，包括微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）和12要素（The Twelve-Factor）、基于API的协作、抗脆弱性等几大主题。

■ 12要素应用程序：云原生应用架构模式的集合。

■ 微服务（MicroServices）：独立部署的服务，每个服务只做一件事情。

■ 自助服务的敏捷基础设施：快速，可重复和一致地提供应用环境和后台服务的平台。

■ 基于API的协作：发布和版本化的API，允许在云原生应用架构中的服务之间进行交互。

■ 抗压性：根据压力变化的系统。

2017年，Matt Stine进一步归纳云原生的特征为：模块化、可观察、可部署、可测试、可处理、可替代。

2015年Google主导成立了云原生计算基金会CNCF（Cloud Native Computing Foundation），最初定义云原生应包含应用容器化、面向微服务架构、应用支持容器的编排调度。

2018年，CNCF在云原生定义中加入了serviceMesh。官网（https://github.com/cncf/toc/blob/master/DEFINITION.md）上的定义中英对照如下。

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach. （云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。）These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil. （这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统做出频繁和可预测的重大变更。）

2.云原生的含义

顾名思义，云原生就是应用基于云而生，应用系统在最初就基于云进行设计，并在云上以最佳方式开发、测试、部署和维护。

云原生概念起源于大厂商云平台的成熟，云计算的3层概念（基础设施即服务（IaaS）、平台即服务（PaaS）和软件即服务（SaaS））已经完善并足以支撑起软件生命周期的各个环节。

无论如何解释云原生，其出发点都是为了将业务处理逻辑从其他复杂的事务中干净彻底地抽象隔离。云原生的各种定义都包含了下列含义。

（1）云原生系统应使用Microservice、service mesh技术，以隔离技术架构对业务处理逻辑的侵入。

使用云原生架构，有必要应用Microservice、service mesh技术。在核心技术架构层使用Microservice这一类架构，一方面提供了松耦合的能够被独立开发和部署的无状态化服务，另一方面提供了完善的服务治理能力，从而使核心业务能够独立扩展、升级和可替换，进而应用云基础设施。

（2）云原生系统应该是面向Iaas、PaaS和SaaS服务设计的，以隔离基础设施对业务处理的侵入。

云原生开发模式意味着要充分利用基础设施即服务（IaaS）、平台即服务（PaaS）和软件即服务（SaaS）的能力。一方面，云平台要保证资源的提供能够实现需求，租户不需要关注资源的细节情况，并拥有充分的自主能力，构建基础设施服务于开发、测试、联调和灰度上线等需求。同时要求业务开发具有较好的架构设计，技术人员使用各个层级的云服务都是通过代码来完成的，并且是自动化的，不能通过手工安装或克隆的方式来管理服务器资源。基础设施通过代码来进行更改、测试，在每次变更后执行测试的自动化流程中，确保能维护稳定的基础设施。不需要依赖本地数据进行持久化，所有的资源都是可以随时拉起，随时释放，同时以API的方式提供弹性、按需的计算、存储能力。

（3）云原生系统应该是有利于DevOps持续集成的，以隔离专业复杂的开发运维管理对业务快速迭代的影响。

云原生开发模式应打破软件生命周期中各个干系人的隔阂，促进开发部门、运维部门和质量保障部门之间的沟通、协作与整合。通过自动化的方式实现持续集成、持续部署、持续发布，确保持续、快速地完成一个个较小的任务目标，完成从开发和测试，再到代码快速、安全地部署到产品环境的全流程。每当开发人员提交了一次改动，就立刻进行构建、自动化测试，确保业务应用和服务能符合预期，确保新代码和原有代码能正确地集成在一起。在持续集成完成之后，要能够发送到预发布系统上，达到生产环境的条件，乃至最后将应用安全地部署到产品环境中。云原生模式要打通开发、测试、生产的各个环节，自动、持续、增量地交付产品，容器和容器编排是完成这个自动化过程的基础。

（4）云原生系统应遵循有利于云原生实施的软件架构模式。

互联网应用在设计过程中，需要遵循一些基本原则，以便用好云设施，并通过云原生模式实现从小规模集成单元到复杂的分布式系统的交付过程。主要原则包括：显式声明第三方类库依赖关系；使用环境配置而不是代码配置；只保持一份基础代码；统一且不加区别地对待本地服务和第三方服务；使用网络通信避免通过本地文件或进程通信；进程无状态且无共享；应用无状态能弹性伸缩；区分构建发行与运行的不同配置；研发测试和生产环境相似以利于持续集成；收集日志使系统可视化等。

3.Serverless架构

Serverless直译为中文是“无服务器”。其含义是指基础设施租户只需要管理“服务”，而不需要管理“服务器”，服务器的管理以及资源分配对用户不可见。另外，对于租户，Serverless是付完即走，基于实际的消费而不是基于预测的预付款进行收费的。可见，Serverless是云原生思想的一种更为彻底的落地模式。国内外的各大云厂商Amazon、微软、Google、IBM、阿里云、腾讯云、华为云相继推出了Serverless产品。

使用Serverless框架之后，应用开发者的整个操作流程就变成了：只需要编写代码（或者函数），以及配置文件（如何构建、运行以及访问等声明式信息），然后进行非常简单的build和deploy操作就能把应用自动部署到集群（可以是公有云，也可以是私有的集群），其他事情都是Serverless平台自动处理的。

■ 自动完成代码到容器的构建。

■ 把应用（或者函数）和特定的事件进行绑定：当事件发生时，自动触发应用（或者函数）。

■ 自动的网络路由和流量控制。

■ 应用的自动伸缩。

Serverless架构的一种典型模式是FaaS（Function as a Service，函数即服务）。例如开发一个图片上传和分析的功能，传统的开发需要关注Tomcat容器，需要MVC架构，而使用FaaS，只需要实现一个Function Handler，处理图片上传完成这个事件，在Function Handler中调用图片识别的相关逻辑，然后调用数据库的REST API存储结果。过程中不用构建MVC，不用配置Tomcat的XML文件，数据持久化直接使用对象存储相关服务。这个应用也不需要7×24小时运行，没有用户上传图片时它只是一份编译好的代码，当用户图片上传完成时，FaaS会为AI应用启动一个新的进程执行代码，该进程在代码执行完成后自动销毁，应用的所有者只需为代码执行的这几十秒钟付钱，节省了很多开支。也无需操心Auto-Scaling的问题，FaaS会在需要的时候自动扩展。

上述过程中，使用了公共云提供的对象存储服务，在Serverless架构中也叫BaaS（Backend as a Service，后端即服务）。BaaS是PaaS的一种特例，它们的区别在于：BaaS仅提供应用依赖的第三方服务，而典型的PaaS平台需要参与应用的生命周期管理，需要提供手段让开发者部署和配置应用，例如自动将PaaS应用部署到Tomcat容器中，并管理Paas应用的生命周期。BaaS不包含这些内容，BaaS只以API的方式提供应用依赖的后端服务，例如数据库和对象存储。

knative是Google开源的serverless架构方案，旨在提供一套简单易用的Serverless方案，把Serverless标准化。目前参与的公司主要是Google、Pivotal、IBM、Red Hat。knative是为了解决以容器为核心的serverless应用的构建、部署和运行的问题。knative是基于Kubernetes和Istio开发的，它使用Kubernetes来管理容器（deployment、pod），使用Istio来管理网络路由（VirtualService、DestinationRule）。

目前serverless架构尚未完全成熟，云厂商依然在致力于基础设施的封装和屏蔽，同时云厂商也需要解决下列问题。

■ 性能问题，包括服务冷启动带来的延迟以及低性能问题、高并发函数实例扩缩容，大规模业务下函数实例的集群管理等。云服务提供商通常会降低那些不经常使用环境的资源，也会限制可用资源的总量，由此带来响应延迟等低性能问题。

■ 开发者生态问题，Serverless架构在监控、debug调试、DevOps等方面的上下游支持还不完善；任何云计算工作事实上都会运行在一个公有云环境，而你无法控制或者进入这些云环境，导致监控、调试以及安全性都无法保障。