Erlang / OTP架构：用于SOAish服务的RESTful协议

Question

让我们想象一下，我们有一个披萨店的订单处理系统来设计和建造。

要求是：

R1。系统应该是客户端和用例不可知的，这意味着客户端可以访问系统，在初始设计期间不考虑该系统。例如，如果披萨店决定其许多客户以后使用三星Bada智能手机，为Bada OS编写客户端将不需要重写系统的API和系统本身;或者，例如，如果事实证明使用iPad而不是Android设备对交付驱动程序来说更好，那么创建iPad客户端并不会以任何方式影响系统的API;

R2。可重用性，这意味着如果业务流程发生变化，系统可以轻松重新配置，而无需重写代码。例如，如果稍后披萨店将开始接受在线支付以及接收交付驱动程序的现金（在接受订单VS接受付款时接受付款），那么系统将很容易适应新的业务流程;

R3。高可用性和容错性，这意味着系统应该在线并且应该全天候接受订单。

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

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

此外，如果披萨店需要对其CRM客户端进行一些增强，那么我们将不得不重写API，客户端和系统本身。

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

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

• Erlang / OTP的所有优点，因为每个Webmachine都是一个Erlang应用程序，可以监督并可以放入Erlang版本中;
• 面向服务的体系结构，包含所有SOA benefits;
• 易于适应业务流程中的changes;
• 易于向客户端添加新客户端和新功能（例如，向CRM客户端），因为客户端可以使用系统中所有服务的RESTful API，而不是一个“中央”API（SOA的服务可组合性）

因此，基本上，第二张图中提出的系统体系结构是面向服务的体系结构，其中每个服务都有一个RESTful API而不是WSDL协定，每个服务都是一个Erlang / OTP应用程序。

以下是我的问题：

1. 图2：我想在这里重新发明轮子吗？我应该坚持使用纯Erlang / OTP架构吗？ （“纯Erlang”意味着Erlang应用程序包含在一个版本中，通过相互交谈 gen_server：call和gen_server：cast function calls）;
2. 您能说出建议方法中的任何缺点吗？ （图2）
3. 您是否认为维护和增长（R1和R2）这样的系统（图2）比真正的Erlang / OTP系统更容易？
4. 这样一个系统的安全性（图2）可能是一个问题，因为有许多入口点可以通过Web（所有服务的RESTful API）而不是只有一个入口点（图1），不是吗所以？
5. 在这样的系统中是否可以使用多个“编排模块”，或者可能存在一些更好的实践？ （图2）中的“接受订单”，“CRM”和“调度订单”服务;
6. 纯粹的Erlang / OTP（图1）在消息传递和协议限制方面是否优于此方法（图2）？ （在我之前的类似question中部分讨论过，gen_server：调用VS HTTP RESTful调用）

Answer 1

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

因此，从我在您的问题中阅读的内容来看，我可能会将服务划分为更粗粒度的服务（见下文）。服务边界内的通信可以是任何地方，因为跨服务的通信使用公共API（REST或Erlang本地由您决定，但关键是它是管理，版本化，安全等） - 再次，服务可能有多种技术中的端点，以方便不同的用户（有时您使用ESB在服务和协议之间进行调解，但对此的需求取决于系统的大小和复杂性）

关于您的具体问题

• 1如上所述，我认为这是一个公开更多公共API的地方 而不仅仅是一个入口点，我不确定暴露每个和 作为public-api服务的每项功能都是正确的方法 见。
• 2＆amp; 3暴露每件小事的缺点是 管理开销，性能下降（例如，您必须 对这些电话进行身份验证）。您获得了nano-services项服务 其开销超过其效用。

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

  • 5可以使用多个编排模块，但是如果超出一些，您可能应该考虑一些编排模块（以及ESB或编排引擎），或者您可以使用基于事件的集成并获得基于编排的集成

  更灵活（但管理性更差）

  • 6第一个选项的优点是易于开发，可能性能更好（如果这是一个问题）。随着时间的推移，硬编码的集成层可能难以维护。 erlang服务，如果你写它们写的应该能够独立发展，如果你保持API集成和它们之间的消息传递（幸运的是，Erland通过它的固有特性（例如不变性）使它变得相对容易）

    < / LI>

Answer 2

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

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