让我们想象一下,我们需要设计和构建一个披萨店的订单处理系统。
要求如下:
R1. 系统应该是客户端和用例无关的,这意味着系统可以被未在初始设计中考虑的客户端访问。例如,如果披萨店决定后来很多客户使用三星Bada智能手机,则编写针对Bada OS的客户端不需要重写系统的API和系统本身;或者例如,如果使用iPad而不是Android设备在送货司机方面更好,那么很容易创建一个iPad客户端并且不会以任何方式影响系统的API;
R2. 可重用性,这意味着如果业务流程发生变化,系统可以轻松重新配置而不需要重写太多代码。例如,如果披萨店将开始在线接受付款,同时与送货司机一起接受现金付款(接受订单前付款与到货时付款),那么很容易将系统适应新的业务流程;
R3. 高可用性和容错性,这意味着系统应该在线,并且应该全天候接受订单。
为了满足R3,我们可以使用Erlang/OTP并采用以下架构:![Pure Erlang/OTP architecture with one RESTful API entry point](https://istack.dev59.com/UBBBn.webp)
此外,如果比萨店需要对其CRM客户端进行一些增强,则需要重新编写API、客户端和系统本身。
因此,以下架构旨在解决这些问题,并帮助满足R1、R2和R3:
![Service Oriented Architecture with multiple RESTful API entry points](https://istack.dev59.com/riGfh.webp)
- 具备 Erlang/OTP 的所有优点,因为每个 Webmachine 都是一个 Erlang 应用程序,可以被监控并放入 Erlang 发布中;
- 享有面向服务的架构(SOA)的所有 benefits;
- 易于适应业务流程中的changes;
- 易于向客户端添加新客户和新功能(例如向 CRM 客户端添加新功能),因为客户端可以使用系统中所有服务的 RESTful API 而不是一个“中央”API(在 SOA 方面的服务组合)。
因此,第二张图片中提出的系统架构实质上是一个面向服务的架构,其中每个服务都有一个 RESTful API 而不是 WSDL 合同,并且每个服务都是一个 Erlang/OTP 应用程序。
下面是我的问题:
- 图片2:我是在试图重复造轮子吗?还是应该坚持使用纯Erlang/OTP架构?(“纯Erlang”指的是将Erlang应用程序打包到一个发布版本中,通过gen_server:call和gen_server:cast函数调用彼此通信);
- 您能否列举出建议方法的任何缺点?(图片2)
- 您认为像这样的系统(图片2)比真正的Erlang/OTP系统更容易维护和扩展吗?
- 这种系统(图片2)的安全性可能会成为一个问题,因为对于Web开放了许多入口点(所有服务的RESTful API),而不仅仅是一个入口点(图片1),是这样吗?
- 在这样的系统中是否可以有几个'编排模块',或者是否存在更好的做法?(图片2上的“接受订单”,“CRM”和“调度订单”服务);
- 纯Erlang/OTP(图片1)在消息传递和协议限制方面是否比这种方法(图片2)具有优势?(在我的类似question之前的部分讨论了这一点,gen_server:call VS HTTP RESTful calls)