每个服务器隔离 Tuxedo 服务（性能考虑）

Question

在 Solaris 上使用 Tuxedo 11.1....

问题是关于在每台服务器上隔离服务时的性能/管理注意事项。我们有一个开发工作，希望将大约 250 种服务减少到 11 种情况，作为 11 种服务提供。这个想法是，有大量重复的服务大致返回相同的客户信息，并且将这种“定制”溢出（主要是为了满足订户的特定需求）打包到许多客户情况中会合乎逻辑地更好（比如“给我有关联系信息的所有信息”或“有关与他人关系的所有信息”）。这些服务情况可能会提供更多数据，并且显然将更多调用汇集到单个瓶颈（必须水平扩展）。例如，我们有像“检索客户标识”这样的服务，在 3 个域（针对同一个数据库）中每秒调用 20 次（平均 20 毫秒）。获取某人的“身份”可能有 20 种不同的风格，尽管返回有点多态（可能在这里和那里有一个额外的属性，但基本信息是相同的）。

我想知道打包这 11 种情况/服务的最佳方式是什么？将它们全部信息放在一个 Tuxedo 服务器上，然后删除具有特定服务的实例（可能只是一个服务）。还是每台服务器一个服务以提高可读性？如果我将所有内容都堆放在一台服务器上，那么裁剪时的内存是多少？是否只有被裁剪的服务被放入内存或服务器定义的所有内容？对我们来说可能不是一个严重的问题（考虑到我们公园的大小），但很好奇。

粗略的估计（没有详细了解开发的具体实施方式）是服务可能必须处理 20 c/s * 20（今天的不同风格）* 3（域）= 1200 次调用/秒。 ;-)

Answer 1

或者每台服务器一个服务以提高可读性？如果我将所有内容都堆放在一台服务器上，那么裁剪时的内存是多少？

盖克！不要那样做！

使用 TUXEDO 的全部意义在于可扩展性，使用 TUXEDO 实现可扩展性的关键是仔细确定您的服务将是什么，无论可读性或程序员的便利性如何。我已经与各种客户和 TUXEDO 专业服务组织进行了 10 或 12 次 TUXEDO 设计会议，其中几次是与编写第一行 TUXEDO 代码的人 Marc Carges 一起进行的。

在几乎所有情况下，客户都会在某个时候质疑服务的定义方式。反对意见通常是“这将使客户端应用程序更难编码”或“这似乎很极端”。最终的答案总是一样的，Marc Carges 的回应是轻描淡写，他显然已经习惯了这些反对意见，并且会这样回答：

可扩展性很难，我知道怎么做，就是这样。

决定您的服务将是什么的第一个因素是考虑该服务将使用的数据库连接。完美的 TUXEDO 服务会在数据库中打开一个表，并且该表将有一个索引。服务访问的数据库资源越少越好。实际上不可能最终得到 100% 完美的 TUXEDO 服务，因此您开始妥协，始终牢记重点是尽量减少任何一项服务所需的数据库资源。

不用担心 TUXEDO 本身，阻碍可扩展性的是数据库，TUXEDO 的作用是让数据库扩展。 TUXEDO 极其轻量级，并且本身具有高度可扩展性，因此不必担心任何设计决策对 TUXEDO 本身的影响，始终考虑设计决策对数据库引擎的影响。