分布式服务框架的4项特性

标签: 分布式 | 发表时间:2014-10-31 09:34 | 作者:Tim
出处:http://timyang.net

在移动及云时代,尽管大部分可扩展的问题可以通过云平台解决,但是服务本身的扩展性挑战仍然存在。比如一个新的项目,用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之外,业界还有一些类似工具,如 serfdomconsui

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

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

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

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

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

本网站后续文章也可以通过微信公众号订阅,欢迎扫码关注。

Similar Posts:

相关 [分布 服务 框架] 推荐:

分布式服务框架:Zookeeper

- - 标点符
Zookeeper是一个高性能,分布式的,开源分布式应用协调服务. 它提供了简单原始的功能,分布式应用可以基于它实现更高级的服务,比如同步,配置管理,集群管理,名空间. 它被设计为易于编程,使用文件系统目录树作为数据模型. 服务端跑在java上,提供java和C的客户端API. Zookeeper是Google的Chubby一个开源的实现,是高有效和可靠的协同工作系统,Zookeeper能够用来leader选举,配置信息维护等,在一个分布式的环境中,需要一个Master实例或存储一些配置信息,确保文件写入的一致性等.

阿里巴巴Dubbo分布式服务框架已开源

- tangfl - ITeye论坛最新精华讨论帖
Serving services with invocations everyday, Dubbo becomes the key part of Alibaba's SOA solution and has been deployed to the whole alibaba.com family:.

分布式服务框架的4项特性

- - Tim[后端技术]
在移动及云时代,尽管大部分可扩展的问题可以通过云平台解决,但是服务本身的扩展性挑战仍然存在. 比如一个新的项目,用PHP或JSP实现了基本功能,部署在Apache或Tomcat等容器上,在业界这种部署在一个容器内的功能模块通常可以称为一个service. 服务容器很容易通过EC2或者docker等方式来扩展部署更多的实例.

Dubbo:来自于阿里巴巴的分布式服务框架

- - 标点符
Dubbo是阿里巴巴SOA服务化治理方案的核心框架,每天为2,000+个服务提供3,000,000,000+次访问量支持,并被广泛应用于阿里巴巴集团的各成员站点. Dubbo是一个阿里巴巴开源出来的一个分布式服务框架,致力于提供高性能和透明化的RPC远程服务调用方案,以及SOA服务治理方案. 远程通讯: 提供对多种基于长连接的NIO框架抽象封装,包括多种线程模型,序列化,以及“请求-响应”模式的信息交换方式.

阿里巴巴分布式服务框架-Dubbo问与答

- - Arccode's blog
Dubbo是阿里巴巴内部的SOA服务化治理方案的核心框架,每天为2000+ 个服务提供3,000,000,000+ 次访问量支持,并被广泛应用于阿里巴巴集团的各成员站点. Dubbo自2011年开源后,已被许多非阿里系公司使用. 项目主页: http://dubbo.io/Home-zh.htm.

微软分布式服务框架WCF开源了

- - 博客园_新闻
微软下了开源的决心之后,好消息接踵而来. 之前是 .NET Core( CoreCLR 和 CoreFX,然后是编译器平台 Roslyn 和 Orleans. 刚才,微软又宣布将其 SOA 框架 WCF 开源了,GitHub 地址是 https://github.com/dotnet/wcf.

基于Dubbo框架构建分布式服务

- - 简单之美
有关Dubbo服务框架的简单使用,可以参考我的其他两篇文章(《基于Dubbo的Hessian协议实现远程调用》,《基于Dubbo的Hessian协议实现远程调用》,后面参考链接中已给出链接),这里主要围绕Dubbo分布式服务相关配置的使用来说明与实践. 首先,根据Dubbo文档,我们引用文档提供的一个架构图以及各组件关系说明,如下所示:.

分布式服务框架设计指标

- - 开源软件 - ITeye博客
 支持通过xml配置的方式发布和导入服务.  支持服务实时自动发现,由注册中心推送服务提供者地址,消费者不需要配置服务提供者地址,地址透明化.  默认提供随机路由、轮询、基于权重的策略等.  总是向同一个提供方发起调用.  失败自动切换,当出现失败,重试其他服务器,常用于读操作及幂等性写操作.  失败自动恢复,后台记录失败请求,定时重发,常用于消息通知操作.

微服务框架-基础框架

- - 人月神话的BLOG
上面一篇文章对SpringBoot框架做了一下简单验证,在文中也写到SpringBoot重点还是在单个微服务模块的开发,已经对于微服务接口开放的便捷性上,而对于微服务基础架构和管控治理层面没有太多支持. 对于微服务基础框架可以看作是微服务治理架构的核心内容,包括了对微服务模块的全生命周期管理能力,这个能力包括了微服务网关APP,DevOps,Docker和云集成,安全,负载均衡,服务注册和发现等诸多能力.

谈Dubbo服务框架

- - 人月神话的BLOG
Dubbo 是阿里巴巴公司开源的一个高性能优秀的服务框架,使得应用可通过高性能的 RPC 实现服务的输出和输入功能,可以和 Spring框架无缝集成. 它最大的特点是按照分层的方式来架构,使用这种方式可以使各个层之间解耦合(或者最大限度地松耦合). 从服务模型的角度来看,Dubbo采用的是一种非常简单的模型,要么是提供方提供服务,要么是消费方消费服务,所以基于这一点可以抽象出服务提供方(Provider)和服务消费方(Consumer)两个角色.