А чем плоха официальная документация? Судя по требованиям, в ней всё есть? Или чего-то не хватает?
P.S. $300 за бумажку, которая устареет в ближайшее же время? Ладно бы с обучением, но это же стоимость только экзамена. Зачем? $30-50 я ещё могу понять, но $300...
Правильно ли я понимаю, что сервис контроля в этом случае должен знать, какие подтверждения должны быть получены, т.е. сильно связан с контролируемыми сервисами? Т.е. в любом случае не получится изменить состав операций, скажем, при создании пользователя, просто убрав или добавив новый микросервис — придётся изменить ещё и сервис контроля, а затем протестировать его работу вместе со всеми остальными сервисами в этой связке (а не только новый микросервис, как было бы в идеале).
Вообще, посоветуете, что почитать по архитектуре из того, чем вдохновлялись сами?
Я бы тоже почитал об этом. Из первого рисунка рождается предположение, что используется NSQ.
Если можно, я бы попросил ещё комментарии о том, как решается вопрос с дедупликацией\идемпотентностью при доставке сообщений. Ну, и отсутствие гарантии порядка доставки сообщений не мешает?
А пилить вообще ничего не нужно никогда, тут я с вами согласен; поэтому и написал — простейший вариант. Кроме того, какая-никакая, но демонстрация GenServer, хоть и без пояснений.
Но, если уж об этом говорить, стоило бы мне, конечно, начать с того, что разработчики языка вообще не рекомендуют вводить кэширование до тщательного профилирования приложения и полной уверенности в том, что именно кэшированием узкое место будет исправлено. И — если более глобально — вообще не лезть в оптимизацию до того, как в этом возникнет реальная необходимость.
Вам было бы удобно писать на Коболе, если бы для него сделали транслятор в С? А насчёт "неизвестно, что и как" как раз вопрос и был: изучается ли что-то и какие результаты изучения.
Но, на самом деле, я не хочу спорить на эту тему. Я надеялся услышать из первых рук что-то вроде "нет, не проводим, потому что..." или "да, проводим, и решили, что..."
Вы имеете ввиду кэширование обращений к базе (кэш данных) или кэш выдачи?
Вообще, своего нет ни того, ни другого. Но простейший кэш можно реализовать буквально несколькими строчками на Elixir:
несколько строк и результат использования
defmodule Example.KeyValueStore do
use GenServer
# Client API
def start_link(initial_state \\ %{}) do
GenServer.start_link(__MODULE__, initial_state, name: __MODULE__)
end
def get(key) do
GenServer.call(__MODULE__, {:get, key})
end
def put(key, value) do
GenServer.cast(__MODULE__, {:put, key, value})
end
# Server API
def handle_call({:get, key}, _from, state) do
{:reply, Map.get(state, key), state}
end
def handle_cast({:put, key, value}, state) do
{:noreply, Map.put(state, key, value)}
end
end
Для того, чтобы понять, что получилось, запустите интерактивную оболочку Elixir iex, скопируйте сначала код выше (не забудьте завершающий перевод строки) и затем вводите следующее:
iex> alias Example.KeyValueStore, as: KVS
Example.KeyValueStore
iex> KVS.start_link
{:ok, #PID<0.114.0>}
iex> KVS.get(:one)
nil
iex> KVS.put(:one, "some text")
:ok
iex> KVS.put(:complex_structure, %{name: "test", title: "record"})
:ok
iex> KVS.put(12345, "key can be any type")
:ok
iex> KVS.get(:one)
"some text"
iex> KVS.get(:complex_structure)
%{name: "test", title: "record"}
iex> KVS.get(12345)
"key can be any type"
Кстати, выше был реализован полноценный отдельный рабочий процесс, который будет исполнятся параллельно всем остальным.
Конечно, с данной задачей и мизерным объемом справочников вообще нет смысла лезть в базу более одного раза после запуска приложения: загрузить всё в память и уже с ней работать. Но хотелось хоть как-то показать взаимодействие с базой.
Я считаю, что прежде, чем говорить, что что-то не соответствует действительности (в частности, что Linux хуже, чем Windows — или хотя бы на том же уровне! — подходит для инструментов, которые вы указали в своём комментарии), стоит иметь для этого какие-то доводы, отличные от субъективных суждений. Точно так же, как и автору статьи стоило бы иметь доводы, утверждая обратное. Ни ваше мнение, ни мнение автора статьи ничем не подкреплено фактически.
В общем-то, я не имею ничего против экспертного мнения, если оно у вас сложилось из практического опыта. Но я против критики низкого уровня статьи доводами, аналогичными приведённым в статье. И, честно говоря, я не вижу смысла продолжать дискуссию на эту тему.
«Если уже написали» — это одно. Если функционал делился\продолжает делиться и — это уж наверняка — растёт, то к чему толкать не очень удобные неподрессоренные телеги с оглоблями, если появились тачки с амортизаторами и удобными ручками? Если они, конечно, действительно появились, а не выдаются за таковые.
Любопытно, если всё равно выносится код в отдельные (насколько я понимаю, независимые) сервисы, то почему непосредственно новые сервисы не реализовывать на более удобных и подходящих для этого инструментах? Проводите ли вы периодически какие-то исследования на этот счёт: всё-таки и Rust уже есть, и Go, и функциональные языки всё чаще используются, причём как раз для похожих задач?
По этому поводу написал ниже. Пока у вас посещаемость 1 человек в неделю — можно хоть на raspberry pi 2 c Windows 10 хоститься. А при работе с серьёзным проектом одного факта запуска чего-либо недостаточно для принятия решения.
Если вы не читали мои комментарии выше, то скажу, что меня смутила вся статья. Но уподобляться ей же в критике глупо. То, что я могу писать на go не означает, что меня срочно нужно взять на должность ведущего разработчика новейшей экспертной системы, которая ведётся на этом языке. Точно так же то, что какие-то инструменты запускаются в той или иной среде не означает, что они в этой среде эффективно работают. Если выбирающий пишет и размещает не личную домашнюю страничку, на которую зайдут полтора инвалида в базарный день, то выбор будет делаться не только по принципу «лишь бы запустилось». И для помощи в этом выборе актуальными были бы данные нагрузочного тестирования на одинаковых виртуалках с указанием производительности и расхода ресурсов, а не широко известные факты.
А у вас есть результаты тестов, которые подтверждают, что это ложь? Статья, конечно, трэш полный, но вот противоположные утверждения без доказательств от статьи ничем не отличаются.
Кому-то в наше время ещё нужны сертификаты?
А чем плоха официальная документация? Судя по требованиям, в ней всё есть? Или чего-то не хватает?
P.S. $300 за бумажку, которая устареет в ближайшее же время? Ладно бы с обучением, но это же стоимость только экзамена. Зачем? $30-50 я ещё могу понять, но $300...
Правильно ли я понимаю, что сервис контроля в этом случае должен знать, какие подтверждения должны быть получены, т.е. сильно связан с контролируемыми сервисами? Т.е. в любом случае не получится изменить состав операций, скажем, при создании пользователя, просто убрав или добавив новый микросервис — придётся изменить ещё и сервис контроля, а затем протестировать его работу вместе со всеми остальными сервисами в этой связке (а не только новый микросервис, как было бы в идеале).
Вообще, посоветуете, что почитать по архитектуре из того, чем вдохновлялись сами?
Спасибо.
Я бы тоже почитал об этом. Из первого рисунка рождается предположение, что используется NSQ.
Если можно, я бы попросил ещё комментарии о том, как решается вопрос с дедупликацией\идемпотентностью при доставке сообщений. Ну, и отсутствие гарантии порядка доставки сообщений не мешает?
О чём — об этом? Выше сказали: никто к ним не обращался за информацией для расследования, ни с той, ни с нашей стороны.
Я тут не рассматриваю вопрос правдивости статьи в целом, кстати.
А наши почему тогда сидят тихо, если это не "русский след"? Расследовали бы, на весь мир громко заявили "смотрите, кто!"? Не?
Всё-таки нервничаете… зря. Эдак вы все нервные клетки растеряете.
Возможно потому, что это транскрипт (расшифровка) живого выступления на конференции.
А пилить вообще ничего не нужно никогда, тут я с вами согласен; поэтому и написал — простейший вариант. Кроме того, какая-никакая, но демонстрация GenServer, хоть и без пояснений.
Но, если уж об этом говорить, стоило бы мне, конечно, начать с того, что разработчики языка вообще не рекомендуют вводить кэширование до тщательного профилирования приложения и полной уверенности в том, что именно кэшированием узкое место будет исправлено. И — если более глобально — вообще не лезть в оптимизацию до того, как в этом возникнет реальная необходимость.
Кстати, решений для кэширования есть в ассортименте, одним ConCache дело не заканчивается.
Конечно, вполне :)
Вам было бы удобно писать на Коболе, если бы для него сделали транслятор в С? А насчёт "неизвестно, что и как" как раз вопрос и был: изучается ли что-то и какие результаты изучения.
Но, на самом деле, я не хочу спорить на эту тему. Я надеялся услышать из первых рук что-то вроде "нет, не проводим, потому что..." или "да, проводим, и решили, что..."
Вы имеете ввиду кэширование обращений к базе (кэш данных) или кэш выдачи?
Вообще, своего нет ни того, ни другого. Но простейший кэш можно реализовать буквально несколькими строчками на Elixir:
Для того, чтобы понять, что получилось, запустите интерактивную оболочку Elixir
iex
, скопируйте сначала код выше (не забудьте завершающий перевод строки) и затем вводите следующее:Кстати, выше был реализован полноценный отдельный рабочий процесс, который будет исполнятся параллельно всем остальным.
Конечно, с данной задачей и мизерным объемом справочников вообще нет смысла лезть в базу более одного раза после запуска приложения: загрузить всё в память и уже с ней работать. Но хотелось хоть как-то показать взаимодействие с базой.
В общем-то, я не имею ничего против экспертного мнения, если оно у вас сложилось из практического опыта. Но я против критики низкого уровня статьи доводами, аналогичными приведённым в статье. И, честно говоря, я не вижу смысла продолжать дискуссию на эту тему.