跳转至

开发区块链和物联网解决方案的最佳实践

正如每个新兴技术的情况一样，成为早期采用者充满了挑战和需要学习的课程。本章的重点是介绍一些我们可以应用到现实项目中的解决方案，以避免陷入困境。

本章将涵盖以下主题:

  • 云应用的参考架构
  • 如何使用 12 因素应用程序开发模型创建云原生应用程序
  • 无服务器计算
  • 使用 Hyperledger Composer 作为应用程序开发的加速器

开发云应用

有许多与云应用程序相关的潜在陷阱，从简单的资源滥用到无法解决的问题。应用一个简洁的架构和使用 12 因素应用程序开发模式可以确保您在应用程序伸缩时不会遇到麻烦。

容器是打包应用程序及其所有依赖项的标准化方式，包括其代码、运行时、中间件、库和操作系统。Docker 和 Garden 是可以在 IBM 云平台上运行的容器，但是也可以使用其他类型的容器，比如 Rockt。使用容器增加了应用程序的可移植性，因此，如果主机操作系统是 Linux 的一个特定发行版，而您的应用程序是在另一个发行版上构建的，这都没有关系，因为操作系统是容器化应用程序的一个层，两个发行版是一起发布的。

下图展示了容器化应用程序的结构:

云平台使用容器化的应用程序，并将它们部署到一组服务器中。我们可以将这些应用程序移动到灵活计算环境中，以更好地利用现有的基础设施，并跟踪部署在服务发现组件中的容器。

每个平台都有自己使用应用程序部署的容器化模型的方式，如下图所示:

容器是基于容器映像部署的，容器映像是基础映像、依赖项和应用程序的只读定义。同一应用程序的每个容器都是基于该映像部署的，运行时对该容器所做的任何更改仅在该容器处于活动状态时存在，并且仅适用于该容器的实例。

参考架构

云计算为部署应用程序创建了一个抽象的环境；我们使用虚拟运行时。这意味着我们没有位置感知能力，也不能保证我们的应用程序会停留在同一个数据中心或虚拟机中。我们甚至不能相信应用程序的 IP 地址会在 10 分钟后保持不变。下图展示了一个使用 IBM Cloud Public (Bluemix)成功应用的云应用参考架构:

云原生应用应该水平扩展，这意味着每当工作负载需求增加时，应用应该增加该应用的实例数量以处理新的请求。同样，如果工作负载减少，应用程序实例的数量也应该减少。

使用 12 因素应用模型的开发

12 因素应用程序模型是为了使云应用程序可伸缩而应该遵循的一组实践。它为不利的云环境变化提供支持。

该模式的 12 项原则如下:

  • 代码库:我们的代码库在版本控制中被跟踪，并被多次部署
  • 依赖关系:我们应该明确地声明和隔离依赖关系
  • 配置:我们应该在环境中存储应用配置参数
  • 后台服务:我们应该将后台服务视为附属资源
  • 构建、发布、运行:我们应该严格分离构建和运行阶段
  • 进程:我们应该将应用程序作为一个或多个无状态进程来执行
  • 端口绑定:我们应该通过端口绑定导出服务
  • 并发性:我们应该通过流程模型进行扩展
  • 一次性:我们应该通过快速启动和平稳关闭来最大化健壮性
  • 开发/生产对等:我们应该尽可能保持开发、试运行和生产的相似性
  • 日志:我们应该将日志视为事件流
  • 管理流程:我们应该将管理任务作为一次性流程来运行

这些原则减少了与云计算相关的简单错误的数量。

您不必将所有这些概念应用于您开发的所有云原生应用程序。例如，如果不需要脚本来预加载数据库，就不需要应用管理进程原则。但是，如果您使用的应用程序需要保存状态或与不同的应用程序(如会话)共享状态，那么使用后备服务是必不可少的，因为您永远不知道响应用户请求的容器位于哪个物理或虚拟计算机主机上。

无服务器计算

无服务器计算是一种部署模型，其中应用程序部署在一个环境中，但不一定一直运行。它的容器在第一次执行时启动，并在请求要求执行时保持活动状态。经过一段时间的不活动后，该应用程序的容器被停止。值得注意的是，停止的容器需要时间来启动，因此实时响应不是无服务器应用程序的强项。

无服务器应用(或者如许多云服务提供商所称的云功能)是一种微服务，它被部署并附加到一个触发器上，该触发器负责启动具有该功能的容器并运行它。触发器可能是数据库更改、传递给代理的消息、HTTP 请求或其他类型的请求。

云提供商通常根据云功能的执行持续时间和资源分配(通常是内存)对云功能的执行进行收费。例如，云函数可能需要 500 毫秒，并使用 256 MB 的内存。

成功的云功能不是计算密集型的，并且没有大量的请求(预定过程)。为了简化构建和部署无服务器应用程序的过程，无服务器框架是一个不错的选择，因为它支持 Google Cloud、AWS、IBM Cloud 和 Microsoft Azure 实现无服务器计算。

使用 Hyperledger Composer 开发区块链

Hyperledger Composer 是 Linux 基金会在 Hyperledger 品牌下主持的一个项目。该项目旨在创建一个框架和工具集，以加速使用 Hyperledger Fabric 的区块链应用程序的开发，并简化与其他应用程序的集成。重要的是要记住，任何框架都试图通过抽象解决方案的某些复杂性来简化解决方案的某个方面，但是它也限制了对所应用的抽象的控制。

Hyperledger Composer 工具包

Hyperledger Composer 并不是解决 Hyperledger Fabric 所有复杂性的通用解决方案。它剥夺了一些任务的灵活性，如果没有它，这些任务是可以定制的。然而，它所做的是提供一个工具包来创建链码项目，构建区块链应用程序包(.bna文件)，并将它们部署到 Hyperledger Fabric。

使用 Hyperledger Composer 开发业务网络的重点是使用项目结构和通用语言创建资产、参与者、交易、查询和访问控制列表。创建业务网络定义后，Composer 提供了将应用程序打包并部署到 Hyperledger Fabric 平台的工具。

Hyperledger Composer REST 服务器

为了简化与其他应用程序的集成，Hyperledger Composer 提供了 Composer REST 服务器，这是一个构建在回送框架之上的 API 服务器，它连接到定义的业务网络。它检索关于资产、事务和参与者的信息，并提供 REST API 服务器和以 swagger 格式描述的服务契约，以便与开箱即用的业务网络进行交互。

Composer REST 服务器附带了许多有用的特性。最值得一看的是身份验证、多用户模式和数据源配置。

身份验证和多用户模式

在创建业务应用程序时，请求身份验证并不罕见。Composer REST 服务器提供了使用 Passport 中间件连接到许多身份验证和授权提供者的方法。虽然该项目声称 Passport 有 300 多种身份验证和授权策略，但我们的经验表明，并非所有这些都是现成的；有时，你必须创建自定义代码来使它们工作。然而，我们已经成功地实现了 Google、GitHub、Auth0 和 LDAP 认证策略。

多用户模式允许多个参与者使用单个 Composer REST 服务器，而不是为每个参与者部署不同的 Composer REST 服务器。在这种模式下，使用主名片来检索 API，但是与业务网络的交互是使用它自己的名片来完成的。此模式要求启用用户身份验证。

数据源配置

Composer REST 服务器使用数据源来存储用户会话数据。这并不意味着必须配置一个显式的数据源；如果没有配置数据源，Composer REST 服务器将使用现成的内存连接器。

当使用 Composer REST 服务器的多个实例来实现高可用性或负载平衡时，这些实例不共享内存，因此需要一个数据源。可以使用任何具有环回连接器的数据源。根据我们的经验，MongoDB、Cloudant 和 Redis 是开箱即用的；我们只需要按照 Hyperledger 提供的步骤安装连接器并配置环境变量。

摘要

在本章中，我们已经了解了在云环境中开发和部署应用程序的意义。我们考虑了容器如何工作，如何将容器化的应用程序部署到云平台，以及一个替代模型:无服务器计算。我们还介绍了开发云原生应用程序的 12 因素模型原则。

然后，我们将 Hyperledger Composer 视为开发区块链解决方案的加速器。我们探索了各种特性，包括使用身份验证、多用户模式和数据源配置。

本书提供了使用 IBM Watson 物联网平台和 Hyperledger Compose 创建简单应用程序的信息。这些远远不是支持物联网和区块链解决方案的唯一平台和工具，但概念是相同的，可以应用。如果您对使用所解释的工具扩展功能感兴趣，Watson IoT 和 Hyperledger Fabric / Composer 都提供了关于如何使用它们的大量文档，以及通过互联网提供的大量社区文章，但是，我们认为实践是了解它们是否适合给定解决方案的最佳方式，因此，即使您确实想学习如何使用该工具包，也要尝试，简单的用例是好老师。

进一步阅读

本章提供的主题是一个概述，如果您需要任何主题的更多深度，我们建议您阅读以下参考资料:

我们一直在努力

apachecn/AiLearning

【布客】中文翻译组