晴转多云h_晴间多云

最新推荐文章于 2024-10-17 15:34:15 发布

danpu0978

最新推荐文章于 2024-10-17 15:34:15 发布

阅读量157

点赞数

文章标签：大数据人工智能 java python 数据库

原文链接：https://www.javacodegeeks.com/2011/09/when-clouds-clear.html

版权

晴转多云h

几年前，当我第一次听说云计算时，我很怀疑，但并没有真正关注它，而是以为这是下一个乞求冒出来的IT泡沫。但是，随着行业中有点歇斯底里的炒作Swift增加，不可避免的是我最终不得不面对并了解更多有关它的知识。我承认一开始会被催眠，但是经过一番思考和研究，终于有了一个清醒的解决方案。

那么，云计算的想法是否具有创新性？如果是，那么它是否在变革IT方面增加了价值？接下来，让我们分析一下云计算的一些基本论点。

按需出租

“按需购买即付”服务具有使企业赶上长尾的潜力，并减少了对大量风险客户投资的需求。但这并不是什么新鲜事物。我可以在大学里为我那愚蠢的小应用租用机架空间！

对于我来说，奇怪的是，大规模的合作突然会使他们的业务关键数据“无处不在”地公开。这是一个信任的问题，Amazon能否说服您他们将兑现SLA并且磁盘I / O不会躲避您的交易？当然没有任何保证，失败将发生，天空将坠落，数据将丢失。知道这一点，我认为银行通过公共云发送SWIFT消息不会感到容易，公共消息中的一条消息可能包含一千万美元（或更多）的交易。

但是，公共租金具有可变资源的价值，因为可变资源是必需的，并且会在短时间内废弃。例如，无状态计算密集型操作，脱机数据处理或缓存。它甚至可能适合测试您的分布式算法是否可扩展或作为模拟slashdot效果的负载生成器。

多租户和弹性

这两个问题的共同点是显而易见的，旨在无人干预地动态分配（和取消分配）资源。在云计算中，这些资源通常由大型数据中心提供，这些数据中心可以看作是异构应用程序之间共享的虚拟化计算资源池。

但是，在阳光下收集资源也不是什么新鲜事。我可能会因设计一个需要手动/人工干预来扩展和收缩JDBC连接池以及负载的系统而冒着工作风险。同样，监视和HTTP已经存在了一段时间，您不觉得吗？

此外，并非每个应用程序都适合多租户。处理敏感数据肯定会涉及安全隐患和法律法规，具体取决于削减的架构级别。

云计算的潜力

我看不到云计算的想法是令人难以置信的创新，而不是经济上或技术上都没有，我们在历史上已经看到了这一切：穿羊皮的狼，营销炒作。但是考虑到当前行业的发展势头，云计算之所以让我兴奋，是因为如果我们朝着正确的方向发展，它有可能提升我们对计算机和软件管理的思考方式。

请允许我详细说明。

令我感到惊讶的是，当今的系统仍然部署得过于庞大，通常是基于对业务的过早预测，从而导致效率低下和成本上升，而缺乏缩减规模并将投资重新用于未来商机的方法。

不，现在是时候放开人类控制计算机的幻想了，因为我们不能，如果我们真的可以的话，可靠性就不会成为问题。实际上，正是这些相当离奇的信念使我们退缩，并使计算机不可靠且效率低下。

但是，我确实相信可以打破这种依赖性，并且如果我们愿意提高抽象水平，则可以将计算机设置为自由状态。为了说明这一点，我将通过比较两种根本不同的方法（推和拉管理）来描述管理计算机的一般问题。

推

这是传统的模型，其中管理员命令计算机网络实现特定的服务。当然，这意味着管理员需要了解服务应如何工作的确切实现细节，并迫使他跟踪服务在何处以及是否（可靠性）满足SLA。

但是如前所述，试图控制计算机的人对安全性和可靠性有影响。

人为因素。
人会犯错误，特别是在复制管理更改方面尤其不擅长，这意味着状态将分散到系统完整性受到无意间的不一致困扰的地步，从而使系统行为变得不可预测和不可靠。
请记住，分布式企业系统通常是非常敏感和复杂的工作。计算机可以将人为的小错误变成巨大的灾难，并且该领域中的许多问题都是人为错误的直接后果。压力，时间，规模和复杂性直接影响安全性和可靠性。

关于此主题的许多研究都承认这些问题，并且结论对具有操作经验的任何人都应该是熟悉的。这项特殊的研究已经过时了，但是所描述的症状仍然太普遍了，甚至到现在为止。

尽管操作员错误对服务故障做出了巨大贡献，但在设计高可靠性系统以及用于监视和控制它们的工具时，操作员错误几乎被完全忽略了。 这种疏忽尤其成问题，因为如我们的数据所示，操作员错误是通过传统技术掩盖的最困难的组件故障。 工业界对最终用户的体验给予了极大的关注，但忽略了操作员用于配置，监视，诊断和维修的工具和系统。

互联网服务为什么会失败，以及如何解决？
计算机高度不可靠且不稳定。
现实世界的严酷现实不断轰炸计算机，在这种环境下会发生坏事。过载，内存泄漏，障碍或计时条件，拒绝服务攻击，入侵，中断，级联故障，配置错误，网络故障，病毒，硬件故障；几乎有无限可能出错的事情。
作为人类，我们不仅威胁计算机，而且放置计算机的环境使计算机变得更加不可靠。由于只有一个授权负责许多可用性，因此容错非常困难。考虑一下您如何管理不存在或无法响应命令的内容？嗯..
缺乏诚信。
从安全的角度看，控制和命令（企图控制）与攻击的可疑地相似。因此，被命令没有机会不同意/不服从命令可被视为违反完整性的安全漏洞。命令是否具有良好意图并不重要，无法再确定可预测的行为。

拉

推式管理的逆向是拉式管理，即计算机随心所欲地提供特定的服务。管理员将发现这些服务，并能够理解它们的工作方式，因为服务很小，并且具有描述其属性的自描述合同。

服务合同也是异步的，这意味着指令从不直接移交，而是存储在中介中。服务拉动此中介，并在方便时应用设置。

这迫使服务变得更加智能，但同时也带来了一些有趣的可能性。

抽象。
管理员不需要知道如何实现实际服务，因为已发布的合同隐藏了那些复杂的细节。这使管理变得更加简单，高效，即使计算机停机也可以继续进行。
安全可靠
由于信息被提取，因此可以通过强化将漏洞表面降至绝对最低。除从服务接口访问外，任何人都不需要访问计算机，因此实际上可以禁用SSH！
通过服务本身提供的合同来控制通信的另一个好处是，合作变得更加可靠-管理员不能违反合同。
高效。
形成特定服务的计算机数量可以自由增长和收缩。实际上，这种弹性可以基于非常复杂的分散式对等算法。
随着系统规模的增长，同时随着拉动保持相当稳定，推式管理变得更加复杂。
自我修复。
由于已经对服务进行了加固，因此只有自身可以访问自身，因此有关自身服务通知的任何异常都可以视为安全漏洞。发生这种情况时，计算机可以自行维修，甚至可以将其重置为上一个已知的良好状态。
计算机甚至可以相互监督，以确保该服务作为一个整体具有高可用性并符合SLA。如果成员掉线，则可以失败/失败，甚至可以在其他地理区域中生成/克隆新成员。没有React或可疑的成员可能会受到STONITH的追究。
可自行配置。
当管理员提供新软件时，服务将通过滚动修改自身来执行自己的维护和升级，同时保持高可用性。

要理解推入和拉取管理之间的一个非常根本且重要的区别是，拉取不传达命令，而是传达“目的地”。这意味着，我们无需声明到达终点状态的确切过程，而只是声明终点状态，并让服务自行找出到达终点状态的过程！

我觉得很高兴发现所有这些与Configuration Management都有很多共同点，这是我非常想知道的主题！

DevOps和持续交付运动在帮助开发人员实现计算机和软件在其自然环境，生产环境中的工作方式方面做得非常出色。吃自己的狗粮，可以这么说。

但是，我相信我们可以做更多，简化，改进。人类不应该做计算机可以做得更好的工作！我知道，放开对自我管理软件的控制会遇到心理障碍。但是我们害怕什么呢？我非常确定您相信引导飞行员安全飞行的软件（除非您像我一样，不怕飞行）？

我们不应该忽视自我管理软件–它具有巨大的潜力，无法使我们的生活变得异常安全，可靠和高效。

无论未来如何发展，我都相信配置管理将始终是成功构建生活在共生关系中的面向服务的动态生态系统的任何成功的基石，在现有生态系统中，现有服务可以轻松地组合为准备收获不可预见业务的新服务机会！

参考： Deep Hacks博客上来自JCG合作伙伴 KristofferSjögren的《 Clouds Clear》。

相关文章：