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

Связанный вопрос: Каков наиболее эффективный способ разбить централизованную базу данных?

Я попытаюсь сделать этот вопрос довольно общим, чтобы он приносил пользу другим.

Около 3 лет назад я внедрил интегрированный CRM и веб-сайт. Поскольку я хотел произвести впечатление на клиента, я реализовал самую дешевую архитектуру, о которой я мог думать, которая заключалась в размещении центральной базы данных и веб-сайта на веб-сервере. Я создал настольное приложение, которое общается с веб-сервером через веб-службу (это приложение выполняется из своего главного офиса).

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

Приобретите более быстрое подключение к Интернету.
Переместите базу данных (и веб-сайт) на собственный сервер.
Переконструируйте архитектуру так, чтобы CRM и веб-базы данных были разделены.

Первый вариант - это "самый простой", но, конечно, не самый дешевый долгосрочный. Второй вариант; если мы переместим сайт на собственный хостинг, клиент должен бороться с такими проблемами, как перегрузка/плохое/автономное подключение к Интернету, потеря мощности и т.д. И последний вариант; клиент ненавистен, чтобы заплатить за меня все деньги, чтобы перепроектировать и переконфигурировать архитектуру, и я не могу позволить себе делать это бесплатно (мне нужно есть).

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

Ответ 1

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

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

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

Ответ 2

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

Было известно, сколько трафика или требований к производительности будет расти. И
Вы сознательно разработали систему для недоиспользования. И
Вы сознательно разработали систему как жесткую и не адаптируемую для изменения.

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

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

Ответ 5

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

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

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

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

Ответ 6

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