Multiple tenants sharing the same set of infrastructure resources
Advantages
Efficient management, with all tenants centrally managed; simple infrastructure configuration and faster product iterations
Lower cost, dynamic scaling of the system according to the actual load of all tenants, very high infrastructure utilisation
Disadvantages
Tenants affect each other, when one tenant takes up a lot of machine resources, the experience of other tenants is affected (restrictions such as flow limitation, downgrading, server isolation need to be added to the architecture)
Difficulty in billing
Data management woes: difficult to delete if tenants do not renew; difficult to recover data in case of failure, which affects other tenants
Single data source single database single data table: there is only one database, all tenants share the same data table; each table has an extra column for the tenant ID, each time the tenant ID is added, deleted and checked
Shaft model: large customers
Each tenant runs in an isolated set of resources, with its own separate set of end-to-end infrastructure
Advantages:
Strong isolation, safety; low impact of faults
Easy billing logic
Disadvantages:
Difficult to scale up: not easy to manage if the number of tenants reaches thousands
High cost of ownership, weakening profitability
Agile iteration capabilities hampered
In this decentralised model, the management and monitoring of each tenant's infrastructure is very complex
Multiple data sources, multiple databases, multiple data tables
After the project starts, the datasource information for all tenants is loaded from the database based on the tenant ID, created and injected into the container; if a tenant goes online or offline, a configuration listener is added to dynamically add and remove datasources.
Distributed Storage
Centerless architecture: Consistent hashing
Omit the namenode and deploy it as a stateless service that can be clustered to deploy apportioned requests.
Core scenes
Intra-tenant model relationships
Create secondary organisations, add people and give roles within the tenant
Ordinary users join the business system to request or use resources
Tenant Identification: Tenants bring their tenant information with them when they request
Tenant billing and metering management
Shaft pattern
Shared mode: combined billing based on data such as request concurrency, storage capacity, number of data objects, etc.
Dynamic Capacity Expansion
Data replication
Raft algorithm: each data change is landed as a Raft log, which is safely and securely synchronised to multiple nodes in the replication group through Raft's log replication function
Failed data recovery
Request flow limiting: Limits based on time windows for ingestion and select requests to avoid overuse of resources and performance degradation
Extension issues
Tenant Network Isolation
Assign the corresponding VPC and subnet when creating the tenant object
Multi-tenant and Distributed database V1.0
Multi-tenant environments share the same system or program components and can ensure data isolation between users.
High-Level architecture
Function
User Model
Tenant Isolation Model
Isolation of the storage, network, and other resources involved in the underlying layer
Hybrid mode
User-selected: Shared mode (base domain) or Shaft isolation mode (dedicated domain)
Shared model: small and medium-sized clients
Advantages
Disadvantages
Single data source single database single data table: there is only one database, all tenants share the same data table; each table has an extra column for the tenant ID, each time the tenant ID is added, deleted and checked
Shaft model: large customers
Each tenant runs in an isolated set of resources, with its own separate set of end-to-end infrastructure
Advantages:
Disadvantages:
Difficult to scale up: not easy to manage if the number of tenants reaches thousands
High cost of ownership, weakening profitability
Agile iteration capabilities hampered
In this decentralised model, the management and monitoring of each tenant's infrastructure is very complex
Multiple data sources, multiple databases, multiple data tables
After the project starts, the datasource information for all tenants is loaded from the database based on the tenant ID, created and injected into the container; if a tenant goes online or offline, a configuration listener is added to dynamically add and remove datasources.
Distributed Storage
Centerless architecture: Consistent hashing
Omit the namenode and deploy it as a stateless service that can be clustered to deploy apportioned requests.
Core scenes
Extension issues