微服务和软件开发目标

阅读数:1206 2015 年 3 月 12 日

话题:语言 & 开发架构

Dan NorthQCon 伦敦大会的演讲中说,软件的目标就是持续地使筹建时间减至最少以产生积极的商业影响,其他事情都是具体细节。他描述了有关代码推理的方法及其如何适应于微服务架构风格。

对 IT 业思想先驱 North 来说,软件开发的目标就是创造商业影响,这里引用了 Gojko Adzic 在其著作《影响地图》中的流行语。商业影响在组织的内部(比如新客户)或者降低运营成本的效果是可见的。软件开发的目标是实现这一商业影响,或者更具体地最小化筹建时间,即从发现商机到完成解决方案的时间。这样做上几次是容易的,难在持续这样做,这推导出 North 前述的软件开发的目标。

North 将代码分为三类,一种是你最新写的并且很熟悉;一种是 North 称其为 fabric 的、每个人都熟悉、代码附有充分的测试和文档;一种是没人熟悉的,依赖不明确且牵一发而动全身。对 North 而言,软件开发中最大的问题是第三类代码,没有人熟悉代表着成本和争端。从 North 的观点得出,代码要么稳定要么干掉,永远不要使其成为第三类,未知的代码。因而,North 搬出了几个模式来支持这一观点并将其引入到微服务之中。

第一种模式是短软件半衰期,参照物理学和不稳定原子衰变之快。North 相信代码应该有一个非常短的软件半衰期,以突显目标明确的代码最重要的是可以被推导的、可以存意使其稳定或将其废弃。他强调,理解的代码的目的是非常重要的。

第二种模式是如我所想(fits in my head),这是引自 James Lewis 的表达。这种模式是关于推理代码能力的;推理大系统的一种方法是将其分解,另一种方法是简化问题或者忽略大的部分而每次关注一个小的特定部分。同样的原理可以用于不同规模上的推理,如何定义一个方法的功能、如何建模一项工程、如何建模通信机制等等。

North 从他的推理中定义了一种架构风格,他称其为可替换的组件架构,通过上下文一致可以很好地将短期软件半衰期和如我所想两种模式结合在一起。所有的组件都是完全可以替换的,它们包装在隐藏内部细节的 API 中,并通过发送消息相互通信。这些组件就像微小的电脑一样传递信息,North 强调了 30 年前 Alan Kay 是如何定义的面向对象(OO)编程的。

微服务可作为一种可替换的组件架构,当优化替换性和一致性时,这两块儿都可以作出每日选择。North 认为使用微服务存在一个概念上的错误,微意味着更小并不总是最好的,更应该是可替换的更好。

查看英文原文:http://www.infoq.com/news/2015/03/microservices-software


感谢丁晓昀对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。