DS
Причём современные инструменты для крутилки-скорострелки во-первых, поддерживают нормально горизонтальное масштабирование, а во-вторых даже один инстанс способен прожевать практически любой объём аудитории.
Size: a a a
2018 May 27
AK
Распараллеливание разработки упрётся скорее в бабло и нехватку кадров. Но мысль интересная!
нет, я о другом. делить на сервисы можно и нужно, но поделить на сервисы можно по-разному. чем выше доля сетевого взаимодействия с другими сервисами, тем ниже его надежность и выше стоимость поддержки и вероятность сложных проблем.
DS
Так. Мы растекаемся мыслью по древу. Давай оперировать строго существующим опытом и рассказывать строго про него?
DS
Как мысль, Aleksandr ?
AK
Так. Мы растекаемся мыслью по древу. Давай оперировать строго существующим опытом и рассказывать строго про него?
ну речь изначально зашла как раз про обобщение опыта, кто-то удачно распилил на сервисы, кто-то нет. интересно как оценить и спрогнозировать удачность этой затеи.
на мой взгляд на это влияет два фактора:
- доля service mesh у каждого сервиса
- количество сервисов в сети: надежность конечного продукта является произведением надежности всех сервисов
на мой взгляд на это влияет два фактора:
- доля service mesh у каждого сервиса
- количество сервисов в сети: надежность конечного продукта является произведением надежности всех сервисов
IF
а чего тут обсуждать
недавно ездили
крупному предприятию надо слезть с информикса
2.5 млн строк. монолит. пишется с 93 года.
недавно ездили
крупному предприятию надо слезть с информикса
2.5 млн строк. монолит. пишется с 93 года.
AK
Хм... Ну не знаю... Я по опыту разработки рекламных сервисов rtb предпочитаю делить сервис на интерфейсную часть, архивную и крутилку-скорострелку.
Вот на микросервисы обычно рубят именно интерфейсную часть. Но там-то как раз обычно и не бывает проблем с нагрузкой.
Вот на микросервисы обычно рубят именно интерфейсную часть. Но там-то как раз обычно и не бывает проблем с нагрузкой.
а что это за части? интерфейсная, архивная, крутилка-скорострелка. можно подробнее?
DK
Мне кажется, надо микросервисы выделять не по функциональной роли, а по прикладной области, тогда это более чем имеет смысл. Если для реализации запроса надо пройти несколько сервисов это не очень хорошо и делать так весьма странно
DK
Условная корзина товаров может не отвечать на вопрос о названиях товаров. А чтобы нарисовать строчку с товаром используется другой сервис. Это всё происходит на фронтэнде засчёт компонентов, которые публикуют разные сервисы.
DK
То есть у нас сервис это не просто набор апи, но и законченные виджеты, которыми пользуются виджеты других сервисов
DK
Виджет корзины добавляет виджет товара с соответствующим кодом, а как рендерить этот товар задача сервиса товаров
DK
Вкратце как-то так
DS
Условная корзина товаров может не отвечать на вопрос о названиях товаров. А чтобы нарисовать строчку с товаром используется другой сервис. Это всё происходит на фронтэнде засчёт компонентов, которые публикуют разные сервисы.
А какое время нагрева холодного взятого с мороза фронта, чтобы он ворвался в тему?
DK
Фронта - это разработчика или речь про компоненты?)
DS
Фронта - это разработчика или речь про компоненты?)
Разработчик, да
DK
Сейчас это экстжс компоненты которые просто работают с бэкендом своего сервиса. Получается и клиентский код, и апи в одном репозитории. Экстжс неплох для быстрого старта, но их виджеты, подход к рендеру и работа с данными это трэш.
DK
С примерами у них всё хорошо, человек который знает жс начинает через пару дней лепить компоненты по образу и подобию
DK
А если опирается на стандартные виджеты экста, то и того быстрее
DK
tarantool-admin/Format.js at master · basis-company/tarantool-admin · GitHub
https://github.com/basis-company/tarantool-admin/blob/master/public/admin/js/Space/Format.js
https://github.com/basis-company/tarantool-admin/blob/master/public/admin/js/Space/Format.js
