В этой серии из четырех частей мы обсудим типичную архитектурную эволюцию веб-сайта / приложения и то, как / почему мы делаем технический выбор на разных этапах.
Создаем ли мы монолитное приложение в самом начале?
Когда мы добавим кэш?
Когда мы добавим полнотекстовую поисковую систему?
Зачем нам нужна очередь сообщений?
Когда мы используем кластер?
В первых двух сегментах мы рассмотрим традиционный подход к созданию приложения, начиная с одного сервера и заканчивая кластером серверов, способных ежедневно обслуживать миллионы активных пользователей. Основные принципы по-прежнему актуальны.
В последних двух разделах мы рассмотрим влияние последних тенденций в области облачных и бессерверных вычислений на создание приложений, то, как они меняют способ создания приложений, и расскажем о том, как учитывать эти современные подходы при создании вашего следующего большого хита.
Давайте рассмотрим, как обычный стартап создавал свое первое приложение. Этот базовый подход был распространен примерно 5 лет назад. Теперь, благодаря бессерверным вычислениям, гораздо проще запустить приложение, которое может масштабироваться до десятков тысяч пользователей с очень небольшими первоначальными вложениями. Позже в этой серии мы поговорим о том, как нам следует воспользоваться этой тенденцией.
А пока мы углубимся в то, как приложение (Llama) традиционно создается в самом начале. Это закладывает прочную основу для остальной части нашего обсуждения.
Llama 1.0 — Монолитное приложение, единый сервер
В этой первой архитектуре весь стек приложений размещается на одном сервере.
Сервер является общедоступным через Интернет. Он предоставляет RESTful API для обработки бизнес-логики и доступа к мобильным и веб-клиентским приложениям. Он обслуживает статическое содержимое, такое как изображения и пакеты приложений, которые хранятся непосредственно на локальном диске сервера. Сервер приложений подключен к базе данных, которая также работает на том же сервере.
С такой архитектурой он, вероятно, обслуживал бы сотни, а может быть, даже тысячи пользователей. Фактическая пропускная способность зависит от сложности самого приложения.
Когда сервер начинает испытывать трудности с растущей нагрузкой на пользователя, один из способов выиграть немного больше времени — это масштабирование до более крупного сервера с большим объемом процессора, памяти и дискового пространства. Это временное решение, и в конечном итоге даже самый большой сервер достигнет своего предела.
Кроме того, эта простая архитектура имеет существенные недостатки для производственного использования. Поскольку весь стек работает на одном сервере, отказоустойчивость или избыточность отсутствуют. Когда сервер неизбежно выходит из строя, время простоя в результате может быть неприемлемо длительным.
По мере развития архитектуры мы узнаем, как решать эти операционные проблемы.