系统架构设计笔记(39)—— 简单分布式系统设计
发布日期:2021-06-29 21:04:31 浏览次数:2 分类:技术文章

本文共 1350 字,大约阅读时间需要 4 分钟。

网络极大地扩展了计算机的应用范围,同时,由于升级到更强的服务器的费用常常远远高于购买多台档次稍低的机器,更何况虽然计算机有了长足的发展,可是单台计算机的功能仍然十分有限,利用联网的计算机协同工作,共同完成复杂的工作成为相对成本较低的选择,而且可以完成单台计算机所无法完成的任务。分布式系统使得这一目标成为可能。

但网络本质上并不可靠,特别是远程通信,分布式系统会带来了并发和同步的问题。

分布式系统可以由两种完全不同的方式来进行协同和合作。

(1)基于实例

第一种是基于实例的协作。这种方式所有的实例都处理自己范围内的数据,这些对象实例的地位是相同的,当一个对象实例必须要处理不属于它自己范围的数据时,它必须和数据归宿的对象实例通信,请求另外一个对象实例进行处理。请求对象实例可以启动对象 、 调用远程对象的方法,以及停止运行远程实例。

基于实例的协作具有良好的灵活性,但由于实例之间的紧密联系复杂的交互模型,使得开发成本提高,而且,由于实例必须能够通过网络找到,所以通信协议必须包括实例的生存周期管理,这使得基于实例的协作大多只限于统一的网络,对于复杂的跨平台的系统就难以应付。所以基于实例的协作适用于比较小范围内网络情况良好的环境中,这种环境常常被称为近连接。

这种情况下对对象的生存周期管理所带来不寻常的网络流量是可以容忍的。使用基于实例的协作常常使用被称为 “ 代理 ” 的方法,某个对象实例需要调用远程对象时,它可以只和代理打交道,由代理完成和远程对象实例的通信工作:创建远程对象,提交请求 、 得到结果,然后把结果提交给调用的对象实例。这样,这个对象实例甚至可以不知道自己使用了远程对象。当远程对象被替换掉(升级)时,对本地代码也没有什么需要修改的地方。

(2)基于服务

另外一种方式是基于服务的协作,该方法试图解决基于实例的协作的困难。它只提供远程对象的接口,用户可以调用这些方法,却无法远程创建和销毁远程对象实例。这样减少了交互,简化了编程,而且使得跨平台协作成为可能。

同样由于只提供接口,这种协作方式使得对象间的会话状态难以确定,而且通信的数据类型也将有所限制,基本上很难使用自定义的类型。基于服务的协作适用于跨平台的网络,网络响应较慢的情况,这种环境常称为远连接,这时,简化交互性更为重要,而频繁的网络交换数据会带来难以容忍的延时。

基于服务的协作往往采用分层次的结构,高层次的应用依赖于低层次的对象,而低层次对象实例的实现细节则没有必要暴露给高层次对象,这种安排使得高层次的实现不受低层次如何实现的影响,同时,当低层次服务修改时,高层次的服务也不应该受到影响。

设计者在进行设计时,通常会倾向于比较细致的设计,对象往往提供了大量的操作和方法,响应许多不同的消息,以增加达到系统的灵活性 、 可维护性等。这在单个系统中没有什么问题,当考虑分布式系统的设计时,这种细致的设计所带来对对象方法的大量调用会比较严重地影响性能,所以在分布式系统中,倾向于使用大粒度的设计方式,往往在一个方法中包含了许多参数,每个方法基本上代表了一个独立的功能。当然这样的设计使得参数的传递变得复杂,当需要修改参数时,需要对比较大范围的一段过程代码进行修改,而不是像小粒度设计一样,只需要修改少量的代码。

转载地址:https://deniro.blog.csdn.net/article/details/106746258 如侵犯您的版权,请留言回复原文章的地址,我们会给您删除此文章,给您带来不便请您谅解!

上一篇:说说 Python 的具名元组
下一篇:系统架构设计笔记(38)—— 工作流设计

发表评论

最新留言

不错!
[***.144.177.141]2024年04月11日 16时51分09秒