可分凝Tuxedo服務（性能考慮）

Question

在Solaris上使用的Tuxedo 11.1 ....

問題是關於性能/管理方面的考慮每臺服務器分離服務時。我們有一個發展計劃，它正在尋求將大約250個服務減少到11個服務提供的11種情況。這個想法是，有大量的重複服務大致返回相同的客戶信息，並且將「定製」的溢出（主要是爲了滿足用戶的特定需求）打包到許多客戶情況中（邏輯上更好）像「給我所有關於聯繫信息的東西」，或者「關於與他人的關係的一切」）。這些服務情況可能會提供更多的數據，而且明顯會導致更多的呼叫進入單個瓶頸（必須水平縮放）。例如，我們有3個域（針對同一個數據庫）的「檢索客戶標識」這樣的服務，每秒調用20次（平均20ms）。獲得某人身份的「識別」可以擁有20種不同的風格，儘管返回有些多態（可能是一個額外的屬性，但基本信息是相同的）。

我想知道的是打包這11種情況/服務的最佳方式是什麼？將所有信息都放入一個Tuxedo服務器，然後禁用具有特定服務的實例（可能只是一項服務）。或者每臺服務器提供一項服務以提高可讀性如果我把所有東西都堆放在一臺服務器上，那麼在什麼時候會造成內存堵塞？是否只有被封鎖的服務纔會被放入內存或者定義給服務器的所有東西？對我們來說這不太可能是一個嚴重的問題（考慮到我們公園的規模），但很好奇。

一個粗糙的場地（沒有詳細瞭解開發實施的細節）是服務可能需要處理20c/s * 20（今天不同的風味）* 3（域）= 1200次/秒。 ;-)

Answer 1

或者每臺服務器有一個服務器的可讀性？如果我把所有東西都堆放在一臺服務器上，那麼在什麼時候會造成內存堵塞？

GACK！不要那樣做！

使用TUXEDO的全部意義在於可擴展性，TUXEDO的可擴展性關鍵在於仔細決定您的服務是什麼，而不管可讀性如何，還是程序員的方便。我已經與不同的客戶和TUXEDO專業服務機構進行了10或12次TUXEDO設計會議，其中一些人與Marc Carges一起編寫了第一行TUXEDO代碼。

在幾乎所有情況下，客戶都會在某種程度上質疑服務的定義方式。反對意見通常是'這會使客戶端應用程序更難編碼'，或'看起來極端'。最終的答案總是一樣的，Marc Carges的反應很低，他顯然很習慣這些反對意見，並會回覆這樣的問題：

可擴展性很難，我知道如何去做，而這是怎麼樣。

決定你的服務的第一要素是考慮服務將使用的數據庫連接。完美的TUXEDO服務將在數據庫中打開一個表格，並且該表格將具有一個索引。服務質量越好，數據庫資源越少。實際上不可能以100％純粹的完美TUXEDO服務結束，因此您開始妥協，始終牢記關鍵是要儘量減少任何一項服務所需的數據庫資源。

不用擔心TUXEDO本身，它是防止可擴展性的數據庫，TUXEDO的角色來擴展數據庫。 TUXEDO非常輕便，並且本身具有高度可擴展性，因此不必擔心任何設計決策對TUXEDO本身的影響，請始終考慮設計決策對數據庫引擎的影響。