面向服务架构的思想在整个软件的架构中已经不是什么新鲜的东西。我简单的认为服务化是模块化的延伸，所以服务化有着和模块化类似的优点和缺点。这里不再讨论这些服务定义服务与服务之间的通信协议（像WSDL等等），我并不认为这是服务化的本质所在。即使Java语言用RMI进行服务与服务之间的通信也仍然不违背服务化的宗旨。
一.为什么需要面向服务架构
1.我觉得面向服务的根本好处是便于管理，也是应用大到一定时候的必然产物。这往往和组织架构之间相契合。其实不合理的服务划分也会带来服务之间的混乱。
2.面向服务是一个解耦的过程，松耦合降低了服务之间的依赖，也意味着服务一个服务出现故障的时候不容易引起连锁反应，也能更好的控制服务与服务之间的关系与优先级。
3.不同语言之间的通信。
二.面向服务架构的好处
在为什么要面向服务架构里面已经讲到了这样的好处。这里再举一些简单的例子来阐述。比如说一个应用部署在一台机器上，然而不管如何优化单机是无法撑起整个应用。这时候有两种思路。
水平扩展，即整个应用作为一个整体，然后水平扩展到多台机器上。
图A
服务拆分，这是解耦的过程，也符合软件工程中“高内聚，低耦合”的思想。往往第一步会进行模块化。这样做可能还不够，我们需要让它们能够独立生存。这样一个大的服务“分裂”成一个一个比较小能够独立生成的服务，这里的关键是可以独立生存，意味着它们可以部署在不同的机器上，一定程度上达到了“分布式”的效果。
图B
三.总结
上面从两个维度讲到了机器扩展。这两者在系统的拆分中会同时存在。从纯性能的角度讲应该采用第一种方案。两第二种方案并不当作解决性能的总体方案。而主要从软件管理的角度来讲进行拆分。这种拆分使得整个业务的粒度越来越细，也会越来越好控制，保证每个服务的高内聚，有清晰的边界。
面向服务架构是一种思想，当然对于大系统而言其利必大于弊，而系统比较小的时候盲目的拆分和服务化其实会导致整个维护成本上升。系统架构并没有一层不变的套路，也不必完全遵循某种模式。一切都在实际应用中结合具体的应用场景。应该说是“方法论”的具体产物。