超碰人人人人人,亚洲AV午夜福利精品一区二区,亚洲欧美综合区丁香五月1区,日韩欧美亚洲系列

軟件即服務(wù) (Software as a service，SaaS) 是一種通過互聯(lián)網(wǎng)按需交付軟件應(yīng)用程序的方法，通常采用訂閱方式。借助 SaaS，云服務(wù)提供商 (CSP) 可以托管和管理應(yīng)用程序軟件和底層基礎(chǔ)設(shè)施，保證系統(tǒng)的可靠性。用戶可以通過手機(jī)或電腦上的網(wǎng)絡(luò)連接到應(yīng)用程序。

通俗地講，就是將用戶的服務(wù)器相關(guān)硬件、操作系統(tǒng)、應(yīng)用程序搬到云上，讓軟件提供商來維護(hù)。SaaS的優(yōu)勢多用于ToB的業(yè)務(wù)，將客戶本地部署的系統(tǒng)遷移到云上，方方便客戶的同時，軟件提供商也創(chuàng)新了盈利模式。

SaaS對客戶來說有什么優(yōu)勢呢？

• 降低IT成本。減少硬件軟件的投入、降低了維護(hù)成本、降低了人員成本。

• 快速部署與更新。開箱即用，無需復(fù)雜流程。自動升級，及時發(fā)布和修復(fù)功能。

• 高安全性。企業(yè)提供標(biāo)準(zhǔn)的安全防護(hù)能力、容災(zāi)恢復(fù)能力。

• 彈性擴(kuò)展。不擔(dān)心硬件資源不足及系統(tǒng)訪問瓶頸。

• 隨時隨地訪問。通過網(wǎng)絡(luò)連接，實現(xiàn)多設(shè)備或異地辦公。

客戶本地數(shù)據(jù)遷移到云上或者直接訂閱使用云上產(chǎn)品，不可避免需要關(guān)注數(shù)據(jù)的安全隔離。使用單租戶模式還是實現(xiàn)多租戶數(shù)據(jù)共存與訪問，企業(yè)在系統(tǒng)設(shè)計之初必須規(guī)劃多租戶的架構(gòu)解決方案。

我們了解下租戶概念：

• 單租戶： 每個數(shù)據(jù)庫僅存儲來自一個租戶的數(shù)據(jù)，數(shù)據(jù)隔離性好。

• 多租戶： 每個數(shù)據(jù)庫都存儲來自多個獨(dú)立租戶的數(shù)據(jù)，數(shù)據(jù)隔離性相對差。

相信大家也有個疑問，在多租戶場景中，為什么要進(jìn)行用戶數(shù)據(jù)隔離？操作數(shù)據(jù)時加條件篩選不也可以嗎？如下查詢：

SELECT * FROM orders WHERE tenant_id = '88888888';

如果開發(fā)者在某個地方漏掉 tenant_id 條件，可能出現(xiàn)以下問題：

• 用戶 A 能看到用戶 B 的訂單數(shù)據(jù)。

• SQL注入可以繞過 tenant_id 條件訪問其他租戶數(shù)據(jù)。

通過數(shù)據(jù)隔離，上述問題就可以完全避免。盡管在操作數(shù)據(jù)時加條件在一定程度上可以實現(xiàn)多租戶數(shù)據(jù)的隔離，但它存在明顯的安全問題。在實際場景中，數(shù)據(jù)隔離通常是通過物理或邏輯上的手段綜合實現(xiàn)的，具體包括分庫分表、分區(qū)、租戶標(biāo)識符控制等方式。

多租戶場景之所以要數(shù)據(jù)隔離，完全是出于數(shù)據(jù)安全與隱私保護(hù)。數(shù)據(jù)隔離可以降低數(shù)據(jù)泄露潛在風(fēng)險、增強(qiáng)用戶對企業(yè)系統(tǒng)的信任、符合隱私法規(guī)（如GDPR、CCPA等）。

多租戶的架構(gòu)中，最常見的方案主要有四種：

1. 單租戶模式，應(yīng)用程序與數(shù)據(jù)庫完全隔離。

2. 單租戶模式，應(yīng)用程序共享系統(tǒng)資源，數(shù)據(jù)庫完全隔離。

3. 多租戶模式，應(yīng)用程序和數(shù)據(jù)庫資源共享，數(shù)據(jù)庫采用schema隔離。

4. 多租戶模式，應(yīng)用程序和數(shù)據(jù)庫資源共享，schema共享，數(shù)據(jù)采用行級隔離。

接下來，我簡單介紹這幾種方案的優(yōu)劣情況和使用場景。

• 單租戶模式，應(yīng)用程序與數(shù)據(jù)庫完全隔離

優(yōu)點(diǎn)：

• 高隔離性：每個租戶有獨(dú)立的應(yīng)用程序和數(shù)據(jù)庫，安全性和隱私性最高。

• 可定制性：針對不同租戶可以自由定制應(yīng)用程序和數(shù)據(jù)庫配置。

• 性能獨(dú)立：一個租戶的負(fù)載不會影響其他租戶。

缺點(diǎn)：

• 高成本：需要為每個租戶提供單獨(dú)的資源，資源利用率低。

• 運(yùn)維復(fù)雜度高：多個服務(wù)和實例帶來的部署、更新和維護(hù)成本較高。

• 擴(kuò)展性差：當(dāng)租戶數(shù)量增加時，難以快速擴(kuò)展。

場景：

• 安全性要求極高的業(yè)務(wù)場景，如金融、醫(yī)療等。

• 少量租戶但需求差異較大的情況，如大客戶的企業(yè)級服務(wù)。

• 單租戶模式，應(yīng)用程序共享系統(tǒng)資源，數(shù)據(jù)庫完全隔離

優(yōu)點(diǎn)：

• 高隔離性：每個租戶使用獨(dú)立的數(shù)據(jù)庫，數(shù)據(jù)安全性強(qiáng)。

• 資源利用率較高：應(yīng)用程序?qū)庸蚕碣Y源，相比上一個方案成本較低。

• 性能獨(dú)立：數(shù)據(jù)庫的隔離性保證了不同租戶之間的性能互不干擾。

缺點(diǎn)：

• 中等運(yùn)維復(fù)雜度：需要管理多個數(shù)據(jù)庫實例。

• 擴(kuò)展成本較高：當(dāng)租戶數(shù)量增加時，仍需為每個租戶配置數(shù)據(jù)庫資源。

場景：

• 中小型企業(yè)或中等數(shù)量租戶的場景，不適合小微企業(yè)。

• 數(shù)據(jù)隔離要求較高但對成本有一定限制的應(yīng)用。

• 多租戶模式，應(yīng)用程序和數(shù)據(jù)庫資源共享，數(shù)據(jù)庫采用 schema 隔離

優(yōu)點(diǎn)：

• 資源利用率高：應(yīng)用程序和數(shù)據(jù)庫實例共享資源，節(jié)約成本。

• 管理相對簡單：相比單租戶模式，維護(hù)一個數(shù)據(jù)庫實例而多個 schema 更加輕量化。

• 隔離性中等：schema 提供了一定的邏輯隔離。

缺點(diǎn)：

• 安全性較低：如果數(shù)據(jù)庫的權(quán)限管理或隔離機(jī)制不足，可能導(dǎo)致數(shù)據(jù)泄露。

• 性能隔離性有限：高負(fù)載的租戶可能影響同一實例中的其他租戶。

• 復(fù)雜的權(quán)限管理：需要通過 schema 進(jìn)行精細(xì)的權(quán)限劃分。

場景：

• 中小型 SaaS 產(chǎn)品，租戶數(shù)量較多，但對數(shù)據(jù)隔離性和安全性要求適中。

• 對成本敏感的企業(yè)級應(yīng)用。

• 多租戶模式，應(yīng)用程序和數(shù)據(jù)庫資源共享，schema 共享，數(shù)據(jù)采用行級隔離

優(yōu)點(diǎn)：

• 成本最低：所有租戶共享應(yīng)用程序和數(shù)據(jù)庫資源，資源利用率極高。

• 管理最簡單：統(tǒng)一的數(shù)據(jù)庫架構(gòu)，無需維護(hù)多個 schema。

• 高擴(kuò)展性：可以輕松增加租戶數(shù)量，適合大規(guī)模擴(kuò)展。

缺點(diǎn)：

• 最低隔離性：租戶間完全共享表結(jié)構(gòu)，隔離性最低，容易受到數(shù)據(jù)泄露和誤操作的風(fēng)險。

• 性能瓶頸：當(dāng)租戶數(shù)量或負(fù)載過高時，資源爭搶可能導(dǎo)致性能下降。

• 復(fù)雜的邏輯控制：需要在應(yīng)用層實現(xiàn)租戶級的行級權(quán)限管理，增加開發(fā)復(fù)雜度。

場景：

• 對隔離性要求不高的大規(guī)模 SaaS 應(yīng)用，如消費(fèi)級互聯(lián)網(wǎng)產(chǎn)品。

• 對成本控制敏感，且需要支持海量小租戶的場景。

在設(shè)計有效的多租戶數(shù)據(jù)庫時，必須仔細(xì)平衡數(shù)據(jù)隔離、可擴(kuò)展性、性能和安全性。對于成功運(yùn)行的多租戶系統(tǒng)，每一個要素都至關(guān)重要。隨著租戶數(shù)量的增加，數(shù)據(jù)庫需要具有可擴(kuò)展性，以便處理增加的負(fù)載。為了保證數(shù)據(jù)庫能夠快速有效地訪問數(shù)據(jù)，性能至關(guān)重要。對于這些應(yīng)用程序，需要考慮實時數(shù)據(jù)訪問。

租戶數(shù)據(jù)庫的設(shè)計方案，需要結(jié)合自身的業(yè)務(wù)選型。在數(shù)據(jù)庫方面，實現(xiàn)數(shù)據(jù)隔離主要有數(shù)據(jù)庫、schema、行級這三種。當(dāng)然也有分區(qū)模式和混合模式。

這三個方案會面臨的問題，我簡單總結(jié)如下：

通常SaaS場景下的單個租戶數(shù)據(jù)量不會太大，一般從幾十MB至幾十GB。新方案初期難確定容量大小，當(dāng)服務(wù)器性能無法滿足時，再新增服務(wù)器分配新租戶來使用。因此設(shè)計數(shù)據(jù)庫的時候，需要一個專門存儲租戶信息的數(shù)據(jù)庫，該數(shù)據(jù)庫用于管理租戶、同時也記錄該租戶數(shù)據(jù)所在的數(shù)據(jù)庫連接信息。

如果明確租戶增長不會太大，且業(yè)務(wù)功能的使用也不同（較多表可能存在數(shù)據(jù)傾斜），數(shù)據(jù)量都是幾十GB的，推薦使用數(shù)據(jù)庫隔離模式。我們可以將幾十個數(shù)據(jù)庫放在同一個實例中，有效利用計算資源。數(shù)據(jù)庫隔離模式也適合schema隔離模式，當(dāng)然需要考慮上面提到面臨的問題。

當(dāng)租戶數(shù)量達(dá)成千上萬的時候，或者未來租戶數(shù)能達(dá)到這個量級，數(shù)據(jù)庫隔離模式就不必再考慮了，schema隔離模式確實可以考慮。能使用schema模式的常見關(guān)系型數(shù)據(jù)庫，如Oracle、SQL Server、PostgreSQL，但如果使用 PostgreSQL 的多schema隔離模式，autovacuum 可能會頻繁執(zhí)行，將是比較大的性能問題！

當(dāng)上萬的租戶、或者數(shù)據(jù)量少的租戶，推薦使用行級隔離。行級隔離的基本原理是，當(dāng)用戶操作數(shù)據(jù)庫表時，系統(tǒng)判斷是否是某個租戶的數(shù)據(jù)，必須在連接會話中獲取能識別租戶的信息，如租戶賬號、租戶ID等。獲取到的信息需要與表中的行數(shù)據(jù)進(jìn)行篩選匹配，如匹配表中字段tenant_id中的值，這樣操作的數(shù)據(jù)只能是該連接的租戶數(shù)據(jù)。

行級隔離不是簡單地加where條件篩選指定的租戶，因為無法不免有漏掉條件的可能。使用行級別安全（Row Level Security，RLS），即使不加租戶相關(guān)條件，租戶也只能操作自己的數(shù)據(jù)，達(dá)到租戶之間的數(shù)據(jù)安全隔離。目前Oracle、SQL Server、PostgreSQL 等都支持行級別安全。

使用RLS也可能存在數(shù)據(jù)傾斜，導(dǎo)致數(shù)量差異大的租戶操作SQL的執(zhí)行計劃不準(zhǔn)確，該如何處理呢？前面提到過混合場景和分區(qū)方案就是其中的解決方案。數(shù)據(jù)庫少的租戶可使用RLS方案，數(shù)據(jù)量大的租戶可以使用數(shù)據(jù)庫或schema方案。另外還可以使用分區(qū)方案，分區(qū)方案只是輔助RLS解決數(shù)據(jù)傾斜問題，不作為正式的租戶隔離方案。對于數(shù)據(jù)量大的租戶，可以將表進(jìn)行分區(qū)，一個或多個分區(qū)存儲大租戶的數(shù)據(jù)，另一個分區(qū)存儲數(shù)據(jù)量少的租戶。

我這里介紹兩種案例：

• SQL Server 使用視圖進(jìn)行“行級隔離”

• PostgreSQL使用行級安全（RLS）功能進(jìn)行隔離

• SQL Server 使用視圖進(jìn)行行級隔離

SQL Server有真正的行級隔離方案，但這里我介紹的是另一種非正式的隔離方案，可以說也是一種通用方案，在其他數(shù)據(jù)庫都可以實現(xiàn)。

該方案在視圖中添加where條件，識別當(dāng)前上下文環(huán)境的登錄用戶ID，到表中進(jìn)行篩選。以下是一個完整的簡單示例。

-- 創(chuàng)建測試表CREATE TABLE dbo.demo_tab(	id uniqueidentifier NOT NULL DEFAULT (newsequentialid()),	tenant_id varbinary(85) NOT NULL DEFAULT (suser_sid()),	order_id bigint NOT NULL,	CONSTRAINT pk_demo_tab PRIMARY KEY CLUSTERED (tenant_id ASC,id ASC))GO-- 創(chuàng)建視圖CREATE VIEW dbo.v_demo_tabASSELECT * FROM dbo.demo_tab WHERE tenant_id = SUSER_SID()GO-- 插入5行數(shù)據(jù)（DML 只操作自己的數(shù)據(jù)）INSERT INTO dbo.demo_tab(order_id) select round(rand()*1000,0)GO 5
/*UPDATE dbo.v_demo_tab SET order_id = 1GODELETE FROM dbo.v_demo_tabGO*/SELECT * FROM dbo.v_demo_tab -- SELECT * FROM dbo.demo_tab
--添加字段后刷新視圖ALTER TABLE dbo.demo_tab ADD order_name VARCHAR(10)GOEXEC sp_refreshview 'dbo.V_DemoTab';GO
-- 也可以切換為指定用戶進(jìn)行操作EXECUTE AS USER = 'huang';GOSELECT SUSER_SID(),SUSER_NAME()GO

應(yīng)用程序只操作視圖，每張視圖背后都對應(yīng)一張表。由于視圖已經(jīng)隔離了用戶數(shù)據(jù)，任何用戶都不可能操作其他用戶的數(shù)據(jù)。如果表結(jié)構(gòu)發(fā)生變化，可以通過存儲過程sp_refreshview刷新視圖定義。這是我以前公司用的一種租戶隔離方案，類似RLS。當(dāng)前你也可以使用SQL Server 官方真正的“行級別安全性(RLS)”設(shè)計租戶隔離。

• PostgreSQL使用行級隔離RLS

另一個實際的案例就是PostgreSQL的“行級安全策略(RLS)”。每張表都存在字段tenant_id，存儲租戶id，租戶id的管理可以從平臺數(shù)據(jù)庫中獲取。

# 創(chuàng)建容器環(huán)境docker run -d --name pg5401 -e POSTGRES_PASSWORD=123456 -p 5401:5432 postgres:latestapt install postgresql-client
# pg管理員登錄創(chuàng)建測試數(shù)據(jù)庫及用戶psql -h 127.0.0.1 -p 5401 -U postgres -W -d postgrescreate database mydb with encoding = 'utf8';create user myrole password 'myrole' login;\c mydbgrant all privileges on all tables in schema public to myrole;grant all on schema public TO myrole;

# pg用戶登錄，創(chuàng)建對象及啟用行級安全psql -h 127.0.0.1 -p 5401 -U myrole -W -d mydb
create table product(tenant_id varchar(50) not null,id int,name varchar(50));
insert into product values('10000',1,'10000'),('10001',2,'10001'),('10002',3,'10002'),('10003',4,'10003'),('10004',5,'10004'),('10000',6,'10000'),('10000',7,'10000'),('10002',8,'10002'),('10000',9,'10000'),('10004',10,'10004');
select * from product;
-- 針對表啟用行級安全策略alter table product enable row level security;
-- 針對表創(chuàng)建策略drop policy if exists product_tenant_isolation_policy on product;create policy product_tenant_isolation_policy on product using(tenant_id = current_setting('app.tenant_id'));\d product
-- 強(qiáng)制所有用戶使用 RLS,否則表 Owner 的用戶會繞過行安全性alter table product force row level security;
-- 具有該屬性的超級用戶和角色 BYPASSRLS 在訪問表時始終繞過行安全系統(tǒng) (指定用戶繞過 RLS，可訪問全表數(shù)據(jù))-- alter user my_admin with bypassrls;  
-- 重新連接操作psql -h 127.0.0.1 -p 5401 -U myrole -W -d mydbselect * from product;-- ERROR:  unrecognized configuration parameter "app.tenant_id"
set app.tenant_id = '10000';show app.tenant_id;-- reset app.tenant_id;
insert into product(tenant_id,id,name)values('10004',99,'kk');update product set name='kk';-delete from product；
# 或者直接命令行操作export PGPASSWORD='myrole'env PGOPTIONS="-c app.tenant_id=10000" psql -h 127.0.0.1 -p 5401 -U myrole -d mydb -c "select * from product;"

我們定義策略參數(shù)app.tenant_id，當(dāng)租戶連接數(shù)據(jù)庫時，需要設(shè)置app.tenant_id的值。當(dāng)訪問表的時候，rls策略將獲取上下文信息app.tenant_id的參數(shù)值，相當(dāng)于將“tenant_id=？” 拼接到where條件中，與前面的“SQL Server 使用視圖進(jìn)行行級隔離”有相似之處。

數(shù)據(jù)庫級別與schema級別的數(shù)據(jù)隔離比較好理解，對租戶來說隔離性好，但不適合大量租戶的情況。一個企業(yè)的租戶數(shù)據(jù)量差異比較大，這就需要考慮產(chǎn)品是否真的符合租戶的業(yè)務(wù)場景。也就是說，企業(yè)內(nèi)部需要對發(fā)布多個版本或多個產(chǎn)品滿足不同的客戶需求，在多租戶的數(shù)據(jù)庫設(shè)計方面也評估使用不同的數(shù)據(jù)隔離方案。

我們除了在數(shù)據(jù)庫選型、租戶架構(gòu)選型之外，也要考慮云資源成本?？蛻臬@取成本、 客戶生命周期價值、月度經(jīng)常性收入、 客戶流失率 是SaaS提供商特別關(guān)注的一些關(guān)鍵績效和業(yè)務(wù)指標(biāo)。這些指標(biāo)對于業(yè)務(wù)優(yōu)化和增長至關(guān)重要，并且它們提供了SaaS公司財務(wù)狀況的全面概覽。針對租戶資源的成本占比、租戶均值成本等，評估租戶開銷是否超出了計劃。

閱讀原文：https://mp.weixin.qq.com/s/Ba_KqWY5a_SAKN4RvPqH5Q