让我们想象一下，我们的应用程序需要从关系数据库到另一个关系数据库的ETL（提取，转换，加载）数据 . 最简单（和大多数性能，恕我直言）的方式是在数据库之间 Build 链接并编写简单的存储过程 . 在这种情况下，我们使用最少的技术和组件，所有功能都是“开箱即用” .
但这是SOA（面向服务的架构）的良好实践吗？紧耦合怎么样？我们是否永远将数据库强烈地相互耦合？
还有另一种方法：我们在每一侧构建2个Java应用程序，并通过SOAP Web服务进行通信 . 这更加SOA友好！但性能下降和额外的失败点值得吗？
在这种情况下，最佳做法是什么？ ETL如何适应SOA？
4 回答
在SOA中，您可以采用Biztalk或SAP BusinessObjects Data Integrator方式进行处理 . 基本上，它是一个调度程序作业/ Windows服务，或类似的东西 . 您提供两个服务点，1表示调度程序检索数据，另一个表示调度程序发送数据 . 此处的调度程序负责定期运行和转换数据 .
所以，基本步骤将是：
步骤1：调度程序运行并从服务A获取数据
第2步：调度程序进行数据转换
步骤3：调度程序将数据发送到另一个服务
在Biztalk和SAP BusinessObject Data Integrator中，这些步骤都是可配置的（它们可以从任何服务中检索并可以进行脚本数据转换），因此它更灵活 .
但是，ETL处理仍然会出现常见问题 . 例如：数据太大，网络性能影响，RTO，重复数据等 . 因此，ETL最佳实践仍然是一个要求（使用登台表，日志记录等） .
性能影响将发生，因为现在您有额外的连接/身份验证步骤（到webservice）和传输步骤（通过协议的webservice到调度程序） . 但是对于容易出错的问题，我认为与其他服务调用需要处理的错误相同 .
这值得么？这取决于 . 如果您在相同的环境（相同的数据库）中工作，那么它是有争议的 . 如果您在不同的环境中工作（例如，两个不同的系统，从Asp.Net到SAP，或者至少是不同的数据库实例），那么这种架构是处理ETL的最佳选择 .
ETL通常适用于SOA - 例如SOA服务可以在彼此之间执行ETL操作 .
当您要复制数据库或在其他类似情况下，数据库到数据库的链接非常有用 . 通常，此方法与SOA无关，除非存在以下情况 .
当SOA服务使用这两个数据库时，数据库到数据库的链接不适合SOA . 在这种情况下，您应该通过服务进行沟通 .
当只有一个数据库是SOA服务的持久性时，数据库到数据库的链接仍然适用于SOA . 另一个可以被视为故障转移或简单复制，与SOA没有直接关系 . 在这种情况下，数据库到数据库的链接只会成为与数据相关的问题，您可以拥有并解决这些问题 .
对我来说，db-to-db和Rest -based设置中缺少几点：etl进程中的异常：
什么时候认为数据的转换是有效的？
如何处理不成功的转换结果？
在大多数情况下，抛弃数据不是一种选择 .
系统故障/恢复
如果一个/两个系统停机一段时间怎么办？如何处理同步？什么时候etl失败了，哪里必须重新启动？
因此，与使用数据库或休息服务相互交流时，这与使用迁移技术（如Apache Camel或使用ESB）更为相关，并且具有数据完整性的正面结果 .
当然：ESB是与SOA相关的技术 . Apache Camel对我来说并不是真的，虽然它被认为是企业集成模式的参考实现 .
基本上，它背后的想法是etl是基于内容而不是基于结构的问题 .
所以你可以用这些技术做的事情如下：
DB < - DataExtractor - Validator
以及更多，但这不适合文本描述 .
所有这些答案都很好，很有帮助 .
正如我现在所理解的，SOA不是关于实现应用程序，而是关于架构（“A”），主要是企业架构 . 企业主要管理方法是服务责任委托（“S”） .
因此，如果企业结构中有两个不同的业务功能，并且有两个不同的负责账户，我们应该将它分成两个不同的服务，其中包含明确定义的 Contract （接口），政治和审计方法 - 这是SOA的主要目的 .
但如果它是一个负责人的原子功能，那么SOA就没那么需要了，我们应该使用简单的技术并实现简单快速的可靠服务应用 .
至于我原来的问题，它缺乏任务上下文信息 . 现在我明白数据库链接不应该跨服务实现，而且设计不好因为没有企业管理兼容性 . 但在服务中，它可能是一个很好的简单解决方案 .
感谢大家的回答 .