使用Kubernetes的区块链案例

译者 | 李睿,审校 | 孙淑娟,为了说明如何使用Kubernetes，建议考虑本文介绍的区块链案例，并探讨为加密货币市场开发的应用程序。这个应用程序使用的技术是实用的，也可以用于其他项目。换句话说，技术任务是一个非常通用的解决方案，主要针对Kubernetes进行了专门调整，也可以用于其他行业。,该项目是一个启动项目，预算有限。而开发人员将定期为投资者提供演示，并定期展示开发新功能的进展情况。因此决定使用以下技术：,对于第一阶段，开发人员的主要目的是将其应用程序拆分为微服务。在这一案例中，决定创建6个微服务。,(1)管理微服务,(2)核心微服务,(3)支付微服务,(4)邮件和通知服务,(5)Cron任务服务,(6)Webhooks微服务,值得一提的是，虽然技术堆栈是实用的，并且可以在各种情况下使用而无需更改，但上述微服务却不是，它们是专门为这一项目中所需的功能而创建的。因此可以使用相同的技术，但必须根据需要设计新的微服务。,以下了解如何在NestJS上制作这些微服务。需要为Kafka消息代理进行配置选项。因此，为所有微服务的常用模块和配置创建了一个共享资源文件夹。,以消费者模式将管理面板微服务连接到Kafka。它将允许捕获和处理来自主题的事件。,使应用程序在微服务模式下工作，以便能够使用事件：,可以注意到消费者配置包含groupId。这是一个重要的选项，它将允许来自同一组的消费者从主题中获取事件，并将它们分发给彼此以更快地处理它们。,例如，假设微服务接收事件的速度快于处理它们的速度。在这种情况下，可以进行自动扩展以生成额外的pod以在它们之间共享负载，并使该过程加快两倍。,为了实现这一点，消费者应该在组中，并且在扩展之后，生成的pod也将在同一个组中。因此，他们将能够共享加载，而不是处理来自不同Kafka分区的相同主题事件。,以下了解一个如何在NestJS中捕获和处理Kafka事件的示例：,消费者可以在两种模式下工作。它接收事件并处理它们而不返回任何响应(EventPattern decorator)，或者在处理事件后将响应返回给生产者(MessagePattern decorator)。EventPattern更好，如果可能的话应该是首选，因为它不包含任何额外的源代码层来提供请求/响应功能。,对于连接生产者，需要为负责发送事件的模块提供生产者配置。,每个微服务可以同时在两种模式(生产者/消费者)或两种模式(混合)下工作。通常情况下，微服务使用混合模式来达到负载平衡的目的，为主题生成事件并均匀地使用它们，共享负载。,基于Helm图表模板的Kubernetes配置，针对每个微服务实现。,,Helm图表描述的Admin API微服务组件及其结构,该模板由几个配置文件组成：,以下来看每个配置文件(没有Helm模板),部署可以包含更多的精简配置，如资源限制、健康检查配置、更新策略等。但是提供了一个基本配置示例，可以根据任何其他项目的需要进行扩展。,需要将服务暴露给外界才能使用它。通过负载均衡器公开的应用程序，并提供SSL配置以使用安全的HTTPS连接。,需要在集群上安装一个负载均衡控制器。这是最流行的解决方案：AWS负载均衡器控制器。,然后，需要使用以下配置创建入口：,应用这一配置后，将创建一个新的alb负载均衡器，需要使用在“host”参数中提供的名称创建一个域，并将流量从该主机路由到负载均衡器。,当想要降低K8s基础设施的复杂性时，Helm变得非常有用。如果没有这个工具——需要编写很多yml文件才能在集群上运行它。,此外，应该记住应用程序、标签、名称等之间的关系。但是，可以使用Helm使一切变得更简单。它的工作方式类似于包管理器，允许创建应用程序的模板，然后使用简单的命令准备和运行它。,使用Helm来制作模板：,模板的值位于“values.yml”、“values-dev.yml”和“values-stage.yml”文件中。使用哪一个取决于环境。检查一下dev env的一些值的示例。,要在集群上应用配置，需要升级图表并重新启动部署。,以下检查负责此操作的GitHub Actions步骤。,在GitHub操作中应用Helm配置,最终，本文研究了如何在特定案例中使用Kubernetes构建微服务。显然跳过了其他必备步骤和组件，将代码示例转换为成熟的工作应用程序。但是，上述源代码足以展示和解释Kubernetes微服务是如何构建的。,原文标题：​​Blockchain Case Using Kubernetes​​，作者：Tetiana Stoyk