предисловие
Можно сказать, что с развитием архитектурного проектирования микросервисная архитектура стала самой популярной концепцией дизайна в области архитектуры. В компании автор также отвечал за сервисное проектирование и разработку системы.
Сегодня поговорим о некоторых проблемах в реализации микросервисов. Я надеюсь, что он может послужить справочным материалом для друзей, которые не имеют ни малейшего представления о дизайне микросервисов; я также надеюсь поделиться своими взглядами и с нетерпением жду возможности пообщаться с вами, чтобы мы могли выявить недостатки.
1. Разделение услуг
Прежде чем внедрять микросервисы, первый вопрос, с которым мы столкнулись, был: как нам разделить сервисы?
Как вы знаете, единого правила разделения услуг не существует. Тем не менее, есть несколько элементов, на которые мы можем ссылаться.
1, независимость бизнеса
В общем, будем учитывать это в первую очередь. Бизнес-модули в системе идентифицируются в соответствии с их обязанностями, и каждый отдельный модуль разделен на независимую службу.
После этого разделения наши услуги должны соответствовать принципу: высокая сплоченность и низкая связанность.
Например, мы разделяем систему на товарные службы, службы заказов и логистические службы. При нормальных обстоятельствах, когда мы модифицируем логистическую службу, это не повлияет на товарную службу, которая является воплощением низкой связанности; тогда функции и логика в службе заказов полностью связаны с основным бизнес-процессом заказа, который может быть говорят, что это очень сплоченный.
2. Стабильность бизнеса
Мы можем различать бизнес в системе по стабильности. Например, в части регистрации и входа пользователя, в нашей системе, пока код этой части написан, он в принципе не изменится, поэтому я разобью их на пользовательские сервисы.
Точно так же есть службы журналов и службы мониторинга, Эти модули в основном являются очень стабильными бизнесами и могут рассматриваться отдельно.
3, надежность бизнеса
Суть здесь в том, чтобы отделить основные службы с высокими требованиями к надежности от неосновных служб с низкими требованиями к надежности, а затем сосредоточиться на обеспечении высокой доступности основных служб.
Избегайте влияния на основные службы из-за сбоев неосновных служб.
4. Эффективность бизнеса
Основываясь на разделении производительности бизнеса, рекомендуется разделить модули с высокой нагрузкой на производительность. У меня две мысли по этому поводу:
- Избегайте влияния служб с высокой производительностью на другие службы.
- Бизнес с высокой посещаемостью изолирован, и он удобен для горизонтального расширения, если его нельзя нести.
Например, в системе, в которой участвовал автор,RocketMQПодключайтесь к большому объему данных от разных производителей.
В то время была создана независимая служба сообщений, предназначенная для потребления сообщений. Потом часть обрабатывается локально, часть черезRPCИнтерфейс пересылается другим службам для обработки, некоторые напрямую черезWebSocketНажмите на интерфейсный дисплей.
В этом случае, даже если трафик резко возрастет, рассмотрите возможность добавления компьютеров в службу сообщений, чтобы увеличить потребляемую мощность.
Когда мы поймем приведенные выше методы разделения, мы сможем рассмотреть разделение услуг нашей собственной системы в соответствии с масштабом нашего бизнеса и размером технической команды.
5. Слишком поздно
Однако здесь особенно стоит отметить, что микросервисы не следует делить слишком мелко, а нужно сочетать с масштабом бизнеса и масштабом технической команды.
Автор уже сталкивался с проектом.В процессе сервис-ориентированного ответственный на тот момент технический специалист разделил сервисы в соответствии с бизнес-независимостью, в результате было разделено около 10 сервисов;Serviceслой иControllerУровни разделены, и каждый бизнес-метод необходимо вызывать удаленно. Согласно описанию сторон, это должно облегчить последующее расширение возможностей расширения.
Но если честно, некоторые системы не имеют такого большого объема бизнеса, и слепое угождение микрословам в микросервисах, несомненно, увеличит сложность для себя и разрушит стабильность всей системы. Поэтому после реорганизации бизнес-процесса автор реконструировал систему для уменьшения количества сервисов.
Здесь я хотел бы уточнить один момент.Serviceслой иControllerСлои можно разделить на несколько модулей, это не имеет значения. Однако это должно быть только разделение модулей, а не сервисов. Например, мы можем разделить их на несколько модулей на этапе разработки, а затем передатьMaven modulesОбъединенные вместе, они по-прежнему представляют собой службу на этапе развертывания и эксплуатации.
2. Технический отбор
Когда разделение сервисов будет завершено, какой фреймворк следует использовать для разработки?Dubbo 还是 SpringCloud ？
Автор не хочет просто обсуждать их преимущества и недостатки, и здесь я могу поделиться мысленным путешествием автора по этому вопросу.
1. Весеннее облако
При первоначальном выборе я выбралSpringCloud, в конце концов, он претендует на роль универсального решения для микросервисов. Затем создайте фреймворк, интегрируйте различные компоненты и завершите демо-разработку и тестирование.
Однако, проделав эту часть работы, пересмотрев всю систему, см.SpringCloud, с привлечениемEureka、Ribbon、Feign、Hystrix、Zuul、Configэти компоненты.
На данный момент у меня два вопроса:
- Нужны ли эти компоненты? Есть ли более легкое системное решение?
- Так много вещей, у меня есть проблема, мы можем держать удержание?
автор для一站式Это слово имеет два слоя понимания. Во-первых, он упрощает разработку инфраструктуры распределенной системы и прост в разработке, во-вторых, упрощая, он должен скрывать сложные принципы конфигурации и реализации, и глубоко понять его принципы непросто.
Как архитекторы или технические руководители групп, мы должны иметь четкое представление о технических моментах, задействованных в нашей системе, или, по крайней мере, понимать их принципы. Таким образом, даже если вы столкнетесь с проблемами, вBaidu / GoogleНе паникуйте, когда нет результата.
2. Даббо
Исходя из этой идеи, автор обратил внимание наDubbo. Для автора даDubboОн более привычный.Из самого его фреймворка реализована балансировка нагрузки и кластерная отказоустойчивость, а способ вызова тоже основан на интерфейсе. СравниватьSpringCloudС точки зренияRibbon/Feignтакие компоненты.
Еще один момент,Dubboблагодаря мощномуSPIмеханизм, мы можем расширить его очень удобно. Если есть потребность в бизнесе, его можно расширить во многих местах, таких как протокол RPC, кластер, реестр, сериализация, пул потоков и т. д.
Но опять же,DubboПросто высокопроизводительный фреймворк RPC, возьмите его иSpringCloudПо сравнению, больше все еще сравнениеREST和RPC. Однако на данный момент это только общий проект, этой разницы в производительности недостаточно для окончательного решения, в лучшем случае это просто вишенка на торте.
3. Безопасность прежде всего
Что касается других компонентов, таких какHystrix/Zuul/Config/zipkinПодождите, точка зрения автора зависит от масштаба бизнеса. Микросервисы — это просто дизайнерская идея, архитектурная концепция, а не микросервис, использующий множество распределенных фреймворков. Генерация этих фреймворков предназначена только для решения проблем, с которыми сталкивается микросервисная система.
Вы должны знать, что вы не можете сделать толстяка одним укусом.Выбирая технологию, не забывайте напрямую ориентироваться на опыт крупных производителей, таких как Ali, JD.com и Meituan.В результате мы можем не столкнуться таких бизнес-сценариев Нет такого кадрового резерва. Ведь если в сети что-то пойдет не так, никто не разделит с вами потери.
В общем, все равно необходимо удовлетворять потребности бизнеса наиболее стабильным техническим решением, исходя из собственной реальной ситуации.
3. Внеузловые ветви
После разделения сервиса и завершения подбора технических решений, тогда все будет хорошо.Вы начали программировать? Если вы просто разработчик, у вас все будет хорошо. Если вы отвечаете за систему, вас устраивает только строительство многоэтажки без учета деталей, это неизбежно приведет к дополнительным проблемам.
1. Тайм-аут и отказоустойчивость
После сервисизации вызовы между различными сервисами являются удаленными вызовами. Самая основная настройка для удаленных вызовов — тайм-аут.
Например, вDubbo, время ожидания по умолчанию составляет 1 секунду. Мы не можем просто использовать значение по умолчанию или единообразно установить другое значение дляDubboЛучше всего установить период тайм-аута целенаправленно.
Например, для относительно простого бизнеса можно установить более короткое время, а для сложного бизнеса это время нужно соответствующим образом увеличить. Потому что есть еще проблема отказоустойчивости кластера.
существуетDubbo, политикой по умолчанию для отказоустойчивости кластера является повторная попытка в случае сбоя с номером 2. Если какое-то дело само по себе требует много времени для выполнения из-за слишком короткого времени ожидания, механизм отказоустойчивости будет запущен для повторной попытки. Большое количество одновременных повторных запросов, которые могут быть заполненыDubboПул потоков влияет даже на серверную систему базы данных, вызывая исчерпание соединений.
2. Устойчивость к неисправностям и идемпотентность
Как мы уже говорили выше, если время ожидания установлено слишком коротким, это может привести к непрерывному повторному выполнению большого количества запросов, что приведет к возникновению исключений.
Здесь скрыта еще одна деталь, а именно запросы на чтение и запросы на запись. Если это запрос на чтение, то повтор не имеет значения, если это запрос на запись, поддерживает ли наш интерфейс автоматический повтор? Это повлечет за собой проблему идемпотентности интерфейса.
Если интерфейс запроса на запись не поддерживает идемпотентность, то отказоустойчивость кластера необходимо изменить наfailfast, т. е. быстро выходят из строя.
3. Распределенные транзакции
Автор считает, что распределенные транзакции — это техническая проблема, до конца не решенная в отрасли. Не существует универсального решения, а также эффективного и простого способа сделать это.
Тем не менее, мы должны принять это во внимание заранее, иначе данные обязательно запутаются.
Прежде чем рассматривать решения, нам нужно убедиться, что наша система действительно стремится к строгой согласованности.BASEТеоретически в распределенной системе есть задержка в процессе синхронизации разных узлов, но после периода ремонта может быть достигнута окончательная согласованность данных.
На основе этих двух идей мы можем сформулировать собственную схему распределенных транзакций.
Для сценариев, требующих строгой согласованности, можно рассмотреть протокол XA, что гарантируется двухэтапной или трехэтапной фиксацией.
Для сценариев, требующих окончательной согласованности, можно рассмотреть режим TCC, режим компенсации или режим на основе очереди сообщений.
Например, на основе режима очереди сообщений вы можете использоватьRocketMQ. Он поддерживает сообщения о транзакциях, поэтому весь процесс на данный момент, вероятно, выглядит так:
- пройти через
RocketMQОтправка сообщений о транзакциях в очереди сообщений; - Если сообщение отправлено успешно, выполняется локальная транзакция;
- Зафиксировать, если локальная транзакция выполняется успешно
RocketMQСообщения о транзакциях, видимые потребителям после отправки; - Удалить, если выполнение локальной транзакции не удалось
RocketMQСообщения о транзакциях, потребители не увидят это сообщение.
К тому же тут Amway под али с открытым исходным кодомSeata. Последняя версия — 1.1.0, которая поддерживает несколько режимов транзакций, таких как режимы транзакций AT, TCC, SAGA и XA.
У автора есть статья на основеSeata 0.7Версия написана, и заинтересованные друзья могут о ней узнать.
SpringBoot+Dubbo+Seata распределенная битва транзакций
4. Очередь сообщений
В распределенной системной архитектуре для разделения и асинхронной обработки между системами, а также для работы с высокой степенью параллелизма и большим трафиком очереди сообщений, безусловно, являются отличным инструментом.
Прежде чем использовать этот инструмент, мы также должны рассмотреть проблемы, которые могут быть вызваны очередями сообщений.
Первое, что нужно учитывать, это доступность.Если очередь сообщений недоступна, не вызовет ли это большую недоступность самой системы;
Тогда не потеряется ли сообщение? Как обеспечить надежную передачу сообщений? Например, необходимо рассмотреть механизм очистки и синхронизации самой очереди сообщений, подтверждение при отправке данных и отправку после потребления;
Затем идет повторное потребление.Если гарантировано, что сообщение не будет потеряно, то может быть проблема повторных сообщений более или менее.В это время необходимо учитывать, есть ли проблема с повторным потреблением, т.е. , идемпотентность сообщений;
Кроме того, проблема порядка сообщений, есть ли проблема порядка сообщений в вашем бизнес-сценарии, если есть эта проблема, либо избегайте ее во время проектирования, либо обеспечьте ее порядок во время потребления.
5. Единый журнал
При разделении микросервисов система ведения журналов также может развиваться в виде отдельных модулей. Чтобы просмотреть журнал, нам может потребоваться войти на разные серверы один за другим, чтобы увидеть.
Поэтому создание единой платформы обработки бревен неизбежно. Мы можем использоватьELKрешение для агрегации журналов.
Здесь также требуется проблема слежения за ссылками. В сложных цепочках вызовов микросервисов обнаружить и отследить проблемы сложнее, чем в монолитных приложениях.
Для этой проблемы мы рассматриваем возможность введения распределенной цепочки вызовов для создания глобально уникальногоTraceID, посредством которого вся цепочка вызовов связывается вместе. В сочетании с фреймворком Dubbo мы можем реализовать собственныеFilter, используется для прохождения через этоTraceID.
Для конкретных идей, пожалуйста, обратитесь к:SpringBoot + Dubbo интегрированный бой ELK
Конечно, мы также можем выбрать некоторые зрелые фреймворки с открытым исходным кодом для решения этой проблемы.
Суммировать
В этой статье кратко излагаются некоторые вопросы, которые могут возникнуть в процессе проектирования и разработки микросервисов.
Вышеприведенные мнения - это только слова одной семьи и только обобщение опыта автора за прошедшее время.
Если это полезно для вас, пожалуйста, поставьте лайк и поддержите ~ Если у вас разные мнения, пожалуйста, говорите активно и общайтесь друг с другом ~