文章列表
 
您正在查看 "大规模应用" 分类下的文章

2009-02-18 21:44

这里列举了七条在不打破预算的情况下,最大化可用性的方法。由于每种方法的首字母都是R,所以又称高可用性的7R原则。他们是:
冗余(Redundancy)
名声(Reputation)
可靠性(Reliability)
修补能力(Repairability)
恢复能力(Recoverability)
响应(Responsiveness)
活力(Robustness)
冗余
多 年来,制造商一直在设计他们的产品中保存一定的冗余,包括多余的能源供应,多处理器,内存分段,以及多余的磁盘。对于整个采用热备模式运行的服务器系统来 说也是如此。基础架构分析人员在配置磁盘、磁盘控制器和服务器使用双路径;把网络负载分散到两条线上;以及提供备用的控制台,这也是采用了同样的方法-- 总而言之,尽可能地减少单点的故障造成服务中断的可能性。

名声
后面三个"R"--名声、可靠性和修补能力--紧密相关。名声指的是主要供应商一贯的记录。可靠性是关于产品中所使用的部件和代码的可 依赖的程度。修补能力是衡量供应商能够多快,并且多方便地修理好(或者替换掉)有问题的部件。下面,我们将仔细看看这三项。在服务器,磁盘存储系统,数据 库管理系统和网络硬件以及软件领域中,供应商的名声是获得高可用性的重要因素。最好是选用最好的供应商。你可以通过下面几中方法来衡量一个厂商的名声。
市场分额百分比
行业分析家和华尔街的报告
在该领域内的历史记录
客户参考(尤其在确认诸如费用,服务,产品的质量,服务人员的培训以及可信程度等因素时,这点格外有用)。
可靠性
软件或者硬件的可靠性也可以通过客户参考和行业分析家来证实。除了这些,你应该考虑采用经验性部件可靠性分析的方法。这需要以下步骤:
检查并分析问题管理日志
检查并分析供应商日志
从操作人员那里获得反馈
从支持人员那里获得反馈
从供应商的维修人员那里获得反馈
同其他人的经验做比较
研究行业分析家的报告
一个对于问题日志的分析应该显示出任何不寻常的失败模式。你应该从供应商、产品、使用部门、发生失败的时间和日期、失败出现的频率以及维修的时间等角度去研究它们。供应商经常保存站内维修日志,你可以用它们来进行相似的分析。

你将发现操作人员的反馈通常是公正的,而且有启迪的作用,能够反映出各个部件真正的性能。尤其是对于那些离站的操作者们。例如每天早晨,在启动前他 们可能要对某一个特定的网络部件做数不清的重启动,但是由于这一情况经常出现,他们可能懒得做日志进行记录。和不同支持人员,比如系统管理员、网络管理员 和数据库管理员进行的相似的交流可能反映出相似的要求。

你可能认为供应商的维修人员提供的反馈会有偏私,但是根据我的经验,他们对于自己产品的反馈和使用那些产品的人的反馈一样公正而且有启迪的作用,能 够正确显示出那些产品的可靠性。这样,那些维修人员就成为评估部件可靠性、以及和其他公司的经验做比较的一个有价值的信息来源。那些和你使用的平台、配 置、提供的服务和客户都很相似的公司的经验特别有帮助。有名的行业分析家的报告也可以预测部件的可靠性。

修补能力
修补能力是技术服务人员能够解决或者替换有问题的部件的能力。衡量这项能力的两个通常的标准是完成维修的时间长短和维修工作多长时 间就要进行一次。在比较成熟的系统里,维修的工作可以通过远程诊断中心来完成,在那里,错误被查明并修正或解决,并执行了永久的解决方案,这个过程只需要 很少或者根本不需要操作人员的介入。

恢复能力
恢复能力指的是克服瞬间的失败的能力,它使最终用户端的可用性完全不受这类事件的影响。它小到从一个内存单元的错误中恢复,大到整个服务器系统转移到热备的系统上而不丢失数据和传输。恢复能力还包括重新尝试对于磁盘或者磁带进行读取或者写入,还包括沿着网线重新尝试传输。

响应
响应指的是紧急情况下,所有相关人员及因素解决问题、排除故障的能力。它包括有训练有素的供应商和内部支持人员能够对问题做出快速而有效的反应。它还包括对于资源,比如磁盘或者服务器的自动恢复能够在多长的时间内起作用。

活力
关于高可用性的最后一个词就是"活力",它描述的是可用性程序的整体设计。一个有活力的程序将能够经受很多不同的考验--无论是来自内 部的还是外部的--而这些问题可能轻而易举地就能够破坏一个比较脆弱的系统的可用性。要保持活力需要对于文件和培训投入相当的额外费用。这些技术培训包 括:为了适应和平台、产品、服务和顾客相关的技术的变化的培训;为了适应相关的人员变动的培训;为了适应新经营方向、合并和收购等新的商业变化的培训。

理解并应用这7有关高可用性的单词,可以帮助你实现高可用性的梦想。本文来自:Net130

 
2008-11-05 11:34
所有活跃在当今国际舞台上的外国巨型公司都知道,面对象联想、华为这样的厂商,他们存活的唯一希望就在于他们对大规模、可扩展、高性能、高可用系统的技术的把握。这,就是真正的核心技术。

1996年,Amazon起家时,在它的后面是一台网络服务器和一个数据库。到了2001年,随着越来越大的系统规模,Amazon系统的可扩展性已经到了极限。

可扩展性和可维护性是软件业永恒的难题。对此,所有的开发者都有着切身体会。面对数十年来延续下来的、全球化团队平行开发、超过百万行的代码和纠缠不清的数据结构,真是令人疯狂,哪才是正确的出路?

2001年,面对同样的问题,聪明的Amazon人坐了下来。经过一段严肃的思考,他们开始了世界上第一次大规模的SOA旅程。历史将记住这个时刻。

5年以后,微软CTO比尔.盖茨宣布即将退位,他委以重任的接班人正是SOA技术专家Ray Ozzie,由此可见SOA在当今世界的地位。

对SOA的定义,下面是Vogels的原话,非常中肯。
"For us service orientation means encapsulating the data with the business logic that operates on the data, with the only access through a published service interface. No direct database access is allowed from outside the service, and there's no data sharing among the services."

目前,Amazon已经这样封装、实现、维护和运营着数百个这样的业务。5年来,Amazon已经从当初的前端网络服务器+后端数据库的两层结构变成 了"a fully-distributed, decentralized, services platform serving many different applications",支撑起了5千5百万用户和1百万合作伙伴。Vogels坦言这一SOA平台是Amazon的战略优势。
Vogels说,严格的面向业务设计和SOA是获得功能模块隔离(isolation),从而获得可扩展性的杰出方法,能够给开发、运营带来前所未有的Ownership和控制,也给加入更高级的系统可扩展技术以提高整个系统性能,如decentralized
request routing 或 distributed request tracking带来了方便。

目前,Amazon主要采用的是业务使用-提供这一模式。在Amazon Service内部采用了WSDL之类标准,但使用了优化的传输和marshalling方法,以提高CPU和网络使用效率,对外部客户使用XML feed接口和REST、SOAP接口。据他们统计,使用REST接入Amazon service的客户端一般是基于LAMP的系统,而使用SOAP的一般是基于Java或.NET平台的系统。

对于最近比较热门的self-describing XML documents flowing around技术,他坦言:"We are on our way to using this in a number of cases, but we are not there yet. There are advantages, especially when you aggregate services into new services, or when you compose pipelines of services that operate on a message floating through the pipeline. But in many of our cases the contract between consumer and producer clearly defines the messages that will be exchanged, and we can optimize by not using self-describing features"。说明作为一个公司,Amazon更切重实际。

令人震撼的是,Amazon不仅将SOA当作其平台的技术架构,更将其整个业务开发流程围绕SOA展开。

Vogels直言,这样做非常困难。他提到的几个典型问题是:"How do you make sure that developers are productive in this large distributed service-oriented architecture? If you have this decentralized organization where everybody is developing things in
parallel, how can you make sure that all the pieces work together as intended, now and in the future?"。他还特别谈到测试。对此我深有同感。好的测试是软件系统成功的一半,大规模软件系统的测试一直是公司质量和成本管理上巨大的难题,而分 布式系统的测试更是一个历史上空前的挑战。
任何有些许大规模软件开发经验的人员都知道,Amazon过去5年来组织和实施这样多达数百个业务的大规模开发、维护和运营,意味着怎样的挑战。勇气、决心、远见、创新、智慧、组织管理技巧,这一切都只是家常便饭,无法保证它的最终成功。

Vogels将这称为"混沌"(Chaos)的挑战。他用"生活本不是决定性的"这一哲学思考来进行理解,得到"混沌"不可避免,也无需逃避的结论。他 说:"From the outside, the services in our platform may appear chaotic, but chaotic in a good sense—in that we try not to impose a rigid structure on the different functional pieces, but we expect there to be order when looking at it from a different dimension. Thinking about this whole system as a big deterministic system would be unrealistic. Life is not deterministic, and a large-scale distributed system such as Amazon has many organic and emerging properties that can come to life only if you do not constrain it."。

为此,一方面,Vogels要求能够进入Amazon的员工主动、有高度责任感。他说:"The Amazon development environment requires engineers and architects to be very independent creative thinkers. We are building things that nobody else has done before, so you need to be able to think outside the box. You need to have a strong sense of ownership, because in the small
teams in which you will work at Amazon, your colleagues will count on you to pull your weight—especially when it comes to operating the service that you have built. Can you take responsibility for making this the best it can be?"。

而另一方面,Vogels们一定有他们的实现方式,当然,这是他们的核心商业秘密,他没有透露。

因为"混沌",过去5年Amazon做的一切,本可以轻而易举地变成一场噩梦,但Amazon取得了最后的胜利。为此,它赢得了我的尊重。

作为负责技术的官员,和在本是技术访谈的讨论中,Vogels谈论最多的竟是客户,令人对Amazon更加充满信心。在这里,又是SOA使Amazon的技术开发和客户需求几乎完全结合,达到了软件工程需求管理方面的新高度。

大多数软件开发人员都知道,对于大规模软件来说,开发人员自己去直接面对客户在客观上、管理上和实现上都几乎难以实现。公司内部必须有详细的分工,才能最后保证高质量地完成哪怕最小的客户需求。而Amazon的SOA使这一要求成为可能,非常令人启发。
为此,他一方面要求Amazon的员工具有强烈的客户意识,并将技术人员两年轮换做客服。他说:"A very important point is whether candidates think the right way about customers and technology. Technology is useless if not used for the greater good of serving the customer. We are a strongly customer-oriented company, and we often use the "working from the customer backwards" approach. This means that in your thought process, you start with the customer and work your way backwards until you have found the simple and minimal technology that you need to satisfy the new customer requirement. It is important that engineers who come to work at Amazon understand that we do not build technology for technology's sake, but to support the customer."
另一方面,因为Amazon通过将其系统和业务分解为数百个Service展开独立开发和运营管理,使这些Service直接面对终端客户成为 可能。具体来说,对于一个新的业务想法,Amazon会首先定义好测量这项业务成功的检验参数,(我想可能是诸如:使客户在网站上的停留时间延长10分 钟,购物平均消费提高5%,之类的参数),然后开始以小组的方式进行敏捷开发,迅速开发出系统原型,然后开始回归。他们"try to go into prototype mode pretty quickly, and then you start iterating on that until you feel that you understand your business problem"。在此,SOA的松散耦合业务模型是他们敏捷开发的关键,用Vogels的原话是:"This fast response to new ideas is enabled through the loosely coupled services model, both in technology and at the developer and operations level"。

在原型开发完成后,便是疯狂地根据前面定义的测量参数进行无情的测量,以决定新业务的改良和生死。据Vogels说,这导致Service的开发团队极具有创造力。

此外,Vogels个人对开发具有足够的尊重和深刻的理解,他说:"Developers are like artists; they produce their best work if they have the freedom to do so"。能够有人这么说,也值得庆幸了。
他举的一个例子是sales rank,就是:there is an attribute on most product pages that indicates what the sales popularity of that product is in its category.

另一个例子是:Listmania service,用来 produces specialized data that on almost every page is adapted to the specific product on that page and the history of the customer.
 
2008-03-13 13:47
对于软件架构这个术语来说,没有一个标准的、被普遍接受的定义,因为它还是一门年幼的学科,……虽然没
有标准的定义,却也不乏定义……
                                                                                                    卡内基·梅隆大学软件工程学院

架构是一组有关软件系统组织方式的重要决策;是对系统构成元素、元素接口以及这些元素间协作行为方式的选择;是一种把这些结构和行为元素逐步组合为更大子系统的合成方式;也是一种构建风格,在其指导下把这些元素、元素接口、元素间的协作和合成组织起来。
                                                                                                     Booch,Rumbaugh 和 Jaclbson[19]

Erlang的作者是这样描述的,非常详细而准确:

从最高的抽象层次上看,架构就是“一种思考世界的方式”。然而,从实用性的层次上看,我们就必需得把我们看待世界的方式转化为一本实用的手册和一组规程,它们可以告诉我们如何使用我们看待世界的特定方式来构造一个特定的系统。

我们的软件架构通过如下一些方面来刻画:

1.问题领域——我们的架构是为解决什么类型的问题而设计的?软件架构一定不是通用的,而是为解决某一类特定问题而设计的。缺少了关于用来解决哪类问题的描述的架构是不完整的。

2.哲学—— 软件构造方法背后的原理是什么?架构的核心思想是什么?

3.软件构造指南——我们如何来规划一个系统?我们需要一个明确的软件构造指南集。我们的系统将由一个程序员团队来编写和维护——所以对所有的程序员和系统设计者来说,理解系统的架构和它的潜在哲学是很重要的。从实用性的角度来讲,这些知识以软件构造指南的方式表现出来更便于维持。一个完整的软件构造指南集包括编程规则集、例子程序和培训资料等等。

4.预先定义好的部件——以“从一组预先定义好的部件中选择”的方式进行设计远比“从头设计”的方式要来得容易。Erlang的OTP库包含了一个完整的现成部件集(称之behaviour库),一些常用的系统都可以使用这些部件构建起来。例如gen_server这种behaviour就可以用来构建client-server系统,gen_event这种behaviour可以用来构建基于事件(event-based)的程序。关于预定义部件的更完整的讨论见6.1节。6.2.2节将给出一个关于如何使用gen_server这种behaviour来编写一个服务器软件的简单例子。

5.描述方式——我们如何描述某一部件的接口?我们如何描述系统中两个部件之间的通信协议?我们如何来描述系统中的静态和动态结构?为了回答这些问题,我们将介绍一些专门的符号。其中一些用来描述程序的API,而其他的则用来描述协议和系统结构。

6.配置方式——我们如何来启动、停止和配置我们的系统?我们可以在系统工作过程中进行重配置吗?
 
 
   
 
 
文章存档
 
     
 
最新文章评论
  

你好,我的毕业设计也是这方面的,第一次接触这些,很想向你学习学习啊,能加一下QQ
 

请问内个sudo chown ender:ender php是神马意思呢?
 

不错! 朋友,有时间可以看看免费开源的、跨平台的、易操作的kangle反向代理服务器软
 

你好 我想请教个问题 memcached-client.php 中 run_command 的用法 因为一定要用memc
 

不错,很准备、全面,收藏QQ了。
   
帮助中心 | 空间客服 | 投诉中心 | 空间协议
©2012 Baidu