水平分片、Java EE 和JNDI
几个月后，我将不得不对我的应用程序进行水平分区。我的应用程序中的某些服务需要 CPU 和内存负载，为了实现可扩展性，我希望将其分片到多个 JVM。
我有一个 EAR，它封装了我需要分区的服务。当我执行此操作时，服务的客户端（例如 UI）将需要能够寻址服务的特定实例。例如，假设我有一个名为 Account 的服务，但实际上我有该服务的 3 个实例在三个不同的 JVM 中运行（但都在同一个 Java EE 域中）。假设我有一个可以从帐户 ID 映射到特定 VM 的服务定位器，我将如何访问可以为该特定帐户提供服务的 EJB？
我看到的一个潜在解决方案是利用应用程序容器为单独应用程序中的 EJB 提供的 JNDI 名称。如果我使用不同的名称部署该模块三次，我可以执行 JNDI 查找来获取它们：
java:global/AccountServer1/AccountFacade
java:global/AccountServer2/AccountFacade
java:global/AccountServer3/AccountFacade
为了使其正常工作，我永远无法使用依赖项注入来访问 AccountFacade，我必须使用能够获取 AccountID 并将其映射到帐户应用程序之一的 AccountLocator EJB。如果我想变得棘手，我可能可以实现一个“本地”帐户外观，它透明地进行查找，假设方法的参数可以识别要使用的服务器......
这种方法可行吗？有更好的选择吗？
In a few months I'm going to have to horizontally partition my application. There are certain services within my application which need loads of CPU and memory, and for scaleability I'm going to want to shard it across multiple JVMs.
I have an EAR that encapsulates the services that I need to partition. When I do this clients of the services (such as the UI) will need to be able to address a particular instance of the service. For example, lets say I have a service named Account, but I actually have 3 instances of that service running in three different JVMs (but all in the same Java EE domain). Assuming I have a Service Locator that can map from an account ID to a particular VM, how would I access the EJBs that can service that particular account?
A potential solution I can see is to take advantage of the JNDI name that the application container gives to the EJBs in separate applications. If I deploy the module three different times with different names, I can do JNDI lookups to get to them:
java:global/AccountServer1/AccountFacade
java:global/AccountServer2/AccountFacade
java:global/AccountServer3/AccountFacade
In order for this to work, I could never use dependency injection to get to an AccountFacade, I would have to use AccountLocator EJB capable of taking an AccountID and mapping it to one of the Account applications. If I wanted to get tricky, I could probably implement a "Local" account facade that did the lookup transparently assuming that the arguments to the methods could identify which server to use...
Is this approach workable? Are there better alternatives?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
您可以将 Hibernate Shards 作为您的架构的蓝图，或者直接使用该框架。简而言之，它们将分片隐藏在 Session 接口（JPA 中的 EntityManager）后面。
You can take a look at Hibernate Shards as a blueprint for your architecture or use the framework directly. In short, they hide sharding behind, Session interface (EntityManager in case of JPA).