Erlang/OTP体系结构:用于RESTful服务的SOAish协议

Question

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

所需经费如下：

R1.系统应该与客户端和用例无关，这意味着客户端可以访问系统，而客户端在最初的设计中没有考虑到这一点。例如，如果披萨店决定其许多客户稍后使用三星Bada智能手机，为Bada OS编写客户端将不需要重写系统的API和系统本身；或者例如，如果发现使用iPads而不是Android设备在某种程度上有利于交付驱动程序，那么就很容易创建iPad客户端，并且不会以任何方式影响系统的API；

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

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

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

​

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

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

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

​

系统中的每个‘服务’都是一个带有Webmachine的Webmachine服务器。这种做法的好处如下：

• Erlang/OTP的所有优点，因为每个put机器都是一个Erlang应用程序，可以进行监督，并可以放入Erlang发行版；
• 面向服务的体系结构，包括所有的利益；
• 易于在业务流程中适应变化；
• 很容易向客户端添加新客户端和新功能(例如，客户端)，因为客户端可以使用系统中所有服务的RESTful API，而不是一个“中心”API(服务可组合性)。

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

以下是我的问题：

1. 图2:我是在尝试重新发明轮子吗？我应该坚持使用纯的Erlang/OTP体系结构吗？("Pure“是指将Erlang应用程序打包到一个发行版中，通过gen_server:call和gen_server:cast函数调用相互交谈)；
2. 你能指出在建议的方法中有什么缺点吗？(图2)
3. 你认为维护和增长(R1和R2)这样的系统比真正的Erlang/OTP系统更容易吗？
4. 这样一个系统(图2)的安全性可能是一个问题，因为有许多入口点可以向web开放(所有服务的RESTful API)，而不仅仅是一个入口点(图1)，不是吗？
5. 在这样一个系统中有几个“编排模块”可以吗?或者可能存在一些更好的实践？(图片2上的“接受订单”、"CRM“和”发送订单“服务)；
6. 纯粹的Erlang/OTP (Picture 1)在消息传递和协议的局限性方面比这种方法(Picture 2)有什么优势吗？(在我以前类似的问题、gen_server:call VS HTTP调用中部分讨论过)

Answer 1

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

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

Answer 2

关于SOA，要记住的是，体系结构与技术无关(REST，WS* )。因此，您可以使用几种类型的端点(我称之为边缘分量 --将业务逻辑从通信和协议等其他关注点中分离出来)建立一个良好的SOA，而且重要的是要注意服务边界是信任边界，因此当您跨越服务边界时，您可能需要进行身份验证和授权，跨网络等等。此外，分离为层(比如数据和逻辑)不应该驱动您划分服务的方式。

因此，根据我在您的问题中所读到的内容，我可能会将服务划分为更粗粒度的服务(参见下面)。服务边界内的通信可以是什么？？因为跨服务的通信使用公共API (REST或Erlang本机由您决定，但重点是它是管理的、版本化的、安全的等等)--同样，一个服务可能在多种技术中都有端点，以方便不同的用户(有时您会使用ESB在服务和协议之间进行中介，但这取决于系统的大小和复杂性)。

关于你的具体问题

• 1如上文所述，我认为有一个地方可以公开更多的公共api，而不仅仅是一个入口点，我不确定是否使用public-api将每个功能都公开为服务是正确的。
• 2&3暴露每件小事的缺点是管理开销、性能下降(例如，您必须对这些调用进行身份验证)。您得到的纳米服务服务的开销超过了它们的实用程序。
• 关于安全性，有一点需要补充的是，某些服务具有REST这一事实并不一定要转换为使普通公众可以使用该API。部署方面，您可以将其保存在防火墙后面，并限制对已知地址的访问，等等。

- 5 It is ok to have several orchestrating modules, though if you get beyond a few you should probably consider some orchestration module (and ESB or an Orchestration engine) alternatively you can use event based integration and get choreography based integration which is more flexible (but somewhat less manageable )
- 6 The first option has the advantage of easy development and probably better performance (if that's an issue). The hard-coded integration layer can prove harder to maintain over time. The erlang services, if you wrote them write should be able to evolve independently if you keep API integration and message passing between them (luckily Erland makes it relatively easy to get this right by its inherent features (e.g. immutability))

​

​

​