现代数据架构的7项关键技术

Jim Scott 陈琳华

这些关键技术正在“重塑”企业IT基础架构以实现对大量宝贵数据更加快捷和更加灵活的访问。

重新构建企业IT基础架构不是一件小事，其通常是由一系列不断变化的关键业务驱动因素引发的。如今企业的处境正是如此。简而言之，目前已经主导企业IT近30年的平台再也无法处理推动业务发展所需的工作负载。

数字化转型的核心是数据，而数据已成为了商业活动中最有价值的东西。长期以来，由于格式不兼容、传统数据库的局限性以及无法灵活地合并来自多个来源的数据导致企业未能充分利用数据。如今新出现的技术有望改变这种局面。

改进软件部署模型是消除数据使用障碍的一个主要环节。更高的“数据敏捷性”需要更加灵活的数据库和更具扩展性的实时流平台。事实上，至少有七种基础技术可以为企业提供灵活的实时“数据结构”。

与正在被取代的技术不同，这七项软件创新具有可扩展性，可满足众多用户和用例的需求。对于企业而言，这些技术可让他们做出更快且更明智的决策，从而带来更好的客户体验。

1. NoSQL数据库

RDBMS已经在数据库市场占据了近30年的主导地位。然而面对不断增长的数据量和越来越快的数据处理速度，传统的关系型数据库已经显得力不从心。得益于出色的处理速度和可扩展性，NoSQL数据库正在逐步占据主导地位。对于文档数据库，它们从软件工程角度提供了一個更为简单的模式。这种简单的开发模式不仅可加快产品上市速度，还可帮助企业更快地响应客户和内部用户的需求。

2.实时流平台

实时对客户做出响应对于客户体验来说至关重要。这也是为什么以消费者为导向的行业在过去十年中被全面颠覆的原因。它们与企业实时响应用户的能力密切相关。告之客户自己将在24小时内提供解决方案是一种非常糟糕的客户体验，因为客户已经在执行他们在23小时前做出的决定了。然而转向实时模式需要事件流。

虽然由消息驱动的应用程序已经出现了多年时间，但是今天的流平台与它们的前辈相比规模更大且成本更低。流处理技术近期取得的进步为许多新的业务优化方法奠定了坚实的基础。及时响应客户只是一个方面。通过为软件开发和测试团队提供实时反馈环路，事件流还可以帮助企业提高产品质量，以及更加迅速地开发出新的软件。

3. Docker和容器

容器对开发人员和运维人员以及企业本身都有很大的好处。传统的基础设施隔离方法是静态分区，即为每个工作负载分配一个独立且固定的资源（无论是物理服务器还是虚拟机）。静态分区的好处是更容易排除故障，但是提供大量未被充分利用的硬件需要很高的成本。例如，Web服务器平均仅使用10%左右的总可用计算资源。

容器技术最大的优势是它们能够创建一种新型隔离方式。那些对容器不甚了解的人可能会认为他们可以通过Ansible、Puppet或Chef等工具获得同样的优势，但是事实上这些技术相互间具有高度的互补性。此外，无论如何尝试，这些自动化工具都无法为那些在不同的基础设施和硬件设置之间自由移动工作负载创建所需的隔离性。同一容器可在本地数据中心的裸机硬件上运行，也可以在无需任何更改的情况下在公有云上的虚拟机中运行，而这是才是真正的工作负载移动性。

4.容器仓库

容器仓库对敏捷性至关重要。如果没有用于创建容器镜像的devops进程和用于存储容器镜像的仓库，那么每台运行容器的机器上都必须创建相应的容器。通过容器仓库，容器镜像可以从任意一台配置为从该仓库读取的机器上启动。在处理多个数据中心时，情况会变得十分复杂。如果在某个数据中心上创建了容器镜像，那么如何将该镜像移动到另一个数据中心上呢？理想情况下，企业可以通过聚合数据平台在数据中心之间映射该容器仓库。

其中的一个关键问题是，在本地部署和云端之间进行映射与在两个本地数据中心之间映射存在着很大的差异。不过，无论企业使用的是物理基础设施还是云基础设施，聚合数据平台提供的功能均可解决这一问题。

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进程，也可以是向NoSQL数据库添加OCR进程文本。我们可以设想一些更为有意思的方式，如每当上传图像时都可以通过机器学习框架对图像进行识别和评分。这方面没有什么限制。在定义了触发器事件后，一旦事件发生，那么函数就会被触发，随后函数将开始工作。

FaaS将成为微服务使用的下一个阶段。然而，用户在部署FaaS时必须考虑一个重要因素，那就是供应商锁定。FaaS隐藏了具体的存储机制、特定的硬件基础设施以及编排方式，而这些对开发人员来说都是非常重要的东西。这种抽象会导致托管的FaaS产品为整个行业制造出有史以来最大的供应商锁定机会。由于API未标准化，因此用户在不彻底放弃原来运行的东西之前想从公有云上的FaaS产品中迁移走几乎是不可能的。如果用户通过聚合数据平台中的事件以一种更为系统的方式使用FaaS，那么在云提供商之间迁移将会变得更加容易。