Это захватывающее время - вы попадаете в Golang, вы только что написали свое первое приложение Hello World и прошли через A Tour of Go и действительно хотите приступить к работе с настоящими приложениями Go. Как и во всем, что связано с технологиями (и некоторые утверждают, что в жизни), возникает вопрос: Хорошо, с чего мне начать?
Если вы не хотите строить полностью с нуля (и, возможно, заново изобретать несколько колес), вы, вероятно, заглянули в готовые пакеты Go SDK (или фреймворки, или наборы инструментов, или просто наборы, как их часто называют). Это не значит, что отказаться от одного из них - плохая идея; на самом деле, во многих случаях лучше всего может быть раствор, произведенный в домашних условиях.
В этой статье будут рассмотрены три из доступных: Я недавно исследовал каждый из них в Интернете, и краткий ответ заключается в том, что у всех есть свои плюсы и минусы. Какой бы из них вы ни выбрали - или ни одного - во многом будет зависеть от вашего конкретного варианта использования.
В дополнение к некоторым моим общим заметкам по каждому из них, я также включу некоторые интернет-мнения, которые я нашел; как и все мнения в Интернете, воспринимайте их серьезно и вместо этого используйте их для создания приятной и сбалансированной общей картины, в которой вы можете с уверенностью сделать выбор для себя.
Перейти комплект
- "Веб-сайт"
- Разделение проблем (транспортный уровень, уровень конечной точки, уровень обслуживания)
- Низкоуровневые библиотеки
- Нет API-шлюза
- Нет требований к инфраструктуре
- Стремится быть непредубежденным
- Нет мнений по поводу эксплуатационных проблем, таких как развертывание, конфигурация, оркестровка и т. Д.
- Ориентирован на долгосрочную ремонтопригодность проекта
- Не ориентирован на быструю разработку приложений
- Набор рекомендаций о том, как структурировать микросервисы на уровне кода - A.K.A., чтобы проблемы микросервисов были «управляемыми».
- Создан на основе установленных практик, таких как Domain Driven Design (DDD), The Clean Architecture, Hexagonal Architecture.
- Помогает структурировать и развивать услуги и избегать распространенных ошибок
- Подходит как для микросервисов, так и для монолитов
- Поставляется с Prometheus / InfluxDB / и т. Д. служба поддержки
- Имеет собственный пакет логирования
- Поддержка обнаружения сервисов через Consul / etcd / etc.
- Стремится сделать Go привлекательным для своей организации.
- Балансировка нагрузки
Интернет-мнения
Заявленная цель Go Kit - сделать Go жизнеспособным вариантом для микросервисов бизнес-логики на современном предприятии. Это термин, который я придумал: я имею в виду такие компании, как SoundCloud, Spotify, Hailo, 37Signals, Bit.ly, Imgur, Secret, вплоть до действительно крупных организаций, таких как Netflix и Twitter. Это компании, которые в значительной степени ориентированы на потребителя, ориентированы на технологии и имеют стимулы для роста. Эти стимулы побуждают их идти на технологические риски, а когда эти риски окупаются, они задают тон индустрии программного обеспечения. Многие идеи, которые мы сейчас принимаем как должное, - например, неизменяемая инфраструктура, разработка / управление или функциональное реактивное программирование - обычно начинаются как эксперименты на современных предприятиях, подобных этим. Я хочу дать Go возможность стать такой же историей успеха.
Тем не менее, комплект Go разработан для уменьшения масштабирования. Если вы хакер и работаете над проектом в одиночку, комплект Go даст вам отличные возможности для начальной загрузки. Если у вас небольшая команда, у которой уже есть какие-то налаженные сервисы, комплект Go можно вставить вместе с ними без каких-либо серьезных изменений или сбоев.
- Питер Бургон, создатель Go kit
Я недавно начал работать с го-китом, который мне очень нравится. Его структура намного более гибкая, чем у Go-Micro. Мне также нравится многоуровневый подход к микросервисам. Единственным недостатком go-kit является то, что из-за интенсивного использования интерфейсов вам придется писать много шаблонного кода.
- / u / DerWaldermar, from r / golang
При использовании go-kit было очень заметно, что накладные расходы на добавление API в ваш сервис очень высоки. Вам нужно добавить много кода, который в основном является копипастом других API, и слишком много мест, где можно делать ошибки.
Чтобы добавить единый простой API, вы должны добавить:
а. Функция в интерфейсе (имеет смысл) b. Реализация (имеет смысл) c. Заводская функция конечной точки d. Транспортная функция e. Кодер запроса, декодер запроса, кодер ответа и декодер ответа. f. Добавьте конечную точку на сервер g. Добавьте конечную точку к клиенту.
Я думаю, что основная причина такой многословности - разделение уровней для бизнес-логики, конечной точки и транспорта, что хорошо и дает преимущества в красивых абстракциях для балансировки нагрузки на стороне клиента, разрыва цепи, трассировки и т. Д.
Но это трудно понять.
Если вы используете go-kit в качестве библиотеки сервисов REST, я рекомендую выучить наизусть следующую функцию ServerHTTP: только тогда вы действительно понимаете, как должен вести себя ваш сервис.
Оу :( Обожаю гоу-киты.
Во-первых, go-kit в значительной степени готов к производству и используется довольно большим количеством организаций.
Во-вторых, да, выкройки в go-kit немного сложны, особенно для новичков. Комплект Go использует интерфейсы и первоклассные функции, чтобы обеспечить очень чистый и компонуемый API.
interface{}i использовал в библиотеке только один раз, чтобы принять структуру запроса и ответа, которая должна быть предоставлена пользователем. Возможно,interface{}можно было бы избежать с помощью некоторой генерации кода, но я бы сказал, что использование пустого интерфейса здесь является разумным компромиссом.
Я довольно часто использовал go-kit за последние два года, создав несколько микросервисов, но в основном то, что я бы назвал хорошо структурированными монолитами. Использование go-kit приводит к созданию чистых, надежных и обслуживаемых кодовых баз. Я считаю этот рубиновый разговор хорошим примером некоторых идей, которые можно найти в кодовой базе go-kit.
Если кто-то хочет попробовать go-kit, http://gokit.io/examples/stringsvc.html - отличное начало. И, конечно же, канал # go-kit о слабине :)
- / u / gogroob, от r / golang, в ответ на предыдущую цитату
Также в облачной среде: сбор
Микро
- "Веб-сайт"
- Полный набор (и по сути «фреймворк») библиотек и инструментов.
- Микросервисы платформа, но не зависят от базовой среды выполнения (пользователи могут использовать Kubernetes, Mesos, Docker Swarm и т. Д.)
- Имеет дашборд и интерфейс командной строки
- По умолчанию использует consul для регистрации / обнаружения сервисов, но подключается к другим сервисам, Kubernetes service discovery, ZooKeeper и т. Д.
- Помогает также в общении между сервисами
- Умышленно самоуверенный
- Имеет собственный API-шлюз (Micro Go-API)
- Богатая экосистема плагинов
- Паб / саб первоклассный гражданин
- API, отличный от gRPC, требующий собственной экосистемы
Интернет-мнения
У нас в разработке находится около 15 микросервисов на основе go-micro, и я очень рекомендую это.
Изначально это поможет вам справиться с обнаружением сервисов, взаимодействием сервиса с сервисом, а также легко добавить функции pub-sub.
Экосистема плагинов очень богата и с ней легко работать.
Наконец, автор очень отзывчивый и очень полезный.
- / u / alex_bilbie, из r / golang
Одна из основных причин, по которой мы выбрали микрокомпьютер, а не набор для игры, заключалась в том, что с ним действительно легко начать работу. Достаточно взглянуть на огромное количество кода в качестве простого примера. Кроме того, у micro есть репозиторий, заполненный примерами, которые были весьма полезны при изучении фреймворка.
Когда мы начали больше использовать фреймворк, нам понравилась возможность расширения. Это позволяет нам, например, легко переключаться между обнаружением служб consul и Kubernetes в зависимости от среды приложения. Мы предпочитаем использовать consul localhost (сборка и развертывание в Kubernetes локально может занять много времени), и мы не хотели также запускать кластер consul в нашей настройке kube. Работает неплохо!
Отказ от ответственности: я изучал (и все еще учусь) Go, поэтому вы должны иметь в виду, что сравнение более опытного разработчика Go может быть более ценным.
Наконец, о поддержке сопровождающего ходят легенды. Я открыл проблему для одного из плагинов, и хотя нам пришлось сначала пройти через несколько пользовательских ошибок, мы в конечном итоге обнаружили проблему с фреймворком, которую он исправил очень быстро. На протяжении всего процесса он был терпелив со мной, четко объясняя, что я сделал не так, плюс отвечал каждый раз в течение нескольких минут.
Просто хотел поблагодарить этого парня, он этого заслуживает, и его вещи определенно стоит проверить!
- / u / Arisnotle_, из r / golang
Я использовал микро. Не рекомендую. Документация - это в основном исходный код. Ошибки странные. API настолько отличается от grpc, что ему нужна собственная экосистема. Не говоря уже об одном случае, когда они сломали весь API - получайте удовольствие, переписывая 30 конечных точек в соответствии с новым API.
- / у / гнгеоргиев, из р / голанг
Хотя go-micro отлично подходил для создания инфраструктуры go-only, он становился беспорядочным, когда вы вводили другой компонент на другом языке (например, NodeJS). Мне очень нравятся идеи, лежащие в основе go-micro, но я думаю, что это сработает только в том случае, если вы собираетесь писать все свои микросервисы на micro.
- / u / DerWaldermar, from r / golang
Что ж, я предвзято, так как написал микро, но я совершенно искренне верю, что если вы изо всех сил пытаетесь выбрать «фреймворк», вы должны просто использовать net / http или net / rpc и сконструировать минимум того, что вы пытаетесь сделать. делать.
Все сводится к ... почему вы хотите использовать микросервисную архитектуру? Как вы думаете, почему это будет полезно для вас? Если вы не можете ответить на этот вопрос, значит, вам не нужны микросервисы. Какие функции вам нужны для микросервисов? Что вам нужно от фреймворка для разработки? Что вам нужно от среды выполнения или платформы? Вы должны уметь ответить на эти вопросы, чтобы сделать выбор. Если вы не можете, то я искренне верю, что главное - придерживаться основ. Когда я создаю сторонние проекты, я все еще начинаю с net / http или net / rpc и создаю монолитное программное обеспечение.
Штуковина
- Веб-сайт (то есть GitHub; специального веб-сайта нет)
- Создатель и инженер для The New York Times, JP Robinson, не захотел ждать Go-kit и решил начать с NY Times потребности
- Стандартизированная конфигурация и ведение журнала
- Конечные точки проверки работоспособности
- Попытки справиться с нецелевыми задачами Го-кита
- Повторно реализует функциональность вместо обертывания существующих пакетов
- Поддерживает шаблоны обмена сообщениями, отличные от RPC
- JSON через HTTP
- pub / sub услуги / реализации для SNS / SQS и Kafka
- Имеет мнения по надзору за процессом
- Не слишком самоуверенный
Интернет-мнения
NY Times экспериментирует с го с самого начала, что дает их разработчикам на несколько лет больше опыта (я полагаю), чем у большинства сусликов прямо сейчас.
Так что, на мой взгляд, Gizmo находится где-то между Go Micro и Go Kit. Это не полный «черный ящик», как Go Micro. В то же время он не такой сырой, как Go Kit. Он предоставляет компоненты сборки более высокого уровня, такие как пакеты config и pubsub.
Ни один из вышеперечисленных
Стандартный совет, который мы даем новичкам: не [выбирайте фреймворк]. Начните со стандартной библиотеки net / http. Это намного лучше, чем эквивалент на большинстве других языков. Вы будете удивлены, насколько далеко это вас зайдет. Если и когда вы обнаружите, что у вас есть конкретная потребность, которая не решается должным образом с помощью stdlib (например, расширенное мультиплексирование), найдите конкретную библиотеку, которая решает эту конкретную проблему (например, gorilla / mux).
Фреймворки могут быть хорошими, но за них приходится платить. Ваш код часто перестает так хорошо взаимодействовать с библиотеками за пределами фреймворка, вы втягиваете множество зависимостей, которые на самом деле вам не нужны, вы даже можете в конечном итоге написать шаблон для поддержки функций, которые вам не нужны. Начав со стандартной библиотеки и обращаясь только к сторонним библиотекам для решения конкретных проблем, вы сохраните свой код компактным, средним и гибким.
Если вам нужен сторонний код, обратите внимание на https://github.com/avelino/awesome-go/blob/master/README.md#web-frameworks.
- / u / PsyWolf на г / голанге
Каждый сторонний пакет, который вы используете, - это еще одна зависимость, которую необходимо отслеживать и управлять. Go немного более склонен делать что-то самостоятельно и избегать еще одной зависимости (во всяком случае, IMO).
- / u / random_jls на r / golang
Выводы
В то время как в Интернете есть множество пользователей, которые высказывают свое мнение относительно их конкретных вариантов использования, лучшее, что вы можете сделать, - это прочитать соответствующие веб-сайты и документацию, чтобы дополнить анекдотический опыт. То, что вы в значительной степени хотите решить, будет зависеть от того, чего именно вы хотите достичь, и вы можете просто выбрать фреймворк, попробовать его немного и посмотреть, не понравится ли он вам (то есть, если у вас есть такая роскошь. время и усилия). Во многих случаях вы можете просто обойтись без набора или фреймворка и просто поработать с нуля со своими пользовательскими реализациями, используя при желании пакеты.
Надеюсь, я собрал некоторую информацию, чтобы помочь вам принять такое решение, но учтите, что это лишь поверхностная сторона вопроса, на который будет сложный ответ.
