Обсуждение:Микросервисы

Эта статья имеет рейтинг Start-class по шкале оценки контента Википедии . Она представляет интерес для следующих WikiProjects :

Вычислительная техника Эта статья находится в рамках WikiProject Computing , совместных усилий по улучшению освещения компьютеров , вычислений и информационных технологий в Википедии. Если вы хотите принять участие, посетите страницу проекта, где вы можете присоединиться к обсуждению и увидеть список открытых задач.Вычисления Википедия:WikiProject Computing Шаблон:WikiProject Computing ??? This article has not yet received a rating on the project's importance scale. Internet This article is within the scope of WikiProject Internet, a collaborative effort to improve the coverage of the Internet on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.InternetWikipedia:WikiProject InternetTemplate:WikiProject InternetInternet ??? This article has not yet received a rating on the project's importance scale.

Полный жаргон. Я ничего не узнал, прочитав это. #layperson — Предыдущий неподписанный комментарий добавлен 68.132.20.182 (обсуждение) 13:55, 15 ноября 2017 (UTC) [ ответить ]

Сейчас 2024 год, и я все еще согласен с этим комментарием. Особенно раздел критики, отправленный для того, чтобы дать понять, что читатель много знает о проектах микросервисов и участвовал в них. Mstachowsky ( talk ) 10:56, 10 августа 2024 (UTC) [ ответить ]

Согласен Ник Левин ( обсуждение ) 21:22, 28 июня 2018 (UTC) [ ответить ]

Согласовано -- 146.233.0.202 ( обсуждение ) 00:29, 1 октября 2021 (UTC) [ ответ ]

Итак... микросервисы не зависят от языка, но в то же время у нас есть раздел для языков.

-- K0zka ( обсуждение ) 12:02, 11 марта 2015 (UTC) [ ответить ]

Определение SOA в Википедии не предполагает, что оно направлено на интеграцию различных бизнес-сервисов. Toddinpal ( обсуждение ) 14:25, 12 августа 2015 (UTC) [ ответ ]

Мы читаем: Этот тип сложности можно уменьшить, стандартизировав механизм доступа. (это бесспорно, поскольку обратное утверждение было бы, что нестандартизация механизма доступа не изменит сложность ... и затем следует нелогичное заключение) Веб как система очень хорошо справляется с этим элементом. Он сохранил по сути тот же механизм доступа между браузером и ресурсом приложения за последние 20 лет. Используя количество веб-страниц, индексированных Google, он вырос с 26 миллионов страниц в 1998 году до примерно 60 триллионов отдельных страниц к 2015 году без необходимости менять свой механизм доступа. Сам Веб является лучшим примером того, что сложность, присущая традиционным монолитным программным системам, может быть преодолена.

Вовсе нет. Веб — это не набор микросервисов. В основном это набор страниц, которые не взаимодействуют (иногда они взаимодействуют, но это редкость, и когда вы хотите пойти этим путем, книги размером с телефон о «оркестровке сервисов», едва разработанная база знаний, ударят ваш стол большим пальцем). Или, говоря иначе, библиотека — это не компьютер (возможно, это сервис). Книга — это не микросервис (возможно, это результат запроса). У вас на кухне есть T101 ( обсуждение ) 09:56, 2 сентября 2016 (UTC) [ ответить ]

Что такое Buzzwords? Спасибо за ваш вклад — Предыдущий неподписанный комментарий добавлен BalintM ( talk • contribs ) 08:35, 6 апреля 2017 (UTC) [ ответить ]

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

Я уверен, что есть и другие ранние примеры разделения больших объемов работы между небольшими службами для достижения большей простоты, пропускной способности и/или других преимуществ. N-ateAbility ( обсуждение ) 16:20, 25 сентября 2017 (UTC) [ ответ ]

Менее чем через год после того, как Питер Роджерс придумал термин «микровеб-сервисы», Microsoft выпустила Windows Communication Foundation (WCF) как часть .NET 3.5 (выпущен в ноябре 2006 г.) ^[1] . Таким образом, WCF стал одним из первых фреймворков, на котором разработчики могли легко реализовывать сервисно-ориентированные архитектуры. По замыслу WCF абстрагирует транспортный уровень от модели программирования, позволяя использовать «веб-сервисы» как один из многих вариантов.

Juval Lowy был основным участником создания WCF, и его последующая работа в коде для расширений WCF и примеров, а также книги и лекции внесли огромный вклад в принятие WCF. Презентация Lowy 'Every Class as a WCF Service' ^[2] определенно описывает, как реализовать идею Питера Роджера в коде.

Микроядра (или, скорее, операционные системы на основе микроядер) представляют собой микросервисы, применяемые к ядрам (с дополнительной сложностью пространства пользователя по сравнению с пространством ядра) (они также появились намного раньше всего, что упоминалось в разделе истории). (Ядро разделяется на небольшое микроядро и целый набор демонов для драйверов, файловых систем, сетей и т. д.). 154.117.159.18 ( обсуждение ) 06:28, 10 сентября 2018 (UTC) [ ответить ]

Подход тот же, да. Однако микросервисы — это все о конструкциях прикладного уровня. То, что модель атома Бора визуально напоминает Солнечную систему, не означает, что эти две концепции одинаковы. В этом случае микросервисы и микроядра решают два разных набора проблем, имеют совершенно разные характеристики и работают в разных масштабах вычислений. Микроядра используются для поддержки одного экземпляра операционной системы. Микросервисы могут быть распределены по многим. По-настоящему параноидальный андроид ( talk ) 16:24, 21 декабря 2018 (UTC) [ ответить ]

Я полностью согласен с этим Марвином. Я удалил ссылку See Also: на микроядро Википедии . У оригинального редактора был этот URL в комментарии "https://www.yogeshgaikwad.com/2016/01/06/microkernels/", который делает попытку, подобную аргументу выше, и может иметь смысл на этой странице. Однако статья Википедии не дала бы никакого контекста о See also . В основной статье отмечается, что микросервисы используют сетевое взаимодействие, которое микроядро никогда не использует. 45.72.155.93 (обсуждение) 18:06, 15 августа 2019 (UTC) [ ответить ]

@ Marvin The Paranoid : попросил меня объяснить, почему я добавил template:unreliable sources . Прошу прощения, я должен был сделать это, когда добавлял тег.

Как один из многих примеров, статья использует декоративную цитату из Роберта Аннетта, но не объясняет, кто этот человек или почему его точка зрения имеет энциклопедическое значение. Источником является эта ссылка: http://www.codingthearchitecture.com/2014/05/01/where_is_the_complexity.html, которая не демонстрирует репутацию проверки фактов и точности, требуемой рекомендациями Википедии по надежным источникам . Сайт, по-видимому, является блогом Саймона Брауна (кого?), но блоги, как правило, не являются надежными источниками согласно WP:SPS .

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

Используется много, много похожих источников, но, надеюсь, эти примеры демонстрируют проблему. Людям, знакомым с темой, хочется добавить информацию, которую они лично знают как истинную, а затем искать источники для подтверждения своих предыдущих предположений, но это обычно ошибка. Вместо того, чтобы полагаться на блоги — даже корпоративные блоги — статья должна опираться на надежные, независимые источники от известных издателей, возможно, дополненные самостоятельно опубликованными комментариями признанных экспертов с четкой атрибуцией в очень редких случаях. Grayfell ( обсуждение ) 04:28, 21 декабря 2018 (UTC) [ ответ ]

@ Grayfell : - Я сделал несколько переписываний, которые, как я думаю, должны решить ваши проблемы. Пожалуйста, просмотрите и дайте мне знать, что вы думаете Действительно параноидальный андроид ( обсуждение ) 16:09, 21 декабря 2018 (UTC) [ ответить ]

Я ценю всю тяжелую работу, которую вы вложили в статью. Однако я все еще вижу некоторые очень сомнительные источники. На первый взгляд я вижу, что самостоятельно изданная книга Лукаса Краузе все еще цитируется со ссылкой на Amazon. Являются ли сообщения в блогах innoq.com, buoyant.io и microservices.io надежными источниками? Я также скептически отношусь к презентациям InfoQ.com. Есть несколько ссылок на martinfowler.com. Если мы признаем, что Мартин Фаулер является экспертом, его блог следует использовать для его мнения с указанием источника, а не для простых утверждений фактов. Подробнее об этом см. в WP:CONTEXTMATTERS .

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

Часть этого по сути является спамом и должна быть удалена. Если информация жизненно необходима, но не подкреплена надежным источником, можно добавить тег template:cn до тех пор, пока не будет найден надежный источник. Если информация просто полезна, редакторы должны быть готовы рассмотреть возможность ее удаления. Существует большое количество нишевых блогов и отраслевой тенденциозности для технологического сектора, поэтому нам нужно фильтровать соответствующим образом и понимать, что то, что может показаться полезным одному читателю (или одному блогеру), будет отвлекать другого. Редактирование требует сдержанности. Grayfell ( обсуждение ) 00:28, 22 декабря 2018 (UTC) [ ответить ]

Спасибо за отзыв. Я думаю, что ваш отзыв о Мартине Фаулере можно легко рассмотреть. Некоторые другие сложнее рассмотреть. Как практикующий специалист в этой области, я считаю, что информация, представленная здесь, основанная на этих источниках, является точной. Однако трудно доказать, что их мнение нужно уважать, поскольку это настолько новая область, и сообщество все еще развивается. Сегодня в отрасли наблюдается сдвиг. Очень немногие люди, разбирающиеся в своих новых развивающихся областях, берут на себя труд публиковаться в более традиционных журналах, потому что гораздо проще публиковать свои мнения и делиться знаниями через блог. Политика WP, похоже, не отражает эти изменения в отрасли, поэтому я думаю, что мои руки могут быть связаны. Действительно параноидальный андроид ( обсуждение ) 17:17, 22 декабря 2018 (UTC) [ ответ ]

Пользователь:Pooyanjamshidi также недавно ввел ссылки на свои собственные статьи (или, по крайней мере, один из авторов статьи совпадает с именем пользователя в Википедии). Это действительно похоже на приличные источники, хотя, кажется, есть четкий WP:COI . (Весь раздел "Шаблоны" также основан на этом) MoHaG ( обсуждение ) 09:53, 22 декабря 2018 (UTC) [ ответ ]

Согласен. Но что нужно изменить в статье? Достаточно ли добавить тег COI на этой странице (обсуждение)? Настоящий параноидальный андроид ( обсуждение ) 17:17, 22 декабря 2018 (UTC) [ ответить ]

Я пропустил это. Когда редактор добавляет ссылки на свои собственные ненадежные источники, это неотличимо от спама. Я отменил эти правки. Такой вид саморекламы несовместим с целями Википедии. Grayfell ( обсуждение ) 00:31, 23 декабря 2018 (UTC) [ ответить ]

@ Grayfell : - возможно, я неправильно истолковываю историю изменений здесь, но мне кажется, что вы удалили ссылку на статью IEEE как часть ваших изменений и оставили ссылку на статью из eventuate.io . Это кажется странным. Кроме того, если ссылка на статью IEEE - это то, что @ MoHaG : имел в виду в отношении COI, я также не согласен с вашей оценкой. Публикации IEEE - это уважаемый и рецензируемый набор публикаций, и это не спам, если автор статьи IEEE ссылается на свою работу. Вы, кажется, говорите, что если бы я прочитал статью и дал на нее ссылку, это было бы приемлемо, но ссылка автора на нее - это спам, даже несмотря на то, что ссылка ведет на очень авторитетный источник. Это может быть COI, как было указано, но похоже, что ваши действия не поддерживаются политикой WP, на которую вы ссылались в этом случае.

Я заметил, что на данный момент кто-то другой (чей идентификатор немного похож на другого автора статьи IEEE) удалил ссылку eventuate.io, удалил вторую ссылку IEEE и восстановил ссылку IEEE, которую вы удалили. Вздох. Настоящий параноидальный андроид ( talk ) 19:41, 23 декабря 2018 (UTC) [ ответить ]

Как вы уже сказали, это, в некотором роде, новая и нишевая тема. Статьи, связанные с "cutting edges", как правило, имеют проблемы с источниками WP:PRIMARY . Это пересекается с темами, связанными с бизнесом и технологиями, поэтому меня не удивляет, что в этой статье есть эта проблема.

Я утверждаю, что это проблема, когда единственная деятельность редактора здесь заключается в том, чтобы включать свои собственные работы в качестве ссылок. Взятая отдельно, такая правка может показаться приемлемой, но как шаблон, она значительно усложняет для нейтральных редакторов установление WP:DUE . Все источники должны оцениваться в контексте , и источник, который надежен в одном контексте, не является автоматически надежным в другом. Если вы прочитали источник и считаете его полезным, не стесняйтесь резюмировать его в статье (возможно, с указанием источника, чтобы читатели могли оценить источник самостоятельно). Бремя по-прежнему лежит на том, кто его добавляет, чтобы резюмировать его нейтрально и пропорционально микросервисам как более крупной теме. Рецензируемый источник — это хорошо. Как нейтральный редактор, вы не будете WP:SELFCITING , и ваша оценка источника может считаться дополнительным слоем рецензии. Самоцитирование вредно, когда это единственный мотив редактора, потому что, во-первых, оно имеет тенденцию перерастать в обсуждения, подобные этим, вместо обсуждения содержания. Что еще важнее, автор статьи не является беспристрастным судьей того, насколько важна эта статья для более широкой темы. «Частично» не означает «неправильно», и такой редактор все еще может действовать добросовестно, но это все равно большой риск, особенно для такой статьи, которая и так имеет множество связанных проблем.

О, и еще, template:ping работает только если он добавлен одновременно с подписью, к вашему сведению. Grayfell ( обсуждение ) 22:36, 23 декабря 2018 (UTC) [ ответить ]

@ Grayfell : - похоже, новый пользователь без других вкладов / sockpuppet только что удалил тег «Ненадежные источники». Это был не я. Я предоставлю вам решать, нужно ли это вернуть или оставить как есть. Настоящий параноидальный андроид ( обсуждение ) 22:26, ​​2 января 2019 (UTC) [ ответить ]

Не знаю, но какое-то объяснение было бы разумным, верно? Grayfell ( обсуждение ) 22:35, 2 января 2019 (UTC) [ ответить ]

Есть раздел «Критика», но мне не хватает раздела «Преимущества» Tech201805 ( обсуждение ) — Предыдущий недатированный комментарий добавлен 07:27, 9 апреля 2019 (UTC) [ ответить ]

Анонимный пользователь 27.03.2019 отметил эту статью как написанную как реклама. Я не вижу обсуждения на этой странице или какого-либо объяснения тега. Я могу только заключить, что это вандализм, и удаляю это. Действительно параноидальный андроид ( обсуждение ) 14:59, 8 июня 2019 (UTC) [ ответ ]

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

Статьи энциклопедии должны предоставлять обзор читателю, который еще не знаком с конкретной темой. Если это невозможно по какой-то причине, она должна, по крайней мере, предоставлять читателям ресурсы, чтобы они могли «догнать» тему достаточно, чтобы вернуться к статье. Прямо сейчас статья не справляется с этим, и с этим плохо. Она использует WP:BUZZWORDS и слишком много MOS:JARGON , и имеет смысл только для того, кто уже знаком с темой. Это сводит на нет смысл статьи. Даже учитывая это, у нее есть и дополнительные проблемы.

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

Простите за клише, но говорят, что если вы не можете что-то объяснить, значит, вы этого не понимаете. Исходя из этого, один из вариантов — сравнить эту статью со статьей Simple English Wikipedia , которая находится здесь: Simple:Microservices. Достаточно ли понятна эта статья для целей этого проекта? Нет, так почему бы и нет, и как ее можно улучшить? Как это отражается на этой статье?

Это было бы базой, которая могла бы поддерживать эту версию статьи в соответствии с реальностью. Я уверен, что эту тему можно объяснить на простом английском. Это может быть нелегко, но возможно. Если при переводе на простой английский какая-то деталь или индивидуальная точка зрения больше не кажутся полезными, скорее всего, изначально они были не такими уж и глубокими. Если это кажется слишком сложным, то это все равно гораздо менее сложно, чем эта статья. Взгляд со стороны может помочь указать, как следует улучшить статью.

Предоставлено ping @ Marvin The Paranoid : который также отменил эти изменения.

Grayfell ( обсуждение ) 01:21, 7 октября 2019 (UTC) [ ответить ]

@Arjunvarma1p: см. мои комментарии. Как вы определяете основную идею MSA? Это просто. Какие новые вещи или идеи вносит MSA? Чем MSA отличается от традиционных не-MSA (существовавших до введения MSA).

Можете ли вы сказать мне, в чем заключается единственное наиболее определяющее различие между подходом MSA и не-MSA? Единственное наиболее определяющее требование для MSA — это разделение монолита на несколько микросервисов.

На ум приходят только две вещи: (1) разбиение монолита на микросервисы и (2) слабое связывание микросервисов.

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

Я бы предложил следующее (я не очень хорош в написании, так что кто-нибудь может это уточнить): основные идеи MSA — это разбиение большого приложения (которое в противном случае было бы реализовано как монолит в традиционном подходе не-MSA) на несколько более мелких служб (называемых микрослужбами) и (2) развертывание приложения путем структурирования приложения как набора слабосвязанных служб. Не существует единого определения для различных процессов MSA, таких как методология разбиения, механизмы слабосвязанности и гранулярности, и это лишь некоторые из них. Со временем в отрасли сложилось единое мнение. Вот некоторые из часто упоминаемых определяющих характеристик: — Предшествующий неподписанный комментарий, добавленный Arjunvarma1p ( talk • contribs ) 09:48, 8 октября 2019 (UTC) [ ответить ]

Это оригинальное исследование . Википедия — не место для оригинальных исследований. Пожалуйста, укажите надежный источник . Спасибо. Grayfell ( обсуждение ) 20:39, 11 октября 2019 (UTC) [ ответить ]

Почему название «Микросервис» не определено как небольшой, развернутый, модульный сервис? — Предыдущий неподписанный комментарий добавлен Mrincodi ( обсуждение • вклад ) 16:00, 31 октября 2019 (UTC) [ ответить ]

Кажется, кто-то здесь рекламирует Spring Cloud в разделе сравнения платформ. Для начала, сравнения, если понимать буквально, проводятся между ортогональными технологиями, причем Kubernetes рекламируется как «механизм оркестровки контейнеров» на странице Kubernetes , а Spring Cloud — как «инструменты для разработчиков, позволяющие быстро создавать некоторые общие шаблоны в распределенных системах» на странице продукта.

Раздел сравнения платформ — это беспорядок, две платформы Spring Cloud и Netflix объединены друг с другом без особой причины. Кроме того, он читается как рекламный буклет Spring Cloud с необъективно звучащим языком, таким как «Это не эквивалент того, что предоставляет Ribbon» и «Одним из примечательных аспектов экосистемы Spring Cloud является то, что все они основаны на технологиях Java, тогда как Kubernetes — это многоязычная платформа выполнения», что имеет сомнительную значимость для обсуждаемой темы. Для статьи, которая якобы может быть доступна многим нетехническим специалистам, стремящимся понять аспекты современных тем разработки программного обеспечения, похоже, в ней довольно много FUD-обсуждений Spring Cloud и очень мало объективности. — Предыдущий неподписанный комментарий добавлен 71.185.203.231 (обсуждение) 17:43, 22 сентября 2020 (UTC) [ ответить ]

Вступление написано с некоторыми элементами, похожими на учебное руководство, которым Википедия не является . Это включает использование « you » и «should». Я сам прочитал только вступление, но полагаю, что остальная часть статьи содержит похожие формулировки; например, я просто быстро нажал Ctrl+F и увидел « note that ». — W.andrea ( talk ) 17:10, 7 июня 2024 (UTC) [ reply ]

Удалены «вы», «должны» и «обратите внимание» Azarboon ( обсуждение ) 01:42, 8 июня 2024 (UTC) [ ответить ]

"It is recommended" все еще слишком поучительно. Чтобы исправить это, вы можете приписать совет, например

По мнению О'Рейли , архитекторам следует избегать определения единообразных характеристик для всей распределенной системы .

Тогда «should» подойдет, потому что это не из Википедии, мы просто повторяем то, что говорит О'Рейли. — W.andrea ( обсуждение ) 18:48, 8 июня 2024 (UTC) отредактировано 18:55 [ ответить ]

Спасибо за объяснение. Изменил соответственно. Azarboon ( обсуждение ) 00:45, 9 июня 2024 (UTC) [ ответить ]