图2：
组合服务对下层的应用服务进行了组合，完成了一个基本的业务动作，应用服务中是最基本的基础性的原子性的操作。但是在复杂的业务需求下大部分业务功能都需要跨越多个应用线来完成一个最外层的企业动作。提交订单可能需要穿过很多应用线，订单管理、仓库、财务等等环节。所以这里我们还需要一个能在最外层对组合服务进行编排的业务服务。这个编排服务可以完全是自动化的，通过工作流引擎进行组合自动化来完成，这对企业应用的自动化流程很有意义。
2.3.业务服务(编排服务)
业务服务是最外层的服务，向下编排了组合服务。业务服务位于最上层，当需要有跨越多个应用线来完成的业务，这个业务就放入业务服务中。比如提交订单，先检查库存、扣减库存(冻结库存)，然后下单，再往后通知财务，再往后通知物流等等都是一个复杂的企业服务线。这种最外层的业务逻辑如果你不进行SOA分层然后将其放入最外层的业务服务中，你把它放入任何一个应用线都会使系统调用混乱不堪。所以问题就是需要进行纵向的划分层次。如果进行了SOA的层次划分后就不会出现互相乱用的情况。其实这里可以参考阿里的服务设计方法。(李智慧写的一本大型互联网架构与实践里面也讲到了服务要划分层次)
图3：
当在业务服务中执行的业务逻辑时，需要跨越多个应用线来完成。这部分的逻辑也说是职责，如果不放入这个位置，放在哪个应用线都不合适，放入哪个应用线都会使系统调用出现混乱。其实这里的问题就是我们不能用一个维度来进行SOA系统的设计，本来服务就具有组合特性，所以适当的提升服务的层次是有好处的，但是应用服务和组合服务可以在代码层面上进行构建，而业务服务也叫编排服务是需要进行物理隔离的，毕竟考虑到系统复杂度和稳定性问题这是值得的。在排查问题，系统性能、稳定性等等方面，物理的隔离有一定的作用，毕竟业务服务本来就是来组合多个应用线的，这样做会使整个系统架构很清晰。
3.SOA化的重构
进行SOA化的实施，大部分情况下都是对现有系统进行重构后考虑的，初期企业发展阶段以快速出原形为首要目标，只有当系统出现瓶颈了才会考虑运用SOA来解决。但是在这个时候有很多历史包袱无法解决，进行SOA化的重构其实成本是很高的，而且很危险，对有些复杂的逻辑说的现实点，是无能为力的。如果都可以通过重构这个技术来解决，那我们就太天真了。《重构—马丁.福勒》一书讲的是代码层面的重构，跟做系统级重构两个概念。对系统级别的重构还没有太多成熟的方法论支撑。尤其现在新技术层出不穷的，各有优点，能很好的运用这些技术、方法论、过程来重构大型企业级系统，难度非常大，这需要整个公司投入很多人力、资源成本。回过头来想想，其实在前期适当考虑一下还是有必要的，这样可以减少后期很多技术债务。
这里我只总结我在分析、设计公司某一块业务系统的时候对其进行SOA化的重构思路。重构本来就是一个不断迭代的过程，不可以跨大步。通过很多脚手架支撑，让系统慢慢的过度到新的SOA架构下，既然要实施SOA架构，那么很重要的一点就是对迁移的业务逻辑适当的归类，什么业务逻辑该放入“业务服务”中，什么逻辑该在代码层面上放入“组合服务”中，对基本的操作有如何放入代码层面的“应用服务”中。
3.1.保留服务空间，为了将来服务的组合
在进行系统拆分的时候，对当前后端的调用都进行适当的规划，将其分为两类，一类是应用服务，一类是组合服务，这两个服务是可以在代码层面上进行抽象。重点是那些调用其他系统的地方，需要将其放入业务服务中，这块逻辑比较复杂，难以抽取，需要适当的结合”数据落地“的思路来综合考虑。有时候把一部分数据落入本地可以提升系统的整体简洁度和稳定性，但是要考虑数据的一个生命周期性质。
在迁移的过程中可能还会有一些新的功能并行开发的，既有新的逻辑需要放入新的SOA服务中，也会有迁移过来的逻辑，这两个过程同时进行其实很痛苦，尽量避免这样同时进行，但是现实是根本不可能，正常都是一起并行推进。如果这两个过程是同一组团队负责其实还好，毕竟对这块的代码、业务都比较了解。