本地处理与集中处理

发布于 2024-07-14 22:49:17 字数 845 浏览 5 评论 0原文

我在一家拥有大量 SAP 投资的公司工作,我们还有数十个大型 .Net 系统(主要用于内部工程系统)和 Java 平台(主要用于外部 Web 应用程序)。 因此,我们在 ABAP、C# 和 Java EE 上拥有大型开发中心。

我们有 20 多个分布在很远距离的主要设施,2 个数据中心,以及分布在城市、农村和偏远地区(靠近北极)的 600 多个小型设施,

我们对每个功能中使用的平台都有适当的标准域,但我们对于何时进行本地处理以及何时使用分布式(中央)处理并不清楚。 (即,胖客户端与瘦客户端)

我想根据最佳实践构建一个决策树来帮助解决这个问题。 我过去看到的一些标准包括:

  • 安装应用程序的任何地方是否都有可靠的网络? (如果不是,本地处理可能是更好的选择)
  • 应用程序是否需要实时数据? (如果是,集中处理可能是更好的选择)
  • 应用程序是否需要密集的 CPU 工作或高磁盘 IO? (如果是,可以选择集中处理或密集本地处理)
  • 应用程序是否需要离线 能力? (如果是的话,本地 处理可能是更好的选择)
  • 是否存在安全问题 将数据合并到 远程环境? (如果是, 集中处理 分布式瘦客户端可能是 更好的选择)
  • 是否有现有的硬件 可以利用来运行的网站 应用程序? (如果是的话,集中 处理可能是一个不错的选择:A 瘦客户端的部署成本更低 并维护,他们更安全, 对小偷来说价值较低)
  • 是否存在现有的应用程序 正在使用相同的用户组, 这些应用程序怎么样 部署了? (可能存在经济 通过整合应用程序进行扩展 融入一种设计模式)

I work at a company with a large SAP investment, and we also have dozens of large .Net systems (mostly internally for engineering systems), and Java platforms (mostly for external web applications). As such, we have large development shops on ABAP, C#, and Java EE.

We have over 20 major facilities distributed over very large distances, 2 data centres, and 600 or so small facilities in urban, rural, and remote areas (think close to the North pole)

We have decent standards for which platform to use in each functional domain, but we don't have a lot of clarity around when to local processing and when to use distributed (central) processing. (i.e., Thick client vs. Thin client)

I'd like to build a decision tree based on best practices to help with this question.
Some of the criteria I've seen in the past include:

  • Is a reliable network available everywhere the application will be installed?
    (If no, local processing may be a better option)
  • Does the application require real-time data?
    (If yes, centralized processing may be a better option)
  • Does the application require intensive CPU effort or high disk IO?
    (If yes, centralized processing or a thick local processing may be options)
  • Does the application need offline
    capabilities? (If yes, local
    processing may be a better option)
  • Are there security concerns for
    having the data consolidated in
    remote environments? (If yes,
    centralized processing with
    distributed thin clients may be a
    better option)
  • Is there existing hardware at the
    sites that can be leveraged to run
    the application? (If yes, centralized
    processing may be a good option: A
    thin client will cost less to deploy
    and maintain, they are more secure,
    and less valuable to thieves)
  • Are there existing applications that
    the same user group is working with,
    and how are these applications
    deployed? (There may be economies of
    scale by consolidating applications
    into one design pattern)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

可遇━不可求 2024-07-21 22:49:17

这里可以考虑各种各样的事情,例如您要使用哪种文件系统? (AFS / NFS)

根据之前的经验,我们已经成功地将需要密集型 CPU 的交易系统分布在远程服务器的 Citrix 集群上。 这些用户都没有任何抱怨。

实时数据我们通常会使用总线方法,由客户端或中间件提供结果。

All sorts of things can be considered here such as what sort of file system are you going to use ? (AFS / NFS)

From previous experience we've managed to distribute trading systems which require intensive CPU over citrix clusters for remote servers. None of these users had any complaints.

Real time data we would usually use a BUS approach where by clients or middleware would deliver the results.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文