(转)漫谈SOA(面向服务架构)

http://blog.csdn.net/luohuacanyue/article/details/12521699

    面向服务架构的思想在整个软件的架构中已经不是什么新鲜的东西。我简单的认为服务化是模块化的延伸，因此服务化有着和模块化相似的优势和缺点。这里再也不讨论这些服务定义服务与服务之间的通讯协议（像WSDL等等），我并不认为这是服务化的本质所在。即便Java语言用RMI进行服务与服务之间的通讯也仍然不违背服务化的宗旨。

一.为何须要面向服务架构

        1.我以为面向服务的根本好处是便于管理，也是应用大到必定时候的必然产物。这每每和组织架构之间相契合。其实不合理的服务划分也会带来服务之间的混乱。

        2.面向服务是一个解耦的过程，松耦合下降了服务之间的依赖，也意味着服务一个服务出现故障的时候不容易引发连锁反应，也能更好的控制服务与服务之间的关系与优先级。

        3.不一样语言之间的通讯。

二.面向服务架构的好处

        在为何要面向服务架构里面已经讲到了这样的好处。这里再举一些简单的例子来阐述。好比说一个应用部署在一台机器上，然而无论如何优化单机是没法撑起整个应用。这时候有两种思路。

        水平扩展，即整个应用做为一个总体，而后水平扩展到多台机器上。

图A

 

        服务拆分，这是解耦的过程，也符合软件工程中“高内聚，低耦合”的思想。每每第一步会进行模块化。这样作可能还不够，咱们须要让它们可以独立生存。这样一个大的服务“分裂”成一个一个比较小可以独立生成的服务，这里的关键是能够独立生存，意味着它们能够部署在不一样的机器上，必定程度上达到了“分布式”的效果。

图B

 

三.总结

        上面从两个维度讲到了机器扩展。这二者在系统的拆分中会同时存在。从纯性能的角度讲应该采用第一种方案。两第二种方案并不看成解决性能的整体方案。而主要从软件管理的角度来说进行拆分。这种拆分使得整个业务的粒度愈来愈细，也会愈来愈好控制，保证每一个服务的高内聚，有清晰的边界。

        面向服务架构是一种思想，固然对于大系统而言其利必大于弊，而系统比较小的时候盲目的拆分和服务化其实会致使整个维护成本上升。系统架构并无一层不变的套路，也没必要彻底遵循某种模式。一切都在实际应用中结合具体的应用场景。应该说是“方法论”的具体产物。