Что такое распределённая система?

А, распределённые системы, говоришь? Ну это ж классика, основа всего современного интернет-говна, прости господи. Представь себе: у тебя не один здоровенный сервер, который пыхтит как паровоз и жрёт электричества дохуя, а куча мелких компов, раскиданных по всему миру. Они между собой перешёптываются, типа координируются, а пользователю кажется, что он общается с одной здоровенной, умной машиной. Иллюзия, блядь, Карл!

Зачем этот цирк вообще нужен?

• Масштабируемость: Это когда твоё приложение стало популярным, и на него набежало столько народу, что один сервер просто ложится и плачет. Ты не покупаешь новый, в десять раз более мощный (вертикальное масштабирование — для лохов и богатых), а просто ставишь ещё пять таких же простых. Добавил железа — получил мощность. Горизонтально, ёпта!
• Отказоустойчивость: Это когда один из твоих компов внезапно накрылся медным тазом — взял и сгорел. А система в целом нихрена не парится и продолжает работать. Ну, может, чуть медленнее, но живёт! Пользователь даже не узнает, что где-то там, в дата-центре, техник матерится и меняет блока питания.
• Прозрачность: Ну это чтобы клиент, долбаёб, не думал, где там его данные лежат — в Сибири или в Амстердаме. Для него это одна большая чёрная коробка, которая просто работает. Магия, ебать!

Где это видали? Да везде! Кластеры баз данных вроде Кассандры, эти ваши микросервисы, которые друг другу письма пишут, CDN, который картинки раздаёт, и даже блокчейн — это всё они, распиздяи распределённые.

Вот, смотри, как два узла могут поболтать (на C# с gRPC):

1. Один узел (Назовём его «Узел А», сидит где-нибудь в Иркутске):

// Запускаем сервак, который будет слушать и отвечать
var server = new Grpc.Core.Server
{
    Services = { Greeter.BindService(new GreeterServiceImpl()) },
    Ports = { new ServerPort("node-a.internal", 50051, ServerCredentials.Insecure) }
};
server.Start();
Console.WriteLine("Сервер Greeter запущен на порту 50051");

2. Второй узел (Допустим, «Узел Б», уже в Питере):

// Тянется к Иркутску по сети и спрашивает
using var channel = GrpcChannel.ForAddress("https://node-a.internal:50051");
var client = new Greeter.GreeterClient(channel);

var reply = await client.SayHelloAsync(new HelloRequest { Name = "Distributed System" });
Console.WriteLine($"Ответ от сервера: {reply.Message}");

Выглядит просто, да? А теперь готовься к главному пиздецу.

Почему это адская боль для разработчика:

• Теорема CAP: Святая троица ебаная. Если сеть между твоими узлами распалась (Partition), ты должен выбрать: либо система будет доступна (A) для всех, но данные в узлах могут временно разъехаться (неконсистентность), либо ты сохранишь согласованность данных (C), но часть пользователей получит ошибки или бесконечную загрузку (недоступность). И то, и другое одновременно при сетевом сраче — невозможно. Выбирай, в какую сторону стрелять себе в ногу.
• Частичные отказы: Это когда не всё сломалось, а только что-то одно. Сеть есть, но один пакет потерялся. Или ответ от сервера пришёл, но через 10 минут. Нужно продумывать каждую операцию: а что, если она зависнет? А если выполнится два раза? Отсюда эти ваши retry, таймауты, идемпотентность и прочие танцы с бубном.
• Отладка и мониторинг: Вот это вообще пиздец. Когда всё работает на одной машине, ты хотя бы понимаешь, где искать логи. А когда у тебя двадцать сервисов разбросаны по трём облакам, и баг проявляется раз в неделю, ты просто садишься и плачешь. Приходится ставить сложные системы трассировки вроде Jaeger, чтобы понять, какой именно микросервис сегодня опять обосрался и тормозит всю цепочку.

Короче, распределённые системы — это как управлять оркестром, где каждый музыкант сидит в отдельной комнате, связь у него через рацию с помехами, и при этом он ещё и периодически отключается. А зритель в зале должен слышать идеальную симфонию. Весело, блядь!