企業應用與網際網路應用的區別，多租戶方案

我們的產品最近在規劃做乙個比較大的變化，從單應用支援單個專案，向單應用支援多專案轉變（多租戶）

企業應用和網際網路應用的區別

產品是所謂的企業應用，雖然用的技術差不多，但是我感覺和網際網路應用有很大區別，暫時想到以下幾點：

1、併發數

企業應用的併發數和網際網路應用（近似理解為**）相比，差別極大。因為**面對的是數以萬計的網際網路使用者，而企業應用面對的是內部使用者，所以併發量完全不在乙個層面上。不用跟大的電商、社交**比，即使是很小的**，併發數也遠遠超過我們的應用

所以，一般來說，企業應用在架構上不需要特別考慮http併發的問題，只需要稍微注意下實現無狀態server，支援水平伸縮即可

2、資料量

資料量這個指標，主要還是取決於應用的規模，跟是企業引用還是網際網路應用，關係不是特別大。就目前的經驗來看，我們應用的效能瓶頸，主要也是出現在資料庫io上。後續在集中部署的場景下，更有可能面對資料庫伸縮的問題

3、可配置性

網際網路應用不強調可配置性，一般的**、論壇等，每個使用者能做的事情都是一樣的。雖然像qq空間那種，允許使用者做一些自定義，但是只是頁面元件和模板化的技術，跟企業應用的可配置性還不一樣

企業應用會面對很多定製需求。比如說我們的產品，要提供給不同的專案，而每個專案的需求都會有一些細微的差異。同樣的工單，不同專案需要不同字段；工單端到端的業務流程，不同的專案有不同的環節；另外不同的專案，可能會與不同的外部系統對接……

如果是單應用支撐單項目的情況，可以通過定製開發的方式實現，只是工作量的問題。但是一旦轉變成多租戶的部署形式，就會相當麻煩，主要是公升級的時候不能互相影響，還有怎麼處理資料庫表結構的差異

所以，這是比網際網路應用複雜的地方

4、資料隔離

還有乙個很大的區別是資料隔離

**的大部分資料是必須共享的，否則就會發生使用者看不到某些帖子、不能買某些商品等錯誤的情況。但是對於企業應用來說，資料隔離不但不是問題，反而是需求。a專案的使用者不應該看到b專案的資料，把不同專案的資料隔離開完全沒有問題

因此，在企業應用中，把資料隔離開，應用只能讀取其中的一部分，是可以接受的

多租戶的方案

多租戶的設計思路，目前想到2種：

第一種是應用只有一套資料庫表，基本上沿用現有的表結構，只增加一列專案id來區分。這種方案短期來看比較簡單，但是以前只存放乙個專案的資料，現在卻要存放幾十個專案的資料，很快就會遇到資料庫瓶頸（業務資料每天都在增加），最終還是要拆表

第二種是一開始就根據專案把錶拆開，每個專案一套表。在專案少資料少的時候，可以只用schema區分，部署在同乙個db server裡；隨著專案和資料增多，再增加db server，做資料遷移。由於本來就根據schema拆了表，遷移起來比較容易

長期來看，我認為第2種方案是比較好的。首先每個專案有自己的表，資料分散，io效能較優；乙個專案的表中的資料損壞，也不會對其他專案造成影響；最後，有天然的資料隔離

另外要解決資料遷移的問題。需要開發配套工具，支援資料快速遷移，減少業務中斷的時間

總結：

2種方案都需要對產品的實現做修改，可以作為規劃，落入後續版本中，短期內難以做到

結合雲部署的方案，當前可以把應用預裝入虛擬機器，然後匯出得到映象，在不修改應用的前提下，實現快速部署。另外，多個專案的資料庫，可以共享db server，節省硬體費用，以及oracle license費用，這需要修改產品的安裝指令碼

上述方案應該看做是過渡方案，長期來看，還是需要對應用進行改造，才能實現真正的多租戶。目前可以識別出的技術難點，主要有3點：

1、資料庫路由模組的設計和實現

2、資料遷移工具的設計和實現

3、針對多租戶場景，可配置性設計的調整（當前的可配置性設計，針對的是單個專案）