跨虚拟机分配层
尽管这是一个以 Java 为中心的问题，但它确实适用于任何使用多层架构的系统。
在 3 层架构中，通常有 3 层：
- 客户端代码所在的客户端/表示层； 业务逻辑所在的中间件
- 层； RDBMS和
- 其他重数据系统所在的数据/eis 层
在 Java 领域，对于 Web 应用程序来说，这可能看起来像：
- 应用程序服务器，例如
GlassFish运行“Web 层”（包含 Web 应用程序中的客户端层的 WAR）以及“业务层”（EJB、中间件等）；体现 - 数据层的RDBMS服务器
在虚拟化/集群环境中，这些应用程序（GlassFish、RBMBS，例如Oracle或PostgreSQL等）将在VM上运行。
我的问题：在这些虚拟机之间分配/分布此 3 层架构的标准方法是什么？这意味着，以下任何一种“策略”都可能可行，但不是优先：
- 一台虚拟机（假设所有虚拟机都是 Ubuntu 服务器，因此成本/价格不受影响）进入等式）同时运行 GlassFish 和 RDBMS（所有 3 层）
- 两个虚拟机：运行 GlassFish 的应用程序服务器虚拟机和运行 PostgreSQL 的数据库服务器虚拟机
- 三个虚拟机：两个都运行的应用程序服务器虚拟机GlassFish，但是 1 个 GlassFish 实例仅运行 WAR（Web 层），而第 2 个 FlassFish 实例正在运行中间件/业务逻辑；然后是第三个数据库服务器
显然，如果所有服务器（所有层）都在同一虚拟机上运行，它们可能会运行得更快或更有效，因为它们不会因网络延迟而陷入困境。但它们将位于同一个虚拟机上，这需要我需要大型硬件来支持它们。此设置也可能存在安全问题。
每个都有优点/缺点。我感兴趣的是哪些策略最能实现以下目标：(1) 最大化吞吐量/速度，(2) 最适合集群/云环境，以及 (3) 最大化安全性。
提前致谢！
Although this is a Java-centric question it really applies to any system utilizing a multi-tier architecture.
In 3-tier architectures, you typically have 3 tiers:
- A client/presentation tier where the client code lives; and
- A middleware tier where business logic lives; and
- A data/eis tier where the RDBMS and other data-heavy systems live
In Java land, for a web application, this might look like:
- An application server, such as
GlassFishrunning both the "web tier" (WARs comprising the client tier in a web app) as well as the "business tier" (EJBs, middleware, etc.); and - A RDBMS server embodying the data tier
In a virtualized/clustered environment, these applications (GlassFish, RBMBS such as Oracle or PostgreSQL, etc.) will run on VMs.
My question: What are the standard ways of allocating/distributing this 3-tier architecture across these VMs? Meaning, any one of the following "strategies" might be viable, but not preferential:
- One VM (let's say all VMs are Ubuntu Servers so cost/price doesn't factor into the equation) running both GlassFish and the RDBMS (all 3 tiers)
- Two VMs: an application server VM running GlassFish, and a database server VM running, say, PostgreSQL
- Three VMs: two app server VMs both running GlassFish, however 1 GlassFish instance is only running WARs (web tier) whereas the 2nd FlassFish instance is running the middleware/biz logic; then a 3rd DB server
Obviously if all the servers (all tiers) were running on the same VM, they may run faster or more efficiently because they wouldn't be bogged down with network latency. But they'd be on the same VM, which needs I would need mega-hardware to support them. There might also be security concerns with this setup.
There will be pros/cons to each. I'm interested in what strategies would best accomplish the following goals: (1) maximizes throughput/speed, (2) is best suited for a clustered/cloud environment and (3) maximizes security.
Thanks in advance!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这完全取决于您的应用程序。例如，数据库可能是您的瓶颈，在这种情况下，您在 JVM 中所做的事情非常重要。
如果您要分发您的系统，您很可能希望分发您的表示层。这是因为他们所做的工作取决于客户的数量，并且每个客户所做的工作在很大程度上是独立的。 （在表示层）
拥有更多虚拟机并不能保证安全性的提高。您的 JVM 应该进行设置，以便在其中运行的不同应用程序无论如何都是相当独立的。如果你想防止拒绝攻击并且你的后端服务被其他系统使用，你可能需要将它们分开，否则没有太大区别。
This depends entirely on your application. e.g the Database could be your bottle neck in which case what you in JVM does matter so much.
If you are going to distribute your system, you are most likely to want to distribute your presentation layer. This is because the work they do is dependant on the number of clients and the work each client does is largely independent. (in the presentation layer)
Having more VMs doesn't guarantee improved security. Your JVM should be setup so the different applications running in it are pretty separate anyway. If you want to prevent denial of attack and your back end services are used by other systems, you may want to separate them otherwise, it doesn't make much difference.
我认为你的问题的答案高度依赖于这个应用程序的行为、数据库的使用等......如果不查看当前的性能指标（正如已经提到的其他答案），就什么也不能说。我发表一些我的想法作为指导。
数据库
大多数组织在单独的主机中运行 RDBMS，一些工程师会选择从不虚拟化这些数据库，具体取决于他们的数据库供应商最佳实践对他们的情况的说法（也就是说，我通常认为虚拟机是等效的）物理主机，我尽可能使用它们）。
在性能方面，RDBMS 通常需要内核调整或非常规文件系统策略，将它们放在单独的主机中会有所帮助。如果需要将数据库设置为高可用性模式或集群，那么将其与应用程序服务器分开也可以使事情变得更容易。请注意，如果您需要进行数据库调整，如果认真对待的话，可能会是一个困难的话题，并且它通常涉及诸如对齐磁盘中的分区、尝试通过巧妙地分配数据库数据段/文件来减少磁盘头移动等内容，考虑到DBMS 和操作系统缓存大小和策略...所有这些都会影响同一主机中运行的其他应用程序，因此我宁愿不理会数据库。
此外，RDBMS 经常服务于多个应用程序（这样做有充分的理由：有时某些集成需要访问多个应用程序数据库）。将它们与应用程序服务器分开会有所帮助。
此外，数据库系统有自己的升级、备份、分发/集群和管理程序，并且通常由与应用程序服务器不同的人员维护。因此，如果单独考虑的话，整个数据库管理主题会更容易处理。如果数据库成为瓶颈，您可以单独处理数据库，而无需考虑其他层是否会影响性能。
我确实建议将 RDBMS 单独保留在单个主机中，以实现规模合理的生产环境。但当然，如果您没有性能、管理或可用性要求，则可以考虑使用共享服务器来处理所有事情。
Glassfish
一般来说，当您想要将 Java EE 应用程序部署到多个服务器（以实现负载平衡或高可用性）时，您可以将相同的应用程序服务器和工件安装到集群中的所有应用程序服务器。然后，您可以选择在集群的每个节点上启用哪些工件。某些应用程序服务器可以根据服务器负载启用或禁用组件。在这种情况下，您的应用程序服务器就是您需要分发的“单元”。
现在，在某些情况下，您或您的组织可能更愿意为 Web 层和业务层使用完全分离的网络层（即安全问题）。在这种情况下，您将为此使用单独的主机。如果您的 Web 层确实很重，并且您发现需要将其与业务层分开扩展（即您发现需要 6 个 Web 服务器，但可以使用 1 或 2 个 EJB 容器来实现），那么我会将这两层分开也。
请注意：在同一个 Glassfish 实例中运行 Web 层和 EJB 层有一些好处：由于它们共享 JVM，因此 Web 层和业务层之间的调用可以使用引用调用语义。根据您的工作负载以及响应的大小和序列化成本，这可能会导致性能显着提高。
在大多数情况下，对于许多企业应用程序，我只会使用一台或两台包含两个层的服务器（取决于您是否需要高可用性），因为即使负载上升，您仍然可以垂直增长（增加服务器功率或虚拟机资源）或水平增长（添加另一台服务器和负载平衡请求）。
全球可用的高吞吐量应用程序需要考虑许多其他方面才能实现可扩展（仅向 Java EE 集群节点添加节点并不能解决问题），因此我认为此解决方案中的任何一个都不是更好或者更糟糕的是为了部署到“云”，但总的来说，如果您计划部署到弹性虚拟化服务并且您的要求证明这一点是正确的，我确实建议将 Web 层和业务层分开。
安全性
在我看来，所讨论的主题对安全性没有直接影响。
最后，我相信关于这个话题还有很多可以说的，我的经验有限，所以请获得更多的意见；）。
I think the answer to your questions is highly dependent on this application behavior, database usage, etc... and nothing can be said without looking at current performance metrics (as other answers already mentioned). I post some of my thoughts as guidelines.
Database
Most organizations run RDBMS in separate hosts, and some engineers would choose to never virtualize these, depending on what their DB vendor best practices say for their case (that said, I do normally consider VMs to be equivalent to physical hosts and I use them whenever possible).
Performance-wise, RDBMS often require kernel tuning or unconventional filesystem strategies, and having them in separate hosts can help. If the DB ever needs to be set up in high availability mode or in a cluster, having it separated from application servers can also make things easier. Note that database tuning, if you ever need to do it, can be a difficult topic if taken seriously, and it often involves stuff like aligning partitions in the disk, trying to reduce disk head movement by cleverly allocating database data segments/files, considering DBMS and OS cache sizes and strategies... All this can impact other applications running in the same host so I'd rather leave the DB alone.
In addition, RDBMS often serve several applications (there are good reasons for this: sometimes some integrations require access to more than one application database). Having them separated from application servers helps.
Also, DB systems have their own upgrade, backup, distribution/clustering and administration procedures, and are often maintained by different persons than application servers. Thus the whole database administration topic is easier to deal with if you consider it separately. And if the database becomes a bottleneck, you can work on the database alone without considering if the other tiers are impacting performance.
I do recommend keeping RDBMS alone in a single host for reasonably-sized production environments. But of course, if you don't have performance, administration, or availability requirements, you can consider using shared server for everything.
Glassfish
In general terms, when you want to deploy a Java EE application to several server (for load balancing or high availability) you install the same application server and artifacts to all of the application servers in the cluster. Then you can choose what artifacts to enable on each node of the cluster. Some application servers can enable or disable components depending on the server load. In this case, your application server is the "unit" that you need to distribute.
Now, there may be cases where you or your organization may prefer to have completely separated network layers for the web tier and the business tier (i.e., security concerns). In this case, you would use separate hosts for this. If your web tier is really heavy and you find that you need to scale it separately from the business tier (i.e. you find you need 6 web servers but you can make it with 1 or 2 EJB containers), I'd separate these two tiers too.
As a note: there are slight benefits in running the web and EJB tiers in the same Glassfish instance: as they share the JVM, calls between the web tier and the business tier can use call-by-reference semantics. Depending on your work load and the size and serialization cost of responses, this can result in a noticeable performance increase.
In most cases, for many corporate applications, I'd use just one or two servers (depending if you need high availability) containing both layers, because even if load rises you can still grow vertically (increase server power or VM resources) or horizontally (add another server and load-balance requests).
World-available and high-throughput applications need to consider many other aspects in order for them to be scalable (simply adding nodes to a Java EE cluster node won't cut it), so I don't think any of this solution is better or worse in order to be deployed to "the Cloud", but in general terms, if you plan to deploy to elastic virtualization services and your requirements justify that, I do recommend to separate the web and business tiers.
Security
In my opinion, the topics discussed don't have a direct impact on security.
Lastly, I'm sure that much more can be said about this topic, and my experience is limited, so please get more opinions ;).