基于服务的架构不一定意味着分布式？
在我的工作场所(以及许多其他领域)，围绕服务构建架构是非常重要的。(我在一家电子商务初创公司工作)。然而，我认为服务被隐含地认为是分布式的。我相信分配的第一定律--“不要分配”。因此，我认为我们不应该不必要地使架构复杂化。它应该是一个可以进化的架构。因此，解决这个问题的方法之一是创建定义良好的命名空间并围绕它构建代码，但通过java api保持通信。(这使得监控需求较低，可靠性/可用性问题也较少)。通过将模块包装到web服务中，当规模需求生效时，可以很容易地将其演变为分布式体系结构。因此，问题是-将代码作为单个应用程序编写并演变为分布式服务，而不是直接跳到实现基于web服务的体系结构中，有什么缺点？我假设服务应该包含设计的基本原则(抽象、封装等)，而不是通过网络分发，这是正确的吗？
回答 1
Stack Overflow用户
发布于 2011-09-18 04:01:28
发行版需要模块化。然而，它需要的不仅仅是模块性:它还需要模块之间的粗粒度交互。
例如，在单进程电子商务系统中，您可能有单独的模块来管理用户的购物车和计算价格。他们可能会通过购物车进行交互，要求计算器给一件商品定价，然后再给另一件商品定价，等等。这将是非常好的。
然而，在分布式系统中，这将需要大量的小方法调用，这是低效的；如果您使用CORBA进行分发，您可能会逃脱惩罚，但是使用SOAP，您就会遇到麻烦。相反，你会想让购物车要求计算器一次性为整个订单定价。从关注点分离的角度来看，这可能会更糟(为什么计算器必须知道购物车的概念？)，但这将是使系统充分执行所必需的。
与粒度相关，还有模块通过接口或实现进行交互的问题。使用单个进程，您可以定义一组接口，模块将通过这些接口进行交互；模块可以相互传递实现这些接口的对象，而不必告诉彼此实现的信息(例如，可以向调度程序模块传递实现interface Job { void run(); }的任何内容)。在整个网络中，对粗粒度的要求意味着任何传递的对象都必须通过值传递(因为通过引用传递将需要对传递模块进行细粒度的回调-除非您正在使用移动代码，而您没有使用移动代码，因为没有人使用移动代码)，这意味着两个模块都必须了解对象的实现并就其实现达成一致。
因此，虽然以模块化方式构建单进程系统可以更容易地在以后实现SOA，但它并不像将每个模块包装在SOAP接口中那样简单。至少，除非您从一开始就以粗粒度的方式构建您的系统，这意味着丢弃许多合理且有用的良好软件工程实践。
https://stackoverflow.com/questions/7457160
复制相似问题
腾讯云开发者
