5.容器编排

每个容器看起来都有它自己的私有操作系统,而不是静态硬件分区。与虚拟机不同,容器不需要计算和内存的静态分区。这使管理员能够在服务器上启动大量容器,而无需担心大量的内存量。有了像Kubernetes这样的容器编排工具,启动容器,移动它们并在环境中的其他地方重新启动容器变得非常容易。

在新的基础设施组件到位之后,诸如MapR-DB或MongoDB之类的文档数据库,MapR-ES或Apache Kafka之类的事件流式传输平台(诸如Kubernetes之类的编排工具),以及在Docker容器中实现用于构建和部署软件的DevOps过程之后,人们必须了解应该在这些容器中部署哪些组件的问题。

6.微服务

从历史上看,微服务的概念并不新鲜。如今的差异在于,启用技术(NoSQL数据库、事件流、容器编排)可以随着数千个微服务的创建而扩展。如果没有这些数据存储、事件流和架构编排的新方法,大规模微服务部署将不可能实现。管理大量数据、事件和容器实例所需的基础设施将无法扩展到所需的级别。

微服务都是与提供敏捷性有关。微服务通常由一个功能或一小组功能组成。工作的功能单元越小且越集中,创建、测试和部署服务就越容易。这些服务必须解耦,否则企业将失去具有敏捷性的微服务承诺。微服务可以依赖于其他服务,但通常通过负载平衡的REST API或事件流。通过使用事件流,企业可以利用请求和响应主题轻松跟踪事件的历史记录。由于整个请求流和请求中的所有数据都可以在任何时间点重播,因此这种方法对故障排除具有重大的益处。

由于微服务封装了一小部分工作,并且由于它们彼此分离,所以随着时间的推移更换或几乎没有障碍地升级服务。在原有模式下,依赖像RPC这样的紧密耦合意味着不得不关闭所有连接,然后重新建立它们。负载均衡是实现这些的一个大问题,因为人工配置使它们容易出错。

7.功能即服务

正如人们已经看到微服务在行业中占据主导地位,所以人们也会看到无服务器计算的兴起或者可能更准确地将其称为功能即服务(FaaS)。 FaaS以这样一种方式创建微服务,即代码可以包装在轻量级框架中,内置于容器中,按需执行(基于某种触发器),然后自动进行负载平衡,多亏有了轻量级框架。FaaS的美妙之处在于它让开发人员几乎完全专注于该功能。因此,FaaS看起来是微服务方法的合乎逻辑的结论。

触发事件是FaaS的关键组成部分。没有它,只有在需要完成工作的情况下,才能调用功能和消耗资源。功能的自动调用使得FaaS真正具有价值。想象一下,每当有人读取用户的配置文件时,都会有一个审计事件,这是一个必须运行以通知安全团队的功能。更具体地说,它可能仅过滤出某些类型的记录。它可以是具有选择性的,毕竟它是一个完全可定制的业务功能。需要注意的是,使用像FaaS这样的部署模型来完成这样的工作流程非常简单。

把事件放在一起

触发服务背后的魔力实际上不过是事件流中的事件。某些类型的事件比其他事件更频繁地用作触发器,但是企业如果希望成为触发器的事件都可能成为触发器。触发事件可以是文档更新,对新文档运行OCR过程,然后将OCR过程中的文本添加到NoSQL数据库。如果人们以更有趣的方式思考,每当上传图像时,都可以通过机器学习框架进行图像识别和评分。这里没有根本的限制。如果定义了一个触发器事件,发生了一些事件,该事件触发该功能,并且该功能完成其工作。

FaaS将成为采用微服务的下一个阶段。然而,接近FaaS时必须考虑一个主要因素,那就是供应商锁定。 FaaS隐藏了特定的存储机制、特定的硬件基础架构和编排,这对开发人员来说都是伟大的事情。但由于这种抽象,托管的FaaS产品是IT行业有史以来最大的供应商锁定机会之一。由于这些API不是标准化的,因此从公共云中的FaaS产品迁移几乎是不可能的,不会丢失已经完成的近100%的工作。如果通过利用来自融合数据平台的事件以更有条理的方式接近FaaS,那么在云计算提供商之间移动将变得更加容易。