大白话说serverless：关于无服务架构

Posted 2021-04-30 大魏分享

前言

本文仅代表作者的个人观点；

本文在书写过程中，请教了我的同事kylin，在此表示感谢；

本文的内容仅限于技术探讨，不能作为指导生产环境的素材；

一、Serverless是什么？

Serverless是什么？百度一下能搜出一大把介绍和广告，其本质是什么：

看不懂？

百度上的东西，其实我也看不懂。

在看了很多篇英文博客之后，加上最近补了一些Java EE的知识以后，我大致理解了Serverless的概念了。

Serverless中的server，指的是不是X86物理服务器，指的是App server，也可以叫EJB container，说简单点，就是传统WAS、Weblogic、JBoss的中间件。

所以，serverless，从字面上理解，就是要摒弃掉app server。

很荣幸，我最近正在看的JavaEE的内容，就是serverless要干掉的技术。

在搞清楚为啥要去app server之前，我先搞清楚什么是app server。

二、app server的本质是什么？

红帽的app server的名称叫JBoss EAP。它以前还有个名称，叫JBoss EJB container，听起来很拉轰。

这又带来了一个问题，什么叫EJB。

企业级软件的核心部分是它的业务逻辑。业务逻辑抽象了整个商务过程的流程，并使用计算机语言将他们实现。

J2EE 对于这个问题的处理方法是将业务逻辑从客户端软件中抽取出来，封装在一个组件中。这个组件运行在一个独立的服务器上，客户端软件通过网络调用组件提供的服务以实现业务逻辑，而客户端软件的功能单纯到只负责发送调用请求和显示处理结果。在J2EE 中，这个运行在一个独立的服务器上，并封装了业务逻辑的组件就是EJB（Enterprise JavaBean）组件。

上面这段话，听起来很高大上，好比这个样子：

别着急，我们来逐条剖析：

剖析1：所谓："业务逻辑" 

我们注意到在EJB 的概念中主要提到的就是"业务逻辑"的封装，而这个业务逻辑到底是什么？说的那么悬乎，其实这个所谓的"业务逻辑"我们完全可以理解成执行特定任务的"类"。

剖析2：所谓："将业务逻辑从客户端软件中抽取出来，封装在组件中……运行在一个服务器上"

既然我们知道了"业务逻辑"的概念就是执行特定任务的"类"，那么，什么叫"从客户端软件中抽取出来"？其实，这个就是把原来放到客户端的"类"，拿出来不放到客户端了，放到一个组件中，并将这个组件放到一个服务器上去运行。

 

变成大白话就是，"把你编写的软件中那些需要执行制定的任务的类，不放到客户端软件上了，而是给他打成包放到一个服务器上了"。EJB 就是将那些"类"放到一个服务器上，用C/S 形式的软件客户端对服务器上的"类"进行调用。

所以，用大白话说：（从java的角度）app server实际上就是运行jar包的一个软件平台。这些jar包中，包含了很多java的类。这些类可以被客户端远程或者本地调用。将jar运行到app server的好处，是实现了应用的分布式。

脱去了马甲，他变成了这个样子：

实际上App server是一个软件组件，提供必要的运行时环境和基础结构来托管和管理Java EE企业应用程序。 应用程序服务器提供诸如并发性、分布式组件架构、多平台可移植性、事务管理、Web服务、数据库对象关系映射（ORM）、异步消息传递以及企业应用程序安全性等功能。

关于Java SE和EE的区别，这是个老生常谈的话题：

用大白话说：JavaSE应用，我们可以通过java -jar直接运行；而Java EE应用，需要部署到app server上，才能运行。

JBoss的app server方案是EAP。它能提供的功能如下：

三、serverless的核心概念

去掉了App Server，剩下的就是一堆java class和调用的方法。那么他们之间的调用和协调如何实现？

通过serverless的方案实现。也就是，通过serverless的方案，替代传统的app server的功能（FaaS）。

谈到serverless，还有具体的两种方式:BaaS和FaaS。

BaaS和PaaS的区别在于：PaaS需要参与应用的生命周期管理，BaaS则仅仅提供应用依赖的第三方服务。典型的PaaS平台需要提供手段让开发者部署和配置应用，例如自动将应用部署到Tomcat容器中，并管理应用的生命周期。BaaS不包含这些内容，BaaS只以API的方式提供应用依赖的后端服务，例如数据库和对象存储。BaaS可以是公共云服务商提供的，也可以是第三方厂商提供的，

我们举个例子，在典型的PaaS平台，Openshift中，我们部署一个tomcat的web sever，将war包拷贝到容器中企业运行；不用的时候，将pod停掉（将rc设置为0）。在这个过程中，我们对应用进行了全生命周期的管理，我们叫PaaS。

BaaS（后端即服务：Backend as a Service）公司为移动应用开发者提供整合云后端的边界服务。例如AppCan，它可以提供的服务有：

• 信息推送。为android和ios终端分别提供基于MQTT和APNS技术的可靠高效信息推送能力，并保证推送信息到达的即时准确。

• 数据库。为移动应用提供了库、表、记录等级别的DDL和DML操作接口，支持多表关联处理和数据批量处理，提供记录导入、导出和检索管理能力，交付灵活的权限控制手段。

• 文件存储。为移动业务应用提供灵活的文件存储、上传、下载服务，支持存储配额操作接口，提供后台统计分析手段。

• 第三方接入。为企业业务应用提供第三方平台(新浪微博、微信、QQ)的接入能力，支持接入授权，快速降低应用注册门槛，方便用户快捷登录

我们可以将BaaS看作PaaS的一个子集，即使用第三方提供的PaaS服务。

在serverless中，FaaS是它的核心。而FaaS，正是上文提到的，通过新的技术，去掉传统app server的功能。那么，将传统的app server去掉以后，应用怎么运行呢？

这就需要看一下serverless的方案了。

四、serverless的方案

Serverless 在当前市场上主要有开源和闭源两类实践，如下表：

• 闭源的方案以 AWS Lambda 为代表，它以服务的方式呈现，在开发者一端，开发者参与到服务的构建，通常实现某特定方法，而在服务器端则需要依赖广泛的 AWS 上服务，如 API 网关、存储、数据库等

• 开源的方案以 Apache OpenWhisk 为代表，这种实现主要是围绕容器对应用开发标准化、规范化、自动化的特性去打造 Serverless，目前它的社区活跃，传统应用开发厂商积极参与，发展势头迅猛

在开源领域，Apache OpenWhisk是很火的。用大白话说，就是用Apache OpenWhisk 替代传统的app server的功能。

Serverless和微服务的区别是什么呢？

从笔者的角度看，微服务是将一个单体应用，拆成多个小的模块，每一个模块负责一个功能，各个模块通过zuul（spring cloud）串起来。而serverless，可以对一个小的功能模块接着拆，最终可以拆成java类的方法，所以serverless的最高境界-FaaS的F，指的就是类的方法、功能。或者，我们可以将FaaS理解成微服务的高阶阶段。

我们举个例子，一个传统的三层应用：

客户端的访问，通过浏览器：html + javascript，应用运行在app server上，连接后端的数据库使用JPA。

将这个架构改造成serverless，将会变成什么样子呢？

看起来好像更复杂了？没关系，解释一下就明白了。

组件1：表示：新的架构，删除了原有架构的认证组件，采用第三方的BaaS服务。如使用Auth0。这里，还得简单介绍一下Auth0。

Auth0是一个“身份即服务”创业公司，同时也是重度的云服务用户。  Auth0提供给了程序员和公司构建模块，使得保护应用程序变成一件简单的事，开发者不需要成为安全领域的专家，即可以轻松构建安全的应用。我们可以将任何应用（基于任何栈的任一种语言）连接到Auth0，也可以定义你想要使用的身份提供者（你想怎样让用户登录）。我们可以基于应用程序所使用的技术来选择相应的SDK（或者调用我们的API）来连接你的应用。每次用户试图登录，Auth0都会验证他们的身份并传回一些应用程序所需要的信息。

组件2：也提供BaaS提供：我们允许客户端直接访问我们数据库的一个子集（用于产品列表），它本身完全由第三方托管（例如，Google Firebase）。我们可能有不同的安全配置文件客户端以这种方式访问数据库，而不是访问数据库的服务器资源。

组件3：此前app server：Pet Store 中的某些业务逻辑，抽取出来，放到客户端内，例如：跟踪用户会话、了解应用程序的UX(UX是User experience的缩写,中文翻译为:用户体验。UX指用户体验,UX设计指以用户体验为中心的设计)结构，从数据库读取数据并将其转换为可用的视图等。由此，客户端正在成为单页应用程序。

组件4：我们可能需要保留一部分可客户体验相关的功能在app server上。这种通常是它的计算密集型或需要访问大量的数据。在我们的宠物商店应用中，典型的就是“搜索”。在这种情况下，我们也不需要像改造之前的架构，长期保留app server，我们可以通过API网关响应HTTP请求。这样也能实现FaaS。

组件5：我们用另一个单独的FaaS功能替换“购买”功能。由于这个功能比较重要，出于安全原因选择保留在服务器端，而不是在客户端实现。因此和搜索功能一样，它也被API网关管理。

我们对比一下新旧架构的区别：

在旧架构中，所有访问流量、控制和安全都由app sever管理。在新的架构中，app server，每个组件都扮演着更具架构意识的角色。以这种方式构建的系统通常“更灵活，更易于改变”。

 四、serverless在私有云中的技术实现

serverless在私有云中的技术实现：Apache OpenWhisk on Openshift。

其架构如下：

Apache OpenWhisk 架构分三个核心：

• 以 API 网关为中心的服务治理 - 云原生应用包括 Serverless 将一切服务化、与传统架构相比，对服务治理的需求更高，现代应用开发需要着重考量服务分类、流量控制、多级安全、记费、API 文档等。

• 以 Kafka 为中心的分布式消息处理层 - Kafka 在现代应用架构中的作用与日俱增，不管是分布式系统，流数据处理，业务集成、数据整合，企业数据湖构建等领域

• 以文件数据库 + 内存计算为中心的数据持层 - CouchDB 是一个文件数据库，基于 NO-SQL key/value 的实现方式，但在内存计算层有比较好的实践

• 以容器为中心的计算层 - 容器在计算层的优势在于可细粒度利用计算资源，可标准化计算单元，这些优势降低应用架构的复杂度，增强了应用架构的敏捷性

我们简单介绍一下工作原理：

事件：触发器(Trigger) - 可能触发一个活动的事件，例如，当一个叫贝克汉姆的人加入到聊天室 (newPersonJoin)

方法:一段短生命周期的代 码处理一个事件，例如，一个 Javascript 输出 "hello! welcome 贝克汉姆，你好帅!"

而方法的运行平台，就是Apache OpenWhisk on Openshift的pod里。

细心的朋友在看上图的时候，会发现JBoss少了个组件：EAP，没错，serverless就是为了去除EAP功能的，放大点看：

所以说，Apache OpenWhisk是将一堆很潮的技术攒到一起，替代了传统app server干的事情。很关键的一点是，Apache OpenWhisk 与当下基础架构中最火的容器有了联系，赋予了它更强的生命力与关注度。也就是说，最终OpenWhisk在Openshift上，将会以一堆pod呈现：

具体实验内容，请参照如下链接：

https://learn.openshift.com/serverless

所以说，serverless与微服务、API管理并不冲突；相反，这三个部件一起，组成了完整的私有云serverless解决方案：

参考文档：

https://github.com/apache/incubator-openwhisk-devtools/tree/master/java-action-archetype

http://ksoong.org/docs/content/jboss/faas/openwhisk.html?from=timeline&isappinstalled=0

https://martinfowler.com/articles/serverless.html

https://www.cnblogs.com/nineep/p/6828469.html

http://www.yunweipai.com/archives/16746.html

https://www.csdn.net/article/2014-12-24/2823285

魏新宇

• "大魏分享"运营者、红帽资深解决方案架构师

• 专注开源云计算、容器及自动化运维在金融行业的推广

• 拥有MBA、ITIL V3、Cobit5、C-STAR、TOGAF9.1（鉴定级）等管理认证。

• 拥有红帽RHCE/RHCA、VMware VCP-DCV、VCP-DT、VCP-Network、VCP-Cloud、AIX、HPUX等技术认证。