四步迁移到SOA

简介: 向面向服务的架构(SOA)迁移是令人畏惧的,尤其是那些初次涉足SOA的企业,本文对此提出了一些建议。

向面向服务的架构(SOA)迁移是令人畏惧的,尤其是那些初次涉足SOA的企业,本文对此提出了一些建议。

 

 

IT业界最新流行的技术是面向服务的架构(Services-Oriented Arc

hitecture,SOA)。一方面,IT经理们因为SOA的美好前景而对此心驰神往,而另一方面又害怕这个新的架构给组织带来的冲击。为了确保平稳过渡到SOA,建议遵守以下四个简单步骤。

 

 

第一步,定义SOA。

 

 

如果就“SOA到底意味着什么”请教5个IT专业人士,你可能会得到5种不同的答案,这是因为这种架构发展很快。不过,这没有关系。IT界对于SOA是否有一个完全一致的定义不是问题的关键,但是IT组织内的每个人对于“SOA对一个公司意味着什么”意见一致非常重要。特别是如果企业正在实施面向服务的架构,请记住最重要的一点就是企业的IT组织对于SOA必须有一个清晰的了解和定义。

 

 

这里建议IT人员研究一些有关SOA的资料,然后制定一个对本企业的IT组织有意义的定义和目标。IT人员也可以向与你在一起工作的SOA领域的专家请教,针对公司的具体要求来定义它。SOA是非常灵活,足以应对各种各样的集成挑战。

 

 

最关键的是整个组织必须“拥有”它自己的SOA定义,IT组织的每个人都必须了解这个定义,完全地支持这个新的规范,而且要应用各种资源来实现它。

 

 

第二步,对员工进行培训。

 

 

对许多企业来说,SOA从根本上背离了传统的界面与应用程序紧耦合的架构。因此,在理解SOA上可能面临较大的认知改变,这时候对员工进行培训和教育就非常必要。

 

 

这里推荐一个至上而下的培训方法。首先,就SOA的基本原理以及部署它的优点,对高层管理人员进行培训,这很关键。比如,如果一个CIO不能掌握SOA的基本理论和这个架构所要达到的目标,他将不能够很好地支持它。

 

 

在对上层管理人员进行了培训之后,接下来还得培训下一级的管理人员。他们不仅仅要接受有关SOA总的目标和理论的培训,而且还得就实践细节以及如何操作进行培训。

 

 

最后,培训员工如何具体地操作和部署SOA。在这个层次,需要就支持公司向SOA迁移的技术进行具体的培训。这是培训的重点,需要花最多的时间和精力。

 

 

谨记一次培训是不够的。因为SOA这个概念对于很多IT专业人士来说很陌生,他们中的许多人更熟悉别的架构模式。而要理解一个全新的规范通常是很困难的。大多数人对事物的认识都有一个边界,当一个新的理论超过这个界线时,人们可能会因为它与他们原来所认知的理论相差太大而拒绝它。想克服这一点需要做大量的工作,包括管理和培训,而且通过对员工进行反复教育也是完全可能达到的,千万不要泄气。多次的时间证明,只要坚持培训,就会收到成效。

 

 

第三步,建立企业治理委员会。

 

 

SOA最终目的是建立一个灵活的架构,能够通过一个通用的平台集成各种各样、相互独立、异构的应用程序。这必须通过设计和开发独立的应用服务来实现,这些服务能在整个组织中被访问和共享。

 

 

确保一个企业能够开发松耦合的应用程序和开发可重用的服务,成立治理委员会是绝对必要的。一些文献和业内人士把这个委员会称为综合能力中心(Integration Competency Center,ICC)。

 

 

当企业建立自己的综合能力中心时,有些关键问题必须考虑。首先必须确保ICC中的成员在业务领域和IT部门中都有很强的代表性。

 

 

要记住,我们的目标是消灭信息孤岛,提高应用在企业中重复使用率。这只能通过大量的企业代表参与的权力制衡机制才能完成。指派其中最好最聪明的同事到治理委员会,确保他们受过良好的培训,而且是非常有见识的SOA的拥护者。他们是最有可能不用CIO为他们花时间的人,所以这项工作并不影响他们同时做别的工作。高层管理者必须了解这个团队参与的重要性,而且愿意为了他们更侧重于这项工作而重新分配工作量。

 

 

第四步,大处着眼,小处着手。

 

 

最后也是最重要的是,刚开始实施SOA时不要过于急于求成,而必须一步一步逐步进行。

 

 

实践证明IT产业中大爆炸式的方法很少起作用。小的、递进式的变化由于更易于管理反而有更大的成功机会。很幸运的是,因为SOA架构使企业可以一次实现一个服务,所以逐步递进的方法在实施SOA的过程中效果很好。

 

 

首先,挑一个低风险但对公司很重要的相对次要功能开始。比如说从若干系统中搜寻和整合客户信息可能是一个比较好的选择,可以从开发这样一个服务着手,要求其功能支持整个组织里的多个应用使用。接下来,对各种各样依赖于点对点的接口的系统进行解耦,重定向到一个新的服务。

 

 

在整个组织大范围采用服务,如把企业的财务应用重定向到一个通用的接口之前,从小的功能开始可以让整个组织初步了解SOA,而且如果有必要的话可以对整个过程进行改善。另外,这也为公司提供了一把很好的尺子,来测量整个组织是否已经为SOA这种全新的架构完全做好了准备。(译自Computerworld) 

相关文章
|
1天前
|
存储 消息中间件 SQL
微服务改造血泪史:数据库拆分踩过的那些坑!
本文复盘了传统项目改造成微服务架构时,数据库拆分过程中遇到的问题。主要问题包括:1. 数据库拆分过细,导致跨服务调用频繁,破坏服务独立性;2. 数据一致性难以保证,分布式事务管理复杂;3. 跨服务查询影响性能,复杂查询难以实现。初次改造时应避免过度拆分,逐步演进架构。
8 0
|
7月前
|
缓存 安全 前端开发
初学后端,如何做好表结构设计?
初学后端,如何做好表结构设计?
111 0
|
存储 分布式计算 Kubernetes
微服务想用好,先把分布式和微服务之间的关系搞清楚
微服务想用好,先把分布式和微服务之间的关系搞清楚
微服务想用好,先把分布式和微服务之间的关系搞清楚
|
SQL 缓存 数据库
微服务轮子项目(30) -数据库分库分表、部署上线方式(上)
微服务轮子项目(30) -数据库分库分表、部署上线方式
124 0
|
canal 中间件 关系型数据库
微服务轮子项目(30) -数据库分库分表、部署上线方式(下)
微服务轮子项目(30) -数据库分库分表、部署上线方式(下)
65 0
|
消息中间件 微服务
微服务轮子项目(31) -消息队列对比参照表
微服务轮子项目(31) -消息队列对比参照表
42 0
|
存储 运维 架构师
如何画架构图?有什么是一定要有的,又有什么是不该有的?
如何画架构图?有什么是一定要有的,又有什么是不该有的?
139 0
如何画架构图?有什么是一定要有的,又有什么是不该有的?
|
XML 前端开发 Java
微服务项目:尚融宝(17)(后端搭建:数据字典)
微服务项目:尚融宝(17)(后端搭建:数据字典)
微服务项目:尚融宝(17)(后端搭建:数据字典)
|
存储 Java 应用服务中间件
漫谈!如何简单明了通过分解和增量更改将单体迁移到微服务
微服务迁移不是一个小更改。你必须搞清楚它是否真的能解决你的问题,否则你可能会创建一个会杀死你的、乱糟糟的实体。 单体有不同类型,其中一些可能是有效的,足以满足业务需求。单体不是一个应该被杀死的敌人。 微服务关乎独立部署。有一些分解和增量更改模式可以帮助你评估并迁移到微服务架构。 当你开始使用微服务时,你会意识到随之而来的是一系列非常复杂的挑战。所以不应该将微服务作为默认选择。你得仔细考虑它们是否适合你。
漫谈!如何简单明了通过分解和增量更改将单体迁移到微服务
|
运维 监控 Kubernetes
一份微服务架构手稿图,彻底搞定微服务核心原理!
微服务的概念最早在 2012 年提出,在 Martin Fowler 的大力推广下,微服务在 2014 年后得到了大力发展。今天我们通过一组手绘图来梳理下微服务的核心架构。
848 0
一份微服务架构手稿图,彻底搞定微服务核心原理!