SOA中的服务发现对此项目的附加价值是什么？

Question

我们正在对一个由大约9个软件产品组成的支离破碎的体系结构进行改造。这些产品都与社会/社区平台有关。这些软件产品，包括网络应用、网络服务和智能手机应用，都是由学生开发的，没有任何体系结构的依附。应用程序本身是用特定的体系结构开发的，但没有考虑或加入任何系统范围的体系结构。因此，我的团队有责任把所有的东西都粘合在一起，这样这些软件产品就可以一起交流了。

我一直在考虑面向服务的体系结构，因为我喜欢能够插入服务的想法，也因为许多软件产品本身都可以被称为服务。然而，真正困扰我的主题是我在每个SOA文本中看到的服务发现。我不明白为什么我会需要它当：

1. 每个软件产品的信息和服务需求都有明确的定义。他们知道他们需要哪些其他产品以及他们想要什么信息。
2. 没有外部/第三方服务目录，也没有使用该目录的计划。

坦率地说，为什么我不能在各自的软件产品中硬编码所需的服务呢？甚至只需创建服务器的小型数据库，并使用代理来编排API调用等等？当然，还会想到可伸缩性的问题：“如果添加了一个新服务怎么办?您要编辑所有的源代码吗？”不，只是那些需要新服务的人。“如果所有的产品都需要新的服务怎么办？”那么，我们将其添加到一个小的开发工作中。

透明度也可能受到影响：“如果我们想知道服务的完整服务描述，以及我们可以针对它的API进行的调用，怎么办？”那我们就看一下文档。

我很难理解这种情况下的必要性。如果没有服务发现或描述之类的东西，我也很紧张，因为我不能把它当作一个真正的SOA。有人能解释一下在这个项目中服务发现的潜力吗？

Answer 1

如果您的所有软件项目都是组织内部的，并且界面边界设计得很好，并且有完整的文档记录，那么您可能根本不需要服务发现。

但是，如果您发布其他组织所依赖的公共API以使其软件正常运行，那么服务发现可能变得更加重要。面向服务的体系结构的一个重要部分是允许公司以一种面向数据的方式进行协作，而服务发现帮助他们做到这一点。

术语“面向服务的架构”与某些“大型编程”相关，比如消息队列和服务总线。如果你不需要这些东西，那么我会质疑一个完整的SOA架构是否适合你的需求。您可以在不部署整个SOA架构的情况下获得松散耦合和模块化的好处，也许可以利用微服务。