Портал: Теория микросервисов (1)
1. Теплая встреча
«Подраздел Всемирной интернет-конференции по микросервисам» в самом разгаре Главный технический редактор Ван Сяову слушал с удовольствием, иногда кивая в знак согласия, иногда аплодируя, чтобы выразить волнение.
День закончился быстро, и брат С., который был гостем на этом мероприятии, также завершил дневную деятельность. Ван Сяоу поспешил к брату С, готовый начать сегодняшнее интервью.
Начало интервью
Сяо Ву: Брат С, мы снова встретились, спасибо, что вытащили интервью из своего плотного графика!
Брат С: Ха-ха, все в порядке, разве мы не решили продолжить сегодня, так что давайте начнем.
Маленькая пятерка: Хорошо. В прошлый раз я упомянул, что вы провели трансформацию микросервисов в будущем. Многие пользователи сети не слышали достаточно. Я хочу, чтобы вы больше рассказали о применимых сценариях трансформации микросервисов.
Brother C: Хорошо, тогда я буду систематически рассказывать о проблемах, на решение которых нацелены микросервисы.
3. Зачем вам микросервисы?
1. Все больше и больше монолитных приложений
Брат С: Сяо Ву, ты знаешь, что такое отдельное приложение?
Сяо Ву: Вы имеете в виду, что все сервисы размещены на одной машине?
Брат К.: Да, вот и все. Монолитные приложения относятся к микросервисам. Монолитное приложение, то есть все сервисы будут выполняться в пространстве процессов и не будут вызываться между процессами. Для большинства компаний ранняя техническая архитектура должна представлять собой одно приложение.
Маленькая пятерка: Да. Как вы сказали вчера, один LNMP может удовлетворить потребности большинства стартапов.
Brother C: Да, но по мере того, как система будет иметь все больше и больше функций, это отдельное приложение будет становиться все больше и больше, а иногда даже воздействует на все тело.
Сяо Ву: Брат С, можете ли вы привести пример, иллюстрирующий эту проблему?
Брат С. Возьмем в качестве примера компанию Guguale. На 5-м году разработки Quack система все еще представляет собой единое приложение, а архитектуру можно представить в виде схемы.
Brother C: Как видите, приложение развернуто на каждой машине. Но каждое Приложение содержит все услуги компании. Мы по-прежнему рисуем картинку, чтобы просто представить состав каждого приложения.
Сяо Ву: Ого, какая огромная система!
Брат К.: Да, по мере того, как бизнес становится все более и более сложным, это единственное приложение также будет становиться все больше и больше.
2. Потяните один волос и двигайтесь всем телом
Сяо Ву: Брат С, кажется, я чувствую "неприятный запах". Часто ли такая архитектура идет не так?
Brother C: Вы правы, потому что все сервисы находятся в одном приложении, если какой-то сервис выйдет из строя, зависнет все приложение.
Сяо Ву: То есть связь этого приложения слишком высока.
Brother C: Да, точно так же, когда обновляется служба, все приложение также должно быть обновлено и выпущено вместе. Можно сказать, что дергаешь за один волос и двигаешь всем телом.
3. Неспособность бегать маленькими шагами
Брат К.: Все мы знаем, что одной из характеристик интернет-продуктов является «быстро», быстрое тестирование воды, быстрое улучшение, то есть так называемый «маленький шаг» и «быстрый бег». Однако система слишком велика, и многие сервисы связаны друг с другом, совместно используя БД, общий кэш и копируя-вставляя код повсюду. Каждый раз, когда мы изменяем функцию, многим командам приходится вносить изменения, и это требует большого количества тестов.
Сяо Ву: Да, тогда принцип быстрого бега маленькими шагами вообще не может быть реализован.
Брат С: Вы не поверите, однажды мы хотели добавить небольшую функцию для напоминания пользователям, и потребовался месяц, чтобы запустить ее в сети.
Сяо Ву: Ха-ха, тогда такую структуру действительно нужно срочно менять, иначе продукт будет слишком неконкурентоспособным.
4. Горизонтальное расширение одного сервиса
Brother C: Горизонтальное расширение услуг также является проблемой. Например, нашему сервису заказов необходимо каждый день обрабатывать большое количество данных, то есть сервису заказов требуется больше вычислительных ресурсов. Но мы не можем горизонтально масштабировать службу заказов. Если служба заказа не может поддерживаться, мы можем только горизонтально расширить все приложение.
Сяову: Да, тогда много вычислительных ресурсов тратится впустую, и в то же время узкое место в производительности службы заказов не может быть хорошо решено.
5. Путаница командного разделения труда
Брат К. Мы видим, что система очень взаимосвязана и хаотична. Напротив, путаница в системе приводит к путанице в разделении труда в коллективе. Поскольку различные службы системы не имеют четких границ, люди в команде делают много дел, из-за чего одни бездействуют, а другие очень заняты.
Сяо Ву: Ну, многие люди должны были испытать это, нет специального человека, который бы выполнял особую работу, и разделение труда неясно.
6. Код не решается на рефакторинг
Brother C: Вы осмеливаетесь проводить рефакторинг, когда видите плохой код?
Сяо Ву: Я все равно не осмеливаюсь реконструировать его, ха-ха, это повлияет на все тело.
Брат С: Да, я не решаюсь на рефакторинг, в огромном одиночном приложении после рефакторинга я могу повесить любой сервис.
7. Повторное использование сервисов
Брат К.: Вчера я также упомянул о проблеме, связанной с повторным использованием сервисов. Например, услуга заказа и услуга выставления счетов используются во многих наших бизнесах (финансовое управление, рассрочка, кредит наличными) Если нет разделения услуг, каждая система может копировать код одной и той же услуги.
Сяо Ву: Да, в этом случае нам нужно поддерживать n наборов одного и того же кода, и машина перевернется, если мы не будем осторожны.
Brother C: Да, но после того, как мы распаковали сервис, этой проблемы больше не существует.
Преимущества микросервисов
Xiaowu: Брат С, слушаю вас, одно огромное приложение приносит много проблем.
Брат К.: Да, все проблемы, о которых я только что упомянул, на самом деле были у Гугуа Ле. Эти проблемы можно решить с помощью микросервисов. Микросервисы слабо связаны, и в то же время разумная корректировка кадровой структуры также приведет к повышению эффективности.
Пятерка, хочу попробовать
Сяову: Брат С, слушаю вас, микросервисы — это так хорошо! Я не могу дождаться, чтобы попробовать это прямо сейчас, ха-ха.
Брат С: Ха-ха, не горячись пока. Многое — палка о двух концах, и микросервисы тоже могут принести немало проблем.
Сяо Ву: О? Какие проблемы это принесет?
Брат С: На самом деле проблем еще много.Если эти проблемы не решить, то вообще хулиганством заниматься микросервисами.
Сяо Ву: Да, вам нужно найти решение, которое вас устроит.
Брат С: Ну, а о недостатках мы поговорим завтра, а сегодня остановимся на этом.
Сяо Ву: Хорошо, брат С, увидимся завтра!
Постскриптум: Все создается для решения определенных задач для определенных сценариев. Поэтому технология, которая не у дел или вне сцены, — это хулиган.
Микросервисам предстоит решить еще много проблем: среди них большая проблема — согласованность данных, а также RPC, Docker, обнаружение сервисов и т. д., которые необходимо учитывать.
Эта серия статей призвана дать каждому полное представление о микросервисах. Мы поговорим о микросервисах и реализации микросервисов в другой день. Хороших выходных ^_^.