对于服务识别的方法，在前面很多文章都已经讲到过，对于SOA实施中服务识别是相关重要的一个环节，如何基于业务驱动IT的思路，识别出真正粗粒度，高度自治，可复用的服务是后期服务治理管控能否顺利的一个关键。否则SOA建设到后期很容易就变成一个数据集成平台，而非是服务共享平台。

要知道服务的本质还是接口和交互，因此对于服务的识别总体来说两种方法：

1. 自顶朝下：基于业务流程分析入手，分析跨系统业务流程交互，识别出集成点和接口点，再转化为服务

2. 自底朝上：基于当前遗留系统已有的系统间接口情况，分析接口对应的业务场景，再进行接口转服务

可以看到不论是哪种方法，这里面都有两个重点，其一是必须要明确的清楚每一个服务的业务含义，对应的业务场景和业务交互点在哪里?其次就是需要做接口转服务这个关键动作。

1. 自顶朝下的服务识别

如果各个业务系统之间没有业务和数据的交互，那么跟根本不应该存在任何的接口或服务。而对于服务的存在原因主要还是我们的端到端业务流程往往是跨了多个业务系统的交互才能实现的，而这些跨业务系统的交互点要么进行业务规则的校验，要么进行关键业务数据和单据的传递。

这些交互点和集成点都是潜在的接口服务识别点，通过这种方式识别出来的服务我们就很清楚服务对应的业务流程和场景。比如采购系统和ERP之间有一个采购订单导入的接口服务，我们就很清楚整个供应链流程中，采购订单的创建和生效是在采购系统里面，但是基于采购订单的采购接收和入库是在ERP系统，因此需要将采购订单同步到ERP系统中。

这种跨系统流程分析基本会把横向的所有关键接口全部梳理出来，但是容易遗漏点纵向的一些基础数据共享接口，距离来说我们在拟制采购订单的时候，是需要输入和选择项目信息，选择对应的库存组织信息的。而这些基础数据需要从项目管理系统和ERP系统中同步过来。但是在流程图中往往只会有采购订单创建节点，因此容易遗漏这些基础数据共享接口。

还有就是某一个业务功能在实现过程中，可能涉及到调用外部的业务规则和逻辑，这种交互点也容易遗漏需要特别注意。举例来说，采购订单在创建完成的时候并提交的时候需要检查预算是否足够，而这个检查规则逻辑是预算管理系统实现的，因此在这里也存在采购系统和预算系统间的业务接口和服务。

2. 自底朝上的服务识别

特别遗留系统环境进行SOA架构改造和服务接入的时候，我们要意识到必须要将遗留系统间的当前已有接口全部分析和梳理清楚。因为既然当前遗留系统能够正常运作，也能完成跨系统的业务交互，那么原来的接口从面上是完全能够覆盖业务需求的，我们唯一要考虑的是接口本身的定义和设计是否合理的问题。

当整理出完整的接口清单后，我们要做的就是搞清楚每一个接口对应的业务场景究竟是如何的?基于这种反向思路我们只关系和接口相关的业务交互场景，而不是关注全部业务流程。搞清楚了具体的业务场景后，接着要做的重点工作就是对接口进行评估，接口的评估主要包括了如下内容：

a) 接口当前使用频度如何?是实时还是定时同步?同步频率能否满足业务的要求?

b) 接口传递的数据量如何?当前在数据传递的时候有无性能问题?

c) 接口本身的实现方法是如何的?比如Dblink，存储过程，WS接口，还是直接原始的JDBC接口等。

d) 接口本身的复用度如何?相关类似的接口由哪些?相互之间有哪些差异?

做了接口评估最主要的仍然是要考虑如何进行接口去重和接口合并，对于接口转服务的方法，我前面有专门一篇文章再谈，在这里就不再展开。

本身相互独立的两个业务系统，比如A系统和B系统，按道理两个系统应该完全独立，包括数据库，中间件，应用部署包等。两个系统之间只能通过标准的接口进行业务和数据的交互。但是实际在项目实施中发现一种普遍存在的现象，即A系统将自己的数据库账户完全开放为B系统，而B系统在拿到数据库连接串信息后，通过自己编码实现完全可以对数据库A中的数据库表进行各种任意的CRUD操作。

在这种情况下可以看到，A和B两个系统之间已经完全耦合在一起，这个时候A系统要做数据库层面的迁移和数据库表结构的变更往往全部会影响到B系统。如果要把这些接口点找到，必须要把B系统中的所有代码进行遍历查找和分析，往往才能够找到具体的接口点有哪些。这些不规范的使用方式都对后续的SOA服务改造和迁移造成相对重大的影响。