BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

模块化成熟度模型

| 作者 Alex Blewitt 关注 4 他的粉丝 ,译者 王丽娟 关注 0 他的粉丝 发布于 2011年10月19日. 估计阅读时间: 9 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

在九月下旬召开的OSGi社区大会上,来自IBM的Graham Charters博士发表了题为《建立模块化成熟度模型》的演讲,模块化成熟度模型是一组正在确定的需求,用来标识模块化相关系统的成熟度。这个模型的目的类似于能力成熟度模型,为组织或项目推行模块化的程度提供了一种度量方式。

请注意,下面的内容还在处理,编号和描述可能会随着时间的推移而发生变化。目前的模块化成熟度模型是:

  • 级别1:特定的。什么都不是模块化的。所有的内容是一堆JAR包,更糟糕的话,可能只是一堆类。这通常会形成一个单一却庞大的应用。
  • 级别2:模块。模块有正式的版本标识,依赖关系由模块标识处理,而不是模块自己处理。Maven、Ivy、RPM和OSGi就属于这一类。
  • 级别3:模块化。模块用模块契约声明,而不是用明确的模块标识或版本声明。这个要求可能是抽象的(比如Declarative Services可用),也可能是特定的包(像org.osgi.framework)。
  • 级别4:松耦合。实现不通过工厂或构造方法获得,而是从注册表里动态查询,或是按需注入。
  • 级别5:委托。工件的所有权委托给具备模块概念的仓库。这些仓库可能会支持协作或治理,以便通过所需功能之间的关系访问资产。
  • 级别6:动态化。模块参与到动态的生命周期里,这个动态的生命周期能够在运行时添加、更新、删除模块,同时保留系统中的状态。

InfoQ有幸对Graham Charters博士进行了采访,问他的第一个问题是,是什么驱使他创建了这个成熟度模型:

Graham Charters:过去这些年我有幸和很多客户进行了交谈,他们都采用了OSGi,处于不同的阶段。他们通常都是事后才采用模块化的,也就是说他们有一些已有的应用,或者有一些无法维护、阻碍他们业务调整和增长的应用。这些客户一般都觉得自己是拓荒者,没有地图,没有明确的目标。成熟度模型所作的就是描述目前最常见、合乎逻辑的应用之旅。成熟度模型是技术无关的,因为最低级别并不需要OSGi,不过在我看来,OSGi是最好的解决方案,因为它有助于更清楚地描述各个级别的特点和优势,而不用关注实现它的具体技术细节。

InfoQ:项目在这个模型里的分布情况是怎样的?

Graham Charters:我在OSGi社区大会上做了一个调查,结果差不多证实了我的想法。从现场看,整个行业平均处于级别二(模块)。我也曾特意问过Eclipse Tools项目这个问题,他们差不多处于级别三(模块化)。有一些项目达到了级别四(松耦合),并恰当地利用了OSGi服务模型,但他们的关注点往往是OSGi,这样的项目有Apache Aries、Apache Felix、Eclipse Gemini、Eclipse Virgo。委托(级别五)和有状态服务里真正的动态化(级别六)非常少见。我希望即将问世的OSGi Bundle仓库规范能达到级别五。

InfoQ:这些级别是线性延续的么?委托和动态化呢?

Graham Charters:通常来说,组织会线性地去遵循这些级别。这个顺序基本上是按照客户最常采用的路径排列的,在现有技术下也最合逻辑。也就是说,委托和动态化之间的顺序不是非常强,更多的是反映了客户的兴趣分布。对客户来说,考虑仓库协作和治理是很正常的,而动态化则更专业一些。我觉得动态性和OSGi的Headless/嵌套用法之间有相当高的相关性。

模型的另一个部分可以随着时间的推移而演进,这部分内容就是模块化和松耦合之间的顺序和区别。有人会说,模块之间的松耦合或独立实现就是模块化的一部分。这在一定程度上是正确的。你可以根据需求和功能共用实现。但通常情况下,客户需要在非模块化的环境中运行他们的模块,所以采用松耦合就是有问题的。这就是我觉得微服务(又名pojoSR)有用的原因。这种技术也可以让客户交换采用模块化和松耦合的顺序。松耦合一般不会注意它对模块化层的影响。如果你的模块是围绕服务等内容而协作的,这就会大大减少模块间API的“表面积”,因为你不再需要共享实现类。

InfoQ:沿着成熟度模型发展会节约成本么?能不能逐步做到?

Graham Charters:是的,会节约成本,清楚阐明这一点也是模型的目标之一。我想为每一层都提供一种通用的表达,说明组织必须具备什么特征,也就是在模块化方面,组织必须反复做哪些事情,以及这么做的好处。就开发、构建和运营时所采用的具体实践来说,升级到上一层会有成本,但也会有好处。我描述了解耦方面的所有好处,每次解耦都能提升组织的敏捷度,进而降低成本、减少实现价值所需的时间。举例来说,一个组织要从模块提升到模块化(从级别二提升到级别三),必须要去描述他们模块的外部环境,让开发、构建和运营适应新级别。这样做的好处是能更深刻地认识系统结构,降低系统的腐坏程度,让系统更易于维护。模块有任何变化,你都可以立即确定它对系统的影响,因为模块可以描述这是个不会引起中断的实现变更,还是个Bug修复,抑或是会引起变化的实现等等。你也不用关心模块重构,因为模块的消费者不再关心某个功能到底是哪些模块提供的。最后,要是有任何重大的结构变化,你很早就能知道警告信息,因为你马上就能确定是否有没满足的需求。

当组织成功营造这么一个环境,或是围绕模块展开协作(提交、审查、讨论等)的环境,他们就不太可能去创建重复的模块。这就会降低成本、提高重用率。随着重用率的提高,质量也会提升。那组织又有什么理由不让他们的开发人员去搜索所需的API和服务,把高质量的模块放到项目里,而是让他们去找一些不知质量如何的东西,或是从头编写呢?

InfoQ:这些判断标准是专门针对OSGi的么?还是它们也适合其他的模块化框架?

Graham Charters:这些判断标准和好处都与技术无关。我这么做是出于两个原因,第一,我觉得这有利于向更多的组织解释某一级别需要具备的特性。如果一个组织处于级别二(模块化),他们并没使用OSGi,那跟他们谈论导入包和导出包就没什么意义,告诉他们定义模块外部环境的好处则比较清楚。第二个原因是,这样能帮助人们去评估模块化框架。并非所有的模块化框架都是相当的,所以这个模型可以帮助人们确定所需的特性和好处,从而确定适用的框架。

InfoQ:有没有计划把这个模型作为正式的标准文档,通过OSGi或其他组织发布出来呢?有没有相关的时间表?

Graham Charters:坦白说,我不确定这个想法是否能被认可,实际上我对这些正面的响应也有些不知所措。我希望有人能喜欢这个主意,而且愿意一起合作。我不确定这算不算授权标准,但我知道它正在制定白皮书,类似于OSGi联盟发布的语义版本。我希望下个月左右能发布第一版。

InfoQ:作为行业和OSGi社区,我们能从成熟度模型里学到些什么呢?

Graham Charters:我在OSGi社区大会上做的调查并不是很科学,调查结果显示,大部分组织和项目处于级别二(模块)。就个人而言,我相信在提升到级别五(委托)的过程中,质量和生产率方面会受益颇多。对拥有大型分布式开发和运营团队的组织来说,尤其是这样。如果我们设定的目标是级别五,我们就需要说服人们去接受更高级别的好处,让他们尽可能简单地从现有级别向上升级。举例来说,要提升到级别三,就需要用好的工具去定义模块的外部环境,执行持续构建,让模块和系统分析发现潜在的问题、帮助确定问题。

OSGi社区Wiki上的模块化成熟度模型已经可用了。你的项目或组织处于模块化成熟度模型的哪个级别呢?

查看英文原文Modularity Maturity Model

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

不错! by decai feng

模块化代表了松耦合,我最近也在思考,软件架构设计的最高境界应该是“松耦合”+“高度集成”,看似矛盾,其实不然。“松耦合”是指模块之间在开发时可以完全独立,在运行时可动态注入。“高度集成”是指各个模块装配以后,形成一个用于一致服务接口、数据模型、业务模型的完整系统,模块之间的关系似乎不存在!

模块化可以是一个架构演进的结果 by 张 晓庆

如果项目初期需求不慎明确,模块边界不清晰,可以在开发过程中等需求相对稳定后再确定模块,并逐渐演进得到一个模块化的结果。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

2 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT