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的所有优点 ;
• 易于适应业务流程的变化 ;
• 易于向客户端添加新客户端和新功能(例如,向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. 您是否认为维护和增长(R1和R2)这样的系统(图2)比真正的Erlang/OTP更容易？
4. 这样一个系统的安全性(图2)可能是一个问题,因为有许多入口点对Web开放(所有服务的RESTful API)而不是一个入口点(图1),是不是这样？
5. 在这样的系统中有几个"编排模块"还是可以存在一些更好的实践？(图2中的"接受订单","CRM"和"调度订单"服务);
6. 纯粹的Erlang/OTP(图1)在消息传递和协议限制方面是否优于这种方法(图2)？(在我之前的类似问题中部分讨论过,gen_server:调用VS HTTP RESTful调用)

Answer 1

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

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