python分布式服务系统框架_分布式服务框架的4项特性

在移动及云时代,尽管大部分可扩展的问题可以通过云平台解决,但是服务本身的扩展性挑战仍然存在。比如一个新的项目,用PHP或JSP实现了基本功能,部署在Apache或Tomcat等容器上,在业界这种部署在一个容器内的功能模块通常可以称为一个service。服务容器很容易通过EC2或者docker等方式来扩展部署更多的实例。但service本身的管理的以下几个方面的问题仍然需要架构师去设计及解决。

1、服务的远程调用(RPC)。

随着系统的用户访问规模增大,以及系统功能的增多,众多的功能模块(service)很难用单个service来承载,这些不同功能的service可能由不同的开发团队开发,甚至使用不同的开发语言,最终部署在不同的服务器容器内。Service之间的调用需要一种协议及远程调用的实现,需要具备灵活的data type支持,对调用双方透明(理想情况它就像在执行本地调用),并且具有良好的性能。比较典型的RPC实现有

Google: Protocol Buffers RPC

Facebook: Thrift

Twitter: Finagle

2、服务的分布式调用链及服务状态跟踪统计

随着系统内部的服务增多,一个功能的调用可能会通过系统内部多个服务相互调用来完成,并且这些服务可能由不同的团队开发,并且分布在不同的服务器容器,甚至可能在多个地域不同的机房内。因此分布式系统需要有一种方式来清晰的了解系统的调用及运行状况,测量系统的运行性能,方便准确的指导系统的优化及改进。

由于trace的主要功能都是依赖日志输出来完成,因此通常也需要建设相关的分布式日志系统及数据实时分析展示系统等,分布式日志收集及数据实时分析也是一个非常大的话题,本文不展开详谈。比较典型的trace系统有

Google: Dapper

Twitter: zipkin

3、服务的配置管理。包括服务发现、负载均衡及服务依赖管理。

比较常用的服务发现是域名方式,调用方通过域名来定位目标服务。域名寻址方式可通过配置多IP(或VIP)来实现负载均衡。域名方式存在一些弊端,常用的DNS服务器通常是上个世纪的产物,管理繁琐,更新域名记录后由于协议设计上存在的TTL缓存机制,修改不能立即生效,也无法做变更的push操作。更高级的特性如控制流量、灰度发布等也无法实现。

目前,成熟的分布式服务较多使用基于ZooKeepr的配置服务,ZooKeeper由于与client保持长连,因此具有push能力,可以迅速的调整配置及生效。但由于ZooKeeper本身只是一个通用工具,分布式服务具体场景各种高级特性还需要自行在此基础上实现。

基于DNS的服务发现在负载均衡方面具有明显缺点,由于多IP或VIP使用类似round robin的策略,在实践中,同一服务的多个IP之间负载通常并不均衡。而服务提供方并没有有效手段对runtime期间不均衡进行调整。基于ZooKeeper的配置服务可以支持各种复杂的特性,但需要做一些定制化开发,但服务发现作为系统中最核心的一个环节,这些定制化开发需要较多的经验的积累及沉淀,之前在线上就碰到过配置服务将一个服务池中疑似不稳定的节点移除过多,从而导致出现雪崩的情况。

除了ZooKeeper之外,业界还有一些类似工具,如serfdom及consui。

4、服务之间的调度及生命周期管理

目前大部分服务的部署都是按照事先的规划安装在机房不同的服务器上,配置服务通常只是起服务节点的failover作用,业务中真正按弹性调度来运作的系统还不普遍。但原理上所有的service可以看做是MapReduce中的task,它的调度及生命周期可以很高效的由分布式容器来管理,并且根据service的属性来灵活的分配资源,比如控制CPU的核及内存大小。

业界比较成熟的有Apache旗下的Mesos及YARN。它们的特性有点类似,但是由不同的组织开发。Mesos主要功能是由C++来实现,可以支持docker container来进行调度,因此它的实现更偏底层一些。Yarn是Hadoop 2的一部分,可以更灵活的来调度MapReduce jobs,它是一种JVM内部的实现,可以很好的支持JVM级别的任务分配及调度。

上面介绍了这么多,主要是最近考虑团队在上述1-4之间做一些事情。一方面目前业界在这几点之间还有一些缺失或者欠优化之处,另外1-4点之间也可以适当做一些实现的整合。整合并不是要产出一个大而庞杂的软件,我个人是极力反对大而全,也不喜欢沉重的框架,业务的service实现方不应该import太多工具或者SDK,因此将要做的功能肯定是透明及可插拔的。

由于这件事情并没有严格的可参考目标,因此对于最终实现的是哪个子集还存在一些不确定因素,这个项目如果具有通用性,也考虑以开源的方式来开发。对这方面有什么想法,欢迎留言。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
要在分布式环境中部署ModelScope框架模型,需要进行以下步骤: 1. 安装ModelScope框架:可以使用pip install命令安装。 2. 准备数据:将数据集分割成多个部分,以便可以在多个节点上同时处理。 3. 训练模型:使用ModelScope框架训练模型,并将模型保存到硬盘中。 4. 部署模型:将模型部署到多个节点上,以便可以在分布式环境中进行推理。 下面是一个简单的代码示例,演示如何在分布式环境中部署ModelScope框架模型: ```python import torch from torch import nn from modelscope import ModelScope # 定义模型 class MyModel(nn.Module): def __init__(self): super(MyModel, self).__init__() self.fc1 = nn.Linear(10, 5) self.fc2 = nn.Linear(5, 2) def forward(self, x): x = self.fc1(x) x = nn.functional.relu(x) x = self.fc2(x) return x # 创建ModelScope对象 ms = ModelScope() # 设置模型参数 ms.set_model(MyModel()) # 分布式训练模型 ms.distributed_train( num_epochs=10, batch_size=64, optimizer=torch.optim.Adam, optimizer_args={"lr": 0.001}, criterion=nn.CrossEntropyLoss, criterion_args={}, train_dataset=train_dataset, val_dataset=val_dataset, num_nodes=2, node_rank=0, backend="nccl", ) # 保存模型 ms.save_model("mymodel.pt") # 加载模型 ms.load_model("mymodel.pt") # 分布式部署模型 ms.distributed_deploy( num_nodes=2, node_rank=0, backend="nccl", ) # 进行推理 output = ms.model(torch.randn(1, 10)) print(output) ``` 上述代码中,我们首先定义了一个简单的神经网络模型MyModel,然后使用ModelScope创建一个ModelScope对象ms,并将模型设置为ms的属性。接下来,我们使用ms对象的distributed_train方法在多个节点上训练模型,并使用ms对象的save_model方法将训练好的模型保存到硬盘中。然后,我们使用ms对象的load_model方法从硬盘中加载模型,并使用ms对象的distributed_deploy方法将模型部署到多个节点上。最后,我们使用ms对象的model方法进行推理,得到输出结果。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值