软件开发

当前位置:首页 > 软件开发

《持续交付四 业务引领的DevOps 精要》第五章

5持续交付的软件系统架构

在2000年, 著名的电商网站亚马逊仍旧是传统的巨石应用,而不是今天大家看到。的微服务架构。这种巨石应用每次部署时必须将整个网站作为一个整体统一进行部署。在大型促销活动期间,网站的稳定性遇到了严峻挑战。尽管团队在活动之前做了预估扩容,但活动期间的流量还是远远超出了团队的预期。生产事件频发,常常修复一处问题却引发另- -处出现问题。

公司管理层对这种现象进行复盘,并认为,最主要的原因是系统耦合度太高,比较复杂。但是,由于业务需求太多,时间比较紧迫,工程师们忙于开发自己手上的功能特性,没有时间进行沟通,了解系统的整体架构。为了解决这一问题, 工程师们应该在开发需求之前进行更加充分的讨论。而公司CEO贝索斯却认为,不应当再增加沟通,而是应该减少沟通,即增加小团队内部的沟通,减少团队之间的沟通。为了做到这一点,应该将网站的巨石架构全面改造为面向服务架构(Service-Oriented Architecture, SOA),并提出以下要求(参见Steve Yegge的《程序员的呐喊》)。

(1)所有的团队都要以服务接口的方式,提供数据和各种功能。

(2)团队之间必须通过接口来通信。

(3)不允许任何其他形式的互操作:不允许直接读取其他团队的数据,不允许共享内存,不允许任何形式的后门。唯- 许可的通信方式,就是通过网络调用服务。

(4)具体的实现技术不做规定,HTTP、Corba. Pub/Sub方式、 自定义协议皆可。

(5)所有的服务接口,必须从-开始就以可以公开为设计导向,没有例外。这就是说,在设计接口的时候,就默认这个接口可以对外部人员开放,没有讨价还价的余地。

(6) 如果不遵守上面规定,就会被解雇。

截至2011年,其生产环境的部署频率已经非常高了。工作日的部署频率达到了平均每1.6秒- 一次,一小时内最高部署次数达到了1079次 (参见Jon Jenkins在O'Reilly VelocityConference 2011上发表的“Velocity Culture")。 这归功于将巨石应用改造为面向服务架构(SOA)。 由此可见,为了能够更好地应对业务发展,持续交付是必然趋势,在软件系统架构方面的“大系统小做”原则是促进这一目标达成的必要条件。

5.1“大系统小做”原则

5.1.1持续交付架构要求

为了提升交付速度,获得持续交付能力,系统架构在设计时应该考虑如下因素。

(1)为测试而设计(design for test)。如果我们]每次写好代码以后,需要花费很大的精力,做很多的准备工作才能对它进行测试的话,那么从写好代码到完成质量验证就需要很长周期,当然无法快速发布。

(2)为部署而设计(design for deployment)。如果我们开发完新功能,当部署发布时,需要花费很长时间准备,甚至需要停机才能部署,当然就无法快速发布。

(3)为监控而设计(design for monitor)。如果我们的功能上线以后,无法对其进行监控,出了问题只能通过用户反馈才发现。那么,持续交付的收益就会大幅降低了。

(4)为扩展而设计(design for scale)。这里的扩展性指两个方面,一是支持团队成员规模的扩展:二是支持系统自身的扩展。

(5)为失效而设计(design for failure)。 俗语说:“常在河边走,哪能不湿鞋。”快速地部署发布总会遇到问题。因此,在开发软件功能之前,就应该考虑的一个问题是: 一旦部署或发布失败,如何优雅且快速地处理。


相关内容

文章评论

表情

共 0 条评论,查看全部
  • 这篇文章还没有收到评论,赶紧来抢沙发吧~