Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal for Addressing OpenIM's Role in Relation to Business Systems: Master-Slave Positioning and Integration Strategy #18

Open
cubxxw opened this issue Nov 12, 2023 — with Slack · 0 comments
Assignees

Comments

Copy link
Contributor

cubxxw commented Nov 12, 2023

Issue Description:

A key discussion topic that was overlooked in our last bi-weekly meeting concerns the master-slave positioning of OpenIM in relation to our business systems. This topic is crucial as it directly impacts our deployment strategy regarding reverse proxy and load balancing.

Discussion Points:

  1. OpenIM as the Primary System: In scenarios where OpenIM acts as the primary system and the user's business system is secondary (similar to a chat application), OpenIM handles user registration and management. In these cases, OpenIM's service endpoints are directly exposed to the public, and load balancing and reverse proxy software are directly linked with Nginx.
  2. OpenIM as a Secondary System: In other scenarios, clients have their own core business systems and integrate OpenIM as a functional module. Here, user registration and management are initially handled by the core system, followed by a secondary registration in OpenIM. In these instances, the client’s core business system is the one exposed directly to the public, making OpenIM an internal supporting system. This positioning requires a different interaction model between OpenIM and the core business system.

Suggestions for Improvement:

  1. Unified Endpoint Strategy: For cases where OpenIM functions as a secondary system, it is recommended that OpenIM adopts a strategy similar to nginx-ingress in Kubernetes. This would involve providing a unified set of external service endpoints (API, WebSocket, backend management notifications, etc.), akin to how database clusters offer a unified access point.
  2. Flexible Deployment and Integration: OpenIM should be engineered to be a versatile and efficient component, capable of both leading and supporting roles in different business scenarios. This flexibility will ensure that OpenIM can be effectively integrated regardless of its position as a primary or secondary system.
  3. Load Balancing and Endpoint Exposure: Independently of its role, OpenIM should be developed and deployed as a cohesive system with robust load balancing capabilities. This includes properly exposing its endpoints for efficient and secure access.

Objective:

The goal is to transform OpenIM into a highly adaptive, efficient, and unified service, capable of effectively serving in both primary and secondary roles in various business scenarios. This will entail reevaluating and potentially revising its deployment and integration strategies to ensure optimal performance and compatibility with diverse business systems.

@cubxxw cubxxw self-assigned this Nov 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant