Василий Банников

Это обычные VPN сервисы
Связываются они через сервер с белым IP, по своим внутренним в VPN сети IP адресам

Давайте разберём на примере шпионов. В городе N работают два глубоко законспирированных шпиона - Агент Икс и Агент Игрек. Каждый из них не знает, где живёт другой (серые адреса). Им и не полагается знать, чтобы если провалится один, он не смог выдать другого. Но для выполнения задания им нужно обменяться информацией. Для этого Агент Икс берёт свою рацию и связывается с Центром (сервер Hamachi, AnyDesk, AmmyyAdmin, TeamViewer и т.п., который имеет белый адрес и всегда готов к сеансу связи с любым агентом), передаёт (в зашифрованном виде, конечно), что у него такая-то информация для Агента Игрек. Через некоторое время Агент Игрек берёт свою рацию и связывается с Центром, ему говорят, что для него есть информация от агента Икс, он очень быстро обдумывает новые сведения (шпион должен быстро соображать) и передаёт (в зашифрованном виде, конечно), что у него такой-то ответ для Агента Икс. Через некоторое время Агент Икс берёт свою рацию... и т.д.
Вот так могут общаться через Центр, хотя Центр не может сам с ними связаться и они напрямую не могут друг с другом связаться.
А еще есть другой вариант. Агент Икс говорит Центру: назначаю рандеву Агенту Игрек в понедельник в час дня в цветочном магазине возле Эмпайр Стейт Билдинг; Агент Игрек выходит на связь, Центр передаёт ему место и время встречи и они встречаются напрямую, Центр уже не знает о чём они говорят или какими документами обмениваются. Это называется "пробитие NAT", для этого используются методы TURN или STUN и подобные, при которых Центр нужен только в момент установки связи, а дальше агенты общаются напрямую, пока не разорвут соединение. Как разорвали - им снова потребуется Центр для связи.

ведь его браузер новые стили не прочитает

Бразуер кеширует конкретный файл. Соответственно, для сброса кэша просто меняют путь к файлу.
Простой вариант: добавить get-параметр, в котором будет содержаться время последнего изменения. Но этот вариант требует чтения с диска на сервере, чтобы узнать mtime (не велика беда) и работает не со всеми reverse proxy (некоторые криво настроенные могут игнорировать get-параметры).
Поэтому уже лет десять существуют системы сборки фронтенда, которые прямо в имя файла подставляю хэш от его содержимого. Сейчас это есть для абсолютно любой системы - gulp, webpack, что угодно.
Называется это Cache Busting, вот вам первая попавшаяся статья: https://www.keycdn.com/support/what-is-cache-busting
А ещё, кэш - это не только "не запрашивай файл 365 дней", там много различных функций: https://jakearchibald.com/2016/caching-best-practices/

при их изменении на стороне клиента

Такая формулировка подразумевает, что это клиент что-то меняет. Я уж обрадовался: "о, какой интересный вопрос, есть над чем подумать!"...

Docker это набор сервисов и утилит созданных для удобного управления встроенными в ядро Linux технологиями Namespace (для изоляции процессов) и CGroups (для управления ресурсами).

По мимо Docker существует ряд инструментов призванных делать тоже самое Systemd-Nspawn, LXC, Podman, etc - все они работают похожим образом и точно так же изолируют Linux-овые процессы. Docker самый распространённый и популярный из-за стандартизации процесса сборки образа и удобных утилит для управления жизненным циклом контейнера, Docker это как libc - только в разрезе контейнеров.

Контейнер можно запустить не имея ни одного из этих инструментов с помощью утилиты unshare - она позволяет точно также управлять Namespac-ами (управлять ресурсами придётся вручную добавив процесс в CGroups).

Контейнер это изолированный Linux процесс - соответственно запустить получиться только Linux-овый софт и больше ничего. Контейнер это не маленькая виртуальная машина, контейнер это не Java для всего. Конетейнер это только средство запустить Linux-овый процесс в изолированной среде (и, возможно, ограничить его по ресурсам), например запустить приложение требующее наличия в системе конкретных зависимостей, но отсутствующих по факту. Или запустить в целях разработки конкретную версию PHP, Python, Ruby, etc при этом избежав конфликта зависимостей и Dependency hell из-за несовместимых библиотек на хостовой машине.

Представь себе ситуацию, когда ядро Linux загрузилось и запустило только один (какой угодно) процесс, присвоив ему PID 1 - вот так контейнер выглядит изнутри.

PS
Есть конетйнеры на Windows Core они запустятся только на Windows и служат для изоляции только Windows софта и для них есть набор утилит, которые распространяются в виде набора бинарных файлов тоже, почему-то, под именемем Docker (не путать с Docker-Desktop, так как Docker-Desktop - это набор сервисов позволяющих виртуализировать ядро Linux и тем самым получить возможность запустить Linux процессы на Windows или MacOS).

Просто смотрите на ножки/контакты под разными углами.
Они всегда должны выглядеть как ровные ряды.
Вообще замятый сокет/погнутые ноги - это из разряда брака - менее 1% случаев.

Найти программиста, дать денег.

use chrono::prelude::*;
use std::sync::mpsc;
use std::sync::mpsc::{Receiver, Sender};
use std::{thread, time};

fn main() {
    println!("- - - - -");
    let mut children = Vec::with_capacity(3);

    for id in 0..children.capacity() {
        let child = thread::spawn(move || {
            let mut date_times = Vec::with_capacity(5);
            for i in 0..date_times.capacity() {
                let t: DateTime<Local> = Local::now();
                date_times.push(t);
                println!("{:?}_ поток, задача _{:?}, время: {:?}", id, i, t);
                thread::sleep(time::Duration::from_millis(3));
            }
            (id, date_times)
        });

        children.push(child);
    }

    for child in children {
        let (id, date_times) = child.join().expect("Дочерний поток паникует");
        println!("thd_{} = {:?}", id, date_times);
    }
    println!("- - - - -");
}

Смотри. Уже прошло время когда все пилили монолиты на микросервисы. Щас пошло переосмысление.
Объективно есть 2 причины пилить. Первое - организационная. Команда по какой-то причине не хочет
или не может поддерживать приложение. Или там что-то с бизнесом. Слияние. Поглощение. Передача
проекта другой команде в поддержку. Тогда берут и ставят задачу раздела отвественностей.
Конвей про это писал еще.

И второе - это баланс нагрузки и децентрализация. Про failover тут еще даже речи нет. Это
тяжелая тема и распилить монолит так чтобы его части были отказоустойчивы очень трудно. Более
того в случае синхронных взаимодействий между частями микросервисов может быть даже падение
перформанса. Да. Теоретики которые там пишут восторженные отзывы - совершенно игнорируют
накладные на RPC. И не упоминают что в монолите цена RPC была равна нулю. Иногда RPC заменяют
на MQ - но это новая архитектура и это надо полностью переделывать бизнес.

И что делать с базой данных? Это тот еще вопрос. Я почти готов спорить что вы базу пилить не будете.
И что в результате будет? Иммитация микро-сервисов? Где слабая связность?

Тоесть если у вас нет таких кричащих ситуаций что оргазниация требует или нужно баланс
нагрузки как-то разнести - то тебе вообще-вообще нет смысла ходить ни в какие микросервисы.

Но имеет смысл сделать модуляризацию монолита. Например что там...

application
- sales
- hiring
- userprofiles

Тоже очень полезно для управления сложностью. И пускай себе будет монолит зато будет сильный
контроль за изменениями.