在Stack上有相同的question，我想做的，但我的问题有一个不同的方面。
今天我有一个Rails应用程序，它管理Web应用程序和API，但我想把它分开，以便更有效地管理服务器资源。
问题是：App 1如何知道App 2何时插入新记录？Rpush？Sql触发器？或者将API转换为gem？
App 1-使用DB 1的WebService端口80
class Post < ActiveRecord::Base
belongs_to :user
before_save :do_stuff_when_app2_insert_record #I know this doesn't work in this environment
def do_stuff_when_app2_insert_record
...
end
endApp 2- API连接-使用DB 1的端口8080
class Post < ActiveRecord::Base
belongs_to :user
end
Post.create(name: 'post')
1条答案
按热度按时间sauutmhj1#
不要这样
首先，两个独立的应用程序共享一个数据库通常不是一个好主意。一个应用程序的不同线程/进程？当然。但是独立的应用程序应该通过结构化进程进行通信，而不是在它们下面更改数据。
但如果你不得不
如果您决定无论如何都要执行此路由，App 1可以通过许多机制了解App 2所做的更新。您可以将更改写入App 1可以轮询的更改/通知表。您可以根据RDBMS使用自定义触发器或存储过程。App 2可以直接写入App 1正在使用的任何作业队列（sidekiq的redis示例，延迟作业表等）。App 2可能会命中App 1上的API端点。更新可以使用消息队列（redis/rabbitmq/Kafka）推送。这里没有真正的最佳实践，因为你已经放弃了他们走这条路。
分布式应用方式
如果你真正的意思是（或者决定实现）App 1和App 2应该有独立的数据库，但共享数据，那么有最佳实践可用。你需要某种灵活/可扩展的消息代理（Kafka/rabbitmq/redis），并可能使用一个强类型的模式来共享数据，以适应未来的变化。Kafka已经为此内置了工具，但也存在像谷歌的ProtoBufs这样的工具。
这意味着要转向真正的分布式体系结构，这意味着许多额外的问题和复杂性。您将不得不考虑哪个系统是任何共享数据的真实来源。您将需要有一些机制来保持系统同步，检测它们何时不同步，在构建分布式系统时，这些最后的步骤经常被忽略，如果不这样做，可能会使组织陷入停顿。t从一开始就考虑到了。
使用这种方法，更新将发布到总线，App 1可以侦听Post更新，在本地记录它们，并触发回调。
可能是正确的方式：独石
另一种方法是App 1和App 2实际上只是同一个rails应用程序的不同方面。除非它们出于某种具体原因绝对需要成为独立的应用程序：他们不应该是。无论你这样做的理由是什么，都应该受到极端的怀疑。
Rails是一个非常灵活的框架，像rails引擎这样的工具已经存在，并且有广泛使用的例子可以借鉴。你的rails应用可以是很多应用，这样做可以消除大量的复杂性。
您可能需要更多的应用程序，但如果它们需要共享数据到考虑共享数据库的程度，那么您可能会强制在单个代码库中解决的问题之间设置边界。