Erlang / OTP体系结构：SOAish服务的RESTful协议

Question

让我们想象一下，我们有一家比萨店要设计和制造的订单处理系统。

要求是：

R1。 该系统应该与客户端和用例无关，这意味着客户端可以访问该系统，而在初始设计期间并未考虑该系统。 例如，如果披萨店决定以后许多客户使用Samsung Bada智能手机，则为Bada OS编写客户端将不需要重写系统的API和系统本身。 举例来说，如果事实证明使用iPad而不是Android设备对交付驱动程序有某种程度的优势，那么创建iPad客户端将很容易，并且不会以任何方式影响系统的API；

R2 可重用性，这意味着如果业务流程发生变化，可以轻松地重新配置系统，而无需重写大量代码。 例如，如果稍后披萨店将开始在线接受付款并由送货司机接受现金（在接受订单之前接受付款与接受送货上付款），那么很容易使系统适应新的业务流程;

R3。 高可用性和容错能力，这意味着系统应该在线并且应该接受24/7的订单。

因此，为了满足R3，我们可以使用Erlang / OTP并具有以下架构：

这里的问题是这种体系结构中有很多“硬编码”功能。 例如，如果披萨店从下达订单时的接受现金付款转为接受在线付款，那么将需要大量时间和精力来重写整个系统并修改系统的API。

而且，如果比萨店需要对其CRM客户进行一些增强，那么我们将不得不再次重写API，客户和系统本身。

因此，以下架构旨在解决这些问题，从而帮助满足R1，R2和R3：

系统中的每个“服务”都是具有RESTful API的Webmachine Web服务器。 这种方法具有以下优点：

• Erlang / OTP的所有优点，因为每个Web机都是一个Erlang应用程序，可以对其进行监控并可以将其放入Erlang版本中；
• 面向服务的体系结构，具有SOA的所有优点 ；
• 易于适应业务流程的变化 ；
• 易于向客户端（例如CRM客户端）添加新客户端和新功能，因为客户端可以使用系统中所有服务的RESTful API，而不是一个“中央” API（就SOA而言，服务可组合性）。

因此，从本质上讲，第二张图中提出的系统体系结构是面向服务的体系结构，其中每个服务都具有RESTful API而不是WSDL合同，并且每个服务都是Erlang / OTP应用程序。

这是我的问题：

1. 图2：我在这里试图重塑车轮吗？ 我应该只坚持使用纯Erlang / OTP架构吗？ （“纯Erlang”表示打包到发行版中的Erlang应用程序，它们通过gen_server：call和gen_server：cast函数调用相互通信）；
2. 您能指出建议方法中的任何缺点吗？ （图2）
3. 您认为像这样的系统（图2）维护和扩展（R1和R2）系统要比真正的Erlang / OTP系统容易吗？
4. 这样的系统的安全性（图2）可能是一个问题，因为有许多入口点（不限一个入口点（图1））开放到网络上（所有服务的RESTful API），不是吗？
5. 在这样的系统中可以有几个“编排模块”，还是存在一些更好的做法？ （图2中的“接受订单”，“ CRM”和“调度订单”服务）；
6. 就消息传递和协议限制而言，纯Erlang / OTP（图1）是否比该方法（图2）具有任何优势？ （在我之前的类似问题 gen_server：call VS HTTP RESTful调用中进行了部分讨论）

Answer 1

关于SOA要记住的一点是，体系结构与技术（REST，WS *）无关。 因此，如果需要/需要时，您可以使用几种类型的端点来获得良好的SOA（我称之为Edge组件 -将业务逻辑与其他方面的问题（如通信和协议）分开）。还要注意服务边界是一个信任边界因此，当您跨接它时，可能需要进行身份验证和授权，跨网络等。此外，分层（如数据和逻辑）不应驱动服务划分方式。

因此，从我在阅读您的问题时所读的内容来看，我可能会将服务划分为更粗糙的服务（请参见下文）。 服务边界内的通信可以是任何东西，因为跨服务的通信使用公共API（REST或Erlang本机由您决定，但关键是要对其进行管理，版本控制，安全保护等）-同样，服务可能具有采用多种技术的终结点，以便利不同的用户（有时您会使用ESB在服务和协议之间进行调解，但是否需要取决于系统的大小和复杂性）

关于您的具体问题

• 1如上所述，我认为有一个地方可以公开比单个入口点更多的公共API，我不确定公开使用public-api作为服务的每项功能是否是正确的选择。
• 2＆3暴露每件事的缺点是管理开销，性能下降（例如，您必须在这些调用中进行身份验证）。 您将获得纳米服务服务，其开销远远超过其效用。

• 关于安全性要增加的一件事是，某些服务具有REST API的事实不必转化为让公众可以使用该API。 在部署方面，您可以将其保留在防火墙后面，并限制对已知地址等的访问。

  • 5可以有几个编排模块，但是如果您不打算使用几个编排模块，则可能应该考虑使用一些编排模块（以及ESB或编排引擎），或者您可以使用基于事件的集成并获得基于编排的集成，这种集成更加灵活（但是不太容易管理）

  • 6第一种选择的优点是易于开发并且可能具有更好的性能（如果这是一个问题）。 随着时间的推移，硬编码集成层可能会变得难以维护。 如果您编写了erlang服务，那么如果您保持它们之间的API集成和消息传递，那么编写的它们应该能够独立发展（幸运的是，Erland通过其固有功能（例如，不变性）相对容易地实现了这一目标）

Answer 2

我将介绍第三种方式，该方式更具成本效益并且对变更反应灵敏。 该体系结构绝对应该面向服务，因为您明确拥有服务。 但是不需要将每个服务公开为Restful或WSDL定义的服务。 我不是Erlang开发人员，但我相信有一种方法可以通过消息传递来调用本地和远程进程，从而避免内部调用的不必要的序列化/序列化活动。 但是有一天，您将面临新的集成问题。 例如，您将要集成会计或物流系统。 然后，如果您根据SOA原则设计了良好的体系结构，则最大的努力将与使用RESTful前端包装公开现有服务有关，而无需努力重构与其他服务的现有连接。 但是问题是保持职责范围整洁。 我的意思是，每个服务都应对最初设计的活动负责。

您提到的安全问题是已知的。 例如，您应该在所有使用令牌的公开服务中进行身份验证/授权。