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

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

要求是：

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

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

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

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

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

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

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

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

• Erlang/OTP 的所有优点，因为每个 Webmachine 都是一个 Erlang 应用程序，可以对其进行监督并可以放入 Erlang 版本中；
• 面向服务的架构，具有所有benefits http://en.wikipedia.org/wiki/Service-oriented_architecture#Benefits of SOA;
• 容易适应changes http://kinderman.net/2010/06/23/approaching-pure-rest-learning-to-love-hateoas在业务流程中；
• 轻松向客户端（例如 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）有什么优势吗？ （在我之前的类似文章中部分讨论过question https://stackoverflow.com/questions/11173252/soa-why-do-not-use-erlang-otp-web-servers-as-services, gen_server:call VS HTTP RESTful 调用）

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

因此，根据我在您的问题中读到的内容，我可能会将服务划分为更粗粒度的服务（见下文）。服务边界内的通信可以是任何形式，因为跨服务的通信使用公共 API（REST 或 Erlang 本机由您决定，但重点是它是受管理的、版本控制的、安全的等）——同样，服务可能具有多种技术的端点，以方便不同的用户（有时您会使用 ESB 在服务和协议之间进行协调，但是否需要取决于系统的大小和复杂性）

关于您的具体问题

• 1 如上所述，我认为有一个地方可以公开更多公共 API 不仅仅是一个入口点，我不确定是否暴露每个入口点 每个功能即服务与 public-api 都是正确的选择 看。
• 2&3 暴露每一件小事的缺点是 管理开销，性能下降（例如，您必须 对这些调用进行身份验证）。你得到纳米服务 http://arnon.me/wp-content/uploads/2010/10/Nanoservices.pdf服务 他们的开销超过了他们的效用。

• 关于安全性需要补充的一件事是，某些服务具有 REST API 的事实并不一定意味着该 API 可供公众使用。在部署方面，您可以将其保留在防火墙后面并限制已知地址对其的访问 ETC。

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

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