将管理功能与公共站点分开的最佳方法是什么？
我正在开发一个网站，该网站在用户群和功能方面都在不断发展，以至于很明显某些管理任务应该与公共网站分开。我想知道做到这一点的最佳方法是什么。
例如，该网站有一个很大的社交组件和一个公共销售界面。但与此同时，管理部分还有后台任务、批量上传处理、仪表板（带有长时间运行的查询）和客户关系工具，我希望这些工具不会受到公共流量激增的影响（或影响公共-面临响应时间）。
该站点运行在相当标准的 Rails/MySQL/Linux 堆栈上，但我认为这更多的是一个架构问题，而不是一个实现问题：主要是如何在这些不同的应用程序之间保持数据和业务逻辑同步？
我正在评估的一些策略：
1) 在另一台计算机上创建面向公众的数据库的从数据库。提取所有模型和库代码，以便可以在应用程序之间共享。为管理界面创建新的控制器和视图。
我在复制方面的经验有限，甚至不确定是否应该以这种方式使用（大多数时候我看到它，它是为了扩展同一应用程序的读取功能，而不是拥有多个不同的应用程序） 。我还担心如果从属设备不在同一网络上，可能会出现延迟问题。
2）创建新的更多特定于任务/部门的应用程序，并使用面向消息的中间件来集成它们。我不久前读过企业集成模式，他们似乎提倡在分布式系统中这样做。 （或者，在某些情况下，基本的 Rails 风格的 RESTful API 功能可能就足够了。）但是，我对数据同步问题以及由此带来的大规模重新架构感到噩梦。
3) 两者的某种混合。例如，某些后台任务所需的唯一公共信息是只读的完成时间或状态。将其放在完全独立的系统上并将数据发送给公众是否有意义？同时，用户/组管理功能将在共享数据库的单独系统上运行？缺点是，这似乎保留了我对前两者的许多担忧，尤其是重新架构。
我确信答案将高度依赖于网站的具体需求，但我很想听听成功（或失败）的故事。
I'm working on a site that's grown both in terms of user-base and functionality to the point where it's becoming evident that some of the admin tasks should be separate from the public website. I was wondering what the best way to do this would be.
For example, the site has a large social component to it, and a public sales interface. But at the same time, there's back office tasks, bulk upload processing, dashboards (with long running queries), and customer relations tools in the admin section that I would like to not be effected by spikes in public traffic (or effect the public-facing response time).
The site is running on a fairly standard Rails/MySQL/Linux stack, but I think this is more of an architecture problem than an implementation one: mainly, how does one keep the data and business logic in sync between these different applications?
Some strategies that I'm evaluating:
1) Create a slave database of the public facing database on another machine. Extract out all of the model and library code so that it can be shared between the applications. Create new controllers and views for the admin interfaces.
I have limited experience with replication and am not even sure that it's supposed to be used this way (most of the time I've seen it, it's been for scaling out the read capabilities of the same application, rather than having multiple different ones). I'm also worried about the potential for latency issues if the slave is not on the same network.
2) Create new more task/department-specific applications and use a message oriented middleware to integrate them. I read Enterprise Integration Patterns awhile back and they seemed to advocate this for distributed systems. (Alternatively, in some cases the basic Rails-style RESTful API functionality might suffice.) But, I have nightmares about data synchronization issues and the massive re-architecting that this would entail.
3) Some mixture of the two. For example, the only public information necessary for some of the back office tasks is a read-only completion time or status. Would it make sense to have that on a completely separate system and send the data to public? Meanwhile, the user/group admin functionality would be run on a separate system sharing the database? The downside is, this seems to keep many of the concerns I have with the first two, especially the re-architecting.
I'm sure the answers are going to be highly dependent on a site's specific needs, but I'd love to hear success (or failure) stories.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
据我从您的描述中可以看出，如果您确实想确保面向公众的性能和管理性能不会相互影响，您将必须在不同的服务器上使用单独的数据库。
关键是要充分了解哪些数据在何处使用以及数据如何参与流程。如果您能做到这一点，请尝试确定是否可以使一个数据库成为“领先”数据库。这将是您的实时数据，另一个数据库将是您的操作数据存储 (ODS)。 ODS 始终是实时数据的衍生品。从实时数据更新 ODS 的过程可以每隔一段时间进行一次，这样既可以简化数据，又可以进行额外的处理，使其更适合使用 ODS 的应用程序。
现在，如果您发现这对于您当前的情况来说是一个很大的飞跃，您可以尝试至少分离数据库中的数据，这样您就不会处理诸如表锁等性能问题。如果您将来需要转向类似 ODS 的模型，这是朝着正确方向迈出的一步。
As far as I can tell from your description, if you really want to make sure public facing performance and admin performance don't impact each other, you will have to use separate databases on separate servers.
The key is to get a good understanding of what data is used where and how the data is involved in the process. If you can do that then try to determine if you can make one database the 'leading' one. This would be your live data and the other database would be your operation data store (ODS). The ODS is always a derivative from your live data. The process of updating the ODS from the live data can happen at an interval and can both simplify data and do additional processing to make it more appropriate for the application using the ODS.
Now if you find this will be to much of a leap for your current situation, you can try and at least seperate the data within the database, so you won't be dealing with performance issues like table locks, etc.. It can also be a step in the right direction for if you need to move to an ODS like model in the future.
我不喜欢复制不需要的东西。我会标记仅管理部分，并将该部分构建为具有内部 IP 或不同端口的单独数据库。然后与公共站点建立外键关系以进行管理员访问。将其视为索引表会比复制更容易管理，并且当您不与遗留系统交互时，API 开发是一项不必要的任务。另外，当您希望保持系统独立时，为什么还要进行复制。
这是我的两分钱。
I am not a fan of replicating what doesn't need to be. I would tag what is admin only and build that portion out as a seperate DB with an internal IP or different port. Then make foreign key relationships to the public site for admin access. Treating it like an indexed table would be far easier to administrate rather then replicating and API development is an unecessary task when you are not talking with legacy systems. Also why replicate when you want to keep the systems seperate.
Thems my two cents.