异步解耦三层体系结构

Question

也许我只是期望“三层架构”提供的不仅仅是在源代码（see here）中明确分离职责 ......

我对这种可以安全地称之为“三层架构”的野兽的期望要高得多......所以，这里他们：

如果您要构建类似“三层架构”系统的东西，但这次使用这些，其他要求和约束：< / p>

• 从用户的角度始终启动并运行
  • 期望更换UI时
  • 当系统的其他部分关闭时，UI必须处理
• 永远不要进入未定义的状态或系统无法自动恢复的状态
  • 系统必须是“可以使用的”
• 中间层必须包含所有业务逻辑
  • 显然在数据层中使用底层数据库（如果你愿意）
• 业务逻辑可以使用大量核心服务（此处在数据层中，不能由UI直接访问，只能通过业务逻辑层外观）
  • 有时无法使用
  • 可以使用多个并行运行的相同进程
• 在Web UI和可能的瞬态视图烘焙模型的情况下，UI可能不包含除会话之外的任何状态
• 表示层，逻辑层和数据/核心服务层必须独立可扩展
• 你唯一理所当然的就是网络

<子> 注意：提到的“核心服务”是访问企业内各种外部系统的重量级组件。一个例子是与Active Directory或“股票市场自动收报机”的连接......

1。你会怎么做？

如果您现在没有答案，可以继续阅读并告诉我您对此的看法：

• 同步被视为有害。以错误的方式将你的系统捆绑在一起（想想：“最薄弱的环节”）。等待超时时线程被阻塞。不容易恢复。
• 对所有进程间通信（所有层之间）使用异步消息传递。允许随时暂停系统。当系统的一部分关闭时，不会发生超时。
• 拥有中央路由组件，其中所有请求都通过路由，核心服务可以自行注册。
• 添加心跳组件，例如告知UI组件当前不可用。
• 状态是必要的恶：除了业务逻辑层之外不允许任何状态。通过这种方式，野兽变得易于管理。虽然核心服务可能需要自己访问数据，但所有数据都应该由调用中间层提供。通过这种方式，核心服务可以以一种火热的方式实现。

2。您如何看待这个“解决方案”？

Answer 1

是大多数大型网站的方式。查看nosql数据库，Google的大型架构等。

<强> 1。这是我采取的一般方法。

我会为数据层使用memcached，nosql-cloud（couch-db或mongo-db）和企业级RDBMS系统（核心数据存储）的混合体。然后，我将在数据层的顶部编写服务层。 nosql数据库API是大规模并行的（看看couchdb及其ngingx服务层parallizer）。然后我提供“oldschool每个请求是一个网页”生成Web服务器，并直接访问新样式AJAX应用程序的服务层;这些都取决于服务层。

P.S。 RDBMS是这里的一个重要组件，它拥有memchached / nosql云中所有数据的权威副本。我会使用企业级RDBMS来进行数据中心到数据中心的复制。我不知道那些大男孩如何进行基于云的网站复制，如果他们将数据云做到数据云复制，我会感到害怕：P

有些观点：

• yYu不需要心跳，使用nosql 采取的方法是，如果内容 变得不可用，你重新生成它 使用。到另一台服务器上 authoratitve数据副本。
• 州的负担 - 无网页设计 被带到nosql和memcached 可无限扩展的图层。 所以你不必担心 这个。只要拥有一个良好的网络 基础设施。
• 就同步而言，就在你身边 与您期望的RDBMS交谈 可接受的同步响应 倍。你应该把你的云视为 一个异步资源，你会的 从API获得帮助 与您的云接口 甚至不必考虑这一点。
• 建议我可以提供网络 和冗余是这样的：不要去 花哨的以太网绑定，因为它不值得 它 - 事情总是出错。只是 设置冗余交换机，以太网卡 并有多条路线到你的所有 机器。你可以使用OpenBSD和 CARP为您的路由器工作 伟大的 - 路由器是你最糟糕的失败点 - openbsd解决了这个问题。

<强> 2。您已经描述了Web 2.0服务器场的常规组件，因此没有评论：D

Answer 2

我认为，在现实世界中，高可用性系统是使用故障转移实现的：例如，如果没有业务层，UI不能继续工作，而是如果业务层变为如果不可用，则UI会故障转移到使用业务层的备份实例。

除此之外，他们可能使用存储转发操作：例如邮件系统可能会存储一封邮件，如果无法立即发送，则会定期重新传输。