5-летний сервер времени от 0 до 200, структура истории бурного роста стартап-компании.

Эта статья была впервые опубликована в вертикальной публичной учетной записи InfoQ: Архитектура чата,5-летний сервер времени от 0 до 200, структура истории бурного роста стартап-компании., отправлено на официальный аккаунт InfoQ:5-летняя история архитектурных изменений в стартапе.

BeiLiao, основанная в 2013 году, является рабочей платформой для родителей детских садов в Китае. Она призвана помочь детским садам решить болевые точки в работе родителей, такие как отображение, уведомление и общение с помощью интернет-продуктов и индивидуальных решений, а также способствовать гармоничным семейным отношениям. BeiLiao — единственный бренд, в который совместно инвестируют Victron (первая акция дошкольного образования A-share), Tsinghua TusHoldings и NetEase. Всего за несколько лет количество пользователей быстро достигло отметки в 10 миллионов, а DAU с каждым годом увеличивалась в геометрической прогрессии. Столкнувшись с таким быстрым развитием, исходная техническая архитектура с трудом поддерживает все более сложные бизнес-сценарии, что оказывает большое давление на техническую группу BeiLiao с точки зрения доступности и стабильности системы. Поэтому вопрос о том, как выбрать подходящую техническую архитектуру для текущих нужд и обеспечить плавную эволюцию архитектуры, заслуживает нашего глубокого размышления.

Три важных исторических этапа эволюции архитектуры Бэйчао

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

Период рождения - выбор технической архитектуры V1.0

На ранней стадии предпринимательства наша первоначальная предпринимательская команда в основном учитывала следующие моменты при выборе архитектуры:

1. На ранней стадии предпринимательства ресурсы НИОКР ограничены, рабочая сила НИОКР ограничена, а технические резервы ограничены.Необходимо выбрать удобную в обслуживании и простую техническую архитектуру;

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

3. На ранней стадии предпринимательства сложность бизнеса относительно невелика, а объем бизнеса относительно невелик.Если вы выберете слишком сложную структуру, это усложнит исследования и разработки, эксплуатацию и техническое обслуживание;

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

Исходя из вышеизложенных соображений, в конечном итоге была выбрана классическая архитектура технологии LNMP, и родилась архитектура BeiLiao V1.0.Чтобы ускорить разработку продукта и как можно скорее запустить продукт, первый этап был разработан и развернут через аутсорсинговые компании. , Возьмите на себя наши сотрудники по исследованиям и разработкам PHP и выполняйте последующую итеративную разработку.

Во время первоначального развертывания было развернуто три сервера ECS.Уровень доступа nginx и система были развернуты на одной машине, база данных RDS была машиной, а кеш Memcached был машиной.Архитектура версии 1.0 имеет следующие характеристики:

Монолитная архитектура, простая архитектура, четкая иерархическая структура;

Его можно быстро разработать, чтобы удовлетворить требования быстрой итерации продукта;

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

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

Период роста — Реконструкция технической архитектуры, версия 2.0

Я присоединился к Beichao в начале 2015. Первоначальная команда R&D состояла всего из трех человек, мне посчастливилось оказаться в этот период.

Он руководил рефакторингом технической архитектуры BeiLiao и провел несколько последующих модификаций архитектуры BeiLiao, реконструируя исходную единую архитектуру PHP в распределенную архитектуру JAVA.

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

1. Первоначальная архитектура LNMP была разработана и поддерживается двумя командами: аутсорсинговой командой и персоналом компании по исследованиям и разработкам PHP.Из-за быстрых изменений в бизнесе исходный дизайн базы данных постепенно выявил множество проблем, дизайн многих таблиц нецелесообразен и многие поля не определены, четкие, довольно хаотичны;

2. В 2015 году в связи с развитием бизнеса приложение BeiLiao необходимо разделить на два клиента: приложение BeiLiao для родителей и приложение BeiLiao для учителей.Различные клиенты используются для обслуживания разных групп пользователей для достижения точной работы.Последнее развитие архитектуры приведет к в сочетании старой и новой логики интерфейса, и многие ранние определения интерфейса не очень стандартизированы, что делает его все более и более хлопотным и трудоемким в обслуживании;

3. Исходная система интерфейса API представляет собой единую структуру, которая содержит различные интерфейсы, смешанные с различными группами обработки бизнес-логики, все функции сосредоточены в системе интерфейса API, код очень раздут, бизнес очень сложен, а скорость итеративной разработки тоже постепенно замедляется, часто вырываются различные проблемы с производительностью, много багов, деплой затруднен, любую модификацию нужно деплоить целиком каждый раз. Поскольку бизнес-логика перемешана, новому персоналу, занимающемуся исследованиями и разработками, требуется много времени, чтобы полностью ознакомиться с системой, и трудно быстро вникнуть в систему в режиме «точка-точка»;

4.Все данные хранятся в одной БД RDS,используется только одна master БД,slave БД нет.При этом многие системы совместно используют одну БД.С одной стороны БД физически не изолирована,с другой С другой стороны, в одной базе данных размещается множество таблиц.В базе данных часто возникает медленный запрос или другая проблема с производительностью, из-за чего показатели всей RDS взлетают вверх, в результате возникает лавинный эффект, все системы выходят из строя по цепочке , и в конечном итоге к нему нельзя получить доступ;

5. Связка госуслуг достаточно серьезная.Многие сторонние сервисы разбросаны по разным системам, что не удобно для унифицированного обслуживания.Когда нужно модифицировать параметры госуслуги или внести другие коррективы, нужно углубляться в каждую систему для изменения или исследования, что очень хлопотно. , он также очень подвержен упущениям, которые в конечном итоге приведут к ошибкам. Необходимо срочно отделить государственные службы независимо друг от друга, отделить государственные службы от бизнес-системы и выполнять независимые техническое обслуживание и развертывание специальным персоналом;

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

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

В период архитектуры V2.0 изначально была реализована архитектура распределенного развертывания.Согласно различным функциям и бизнес-логике, было завершено разделение на уровне системы.В то же время сторонние сервисы были разделены, а независимые сервисные модули были разделены. , мы реализовали разделение на системном уровне и физическое независимое развертывание, а также реализовали разделение базы данных master-slave, введя очередь сообщений MQ и используя SLB для достижения балансировки нагрузки и унификации пропускной способности трафика.

Архитектура периода V2.0 имеет следующие характеристики:

Распределенная архитектура развертывания, система легко расширяется;

Разделение на системном уровне, разделение подсистем с независимой логикой бизнес-функций и независимое разделение БД;

Предварительная реализация сервиса, использование Hessian для реализации RPC между системами;

БД обеспечивает физическую изоляцию, избегая сбоя одной БД в прошлом, вызывая каскадные сбои в бизнесе, и добиваясь разделения базы данных «главный-подчиненный»;

Внедрить очередь сообщений MQ, чтобы реализовать асинхронность сообщений и задач, ускорить скорость отклика интерфейса, улучшить взаимодействие с пользователем, а также реализовать асинхронность для некоторых задач отправки сообщений, избежать раннего опроса механизма MySQL, уменьшить задержку отправки сообщений и повысить скорость отправки сообщений;

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

Разделение системы и разделение БД

Система БД для разделения и разделения, мы должны закончить работу в двух этапах.

Первый этап

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

вторая стадия

После завершения разделения на уровне системы мы реализовали разделение на уровне БД, независимо разделив таблицы, от которых зависит каждая подсистема, и поместив их в разные базы данных RDS для достижения физической изоляции и разделения базы данных между ведущими и подчиненными. Окончательный эффект выглядит следующим образом:

первоначальное обслуживание

На этом этапе мы используем Hessian, который относительно прост и удобен в использовании, для реализации начального RPC-сервиса. Для сторонних общедоступных сервисов он отделен от исходной системы, а сервисные компоненты независимо разделяются и развертываются независимо, чтобы остальные бизнес-системы могли вызывать единообразно. Межсистемные вызовы также реализуют удаленные вызовы RPC через Hessian.

Балансировка нагрузки SLB

Во время архитектуры V1.0 наш Nginx был развернут в одной точке.Если сервер Nginx выйдет из строя, это повлияет на большое количество бизнес-систем, и риск очень высок, как показано на следующем рисунке:

В архитектуре версии 2.0 мы представили SLB для балансировки нагрузки, которая была настроена с несколькими модулями Nginx, а также достигла балансировки нагрузки на уровне бизнес-системы, избегая единых точек отказа и обеспечивая высокую доступность.

Период эпидемии — микросервисная архитектура V3.0

С 2016 года бизнес BeiLiao быстро развивался, количество пользователей за короткий промежуток времени увеличилось на миллионы, при этом постепенно расширялись различные направления бизнеса, бизнес-сценарии усложнялись, а масштаб кода увеличивался. расширялась очень быстро.Команда НИОКР быстро достигла десятков Масштаб людей, система разрабатывается многими людьми, уровень персонала НИОКР разный, спецификации трудно унифицировать, а бизнес-логика серьезно связана.Каждый раз он выходит в онлайн, всю большую систему нужно упаковать и запустить, что очень рискованно, а стоимость обучения новых людей после прихода на работу очень высока. Поэтому мы внедрили микросервисную архитектуру, чтобы разделить бизнес-логику на независимые компоненты микросервиса.Каждый микросервис построен вокруг конкретного бизнеса, разрабатывается и поддерживается выделенным человеком, а также выделенным человеком для оптимизации производительности и оптимизации архитектуры. Разработка и запуск сервисных компонентов никак не влияют друг на друга.

В сочетании с архитектурой V2.0 мы выбрали Dubbo в качестве распределенной среды микросервисов, исходя из различных соображений при реализации архитектуры микросервисов.

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

Его можно легко интегрировать с инфраструктурой Spring.Наша архитектура основана на Spring, и при доступе к Dubbo код может быть неинвазивным, и доступ очень удобен;

Возможность регистрации услуг, обнаружения, маршрутизации, балансировки нагрузки, ухудшения качества услуг и корректировки веса;

Код с открытым исходным кодом, который можно настроить в соответствии с потребностями, расширенными функциями и собственной разработкой;

При создании микросервисов мы учитывали следующие ключевые моменты:

Сервис-ориентированный, все является сервисом, и каждый сервис инкапсулирован для одного бизнеса, чтобы обеспечить функциональную целостность и единую ответственность;

Слабая связь, функции между службами независимы, их можно развертывать независимо, а службы взаимозависимы;

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

При реализации микросервисной архитектуры в основном учитываются следующие аспекты:

Независимая логика функций разделена на микросервисы, которые развертываются и обслуживаются независимо друг от друга;

Все системные функции реализуются через вызов микросервисов, и система не может напрямую обращаться к БД;

Небольшой объем данных и большое количество одновременных вызовов используют для связи протокол длинных соединений Dubbo, а службы больших объемов данных, такие как файлы, изображения, видео и т. д., используют для связи протокол Hessian;

Каждый микросервис поддерживает отдельную БД.

Разделенный кейс микросервиса

1 класс динамических микросервисов

Динамика класса Beichao — часто используемая функция. Директора, учителя и родители могут публиковать обновления в классе и взаимодействовать с помощью лайков и ответов. С быстрым развитием бизнеса Beichao количество пользователей резко возросло, и каждый день генерируются сотни тысяч динамики классов, в то же время количество ежедневных ответов и лайков достигло миллионов. Перед лицом такого большого объема данных нам приходится иметь дело с давлением на производительность высокого параллелизма, с одной стороны, и давлением данных, с другой стороны.Исходные динамические функции класса разбросаны в системе интерфейса API и фоновая система управления и связанные таблицы. Чтобы совместно использовать БД с исходной системой, нам срочно необходимо разделить компоненты динамического микросервиса независимого класса, а также необходимо сделать подтаблицу подбазы данных, чтобы уменьшить давление одного база данных. Поэтому мы специально выделили способный персонал для НИОКР и выделили класс динамических микросервисных компонентов.

Старый класс вызывается динамически следующим образом

Компоненты динамического микросервиса класса называются следующим образом:

Выделив класс динамических микросервисов, мы решили следующие проблемы:

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

Повторное использование кода, динамическая бизнес-логика класса извлекается отдельно, чтобы сделать независимые компоненты микросервиса, бизнес-система больше не разбрасывает код динамической бизнес-логики класса, нет необходимости копировать код;

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

2 микросервиса User Pass

Многие начинающие компании, стремясь к скорости и нехватке рабочей силы, временно помещали таблицы пользовательских данных и таблицы бизнес-данных в БД в начале своего развития.Так было в первые дни Bei Liao, что привело к различные бизнес-системы.Все они пишут DAO отдельно для получения пользовательских данных, что приводит к большому количеству дублирующихся кодов копирования пользовательской логики. С быстрым развитием бизнеса все больше и больше бизнес-систем нуждаются в доступе к пользовательским данным.Логические коды пользователей разбросаны по различным бизнес-системам.Пользовательские данные все труднее поддерживать, а сложность все выше и выше.В то же время , количество пользователей становится все больше и больше, и часто возникают проблемы с высокой производительностью параллелизма, и не так просто выполнить независимую оптимизацию производительности, поэтому неизбежно разделение независимых микросервисов прохода пользователя.

Как получить старые данные пользователя

Микросервис пропуска пользователя

Выделив микросервис пользовательских пропусков, мы решили следующие проблемы:

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

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

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

Управление микросервисами

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

1 система выпуска версий

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

Конфигурация проекта включает имя проекта, администратора, участника проекта, адрес SVN/Git, учетную запись, оболочку запуска службы, пользовательский сценарий, конфигурацию JVM для различных сред, конфигурацию веб-контейнера и т. д.;

После завершения настройки по проекту можно инициировать онлайн-форму заявки, а после одобрения развернуть ее одним кликом;

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

Журналы, созданные в процессе развертывания, можно собирать в режиме реального времени, а проблемы, возникающие в процессе развертывания, можно отслеживать в режиме реального времени визуально;

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

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

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

2 Развертывание тестового выпуска для разработки

Для сложной архитектуры микросервисов, чтобы обеспечить качество доставки каждого микросервиса, мы развертываем четыре среды:

Среда разработки, которую персонал НИОКР может использовать на этапах разработки и отладки;

Среда тестирования — это среда, в которой персонал отдела исследований и разработок обращается к тестировщикам для приемки после завершения всех функциональных разработок и тестирования в среде разработки;

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

Производственная среда, то есть онлайн-среда, — это онлайн-среда для пользователей.

Благодаря четырем вышеперечисленным средам обеспечивается качество исследований и разработок, тестирования и выпуска компонентов микросервисов.

3 Распределенный центр конфигурации и распределенная платформа планирования задач

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

Платформа управления распределенной конфигурацией Disconf реализует унификацию выпуска конфигураций. Все конфигурации хранятся в облачной системе. Пользователи могут публиковать и обновлять конфигурации на платформе унифицированным образом. При изменении конфигураций нет необходимости переупаковывать или перезапускать микросервисы, и они могут быть изменены напрямую через платформу управления.В то же время мы провели персонализированные исследования и разработки, и вся информация о конфигурации была зашифрована, чтобы избежать утечки конфиденциальной информации, такой как номера учетных записей и пароли;

Платформа распределенного планирования задач Elastic-Job реализует такие функции, как реестр задач по расписанию, сегментирование задач, эластичное расширение и сокращение задач на сервере, отработка отказа, восстановление и отключение при остановке задач, что упрощает управление синхронизацией в среде с распределенной архитектурой.

4 Полное отслеживание ссылок

Архитектура микросервиса разделяет большое количество подсистем и компонентов микросервиса.В условиях такого сложного и крупномасштабного распределенного кластера между несколькими компонентами микросервиса может возникнуть вызов ссылки.Как отследить вызов ссылки и как быстро выяснить, какой части вызова интерфейса необходимо оптимизировать, и какой интерфейс микросервиса вызывает замедление общего вызова. В ответ на вышеуказанные проблемы мы представили инструмент APM Cat, систему мониторинга в реальном времени Meituan Dianping, интегрированную с сервисной структурой Dubbo, и реализовали функцию отслеживания ссылок с помощью глобального идентификатора ссылки.

5 Авторизация микросервиса

По умолчанию в Dubbo не реализована функция авторизации сервисов. Система вызывает микросервисы, а вызовы между микросервисами не реализуют проверку авторизации. Все они напрямую обращаются к интерфейсу компонента микросервиса. Поэтому мы провели персонализированные исследования и разработки для Dubbo, и разработана авторизационная аутентификация микросервиса.Центр обеспечивает безопасность вызовов основного интерфейса микросервиса посредством авторизации и аутентификации.

6 Мониторинг микросервисов

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

7 Управление микросервисами

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

После более чем года микросервисов архитектура V3.0 выглядит следующим образом:

Микросервисная архитектура версии 3.0 имеет следующие характеристики:

Полностью реализована архитектура распределенного развертывания, а системные и микросервисные компоненты очень легко расширяются;

Сосредоточенные на сервисах компоненты микросервисов полностью построены;

Нет единой точки риска в системе, микросервисных компонентах, кеше, очереди сообщений MQ, БД и т. д., и все они обеспечивают высокую доступность HA;

Будущее - Beichao Architecture Evolution V4.0

Хотя архитектура V3.0 реализует микросервисную архитектуру, в архитектуре все же есть следующие моменты, которые можно продолжать развивать:

Развертывание контейнера Docker, Docker имеет преимущества легкого, быстрого развертывания, изолированных приложений и кроссплатформенности.Микросервисы очень подходят для быстрого развертывания в сочетании с Docker.Хотя мы внедрили микросервисную архитектуру, мы еще не достигли быстрого и эластичное расширение. Если микросервисы сочетаются с контейнерами Docker, можно добиться быстрого и эластичного расширения, серверы можно быстро и автоматически расширять во время пиковых нагрузок, а серверы можно автоматически перезапускать во время низких пиковых нагрузок. Далее мы реализуем контейнерное развертывание Docker для микросервисные компоненты;

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

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

Суммировать

Эволюция архитектуры уже началась. Архитектура должна вращаться вокруг бизнеса и не может быть отделена от бизнеса. Разные периоды бизнеса требуют разных архитектур.

Монолитная архитектура приложений больше подходит для начального этапа предпринимательства.Компании нужны быстрые пробы и ошибки и проверка реакции рынка, требуется более высокая скорость НИОКР.В то же время меньше персонала НИОКР, а монолитная архитектура приложений относительно простой и может быть быстро врезан.Требования к стеку не особенно высоки, и вы можете быстро начать работу и быстро развиваться.Однако при проектировании единой архитектуры приложения лучше всего заранее планировать будущую масштабируемость.Вы можете спланировать ее сначала на уровне бизнеса, чтобы бизнес мог развиваться до определенного масштаба в будущем, что можно было бы осуществить быстро.Развязка и внедрение микросервисной архитектуры.

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

В настоящее время мы все еще находимся на пути эволюции архитектуры, и мы прошли через описанные выше архитектурные путешествия.Хотя мы добились определенного прогресса, нам еще предстоит решить множество проблем. Планирование технической архитектуры должно всесторонне учитывать масштаб бизнеса, своевременность бизнеса, масштаб группы НИОКР, технические возможности НИОКР и конфигурацию базовой среды. Архитектура исходит из бизнеса, и жизненный цикл эволюции архитектуры может дать наилучшие результаты только тогда, когда он идеально соответствует жизненному циклу бизнеса.