本页内容
![]() | 处理服务简介 |
![]() | 业务处理服务的优点 |
![]() | 使用处理服务准则 |
![]() | 处理服务所带来的好处 |
![]() | 处理小结 |
在使用多项服务来创建系统时,很容易出现服务间通信失控的情况。 例如,可能有一项服务会调用另外五项服务,而在这五项服务中,有些会再调用其他服务,这样,系统很快就会失去控制。 由于每项服务都必须辨别出其所调用服务的接口,从而导致大型系统最终会包含大量依赖项。 它还会使系统中创建多个入口点,这将进一步使系统失控。
图 1 说明多项服务如何很快变得难以管理。
![失控的服务](https://i-blog.csdnimg.cn/blog_migrate/91ee23042dd1c0b4c210e710799fa8da.png)
图 1. 失控的服务
在该方案中,处理与业务操作是紧密缠绕在一起的。 虽然在所有服务间互相传递的消息提供了一个隐式处理,但在这种情况下,很难更改该处理,使之符合您单位的需要。 它还使找出系统中的问题所在变得更困难。
在雇员雇佣/解雇方案中所发生的情况,就是这种情况的一个示例:要实现所有必要的任务,需要与大量服务进行通信。 需要向人力资源部门报告某雇员的现况,通知信息技术部门更新用户帐户和域信息,通知安保部门更新该雇员进入大厦的权限,等等。 每一项任务在实施过程中都包含一系列步骤;例如,人力资源服务需要将新雇员添加到公司的薪水册名单、电话号码簿、通知列表中,等等。 要使所有这些系统都知道彼此的情况,您需要在整个系统中创建许多依赖项,而这将不利于系统的维护。
处理服务简介
针对上面所提出的问题,一个合理的解决方案就是将服务的过程因素分离出来,形成一个专用的业务处理。 业务处理(即处理)控制执行某些工作的分步操作,使系统从一种状态进入另一种状态。 它将在每一步调用一个业务操作。 这些处理可以在业务处理服务或处理服务中管理。 这种处理服务中的处理将发送消息来调用服务中包含的业务操作,然后继续执行下一步,而在下一步中,将需要使用不同服务。
针对前面提到的雇员信息示例,可以创建一个负责与各个部门进行通信的处理。 这样,每个部门都将有其自己的处理来控制完成内部业务职能所需的步骤。
图 2 演示了如何使用这些处理服务将这些职能集中起来。
![使用处理服务](https://i-blog.csdnimg.cn/blog_migrate/99db15efa3f9290b8f3fb4b9f4d003ce.png)
图 2. 使用处理服务
业务处理服务的优点
使用业务处理服务的优点很多,其中包括:
• | 更好地控制业务处理。 使用处理服务可以提供一个中心服务,该中心服务控制其他服务的交互,从而可以查询运作信息和管理信息。 这将进一步改善系统的管理和维护。 例如,在设计订购应用程序时,可以在处理中添加功能,从而可以查询当前所下定单的数量或这些定单的总成本。 还可以使用业务处理来获得处理中特定步骤所占用的时间或询问系统不同部分在任意时间的负载。 |
• | 降低处理更改的系统开销。 大多数系统的处理定义都是动态的;它将根据组织内的业务决策而更改。 从另一方面来说,核心业务功能的改变不会这么快并且其改变都是局部的。 将功能的这两种因素分开处理更有利于处理本身的更新。 例如,可以更改下定单所需的步骤,向客户关系管理 (CRM) 系统请求地址信息,而不是每个定单都手动输入一次地址信息,但这不会改变实际的定单进入定单系统的过程。 如果在其他位置针对业务逻辑定义了处理,则可以更容易地在步骤中添加对 CRM 服务的调用。 |
• | 减少依赖项的数量。 当许多服务直接交互时,这些服务必须辨别出各自的服务接口。 这样,在合并更多服务时,依赖项数量将按服务数的指数倍增长。 而利用处理服务提供的中心管理点,则可以使用星形拓朴,其在系统中保留的依赖项总数与涉及的服务数呈线性比例关系。 |
• | 简化外部通信。 仅向外界公开一个入口点,这样可以简化外部服务的连接并更易于确保系统没有后门。 |
• | 简化异常处理。 在分布式系统中,如果没有独立的处理服务,将很难在发生异常时确定需要执行的任务。 而如果使用处理服务,则可以有一个中心管理区域来控制处理中的每一步,这意味着您可以纵览全局,从而更易于找出解决问题所需的步骤。 |
使用处理服务准则
要避免许多协定并对服务去耦,下列做法是不错的选择:
• | 避免业务服务之间的直接通信。 使业务服务通过处理服务进行通信。 这样,将形成一个异常处理中心点和一个扩展系统功能的中心点;在以后,将有机会添加其他调用。 如果这意味着仅需单一操作就可以定义一个处理,那就这样吧。 在实现或部署过程中优化处理是很容易的;而从头设计则很难。 |
• | 使处理订阅事件而不是使业务服务订阅事件。其推理与前面段落中所述完全相同。 |
• | 在服务与服务(尤其是顶级处理服务)之间使用较粗粒度的请求。 如果需要,处理可以将这样的请求拆分为较细粒度请求。 较粗粒度请求更改的可能性较小,因而因而需要的通信较少。 |
• | 创建提供无状态会话的业务服务。 也就是说,业务服务公开双方都无需保留处理状态的服务接口,这将要求保持双方的处理同步,从而使服务更加复杂,而这种复杂是没有必要的。 |
• | 避免公开机密/技术详细信息。 公开服务的内部信息,不管这种内部信息是算法还是数据库布局,都将使以后的更改变得更困难。 |
• | 不要在服务间共享原子事务。 这一点在以前曾经陈述过;ACID 事务要求在外部锁定数据,而这种锁定所持续的时间是不确定的。 即使另一项服务是完全受信任的,也不能保证两项服务总是彼此靠近并总是保持可靠和快速的连接。 共享事务是一种紧耦合形式。 |
请注意,如果由于处理仅调用一项服务而导致其不提供任何其他值,则最好优化它,而不是设计它。 如果以后需要扩展处理,那么,撤消优化比设计处理要更容易。由于可以使用消息路由基础结构来执行优化,所以无需修改客户端来适应这种更改。
处理服务操纵其从其他服务获取的数据;它们处理引用数据以及每种处理状态。 处理服务可以使用服务代理来管理其状态的这一部分,如图 3 所示。
![处理服务使用服务代理](https://i-blog.csdnimg.cn/blog_migrate/320b3212cfcbb8b9a3ac17224236228b.png)
图 3. 处理服务使用服务代理
处理服务所带来的好处
使用这里所描述的处理服务可以带来以下好处:
• | 集中化和结构化的异常处理。 由于任何任务所涉及的服务都有一个集中化的处理,所以,可以从一个地方来控制异常处理和任何修正请求。 |
• | 有限数量的依赖项。 由于服务之间不直接交互,所以,一个服务不需要知道其他服务的服务接口。 |
• | 处理易于管理。 处理功能的集中化,使诸如任务调度这样的情况更易于管理。 |
• | 处理的适应性提高。 因为处理是独立于业务逻辑的,所以更易于在不干扰应用程序核心业务功能的情况下实现处理的更新。 |
处理小结
使用处理可以控制服务的过程因素并将其与功能因素分离开来。 这一过程可以在服务中实现,也可以作为该任务专门的独立服务来实现。
通过这样的分离,可以得到一个控制服务交互的中心点,因而可以更好地控制业务处理。 这意味着,管理该处理将变得更容易,并且可以根据系统需要的更改而随时对其进行更改。 这还意味着,系统只有一个入口点。 使用处理服务还提供了一个在系统内进行错误处理的集中点。