Что сделать, когда Вы действительно завинтили дизайн распределенной системы?

1. Вы не облажались. Заказчик хотел самый дешевый вариант, вы ему дали, это цена, которую они откладывают. Надеюсь, вы не взяли на себя вину своего покупателя. Если они обвиняют вас, это классический случай, когда они платят за Chevy, а хотят Mercedes.

   В соответствии с этим:

2. Ваш клиент должен принять бизнес-решение о том, что ему делать. Ваша задача - как можно честно и профессионально объяснить им последствия каждого выбора и оставить выбор за ними.

Просто помните, вы не облажались! Вы предоставили им решение, которое годами удовлетворяло их потребности, и они были довольны им, пока не превзошли проектную основу системы. Если они не хотят снова поддерживать масштабируемость системы через три года, им придется заплатить за это сейчас. Программное обеспечение - это не волшебство.

Вы уверены, что причиной тайм-аутов является подключение к Интернету, а не проблемы с производительностью веб-службы / системы CRM? Под тайм-аутом я предполагаю, что вы имеете в виду что-то вроде ~ 30 секунд, в этом случае:

• Либо виновато интернет-соединение, и вы увидите такие тайм-ауты для других веб-сайтов (например, Google), что явно неприемлемо, поэтому сортировка в Интернете - ваш единственный реальный выход.
• Или тайм-аут вызван либо настольным приложением, либо веб-службой, либо чрезмерно большим объемом информации, передаваемым взад и вперед, и в этом случае вам следует либо решить проблему производительности, как и любую другую ошибку, либо изучите способы оптимизации настольного приложения, чтобы меньше информации передавалось вперед и назад.

В общем: архитектура, которая у вас есть в настоящее время, мне кажется (в основном) прекрасной на том основании, что (помимо проблем с производительностью) доступ компании к системе CRM должен быть сопоставим с доступом общественности к системе - поскольку пока у ваших клиентов есть разумное время отклика, должна поступать и компания.

Вы уверены, что соединение переполнено? Вы можете столкнуться со всеми видами проблем с сетью, вводом-выводом и базой данных ... Если вы еще не сделали этого, используйте wirehark для анализа трафика; измерять пропускную способность и делиться с нами результатами.

Я бы не назвал это провалом, если:

1. Не было известно, насколько вырастут требования к трафику или производительности. И
2. Вы намеренно спроектировали систему так, чтобы ее производительность была недостаточной. И
3. Вы сознательно сконструировали систему так, чтобы она была жесткой и не адаптируемой к изменениям.

Ошибкой было бы чрезмерное проектирование очень сложной системы, которая стоила бы больше, чем требовали масштабы того времени.

На самом деле хорошей практикой является инвестирование только той суммы, которую в настоящее время может использовать бизнес, используя рост для финансирования дальнейших инвестиций в масштабируемость, если это потребуется. Это простое управление рисками.

Несомненно, поскольку бизнес со временем рос, предположительно с помощью вашего программного обеспечения, они также отложили что-то для следующего уровня. Они должны благодарить вас за помощь в развитии их бизнеса сверх ожиданий и кидать в вас деньги, чтобы вы могли помочь им перейти на следующий уровень роста.

Все эти три варианта могут быть хорошими. Какой из них лучше, зависит от анализа рентабельности, рентабельности инвестиций и т. Д. Это частично техническое решение, но в основном бизнес-решение.

Поздравляем, вы помогаете строить растущий бизнес прямо сейчас и в будущем.

Установить копию базы данных в локальной сети. Затем позвольте клиентскому программному обеспечению взаимодействовать с локальной копией и позволить программному обеспечению базы данных выполнять синхронизацию между локальным сервером базы данных и базой данных на веб-сервере. Это зависит от того, какую базу данных вы используете, но у некоторых из них есть инструменты для этой работы. В MSSQL это называется репликацией.

Перво-наперво, сколько кода вам действительно нужно выбросить? Какой язык вы использовали для настольного клиента? Что-то .NET, и вы, возможно, сможете спасти хороший кусок логики системы, и вам потребуется только переделать пользовательский интерфейс и некоторые соединения.

Я считаю, что вопросы 1 и 2 исключены, хотя 1 может быть хорошей идеей, но не решает реальной проблемы. И мы, как инженеры, должны стараться создавать решения, не зависящие от клиента, когда это возможно. А 2 заставляет их заниматься тем, в чем они не разбираются, и лучше оставить хостинг в другом месте.

Кроме того, поскольку вы упомянули веб-службу, вы действительно теряете пользовательский интерфейс? Вы всегда можете повторно использовать веб-сервисы для интерфейса веб-сервера.

Наконец, вы могли бы посмотреть на использование фреймворка, чтобы помочь создать простой веб-интерфейс CRUD для запуска и последующего расширения.