非商业转载请注明做译者、出处,并保留本文的原始连接:http://www.ituring.com.cn/article/195743git
Michael T. Nygard是一位从业二十余年的资深程序员,现任Cognitect首席架构师,他被誉为在线业务的“流动解决问题专家”。Nygard曾前后为美国政府、军队、银行、金融、农业和零售等多个行业交付过运营系统,这种实际运营的经历改变了他对软件架构的见解,也让他对在至关不友好的环境下构建高性能、高可靠性的软件有了独特的看法。他写过多篇文章和社论,是软件架构经典著做《架构之美》和《软件架构师须要知道的97件事》的做者之一。Nygard最新出版的著做《发布!软件的设计与部署》详细展现了软件发布前可能出现的种种问题以及相应的解决之道,书中全部主题都是经过做者本身研究过的真实案例来阐述的。程序员
问:您曾经在博客中说过可能会写几本新书(Three Book Ideas),有最新的进展吗?github
任什么时候候,若是你问一位做者这个问题都会获得颇有趣的回应。他会看起来很紧张,开始出汗,而后含糊地说一些并不连贯的话,同时他还会急迫地寻找最近的出口。我要说的是,如今这个阶段我尚未什么好宣布的。web
问:《发布!》中提到的一些模式如今已经被普遍采用,如 Circuit Breaker,已经有了 Netflix 的 Hystrix 这样漂亮的实现,考虑到《发布!》是一本2007年出版的书,现在8年已通过去,你是否看到了一些新的稳定性/容量模式?编程
有一种重要的模式,它经过两种方式显示出来:异步式和反应式。我把它们看作一个硬币的两面。由于不少稳定性模式都要依靠阻塞线程才能起做用,因此这两种方式都有用。设计模式
问:有时候简单的错误就会形成整个系统宕机,这难道仅仅是程序员的一行代码形成的吗?能够引入什么机制来保证复杂系统的稳定性呢?微信
不少问题事实上就是一行代码引发的,可是老是有其余因素来放大这个问题。外部环境的变化可能会致使一个潜在的错误显现出来。或者一位操做员的活动可能会触发平时不会执行的代码,从而致使问题出现。网络
有一些问题则是由于系统的大规模结构而产生的。好比,我并不喜欢SOA中的“实体服务”模型。缘由是每一个应用都须要不少实体。几率的规则告诉咱们当全部实体服务都不工做的时候,扩展的系统极可能会出现故障。架构
因此,我会努力在微观和宏观范围内都让系统具备更大的恢复力(甚至是稳健性)。在微观层面上,我使用书中提到的设计模式。在宏观层面上,我分析系统的“故障域”。也就是说,当一个部件(硬件或软件)坏掉的时候,受影响的应用和功能的范围有多大?经过在应用间从新分配功能和把实体拆分红小平面,总有办法把系统分割成独立的故障域。框架
问:复杂的业务会致使复杂的系统吗?做为一位架构师,如何作到不伤害正常业务处理流程的同时又保持架构简单?
到目前为止,我没有发现复杂业务和复杂系统之间的关联性。我知道的系统复杂度的最强的预示变量就是规定。
问:DevOps和传统运营工程师有什么区别?
DevOps强调同感。在DevOps的文化中,开发者关心他们的应用如何影响运营者们的生活。个人应用要求管理员必须在半夜保持清醒来作部署吗?我怎么改变个人应用才能让她能少花时间在终端上,从而拥有更多的时间和家人在一块儿?运营做为报答:咱们如何才能创造一个更好的环境,让开发者带着勇气创造并传递价值?
问:从2007年的C/S和B/S到如今的App和NoSQL,互联网行业已经经历了重大变革。不少敏捷方法都已经有所进化。这些年软件发布都发生了哪些变化?还有什么是不变的?
我认为有三件事变化最大:
首先是Sun和微软两家公司统治的覆灭。在之前,几乎全部公司的软件开发都要用Java或 .Net,辅以当时发展迅速的Ruby on Rails社区。今天,常常能够见到使用不一样语言和运行时环境的系统。
第二,云部署环境已经戏剧性地改变了经济。
第三点同时很大程度上也是前两点形成的结果,开源操做工具已经使高可靠性的运营变得大众化。在2007年的时候,须要花费上百万美圆才能作好数据中心自动化,集中管理,以及监控。现在,你能够下载全部这些。
问:随着移动互联网的兴起,云服务的成熟,IT行业在发生天翻地覆的变化。做为一名架构师,应该重点关注哪些技术理念?
企业架构师以前关注的是图表中“方盒内”的技术。也就是说,他们的目标是执行细节完备的标准化技术。
在如今的世界里,我认为架构师应该更加关心数据格式和数据表示法。也就是说,他们应该关心的是箭头,而不是方盒。
问:Cognitect使用的编程语言主要是Clojure,这和大部分公司使用的主流语言(C / Java / C#)不一样。你认为将来的编程语言会变成什么样?
我并不适合回答这一问题。我只能说我看到不少开发者都在朝着函数式编程转型。
问:在Cognitect,每周五开发者都会花时间在业余项目和开源软件上。20%的整体工做时间是一个很大的比例。大家在这个每周都举办的活动中获得了什么收获?这些收获是否弥补了时间上的损失?
咱们利用20%的时间创造了一些不少人都承认的项目,其中包括web框架Pedestal,以及最初的ClojureScript实现。今天,咱们20%时间仍然用来开发Clojure,ClojureScript,Pedestal,以及其余一些新玩意儿,咱们不久以后就会揭晓。
很长时间以来,咱们一直都有一个习惯,就是质疑咱们对软件开发最基本的假设,咱们经过检验本身的工做来找到构造软件更好的方法。在20%时间里咱们也是这么作的。因此这项活动并非咱们一直在作的一个爱好或平常工做。咱们常常要评估这样作是否值得。
到目前为止咱们以为这项活动是颇有价值的。当咱们说,咱们想让软件开发对于每一个人来讲都变得更好时,咱们是认真的。咱们的开源工具就是其中的一部分。
问:你为何要为仿真测试编写工具Simulant?这个项目的进展如何?
虽然我常常会提到Simulant,可是这个工具是Stuart Halloway在Rich Hickey的架构基础上写的。
Simulant程序库如今处于稳定状态。个人目标在于帮助人们成功地应用这个工具。为此,我去年开了一个关于Simulant的网络研讨会。同时我也作了一个样本项目,你能够在GitHub上找到。(https://github.com/mtnygard/simulant-example)
如今,我在忙一个叫作“解决方案蓝图(solution blueprint)”的项目,不管是否用到Simulant,这个工具均可以帮助人们完成仿真测试。