服务反模式与案例研究
1. 服务反模式
1.1 事务集成与Saga模式
在处理库存问题时，订单服务可能需要执行补偿操作。为了合理处理，服务可能需要保存一些数据，如库存水平数据，以便自主做出合理决策。
Saga模式可与通信反转模式结合，使服务根据自身操作发送事件，并订阅其他事件以创建编排场景。以订单服务为例，订单服务发布新订单需要处理的事件，库存服务监听该事件。库存服务确保物品后，发布相应事件，订单服务可通知客户订单已准备好。
Saga和通信反转模式都实现了最终一致性系统，放宽了各服务决策的时间限制，这通常也符合业务的一般运作方式。
事务集成在大多数分布式系统中通常不是好主意，但在基于SOA原则构建的封闭系统中可能是个例外。不过，即使在这种罕见情况下，也最好使用编排引擎在服务外部控制事务范围。
1.2 老方法反模式
老方法反模式可能在应用新技术或架构时出现，当难以将其在现实世界中实现时就可能发生。
例如，一个所谓的“SOA”架构，左边是数据服务（数据库包装在Web服务或RESTful外壳中），中间是处理客户和账户业务逻辑的实体，右边是CRUD服务接口。但这实际上是一个n层/n级架构，并非真正的SOA。
这种反模式的后果是，使用SOA工具和开销实现非SOA架构，付出了SOA的代价却未获得SOA的好处。SOA的代价包括设计和运行时的更多投入，以及增加的延迟和组件局部复杂性。
老方法反模式主要由对SOA理解不足导致，常见误解是将Web服务与SOA服务直接关联。此外，从其他架构风格向SOA过渡的系统也可能出现这种反模式。
重
