activiti 多租戶

我們過去聽到的一項功能請求是以多租戶方式運行Activiti引擎，使租戶的數據與其他數據隔離。 當然，在某些云/ SaaS環境中，這是必須的。

幾個月前，波恩大學的學生拉斐爾·吉倫（Raphael Gielen）與我接觸，他正在撰寫有關Activiti多租戶的碩士學位論文。 幾周前，我們在一個共同工作的咖啡館聚會，反彈想法，并為租戶一起破解了具有數據庫模式隔離的第一個原型。 很有趣 ：-）。

無論如何，我們一直在完善和完善該代碼，并將其提交給Activiti代碼庫。 讓我們在下面的前兩個部分中了解使用Activiti進行多租戶的現有方法。 在第三部分中，我們將深入研究新的多租戶多模式功能，其中包含一些實際工作的代碼示例！

共享數據庫多租戶

Activiti已經有一段時間可以支持多租戶了（從5.15版本開始）。 所采用的方法是共享數據庫 ：擁有一個（或多個）Activiti引擎，并且它們都進入同一個數據庫。 數據庫表中的每個條目都有一個租戶標識符 ，最好將其理解為該數據的一種標記。 然后，Activiti引擎和API會讀取并使用該租戶標識符在租戶的上下文中執行其各種操作。

例如，如下圖所示，兩個不同的租戶可以具有使用相同密鑰的流程定義。 引擎和API確保沒有數據混合。

這種方法的好處是部署簡單，因為與設置“常規” Activiti引擎沒有區別。 缺點是您必須記住使用正確的API調用（即那些考慮了租戶標識符的調用）。 而且，它與任何具有共享資源的系統都存在相同的問題：租戶之間總是存在對資源的競爭。 在大多數用例中，這很好，但是有些用例不能以這種方式完成，例如為某些租戶提供更多或更少的系統資源。

多引擎多租戶

自Activiti的第一個版本以來，另一種可能的方法就是為每個租戶簡單地擁有一個引擎實例：

在此設置中，每個租戶可以具有不同的資源配置，甚至可以在不同的物理服務器上運行。 當然，此圖中的每個引擎可以是多個引擎，以提高性能/故障轉移/等等。 現在的好處是，資源是為租戶量身定制的。 缺點是設置比較復雜（多個數據庫架構，每個租戶都有不同的配置文件，等等）。 每個引擎實例都將占用內存（但是Activiti會占用很少的內存）。 另外，您無需編寫一些路由組件 ，就可以以某種方式知道當前租戶的上下文并路由到正確的引擎。

多架構多租戶

Activiti多租戶故事的最新添加是在兩周前添加的（這是commit ），同時是版本5和6的添加。這里，每個租戶都有一個數據庫（模式），但是只有一個引擎實例。 再次，在實踐中，可能有多個用于性能/故障轉移/等的實例，但是概念是相同的：

好處顯而易見：只有一個引擎實例可以管理和配置，而且API與非多租戶引擎完全相同。 但最重要的是，租戶的數據與其他租戶的數據完全分開。 缺點（類似于多引擎多租戶方法）是有人需要管理和配置不同的數據庫。 但是復雜的引擎管理已不復存在。

我上面鏈接到的提交還包含一個單元測試 ，該測試顯示了多模式多租戶引擎的工作方式。

構建流程引擎很容易，因為有一個MultiSchemaMultiTenantProcessEngineConfiguration可抽象出大多數細節：

config = new MultiSchemaMultiTenantProcessEngineConfiguration(tenantInfoHolder);config.setDatabaseType(MultiSchemaMultiTenantProcessEngineConfiguration.DATABASE_TYPE_H2); config.setDatabaseSchemaUpdate(MultiSchemaMultiTenantProcessEngineConfiguration.DB_SCHEMA_UPDATE_DROP_CREATE);config.registerTenant("alfresco", createDataSource("jdbc:h2:mem:activiti-mt-alfresco;DB_CLOSE_DELAY=1000", "sa", "")); config.registerTenant("acme", createDataSource("jdbc:h2:mem:activiti-mt-acme;DB_CLOSE_DELAY=1000", "sa", "")); config.registerTenant("starkindustries", createDataSource("jdbc:h2:mem:activiti-mt-stark;DB_CLOSE_DELAY=1000", "sa", ""));processEngine = config.buildProcessEngine();

這看起來與啟動常規Activiti流程引擎實例非常相似。 主要的區別是，我們在注冊與發動機租戶。 每個租戶都需要添加其唯一的租戶標識符和數據源實現。 當然，數據源實現需要有自己的連接池。 這意味著您可以根據使用情況有效地為某些租戶提供不同的連接池配置。 Activiti引擎將確保已創建或驗證每個數據庫架構都是正確的。

魔術以使這一切工作是TenantAwareDataSource 。 這是一個javax.sql.DataSource實現，它根據當前租戶標識符委托給正確的數據源。 此類的思想在很大程度上受到Spring的AbstractRoutingDataSource （站在其他開源項目的肩膀上！）的影響。

通過從TenantInfoHolder實例獲取當前的租戶標識符來完成到正確數據源的路由。 如您在上面的代碼片段中所看到的，在構造MultiSchemaMultiTenantProcessEngineConfiguration時，這也是必需的參數。 TenantInfoHolder是您需要實現的接口，具體取決于您環境中用戶和租戶的管理方式。 通常，您將使用ThreadLocal來存儲由某些安全過濾器填充的當前用戶/租戶信息（類似于Spring Security）。 該類有效地充當下圖中的“路由組件”：

在單元測試示例中，我們確實使用了ThreadLocal來存儲當前的租戶標識符 ，并用一些演示數據填充它：

private void setupTenantInfoHolder() {DummyTenantInfoHolder tenantInfoHolder = new DummyTenantInfoHolder();tenantInfoHolder.addTenant("alfresco");tenantInfoHolder.addUser("alfresco", "joram");tenantInfoHolder.addUser("alfresco", "tijs");tenantInfoHolder.addUser("alfresco", "paul");tenantInfoHolder.addUser("alfresco", "yvo");tenantInfoHolder.addTenant("acme");tenantInfoHolder.addUser("acme", "raphael");tenantInfoHolder.addUser("acme", "john");tenantInfoHolder.addTenant("starkindustries");tenantInfoHolder.addUser("starkindustries", "tony");this.tenantInfoHolder = tenantInfoHolder;}

現在，我們開始一些流程實例，同時還要切換當前的租戶標識符。 在實踐中，您必須想象有多個線程隨請求一起進入，它們將根據登錄的用戶設置當前的租戶標識符：

startProcessInstances("joram"); startProcessInstances("joram"); startProcessInstances("raphael"); completeTasks("raphael");

上面的startProcessInstances方法將使用標準Activiti API設置當前用戶和租戶標識符，并啟動幾個流程實例， 就好像根本沒有多租戶一樣 （ completeTasks方法類似地完成了一些任務）。

同樣很酷的是， 您可以使用與構建流程引擎時相同的方法來動態注冊（和刪除）新的租戶 。 Activiti引擎將確保已創建或驗證數據庫架構。

config.registerTenant("dailyplanet", createDataSource("jdbc:h2:mem:activiti-mt-daily;DB_CLOSE_DELAY=1000", "sa", ""));

這是一部電影，顯示正在運行的單元測試以及有效隔離的數據：

多租戶工作執行者

最后一個難題是工作執行者。 常規Activiti API調用“借用”當前線程以執行其操作，因此可以使用之前在該線程上設置的任何用戶/租戶上下文。

但是，作業執行程序使用后臺線程池運行，并且沒有此類上下文。 由于Activiti中的AsyncExecutor是一個接口，因此實現多方案多租戶作業執行器并不難。 當前，我們添加了兩個實現。 第一個實現稱為SharedExecutorServiceAsyncExecutor ：

config.setAsyncExecutorEnabled(true); config.setAsyncExecutorActivate(true); config.setAsyncExecutor(new SharedExecutorServiceAsyncExecutor(tenantInfoHolder));

此實現（顧名思義）對所有租戶使用一個線程池。 每個租戶確實都有其自己的作業獲取線程，但是一旦獲取了作業，便將其放到共享線程池中。 該系統的好處是Activiti使用的線程數受到限制。

第二種實現稱為ExecutorPerTenantAsyncExecutor ：

config.setAsyncExecutorEnabled(true); config.setAsyncExecutorActivate(true); config.setAsyncExecutor(new ExecutorPerTenantAsyncExecutor(tenantInfoHolder));

顧名思義，該類充當“代理” AsyncExecutor。 對于每個注冊的租戶，將啟動完整的默認AsyncExecutor。 每個都有自己的獲取線程和執行線程池。 “代理”僅委托給正確的AsyncExecutor實例。 這種方法的好處是，每個租戶都可以根據租戶的需求進行細粒度的作業執行者配置。

結論

一如既往，歡迎所有反饋。 放手多方案多租戶，讓我們知道您的想法以及將來可以改進的地方！

翻譯自: https://www.javacodegeeks.com/2015/10/multi-tenancy-with-separate-database-schemas-in-activiti.html

activiti 多租戶

總結

以上是生活随笔為你收集整理的activiti 多租户_Activiti中具有独立数据库架构的多租户的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。