可靠性、可用性和容灾设计这些活动都是围绕 “安全” 这个核心,而性能优化,提升响应性则是围绕 “效率”

  「我们一直这样做开发,时间做久了,便忘了当初的本意。」

  有关软件系统开发,我们谈些什么?
  我们谈过程,编码规范、开发流程、同行评审、结对编程、持续集成,从瀑布到敏捷再到极限编程。
  我们谈架构,企业级、J2EE、容器化、SOA(面向服务架构)、Microservices(微服务化)。
  我们谈规模,大容量、高并发、大数据。
  我们还谈可靠性、可用率、n个9、响应时间等等。。。
  这一切的核心是什么?

  先讲个电力行业的一个故事,电力的项目我没做过,对电厂的原理虽有所了解,但看见那些大规模的电站还是感觉挺复杂的。 故事是这样开始的:

  记得有个给我们上培训课的主讲老师是个须发皆白的老先生,进门后掏出一堆零件放在讲台上, 一盏酒精灯、一个小水壶、一个叶片、一个铜光闪闪的小电机、一盏小灯泡。 老先生往壶里倒了些水,点燃酒精灯,不一会儿水开了,从壶嘴里喷出了蒸汽,带动叶片旋转,然后小灯泡就亮了。

  他说:这就是电厂。
  他还说:如果烧的是煤炭,这就是燃煤电厂;如果烧的天然气,这就是燃气电厂;
  如果获得热能的方式是核裂变,这就是核电厂;如果带动叶片的能量来自水从高处流向低处,这就是水电厂。
  老先生说:你们或许会问 “那我们看到的电厂怎么这么复杂”,答案其实很简单, 电力项目需要复杂系统的目的,一是为了确保安全(Safety),二是为了提高效率(Efficiency)。

  安全和效率的平衡,是所有工程技术的核心。

  看完这个故事,我就感觉到所谓 “大道至简” 大概就是这样的。

  开发软件系统的根本在于满足需求,不能满足需求的系统本身是没有意义的。 就像一个再安全、有效率的电厂不能发电又有什么意义呢。 所以软件系统开发也就是围绕根本的基础上确保安全与提高效率。

  需求作为软件的根本差异很大,需求是多样,需求也是复杂的。 一个大型 ERP 系统,一个大型仓储系统,一个大型网站系统,到底谁更复杂,没有一个定量标准,甚至都不好定性分析。 所以前面我们谈软件系统开发那么多内容都是关于 “安全” 和 “效率” 这两个围绕根本的核心。

  所有软件开发的方法论,像瀑布、敏捷到极限编程围绕的是开发活动的效率问题,而编码规范、流程制定、同行评审等等则是有关开发的安全问题。 那么 SOA 化或进一步微服务化其实同时考虑到了安全与效率,服务化拆分有利于大规模开发团队的并行开发,提升了开发效率, 但上线部署复杂了降低了运维效率,但运维效率可以通过自动化来得到弥补,而开发则不可能自动化。

  同理,可靠性、可用性和容灾设计这些活动都是围绕 “安全” 这个核心,而性能优化,提升响应性则是围绕 “效率”。 有些关键的软件系统必须同时兼顾 “安全” 和 “效率”,例如用在飞机、汽车内用于控制起落、刹车、油门的软件系统, 不安全或无效率造成事故是会死人的,而另外一大部分软件系统因为不安全或无效率造成的事故则死的是钱。

  没有人去争论建设电厂到底是不是一门艺术,但肯定有人在争论软件开发(程序设计)到底是不是一门艺术, 但终究大部分的软件系统开发还是更偏向于工程技术。

http://kb.cnblogs.com/page/535278/

时间: 2024-10-16 04:09:40

可靠性、可用性和容灾设计这些活动都是围绕 “安全” 这个核心,而性能优化,提升响应性则是围绕 “效率”的相关文章

联鼎容灾备份一体机---容灾鼎

容灾鼎是将虚拟化技术.数据同步技术.数据容灾技术.高可用集群技术和高性能硬件进行无缝集成,并在出厂前完成预安装.预配置.预测试,从而简化现场部署流程,加快应用上线的速度.用户选择容灾鼎,就是选择了一体化的交付模式,用户无需分别选择软件.硬件再进行集成,只需关注自己的核心业务系统即可,高可用容灾一体化是未来的发展方向. 容灾鼎作为一款国内领先的一体化容灾核心设备,突破了传统业务系统软硬件分离式部署的模式,大大减低了系统部署的难度和操作复杂度, 极大地提高了系统整体可靠性, 使用户真正体验到"数据安

容灾与集群(1)

容灾与集群(1) 在上一篇:微软分布式云计算框架Orleans(1):Hello World,我们大概了解了Orleans如何运用,当然上一篇的例子可以说是简单且无效的,因为用了Orleans不可能只写一个Hello World吧,Orleans是为分布式和云计算而生的框架,那么今天我们就简单说一说容灾.集群.容灾与集群在Orleans中的运用. 集群是什么? 下面摘抄自百度百科: 集群(cluster)技术是一种较新的技术,通过集群技术,可以在付出较低成本的情况下获得在性能.可靠性.灵活性方面

【大话存储】学习笔记(17章),数据容灾

数据容灾 数据备份系统只能保证实际上被安全复制了一份,如果生产系统故障,必须将备份数据尽快的恢复到生产系统中继续生产,就叫容灾. 容灾可以分为四个级别: 数据级容灾:只是将生产站点的数据同步到远端. 与应用结合的数据级容灾:保证对应应用数据一致性. 应用级容灾:需要保证灾难发生以后,需要保证原生成系统中的应用系统在灾备站点可用. 业务级容灾:除了保证数据.应用系统在灾备站点可用,还要保证整个企业的业务系统仍对外可用,是最终层次的容灾. 概述 如果要充分保证数据的安全,只是在本地做备份是不够的,所

存储容灾的相关限制

我们常常说存储容灾包括同城容灾和异地容灾,同时也包括同步容灾和异步容灾. 我们常说的同步容灾最大为100公里.该数值指的实际光纤长度是100公里,而不是物理距离,因为你不可能确保两个物理地之间恰巧有一根直线连接的光纤,一般经验中常选择的同步容灾站点物理距离在50-80公里之间.具体还需要根据应用对时延的要求和两地之间的实际测量时延为依据,100公里只是理论值. 存储的同步容灾只能在100公里的范围内实现.这是IT系统容灾界的标准法则. 该法则的计算理论依据为: 1)同步容灾需要任何一个I/O要同

福岛灾难六年祭:容灾前线,警钟长鸣

    3月11日是东日本地震海啸灾难6周年纪念日.在这次人类历史上罕见的浩劫中,福岛核电站事故造成的损失最为惨重.与前苏联的切尔诺贝利核电站事故相比,福岛的灾难最初是由地震和海啸的天灾引起,似乎不应该算作人为事故.但是,静下心来仔细研究,发现这个事故发生得实在蹊跷: - 日本作为一个世界上自然灾难发生最频繁的国家,地震与其说是一种灾难不如说是一种常见的自然现象.就算是这次地震的震级很强,作为世界上最大的核电站,难道没有应对的预案?还是说应对预案不起作用? - 相比切尔诺贝利事故从开始到爆炸只有

避开容灾备份的误区

随着信息行业的发展,容灾备份已经被很多公司和企事业单位所接受.同时,容灾备份的厂商也抛出了不少的新概念和观点.不过,北京和力记易科技有限公司(以下简称"和力记易")作为行业内的专业容灾备份提供商,发现目前在该行业存在一些误区,而且有些观点误导性还很大,因此有必要将其逐一澄清,既利于行业发展,也利于客户选择好的产品. 误区一:容灾备份=拷贝 在容灾备份领域,有一些人认为所谓容灾备份就是将文件进行简单拷贝,这是一种十分肤浅而且是错误的理解!事实上,首先,拷贝仅仅是一种定时备份,是一种冷备份

备份和容灾

备份和容灾目的 备份在于应付系统数据恢复和历史数据保存,为"离线数据": 容灾在于系统发生故障时,仍然能够正常的提供服务,为"在线数据": 备份关心数据的安全,容灾关心业务应用的安全 备份和容灾的关系 从定义上看,备份是指用户为应用系统产生的重要数据制作一份或者多份副本,以增强数据的安全性.因此,备份与容灾所关注的对象有所不同,备份关心数据的安全,容灾关心业务应用的安全,可以把备份称作是"数据保护",而容灾称作"业务应用保护"

今天,你的服务器做容灾备份了吗?

IDC圈内的人经常会听到容灾.备份这样的词汇,那么什么是容灾什么是备份,容灾和备份的区别是什么呢? 容灾:是提供一个能防止用户业务遭受各种灾难影响破坏的计算机系统,是指通过建立异地容灾中心,做数据的远程备份,在灾难发生之后要确保原有的数据不会丢失或者遭到破坏. 备份:是容灾的基础,是指为防止系统出现操作失误或系统故障导致数据丢失,而将全部或部分数据集合从应用主机的硬盘或阵列复制到其它的存储介质的过程. 容灾备份的区别?容灾与备份可以说是存储领域两个极其重要的部分.首先,从定义上看,容灾与备份所关

阿里云负载均衡升级:同城容灾进一步提升可用性

为了向广大SLB用户提供更加稳定可靠的负载均衡服务,近期阿里云对其SLB系统进行了升级,优先在杭州和青岛地域部署了同城容灾的本地高可用解决方案,下面就让我们一起来了解一下SLB同城容灾方案. 什么是同城容灾? SLB集群本身,已经实现了各种冗余,包括电力.网络.服务器等.我们单集群可以防止“单路电力故障”.“单边网络故障”.“服务硬件故障”.“系统意外宕机”甚至“整(一)个机柜突然掉电.突然断网.突然宕机”等故障对用户对外服务造成的影响. 但是更大范围的故障,比如整个数据中心不可用,已经不能从S