论坛 产品库 视频 专题 CIO俱乐部 Windows8 实验室 CMO俱乐部 案例

如何从传统企业架构向SOA架构迁移?

发布时间:2014-10-29 11:34:00 来源:比特网 作者:资深IT架构师 王俏
关键字:soa 架构 系统实施

  目前很多正在使用的企业架构都是在数年前或更早时期设计和部署,为支撑企业的业务体系立下汗马功劳,但是随着业务战略变革更加迅速、业务需求更加复杂的情况下,传统企业架构(烟囱式、竖井式、分散式)逐渐显现出老态龙钟,不能快速的与业务保持一致, SOA 架构在这种背景下显示出其巨大的优势。很多企业已经开始动手或计划将传统企业架构迁移到 SOA 架构。 SOA 架构方法比较新潮,业内可参考的落地方法、成功实践比较少,涉及到的迁移策略也是五花八门,有种雾里看花的感觉,因此,本人总结了参与过的多个 SOA 落地项目,将分享下比较有实践意义的迁移策略。

  首先要先了解一下 SOA 架构的特点,从这些特点中找出 SOA 实施的挑战。

  SOA 架构的特点及实施难度分析:

  · 可从企业外部访问 ,说明安全性更具挑战,安全管控要求更高

  · 随时可用 ,说明服务与接口的规范性、可用性、兼容性要求很高

  · 粗粒度的服务接口分级 ,说明服务的定义难度加大,颗粒度和级别的划分要求很高,颗粒度和分级要管控

  · 松散耦合 ,说明组件(系统)之间的上下文关系定义要求更高,对系统功能的切分要求更高

  · 可重用的服务, 说明服务的标准化提高、服务的冗余度尽量降低

  · 服务接口设计管理 ,说明服务设计要求提高,服务管理规范化提高

  · 标准化的服务接口 ,说明其兼容性、扩展性、易用性被大大提高

  · 支持各种消息模式 ,说明其兼容性、扩展性要求很高

  · 精确定义的服务契约松耦合的系统 ,说明组件(系统)的功能切分要求很高,且规范化

  从上述的 SOA 特点和实施难度分析来看,频繁的出现诸如:兼容性、扩展性、安全性、易用性、标准化等各种高要求,这么多的“高”要求想通过一次性的系统重构来解决问题,难度和风险可想而知,与数年前相比,不管是业务顾问还是技术顾问,不管是架构师还是开发人员,实际上的能力并没有很大的提高,人马基本还是那套人马,挑战和风险可是与日俱增,怎么办?

  我们再回过头来分析和总结一下 SOA 的特点和实施难度,有什么新发现?

  有几个关键词语逐渐映入眼帘:高标准化、高规范化、高管控。

  上面提到的所有 SOA 特点基本上都能用这 3 个词语来支撑,即: 按照既定规范来实现标准化的实施目标,且整个过程是被合理管控的 。听上去有点咬文嚼字的感觉,但是,这就是 SOA 架构设计与实施的精髓,所有成功的 SOA 实施项目都离不开高质量的标准化、规范化和管控。但是这里又引出一个问题,如此高质量的标准化、规范化和管控,怎样能尽量快速、高质量的实现并保证 SOA 架构实施的成功率?

  既然是普遍性的“高”要求,则很难保证这种“高”要求能一次性的覆盖到所有的系统实施、所有的流程和服务设计、所有的管控细节,因此,在大规模实施 SOA 架构时,多轮迭代的方法称为基本策略,基本方法如下:

  将系统实施分成 3 个子策略:

  · 新建组件(系统) ,当业务建模后发现现有系统均不能覆盖需求时,则必须新建一个组件(系统)以满足业务需求,新建的系统必须符合 SOA 架构规范标准

  · 先改造封装组件(系统)后再重构 ,当业务建模后,发现某些原有系统基本功能可以满足业务需求时,但是不能满足 SOA 架构标准规范时,将原有系统进行 SOA 服务改造,使其能够符合新的 SOA 架构标准规范,待其时机成熟时再重构成新的符合 SOA 架构要求的组件(系统)

  · 保持现状 ,当此系统可以完全满足业务建模需求,而且 SOA 架构改造不够紧迫时,建议保持现状的系统。

  按照上面的 3 个子策略特征,将现有系统进行全部分析,分别选择上述的 3 种实施策略,跟据业务需求的紧迫度、功能满足度、数据满足度、系统老化程度、资源投入状况、改造风险等维度,进行多轮迭代改造,逐步将企业中的全部系统改造成复合 SOA 架构。

  这种多轮迭代的方式,可以充分的锻炼 IT 队伍,使大家的 SOA 架构能力逐步提高,每次迭代都使得标准、规范和管控逐步提高到新的成熟度,既满足了业务战略需求,又降低了实施风险和投入,是大型传统企业架构到 SOA 架构的迁移策略的最佳方案


比特微信账号
比特微信账号

微信扫一扫
关注Chinabyte

返回首页 长微博 返回顶部