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

1. Упростить масштабирование и работать с огромным потоком данных, создаваемым большим количеством одновременных пользователей (например, пациентов, врачей, медперсонала и администраторов больниц) через несколько устройств (например, смартфоны, носимые устройства, планшеты и настольные компьютеры).

2. Обеспечьте максимально удобное и последовательное взаимодействие с пользователем независимо от нагрузки на систему.

3. Принять гибкую разработку программного обеспечения и непрерывную интеграцию / развертывание (CI / CD) через Amazon Web Services.

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

Что такое реактивные микросервисы?

Архитектура микросервисов, без сомнения, в настоящее время является одним из самых горячих шумих и модных словечек в индустрии программного обеспечения, и доказательством этого является присутствие микросервисов в так называемом цикле хайпа Gartner!

Если оставить в стороне шумиху, с технической точки зрения архитектура микросервисов - не что иное, как частный случай архитектуры распределенной системы. Основная идея состоит в том, чтобы по существу написать программное обеспечение в виде набора небольших изолированных служб, где каждая служба владеет своим хранилищем данных, может независимо развертываться и масштабироваться по мере необходимости независимо от других служб. Это дает разработчикам программного обеспечения свободу использовать любые технологии, которые имеют больше смысла для конкретной службы, например, Служба A может, например, использовать MongoDB и фреймворк X, написанные на Java, а Служба B может используйте что-то совершенно другое, например MySQL и фреймворк Y, написанный на Ruby on Rails. Это теоретически (не всегда на практике!) Означает, что команде разработчиков намного проще вносить и развертывать изменения в производственной среде на нескольких серверах с минимальными нарушениями работы пользователей, в отличие от старого подхода, когда система может часами находиться в обслуживании. режим, пока разработчики внедряют новые изменения или исправления ошибок.

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

Следует ли стартапам на ранних этапах использовать такую ​​передовую архитектуру?

На этот вопрос нет правильного или неправильного ответа. Но традиционно наиболее успешные и прорывные стартапы (например, Netflix и Uber) какое-то время начинали с монолитной архитектуры, пока их бизнес-модель не была проверена, а затем для масштабирования перешли на более продвинутый архитектурный шаблон, такой как микросервисы. Фактически, в прошлом году Uber поделился своим переходом к микросервисам в этом сообщении в блоге.

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

Забегая вперед, сегодня инфраструктура для поддержки распределенных приложений стала гораздо более зрелой и доступной для стартапов, например. сети быстрее, многоядерные машины дешевле, оперативная память дешевая, а поставщики облачной инфраструктуры, такие как AWS, увеличили площадь своих глобальных центров обработки данных, чтобы компании могли регулировать нагрузку на свои ресурсы географически в зависимости от местоположения клиентов. Следовательно, в Zaiku мы думаем, что для амбициозных стартапов, стремящихся подорвать свои отрасли, есть смысл как можно раньше внедрить передовую распределенную архитектуру, чтобы сразу начать работу. Мы с нетерпением ждем возможности поделиться успехами стартапа в области скрытой медицинской аналитики после его публичного запуска в следующем году. Мы благодарим их руководство за разрешение поделиться с вами некоторыми подробностями высокого уровня.

Если вы являетесь генеральным директором / техническим директором стартапа и хотите изучить передовую распределенную архитектуру, мы будем рады получить от вас известие. Ознакомьтесь с нашим репозиторием Github, где вы найдете наш универсальный набор инструментов Java с открытым исходным кодом, призванный помочь разработчикам реализовать широкий спектр распределенных систем.

Хакерский полдень - это то, с чего хакеры начинают свои дни. Мы часть семьи @AMI. Сейчас мы принимаем заявки и рады обсуждать рекламные и спонсорские возможности.

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