Erlang/OTP 架构:用于 SOAish 服务的 RESTful 协议 [英] Erlang/OTP architecture: RESTful protocol for SOAish services

问题描述

假设我们有一个供比萨店设计和建造的订单处理系统.

Let us imagine we have an orders processing system for a pizza shop to design and build.

要求是:

R1. 系统应该与客户端和用例无关，这意味着系统可以被在初始设计时没有考虑在内的客户端访问.例如，如果比萨店决定其许多客户以后使用三星 Bada 智能手机，那么为 Bada OS 编写客户端将不需要重写系统的 API 和系统本身；或者例如，如果事实证明使用 iPad 而不是 Android 设备在某种程度上更适合送货司机，那么创建 iPad 客户端会很容易，并且不会以任何方式影响系统的 API；

R1. The system should be client- and use-case-agnostic, which means that the system can be accessed by a client which was not taken into account during the initial design. For example, if the pizza shop decides that many of its customers use the Samsung Bada smartphones later, writing a client for Bada OS will not require rewriting the system's API and the system itself; or for instance, if it turns out that using iPads instead of Android devices is somehow better for delivery drivers, then it would be easy to create an iPad client and will not affect the system's API in any way;

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

R2. Reusability, which means that the system can be easily reconfigured without rewriting much code if the business process changes. For example, if later the pizza shop will start accepting payments online along with accepting cash by delivery drivers (accepting a payment before taking an order VS accepting a payment on delivery), then it would be easy to adapt the system to the new business process;

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

R3. High-availability and fault-tolerance, which means that the system should be online and should accept orders 24/7.

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

So, in order to meet R3 we could use Erlang/OTP and have the following architecture:

这里的问题是这种架构有很多硬编码"的功能.例如，如果比萨店在下订单前从接受货到付款转变为接受在线支付，那么重写整个系统和修改系统的 API 将需要大量的时间和精力.

The problem here is that this kind of architecture has a lot of "hard-coded" functionality in it. If, for example, the pizza shop will move from accepting cash payments on delivery to accepting online payments before the order is placed, then it will take a lot of time and effort to rewrite the whole system and modify the system's API.

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

Moreover, if the pizza shop will need some enhancements to its CRM client, then again we would have to rewrite the API, the clients and the system itself.

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

So, the following architecture is aimed to solve those problems and thus to help meeting R1, R2 and R3:

系统中的每个服务"都是一个带有 RESTful API 的 Webmachine 网络服务器.这种方法有以下好处:

Each 'service' in the system is a Webmachine webserver with a RESTful API. Such an approach has the following benefits:

• Erlang/OTP 的所有优点，因为每个 Webmachine 都是一个 Erlang 应用程序，可以被监督并可以放入 Erlang 版本中；
• 面向服务的架构，具有 SOA 的所有优势；
• 易于适应变化 在业务过程中；
• 易于向客户端添加新客户端和新功能(例如添加到 CRM 客户端)，因为客户端可以使用系统中所有服务的 RESTful API，而不是一个中央"API(SOA 方面的服务可组合性).

因此，本质上，第二张图片中提出的系统架构是面向服务的架构，其中每个服务都有一个 RESTful API 而不是 WSDL 契约，并且每个服务都是一个 Erlang/OTP 应用程序.

So, essentially, the system architecture proposed in the second picture is a Service Oriented Architecture where each service has a RESTful API instead of a WSDL contract and where each service is an Erlang/OTP application.

这是我的问题:

1. 图 2:我是在尝试重新发明轮子吗?我应该坚持使用纯 Erlang/OTP 架构吗?(Pure Erlang"意味着 Erlang 应用程序打包成一个版本，通过gen_server:call 和 gen_server:cast 函数调用);
2. 您能说出建议方法中的任何缺点吗?(图二)
3. 您认为维护和发展(R1 和 R2)这样的系统(图 2)比真正的 Erlang/OTP 系统更容易吗?
4. 这样的系统(图 2)的安全性可能是一个问题，因为有许多对 Web 开放的入口点(所有服务的 RESTful API)，而不仅仅是一个入口点(图 1)，不是吗?那么?
5. 在这样的系统中是否可以有多个编排模块"，或者是否存在一些更好的做法?(图 2 中的接受订单"、CRM"和发货订单"服务)；
6. 纯 Erlang/OTP(图 1)在消息传递和协议限制方面是否比这种方法(图 2)有优势?(在我之前的类似问题中部分讨论过, gen_server:call VS HTTP RESTful 调用)

1. Picture 2: Am I trying to reinvent the wheel here? Should I just stick with the pure Erlang/OTP architecture instead? ("Pure Erlang" means Erlang applications packed into a release, talking to each other via gen_server:call and gen_server:cast function calls);
2. Can you name any disadvantages in suggested approach? (Picture 2)
3. Do you think it would be easier to maintain and grow (R1 and R2) a system like this (Picture 2) than a truly Erlang/OTP one?
4. The security of such a system (Picture 2) could be an issue, since there are many entry points open to the web (RESTful APIs of all services) instead of just one entry point (Picture 1), isn't it so?
5. Is it ok to have several 'orchestrating modules' in such a system or maybe some better practice exists? ("Accept orders", "CRM" and "Dispatch orders" services on Picture 2);
6. Does pure Erlang/OTP (Picture 1) have any advantages over this approach (Picture 2) in terms of message passing and the limitations of the protocol? (partly discussed in my previous similar question, gen_server:call VS HTTP RESTful calls)

推荐答案

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

I'd introduce the third way that is rather more cost effective and change-reactive. The architecture definitely should be service oriented because you have services explicitly. But there's no requirement to expose each service as Restful or WSDL-defined one. I'm not an Erlang developer but I believe there's a way to invoke local and remote processes by messaging and thus avoid unnecessary serialisation/serialisation activities for internal calls. But one day you will be faced with new integration issue. For example you will be to integrate accounting or logistic system. Then if you designed architecture well regarding SOA principles the most efforts will be related to exposing existing service with RESTful front-end wrapper with no effort to refactor existing connections to other services. But the issue is to keep domain of responsibilities clean. I mean each service should be responsible to the activity it was originally designed.

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

The security issue you mentioned is known one. You should have authentication/authorization in all exposed services using tokens for example.

这篇关于Erlang/OTP 架构:用于 SOAish 服务的 RESTful 协议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！