Оригинальный адрес:Блог Лян Гуйчжао
адрес блога:blog.720ui.com
Добро пожаловать на официальный аккаунт: «Серверное мышление». Группа людей с одинаковой частотой растет вместе, вместе совершенствуется и преодолевает ограничения познания.
1. Отказаться от монолитных систем и использовать микросервисы?
Разница между монолитной системой и микрослужбой заключается в том, что монолитная система представляет собой большой и всеобъемлющий набор функций, и на каждом сервере выполняется полная служба приложения. Микросервисы — это независимые и автономные функциональные модули, которые являются частью экосистемы и имеют симбиотические отношения с другими микросервисами. В настоящее время общий взгляд отрасли на монолитные системы и микросервисы заключается в том, что монолитные системы очень легко разрабатывать, тестировать и развертывать, но есть также много проблем, с которыми сталкиваются монолитные системы, такие как более низкая эффективность разработки, повышенные затраты на обслуживание и изменения в влияние развертывания Большой размер, плохая масштабируемость и высокие затраты на выбор технологии, а также внедрение микросервисов могут упростить разработку и обслуживание каждого микросервиса, облегчить общение и совместную работу и очень подходят для гибкой разработки и непрерывной доставки небольших групп; ответственность каждого микросервиса. Единая, высокая связанность, низкая связанность. В то же время каждый микросервис можно разрабатывать, запускать и развертывать независимо; каждый микросервис независим. Если сервис развернут или недоступен, это повлияет только на текущий сервис, а не на всю бизнес-систему. независимо расширяться по горизонтали и вертикали перед лицом большого количества пользователей и высокого параллелизма, поскольку масштаб системы продолжает расширяться; каждый микросервис может использовать разные языки программирования и разные технологии хранения, что упрощает нам опробование новых методов. Кроме того, реструктуризация бизнеса одной службы не столкнется с большим бременем бизнеса и техническими облигациями.
Точка зрения автора на микросервисную систему заключается в том, что в процессе перехода от монолитной системы к микросервисной системе нам необходимо тщательно продумать, на каком этапе использовать микросервисы. Микросервисы не панацея, они выдвигают повышенные требования к сложности проектирования и эксплуатации и сопровождения, а также привносят некоторую техническую сложность. Поэтому нам необходимо подумать и решить такие решения, как распределенная сложность, согласованность данных, управление сервисами, эксплуатация и обслуживание, а также автоматическое развертывание сервисов. На самом деле микросервисы уменьшают сложность одного сервиса, разбивая монолитную систему на несколько более мелких сервисов. Однако мы рассматриваем его как единое целое. Такой подход привел к существованию большого количества сервисов, а сервисы взаимно вызовы между ними также увеличатся, что приведет к более сложной архитектуре системы.
Мы часто игнорируем соображения ценности и затрат для бизнеса и слишком сильно гонимся за технологиями, что может привести к тому, что наша хорошо спроектированная распределенная архитектура серьезно повлияет на скорость нашей разработки и быстрое повторение нашего бизнеса, а неопределенность бизнеса часто приводит к нашей структуре. полностью не применима в течение полугода-года, и ее необходимо перестраивать. Кроме того, если бизнес не будет развиваться, это также приведет к слепой трате большого количества серверных ресурсов на ранней стадии, что не стоит выигрыша для начинающего бизнеса. Поэтому на ранней стадии проекта для обеспечения быстрого роста бизнеса обеспечить максимально независимую и завершенную систему, а также снизить техническую сложность после внедрения микросервисной архитектуры, например, выдвигает более высокие Требования к сложности эксплуатации и обслуживания, поскольку для хорошей архитектуры микросервисов требуется стабильная инфраструктура. По мере успешного развития бизнеса масштаб системы будет продолжать расширяться, а ее масштабируемость, масштабируемость, доступность и производительность ограничивают развитие нашего бизнеса.Трансформация услуг.
Архитектура микросервисов использует сервисы как модульные единицы. Затем мы можем изначально изолировать зависимости с помощью модуляризации модулей Maven на раннем этапе проектирования и зарезервировать место для нашего последующего преобразования. Обратите внимание, что микросервисы — это симбиотические отношения в экосистеме. Здесь не только ограничено, что они могут иметь зависимости от ссылок, но и их коммерческая ценность должна быть симбиотической. Поэтому на более позднем этапе выделяют основную ценность и ключевые функции единой системы, а затем эти функции разделяют на самостоятельные и самозавершающиеся модули. Здесь план преобразования можно прочитать в статье автора «Высокодоступная и масштабируемая микросервисная архитектура: на основе Dubbo, Spring Cloud и Service Mesh», глава 12 «Преобразование микросервисной архитектуры устаревших систем».
Подводя итог, можно сказать, что микросервисы уменьшают сложность одного сервиса, разбивая монолитную систему на несколько более мелких сервисов.Однако с общей точки зрения такой подход привел к существованию большого количества сервисов и сервисов. они также будут увеличиваться, что приведет к более сложной архитектуре системы. Поэтому мы не только ориентируемся на технологии, но и должны учитывать соотношение «затраты-выпуск», чтобы максимизировать выгоду на текущем этапе.
2. Избавиться от единой системы и держаться подальше от большого комка грязи?
Монолитная система, которую многие критикуют, заключается в том, что ее услуги сплочены и запутаны, и она выглядит как большой ком грязи. Итак, после службы эта проблема решилась? На самом деле микросервисы уменьшают сложность отдельного сервиса, разбивая монолитную систему на несколько более мелких сервисов, делая единую систему функционально более понятной, но общая архитектура системы становится более сложной. На самом деле вызовы между несколькими службами в производственной среде могут быть сценарием, показанным на рисунке.
Обычно микросервисная экология производственной среды намного сложнее, чем в приведенном выше случае, и сервисов может быть от десятков до сотен. Тогда для нас очень важно, как систематически разбираться в зависимостях и связывать отношения между сервисами. Особенно во время большого продвижения необходимо обеспечить надежную гарантию основной ссылки, и эта работа становится еще более важной. В связи с этим я рекомендую автоматическую обработку ссылок с помощью сбора трафика APM.
Кроме того, мы разрабатываем архитектуру.Всякий раз, когда возникает проблема детализации обслуживания, например, создание нового проекта или когда границы обслуживания неоднозначны, нам необходимо четко обсудить границы обслуживания и сохранить наши услуги как сплоченные как можно секс.
3. Может ли миграция микросервисов повысить надежность системы?
Здесь есть еще одно широко распространенное мнение: монолитная система — это большой и полный набор функций. Если служба выйдет из строя, это повлияет на всю бизнес-систему. Однако с помощью микрослужб можно понять, что если служба будет развернута или закрыта, влияет только на текущий сервис, а не на всю бизнес-систему.
На самом деле эта точка зрения кажется очень правильной, но в реальных бизнес-сценариях она не является ключевой причиной нашей трансформации. Во-первых, во избежание единой точки отказа отдельному блоку обязательно нужна кластеризация и балансировка нагрузки, при этом следует отметить, что кластеризация, балансировка нагрузки и микросервисы (вертикальное разделение сервисов) не исключают друг друга, а находятся в высокой степени параллелизма. и распределение отношения сосуществования. Кроме того, чтобы решить проблему развертывания службы, мы можем рассмотреть возможность непрерывного выпуска служб, чтобы обеспечить бесперебойную работу служб. Итак, монолитная система не обязательно ненадежна. В то же время, после внедрения микросервисов, с общей точки зрения, этот метод привел к существованию большого количества сервисов, а также увеличатся взаимные обращения между сервисами, что приведет к общей архитектуре системы. становится все более сложным, вероятность отказа узла значительно возрастает, а чем больше зависимостей, тем больше проблем. В настоящее время, если предположить, что микросервис на одном из каналов вызова не работает и не может предоставлять услуги, как обеспечить его собственную доступность для вышестоящих сервисов, которые сильно зависят от него? (Здесь я специально имею в виду вызовы с сильными зависимостями, деградация службы или механизмы прерывания цепи могут нанести ущерб бизнесу и не являются эффективным решением.) Поэтому во многих сценариях время простоя службы может также повлиять на всю бизнес-систему.
Поэтому, если мы не будем проектировать на отказ и не построим систему управления сервисом, это приведет к ненадежности всего сервиса.
4. Может ли перенос микросервисов повысить производительность системы?
Итак, каковы основные мотивы миграции микросервисов? Я думаю, что основным преимуществом является масштабируемость службы и возможность повышения производительности. Служба может стать узким местом из-за ограничений хост-компьютера. Чтобы еще больше сократить ресурсы машины, рекомендуется разделить службу. В то же время мы можем дополнительно реализовать автоматическое масштабирование для настройки использования машины. Однако обязательно ли миграция микросервисов повышает производительность системы? Мое мнение не обязательно. После сервисизации ссылка вызова становится длиннее, исходная RPC-связь может удлиняться в несколько раз, а потери производительности возрастают. Например, одной из основных проблем удаленной мультиактивности является сетевая задержка.Должны быть проблемы с задержкой в разных городах.Предполагая, что межрегиональная сетевая задержка может быть в пределах 100 миллисекунд, один HTTP-запрос включает одну или две сотни межгородских запросов. Вызовы RPC. , то общее время отклика значительно возрастет, поэтому проблема задержки очень велика. Затем, чтобы решить проблему задержки данных, Alibaba сначала предложила унифицированное решение, то есть для того, чтобы запросы сходились в одной и той же области для завершения, единица была высоко связанной, и не выполнялся доступ между областями, то есть , "закрытие блока". Кроме того, существует также проблема сетевого тайм-аута межсервисных вызовов, а также увеличивается скрытая опасность блокировки синхронизации при повторных попытках.
Таким образом, сервитизация жертвует производительностью вызовов на канале между службами, чтобы повысить производительность всей бизнес-системы за счет сокращения ресурсов машины в целом.
5. Доступность микросервисов = каждый вызов, предоставляемый сервисом, надежен и доступен?
Понимание многих людей о доступности микросервисов заключается в том, что каждый вызов, предоставляемый сервисом, надежен и доступен. Эта точка зрения неверна. Фактически микросервисы гарантируют общую доступность своих сервисов. Обычно, если служба A вызывает службу B, если для вызова требуется 10 секунд, то последняя ситуация может косвенно блокировать, вызывая разрыв пула потоков, делая службу недоступной. Поэтому мы примем механизм тайм-аута, чтобы гарантировать, что ответ с результатом будет завершен за очень короткое время, и не будет проблем с блокировкой синхронизации, насколько это возможно.
Кроме того, в случае отказа службы B все службы, зависящие от вызова, будут заблокированы, а при большом количестве запросов ресурсы потока будут потребляться, что приведет к параличу службы. На самом деле зависимости между сервисами могут приводить к каскадному распространению, что косвенно приводит к «лавинному» эффекту отказа сервисов, делая недоступной всю микросервисную систему. Для решения этой проблемы в дело вступает механизм автоматического выключателя.
6. Являются ли базы данных в микросервисах независимыми и прозрачными?
Общепринятое представление о микрослужбах заключается в том, что каждая служба имеет собственный кеш и базу данных, а кеш и база данных независимы и прозрачны. Поэтому неправильно совместно использовать кеш и базу данных. Что, если сервису А нужно получить данные сервиса Б? Общая практика заключается в том, что служба B предоставляет API-интерфейс для получения данных, а служба A выполняет бизнес-сборку, вызывая этот интерфейс. Поэтому после микросервисизации обмен данными между сервисами осуществляется через интерфейсы.Если сервис А будет обращаться к данным сервиса Б через бизнес-логику сервиса Б, это разрушит независимость данных между микросервисами.
В этот момент мне нужно налить немного холодной воды. Нет абсолютных значений, и есть несколько особых сценариев, которые могут потребовать обмена данными. Первый — это сценарий, в котором старая служба переходит к новой службе, а новая служба повторно использует базу данных старой службы для удовлетворения требований передачи функций и данных. Во-вторых, несколько служб могут зависеть от одного и того же источника данных, например агрегация данных для отчетов. В этом случае, если мы просто полагаемся на вызовы интерфейса RPC, это может привести к случайным тайм-аутам вызовов, что приведет к большей вероятности сбоев. Затем распространенным способом решения этой проблемы является совместное использование данных либо для синхронизации данных за счет избыточности данных, а затем для агрегирования данных в границах на основе локальных служб; затем передача обработанных данных извне. В-третьих, более реалистичный вопрос стоимости. На самом деле, большее количество баз данных потребует больших капитальных затрат. Во многих случаях мы также будем рассматривать проблему со стороны затрат средств. Мы выбираем повторное использование исходных таблиц базы данных, ждем, пока бизнес-ценность станет ясной, а затем рассматриваем возможность создания отдельной независимой базы данных.
В то же время решения на основе технологий общих данных позволяют избежать дорогостоящей и повторяющейся миграции данных, когда контекст между данными неоднозначен, и упрощают настройку степени детализации службы при необходимости, а затем перенос данных после того, как степень детализации службы стабилизируется. Поэтому нам нужно найти правильный баланс между ними, максимально придерживаться общепринятого взгляда на микросервисы и в полной мере использовать преимущества микросервисов.
7. Гарантирует ли организация внедрение микросервисов?
Микросервисы выдвигают новые требования к организационной структуре: рекомендуется разделить большую команду на несколько небольших команд, и каждая команда будет работать, разрабатывать и эксплуатировать один или несколько сервисов, а также требует непрерывной доставки и непрерывного потока процессов.Развертывание, DevOps.
Разные сервисы могут разрабатываться и поддерживаться разными командами.В реальных сценариях удобство микросервисов больше заключается в том, что внутри команды может быть создан замкнутый цикл.Внешние команды несут большие затраты на общение и совместную работу. Как показано на рисунке, понимание Службы C Командой А — это черный ящик. Ограничение тока, предохранитель и деградация, стратегия и способ доступа. Если нам нужно подтвердить эти проблемы, обычно требуется сотрудничество и подтверждение со стороны человека.
Конечно, это неизбежная проблема, вызванная организационным разделением труда, поэтому мы делаем все возможное, чтобы обеспечить сплоченность сервисов внутри нашей собственной команды и разделить их по бизнес-модулям, чтобы микросервисы обладали бизнес-независимостью и целостностью. несколько сервисных зависимостей и цепных вызовов. Вот и вылезла новая проблема. Насколько «микро» являются микросервисы? На самом деле дробление сервисов не такое уж и мелкое, и даже крайний случай — дробить кусок функционала на сервис, что неправильно. Таким образом, гранулярность разделения должна гарантировать, что микросервисы обладают бизнес-независимостью и целостностью, а разделение сервисов основано на бизнес-модулях. Если бизнес-ценность/техническая ценность отдельных сервисов не ясна, то достаточно их связать в этой единой системе на протяжении всего жизненного цикла проекта. С развитием и потребностями бизнеса мы можем скорректировать структуру модулей на уровне исходного кода системы и разбить ее на независимые микросервисы.
Иногда команда полностью владеет проектом, поэтому микросервис в продакшене — это «полуфабрикат» из-за учета интересов команды. Автор считает, что данная ситуация не является исключением, а в подавляющем большинстве случаев является нормой. Теперь давайте рассмотрим случай. Команда А разработала «компонент взаимодействия», который включает функцию «модуль комментариев» с учетом возможности повторного использования функций. В этот момент команда Б разработала аналогичный «компонент взаимодействия» без их ведома. Это требование также предъявляется к команде С. Она знает, что у команды А есть этот «интерактивный компонент», и надеется повторно использовать его. , он не поддерживает функцию «создания комментариев», и, поскольку команда А не может оказать поддержку немедленно из-за прогресса других проектов, команда С решает потратить неделю после оценки на разработку «интерактивного компонента», который отвечает ее собственным бизнес-потребностям. . . . На этом этапе каждая проектная группа поддерживает «интерактивный компонент». В этом случае из-за ответственности и границ между командами возникают ограничения в повторном использовании сервисов и даже ситуация борьбы друг с другом, которая обычно требует планирования и координации на уровне компании. Так совпало, что и команда А, и команда Б работают над системой нарядов на работу, но их нужно интегрировать.Чтобы обеспечить существующие интересы двух команд, они не нарушили исходную структуру интеграции, а определили предметную область граница на исходной основе. .
Кроме того, предполагая, что внешний RPC-интерфейс нестабилен, общий подход заключается в анализе причин нестабильности, но в случае пересечения командной работы внешние службы могут быть черным ящиком, а команда может быть скрытой стеной. и сотрудничает очень много.В это время кому-то нужно прийти на полную ссылку, чтобы вести интересы всех. Затем наиболее эффективный способ обойти эту проблему — избежать ее внутри с помощью других средств, таких как избыточный кэш или адаптация интерфейса. Таким образом, это может быть лучший план для максимизации ценности бизнеса в текущей организационной структуре и в среде, нам нужно адаптироваться к будущему, с нетерпением ожидая будущего. Говоря об адаптации интерфейса, на самом деле существует очень распространенный дизайн микросервисной архитектуры: режим службы адаптера. В обычных условиях внешние сервисы дают нам формат сообщения и необходимую нам несогласованность.В это время мы заставим их трансформироваться, поэтому, чтобы защитить нашу бизнес-логику, не вводя много логики бизнес-адаптера, мы Адаптация Вводится уровень (служба адаптера), он преобразует тело сообщения внешней службы в единый стандартный формат, а затем предоставляет службу, такую как адаптация возврата, адаптация логистики и т. д.
Поэтому организация компании во многом влияет на определение границ обслуживания. Обычно мы делим поле в границах собственной команды, чтобы максимально удовлетворить бизнес-потребности.Хотя это и «полуфабрикат» с технической точки зрения, это может быть лучший способ максимизировать ценность бизнеса в Текущая среда План. Так называемая долгосрочная интеграция, когда все видят, что она имеет достаточную ценность, также является хорошей идеей рассмотреть возможность дальнейшей интеграции.
Написано последним голосом
Наконец, поговорим о внедрении новых технологий, чтобы принести проекту технические дивиденды. Новая технология должна учитывать стоимость обучения и обслуживания, а также гарантию доступности и работоспособности. Например, в сопровождении компании по эксплуатации и обслуживанию я легко могу использовать различные технологии и т.д. Однако я могу не рискнуть использовать MongoDB в другой компании, так как знаю, что не являюсь специалистом по эксплуатации и обслуживанию в этой области , Есть проблема, и я, возможно, не смогу ее решить. Тогда внедрение новой технологии может иметь технические риски. Часто мы проектируем, основываясь на неудачах, а это как раз и есть разрыв между младшими инженерами и старшими инженерами. Например, Redis реализует распределенные блокировки. Многие люди хотят только увидеть, как реализовать эту логику через код. Однако, если главная служба в кластере Redis зависает, переключитесь непосредственно на подчиненную службу, потому что асинхронная синхронизация master-slave и распределенная блокировка Важно то, что работают только последние данные блокировки, то есть они работают только в одно мгновение.В это время, если данные распределенной блокировки будут потеряны, ваш бизнес вызовет повторные запросы.Если применяется распределенная блокировка в бизнесе это должно быть Это очень важный сценарий, особенно в финансах и платежах, поэтому одноточечная версия распределенной блокировки Redis не является хорошим методом и не может быть использована.Если вы хотите использовать его, вам нужно решить проблему стабильности. (Цитируя случай, которым поделился автор «Чэн Чао» из «Highly Available and Scalable Microservice Architecture: Based on Dubbo, Spring Cloud and Service Mesh» в группе, что особенно интересно.) Здесь небольшое отступление, вернемся к тема, мы Часто можно обнаружить, что новые проекты пробуют новые технологии, в то время как старые проекты более консервативны, потому что первые менее затратны на пробы и ошибки. Интересно, что новые компании более чувствительны к развитию технологий, например, многие небольшие компании имеют множество практик и внедрений в облачных технологиях. К этому моменту вы, наверное, поняли высказанную мною точку зрения: обычно за использованием технологических стеков стоит гарантия компании эксплуатации и обслуживания, а также возможность контролировать глубину технологии. Поэтому нам необходимо заранее зарезервировать новые технологии, чтобы подготовиться к бою в любое время, но в большинстве случаев мы должны убедиться, что мы используем существующие технологии (инструменты) для максимизации ценности бизнеса.
Подводя итог, эта статья ускорила многое из того, что я видел и слышал, и практические размышления со времени моей работы.Основная точка зрения состоит не в том, чтобы критиковать микросервисы, а в том, чтобы заставить всех думать независимо, думать об архитектуре с точки зрения чистой технологии, и посмотрите на микросервисы.Услуги, чтобы обеспечить использование существующих технологий (инструментов) для максимизации ценности бизнеса.
напиши в конце
[Мышление на стороне сервера]: давайте поговорим об основных технологиях на стороне сервера, а также обсудим структуру проекта и практический опыт первой линии Интернета. Пусть все сотрудники отдела исследований и разработок, работающие в одиночку, найдут свой собственный круг для общения и совместного обсуждения. Здесь мы можем совершенствовать наше познание, общаться с ведущими технологическими гигантами, соединяться с превосходными способами мышления, соединяться с кратчайшим путем для решения проблем, соединяться со всеми превосходными методами и разрушать ограничения познания.
Еще больше интересных статей в разделе «Серверное мышление»!