我有一个难题，我正在就如何进行提出不同的建议。因此，id喜欢将其放入GIS-SE中以获得一些合理的答案。
场景：
客户端具有Web制图应用程序。不想拆分为多个较小的应用程序。 尽管这与现代的Web地图方法（即在一张主Web地图上有很多聚焦的Web Map应用程序）背道而驰，但我坚信对于某些用户而言，尝试在Web上复制GIS应用程序是好的（有时）。
客户已将其底图图层中的大部分缓存到单独的服务中。
- 客户在动态地图服务中仍需要额外的600-700层 ...
- 该服务将在所有这些层都关闭的情况下发布。
- 预计用户一次不会打开10-40多个层。
我想您对此的最初反应类似于我的反应（600+ ?! WTF ?!）
但是-要求是一成不变的，为什么不呢？他们以前的ArcIMS应用程序具有类似的功能，那么为什么这个较新的ArcGIS Server产品不能做到相同？即使这些层属于其他部门，用户潜在地也需要能够对整个层范围进行交叉比较和执行分析。
在下结论之前，客户端是一个ArcGIS Server管理员。
他们已经按照所有最佳实践规则管理了600层：例如，比例范围与定义查询相结合；标签上的注释；小规模地概括复杂的层；以MSD形式发布；等等
问题：
这里有什么更好的方法？
将所有600层发布到一项动态地图服务中
将各层划分为逻辑分组（水文，规划，生态，公用事业等）
如果您选择＃1，则需要打开一些复杂的图层。如果要打开简单的点图层，则ArcGIS Server仍然必须重新渲染整个显示的图层。
如果您使用＃2，则每次提出请求时，Web应用程序都可能不得不从单个地图服务中对ExportMaps进行多个GET请求（这很不好，或者是否会给＃1上的ArcGIS Server带来额外的负担？）
然后，这导致配置和调整，以确保一切都尽可能快。我们可以将ArcGIS Server的后端扩展到多个主机，并拥有一些不错的硬件。
如果使用＃1，则可以抛出AGS可处理的最大实例数。
如果您选择＃2，则假定您评估了地图服务的性能（负载测试和查看等待时间），并相应地处理了最小/最大实例，以确保没有一个服务是“弱链接”。
我目前倾向于采用第二种方法，因为我的头脑仍然在告诉我，一项服务中包含600层是疯狂的，但是如果默认情况下将它们全部关闭，则确实没有问题。
很想听听您的想法。让我知道您是否需要通过评论获得更多信息，而不是寻找“使用桌面应用程序”或“教育他们以不同的方式做事”之类的答案。
从评论讨论中，我没有提及另一个考虑。服务将在其中使用的应用程序具有层级安全性（在应用程序级）。因此，将用户组（相当大）分配给特定角色，并且该角色将可以访问整个600层。其他角色将受到限制。
