And*_*ewO 9 architecture administration modularity admin
我工作的地方它变得明显,一些管理任务应该是从公共网站独立多数民众赞成成长无论是在用户基础和功能点方面的站点.我想知道最好的办法是什么.
例如,该网站有一个很大的社交组件和一个公共销售界面.但与此同时,管理部分还有后台任务,批量上传处理,仪表板(长时间运行的查询)和客户关系工具,我希望不会受到公共交通高峰的影响(或影响公众 - 面对响应时间).
该站点运行在一个相当标准的Rails/MySQL/Linux堆栈上,但我认为这更像是一个架构问题,而不是一个实现问题:主要是,如何在这些不同的应用程序之间保持数据和业务逻辑同步？
我正在评估的一些策略:
1)在另一台机器上创建面向公众的数据库的从数据库. 提取出所有模型和库代码,以便可以在应用程序之间共享.为管理界面创建新的控制器和视图.
我对复制的经验有限,甚至不确定它是否应该以这种方式使用(大多数时候我已经看过它,它是用于扩展同一应用程序的读取功能,而不是具有多个不同的应用程序) .如果从站不在同一网络上,我也担心潜在的延迟问题.
2)创建新的更多任务/部门特定的应用程序,并使用面向消息的中间件来集成它们. 我读了一段时间的企业集成模式,他们似乎主张分布式系统.(或者,在某些情况下,基本的Rails风格的RESTful API功能可能就足够了.)但是,我有关于数据同步问题的噩梦以及这将带来的大规模重新架构.
3)两者的混合物. 例如,某些后台任务所需的唯一公共信息是只读完成时间或状态.将它放在一个完全独立的系统并将数据发送给公众是否有意义？同时,用户/组管理功能将在共享数据库的单独系统上运行？缺点是,这似乎保留了我对前两个问题的许多担忧,特别是重新构建.
我确信答案将高度依赖于网站的特定需求,但我很想听听成功(或失败)的故事.
据我从您的描述中可以看出，如果您确实想确保面向公众的性能和管理性能不会相互影响，您将必须在不同的服务器上使用单独的数据库。
关键是要充分了解哪些数据在何处使用以及数据如何参与流程。如果您能做到这一点，请尝试确定是否可以使一个数据库成为“领先”数据库。这将是您的实时数据，另一个数据库将是您的操作数据存储 (ODS)。ODS 始终是实时数据的衍生品。从实时数据更新 ODS 的过程可以每隔一段时间进行一次，这样既可以简化数据，又可以进行额外的处理，使其更适合使用 ODS 的应用程序。
现在，如果您发现这对于您当前的情况来说是一个很大的飞跃，您可以尝试至少分离数据库中的数据，这样您就不会处理诸如表锁等性能问题。如果您将来需要转向类似 ODS 的模型，这是朝着正确方向迈出的一步。