四步迁移到SOA

简介:
向面向服务的架构迁移是令人畏惧的,尤其是那些初次涉足SOA的企业,本文对此提出了一些建议。
 
 
IT业界最新流行的技术是面向服务的架构一方面,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最终目的是建立一个灵活的架构,能够通过一个通用的平台集成各种各样、相互独立、异构的应用程序。这必须通过设计和开发独立的应用服务来实现,这些服务能在整个组织中被访问和共享。
 
 
确保一个企业能够开发松耦合的应用程序和开发可重用的服务,成立治理委员会是绝对必要的。一些文献和业内人士把这个委员会称为综合能力中心
 
 
当企业建立自己的综合能力中心时,有些关键问题必须考虑。首先必须确保ICC中的成员在业务领域和IT部门中都有很强的代表性。
 
 
要记住,我们的目标是消灭信息孤岛,提高应用在企业中重复使用率。这只能通过大量的企业代表参与的权力制衡机制才能完成。指派其中最好最聪明的同事到治理委员会,确保他们受过良好的培训,而且是非常有见识的SOA的拥护者。他们是最有可能不用CIO为他们花时间的人,所以这项工作并不影响他们同时做别的工作。高层管理者必须了解这个团队参与的重要性,而且愿意为了他们更侧重于这项工作而重新分配工作量。
 
 
第四步,大处着眼,小处着手。
 
 
最后也是最重要的是,刚开始实施SOA时不要过于急于求成,而必须一步一步逐步进行。
 
 
实践证明IT产业中大爆炸式的方法很少起作用。小的、递进式的变化由于更易于管理反而有更大的成功机会。很幸运的是,因为SOA架构使企业可以一次实现一个服务,所以逐步递进的方法在实施SOA的过程中效果很好。
 
 
首先,挑一个低风险但对公司很重要的相对次要功能开始。比如说从若干系统中搜寻和整合客户信息可能是一个比较好的选择,可以从开发这样一个服务着手,要求其功能支持整个组织里的多个应用使用。接下来,对各种各样依赖于点对点的接口的系统进行解耦,重定向到一个新的服务。
 
 
在整个组织大范围采用服务,如把企业的财务应用重定向到一个通用的接口之前,从小的功能开始可以让整个组织初步了解SOA,而且如果有必要的话可以对整个过程进行改善。另外,这也为公司提供了一把很好的尺子,来测量整个组织是否已经为SOA这种全新的架构完全做好了准备.









本文转自 牛海彬 51CTO博客,原文链接:http://blog.51cto.com/newhappy/77294,如需转载请自行联系原作者
目录
相关文章
|
6月前
|
关系型数据库 MySQL 网络安全
MySQL主从复制之多主多从部署流程—2023.04
MySQL主从复制之多主多从部署流程—2023.04
157 0
|
5月前
|
SQL 缓存 数据库
微服务轮子项目(30) -数据库分库分表、部署上线方式(上)
微服务轮子项目(30) -数据库分库分表、部署上线方式
56 0
|
5月前
|
canal 中间件 关系型数据库
微服务轮子项目(30) -数据库分库分表、部署上线方式(下)
微服务轮子项目(30) -数据库分库分表、部署上线方式(下)
39 0
|
8月前
|
监控 关系型数据库 MySQL
架构基本流程
架构基本流程
|
11月前
|
Kubernetes 测试技术 Go
分享:一文搞清楚应用发布到k8s集群的基本流程
分享:一文搞清楚应用发布到k8s集群的基本流程
312 0
|
存储 缓存 前端开发
微服务测试:关键策略和工具
开发团队越来越多地选择微服务架构而不是单体结构,以提高应用程序的敏捷性、可扩展性和可维护性。随着决定切换到模块化软件架构——其中每个服务都是一个独立的单元,具有自己的逻辑和数据库,通过 API 与其他单元通信——需要新的测试策略和新的测试工具。
122 0
|
存储 Java 应用服务中间件
漫谈!如何简单明了通过分解和增量更改将单体迁移到微服务
微服务迁移不是一个小更改。你必须搞清楚它是否真的能解决你的问题,否则你可能会创建一个会杀死你的、乱糟糟的实体。 单体有不同类型,其中一些可能是有效的,足以满足业务需求。单体不是一个应该被杀死的敌人。 微服务关乎独立部署。有一些分解和增量更改模式可以帮助你评估并迁移到微服务架构。 当你开始使用微服务时,你会意识到随之而来的是一系列非常复杂的挑战。所以不应该将微服务作为默认选择。你得仔细考虑它们是否适合你。
179 0
漫谈!如何简单明了通过分解和增量更改将单体迁移到微服务
|
消息中间件 缓存 容灾
四步构建异地多活(3)
四步构建异地多活(3)
234 0
四步构建异地多活(3)
|
消息中间件 容灾 关系型数据库
四步构建异地多活(2)
四步构建异地多活(2)
四步构建异地多活(2)
|
消息中间件 缓存 容灾
四步构建异地多活(1)
四步构建异地多活(1)
181 0
四步构建异地多活(1)