Да. У меня несколько хлопцев на roam сидят

А зачем что-то кроме certbot обернутого в шелл или морду?

Серты же получаются не раз в секунду на домен. Они на пару месяцев обычно как минимум.

Ревокать тож сертботом можно, он и конфиги  нжинкса сам обновит, если надо.

Traefik умеет из коробки

0

а можно заюзать dehydrated и забыть о серт боте

Только со статичным конфигом же

Он умеет брать информацию из consul

Всем привет.
Есть несколько вопросов по архитектуре, предложенной на рисунке (предложенное решение описанной ниже задачи).

Цели:
1. Основная задача - объединить все ИТ-проекты компании, разрабатываемые на различных языках и технологиях, в единую экосистему, которую можно будет поддерживать штатом своих разработчиков (сейчас же это outsource). Хочется уйти от текущего "зоопарка" технологий.
2. По возможности максимально перевести outsource-решения на аналогичные внутренние .NET-проекты (какие можно перевести), так как в штате C#-разработчики. Возможно, часть (но меньше) останется на outsource.
3. Желательно иметь общий бэкенд для всех фронтендов (возможно в виде расширения текущего WebAPI).
4. Хотелось бы уменьшить кол-во PHP кода (расширять штат PHP-шниками не планируется).

Текущие условия:
* У внутреннего WebAPI - бэк на Asp.NET Core 3.1 (отдаётся потребителям в виде OpenAPI). БД - MSSQL.
* У интернет-магазина - свой бэк и фронт (1C-Bitrix, PHP). - outsource
* У ещё одного сайта по продаже - свой бэк и фронт (PHP, Oracle). - outsource
* У мобильных приложений (Android, iOS) - свой бэк и фронт (Java, Kotlin, Swift). - outsource
* У основного сайта - свой бэк и фронт (Java, ReactJS, Postgres). - outsource
* У ещё одного отдельного сайта - свой бэк и фронт (Java, AngularJS). - outsource

- Для обработки части бизнес-логики, регистрации/авторизации, получения данных о клиентах из CRM, связи с 1С и другими сервисами уже используется ASP.NET Core 3.1 WebAPI в виде OpenAPI (представлен в Swagger UI). Все зависимые ИТ-проекты обращаются к нему (помимо своих бэков).
- Интернет-магазин размещает заказы в 1С тоже через WebAPI.
- Доступ к WebAPI сейчас только во внутренней сети (наружу не выглядывает). Используются JWT-токены для авторизации.

Пожелания:
1. Основной язык - C# (так как сейчас в штате разработчики C#, они же и будут поддерживать будущую экосистему).
2. Максимальный уход от множества бэкендов, консолидация логики в общем бэке.
3. Разработка мобильных приложений - кроссплатформенная (Flutter или Xamarin).
4. Интернет-магазин пока оставить на 1C-Bitrix (возможно потом поменяется).

Вопросы:
1. На предложенной схеме смущает добавление LaravelAPI (PHP), как прослойки между клиентами и сервисами. Можно ли напрямую давать сайтам и мобилкам доступ к WebAPI с точки зрения безопасности (сейчас он не выглядывает наружу) или нужен какой-то промежуточный слой?
2. Правильно ли объединять все имеющиеся бэкенды в общий бэк в виде WebAPI? Или стоит для каких-то решений оставить свой бэк?
3. Насколько оправдан выбор Apache Kafka? Стоит ли рассматривать RabbitMQ? И вообще стоит ли сразу закладывать в инфраструктуру наличие брокера сообщений или пока можно без него?
4. Нужен ли в текущих условиях распределённый кэш (например, в виде Redis)? Для каких сценариев?
5. Стоит ли рассматривать Xamarin (в будущем MAUI) для мобилок или это принесёт определённые "страдания" как разработчикам, так и клиентам?
6. Субъективно (ваше мнение): Имеет ли смысл рассматривать Blazor для фронтенда (ибо штат - .NET-чики) или лучше React, Vue?
7. Что ещё необходимо добавить (предусмотреть) в схеме разрабатываемой экосистемы? Чего не хватает? О чём необходимо подумать?
8. На будущее: Стоит ли рассматривать для интернет-магазина eCommerce решения на .NET (nopCommerce, Umbraco, Orchard Core, Piranha Core) или лучше оставить 1C-Bitrix?

P.S. Возможно, часть вопросов банальные, или ответы на них очевидные. Но мне ранее не приходилось ими задаваться, так как большая часть систем - outsource. Сейчас же пытаюсь во всём этом разобраться.
P.P.S. Буду очень признателен, если поможете с ответами на вопросы.

1. Есть куча готовых решения для API Management, можно посмотреть в их сторону
2. Что значит один? у вас пуши на мобилки специфичная отдельная штука, которая вебу не нужна. У вас может быть набор сервисов которые универсальные для всех клиентов и набор сервисов специфичных для клиентов
3. На рисунке кафка у вас в очень интересном месте, между, насколько я понял, DMZ и интернетом, что она там вообще делает?
4. Надо смотреть кейсы/нагрузку, все сложно :)
5. Рассматривать можно, если решения на уровне простых форм. Красивости, скорость работы когда я смотрел на Ксамарин - неа
По остальным пунктам ничего не могу прокомментировать.

5 - у вас будут проблемы с подбором персонала. Xamarin (как и другие кроссплатформенные решения) не освобождают от знания тонкостей целевой платформы (iOS/Android). Значит нужно этому либо учить текущих C# разработчиков (с неизвестным результатом) либо искать мобильных разработчиков, готовых пересесть на C# (тоже непонятно где).  Это все более менее живет для кейсов "нам нужно сделать мобильное приложение для внутреннего использования, с простеньким дизайном, как можно дешевле".

именно, быстрый прототип - это да, можно попробовать. в остальных случаях - очень спорный выбор

2. Будут разные контроллеры: для веба - свой, для мобилок - свой.
3. Схема предложена одним из разработчиков. Kafka в DMZ. Видимо, подразумевалось, что все запросы от клиентов должны проходить через брокер сообщений.
5. Сложилось такое же впечатление.

Спасибо.

Такое ощущение, что в "век микросервисов" вы решили удариться в монолиты

По этому пункту скорей всего будет либо Flutter, либо нативщики под каждую платформу. И да, тут, вероятно, останется outsource

3. Запросы от клиентов это, как правило, синхронные запросы в API. Делать асинхронную кафку, за ней Management API, а потом сервисы.... Очень спорное решение

Поддержка микросервисной инфраструктуры - тоже то ещё удовольствие. Хотелось бы пока оставить монолит, но с заделом на возможное разделение на микросервисы (если будет необходимость).
Сейчас в монолитном решении итак есть разбивка по сервисам-проектам, просто нет необходимости в переходы к микросервисам.

> Сейчас в монолитном решении итак есть разбивка по сервисам-проектам

Часто такая "разбивка" совершенно иллюзорна и на поверку оказывается неразрываемым комком.
У сервисов отдельные и не связанные между собой БД?

Какие альтернативы? Напрямую кидать все запросы клиентов в WebAPI?

В DMZ может быть API Management или просто nginx, ну и они уже проксируют запросы во внутренюю сеть и находящееся там API