Към съдържанието
wannacode

Монолит, модулен монолит, услуги

Накратко: Модулният монолит е едно приложение с ясни модули, всеки с публичен API и свои данни; микроуслугите се отделят, когато екипи, мащаб или независим deploy си струват цената.

Проблем

Поръчките в таблицата на склада

Магазинът в града запазва бройки за клиенти, които ще дойдат на място. Складът пази наличността и резервациите, а за чайника KTL-100 наличността е 2. Онлайн поръчките са писани от друг екип, който „за бързина“ чете и пише направо в таблицата на склада:

// Склад: наличността и резервациите на магазина в града
class Warehouse {
  stock = new Map();
  reserved = new Map();


  reserve(sku, qty) {
    if (this.free(sku) < qty) return false;
    this.reserved.set(sku, (this.reserved.get(sku) ?? 0) + qty);
    return true;
  }


  free(sku) {
    return (this.stock.get(sku) ?? 0) - (this.reserved.get(sku) ?? 0);
  }
}


// Поръчки: бъркат направо в таблицата на склада
class Orders {
  constructor(warehouse) {
    this.warehouse = warehouse;
  }


  place(sku, qty) {
    const left = this.warehouse.stock.get(sku);
    if (left < qty) return "няма наличност";
    this.warehouse.stock.set(sku, left - qty);
    return "приета";
  }
}
const warehouse = new Warehouse();
warehouse.stock.set("KTL-100", 2);
const held = warehouse.reserve("KTL-100", 2);
console.log("Резервация за магазина: " + (held ? "да" : "не"));
const orders = new Orders(warehouse);
console.log("Онлайн поръчка: " + orders.place("KTL-100", 1));
console.log("Свободни в склада: " + warehouse.free("KTL-100"));
Изход
Резервация за магазина: да
Онлайн поръчка: приета
Свободни в склада: -1

Магазинът е запазил и двата чайника, а онлайн поръчката е приета. Свободните са -1: продадена е бройка, която я няма. Правилото за резервациите е в склада, но поръчките не минават през него.

Втората болка идва по-късно. Екипът на склада иска да раздели stock по складове (София, Пловдив). Не може: не знае кой още чете и пише в таблицата му, и всяка промяна чупи чужд код.

Идеята

Модули с API и свои данни

Кодът е в една програма, която се пуска наведнъж: монолит. Това само по себе си не е беда. Бедата е, че вътре няма граници.

Модулен монолит е монолит, разделен на модули. Всеки модул:

  • има публичен API: няколко метода, през които другите го викат (receive, reserve, available);
  • има свои данни: таблиците и класовете вътре са негови, и никой друг не чете и не пише в тях;
  • зависи само от модулите, от които има право.

Това е подредбата „по функция“ от урока Слоеве, с правило за границите. В domain-driven design такава граница се казва bounded context: частта от системата, в която думата „наличност“ има едно значение.

Модулите са в един процес и често в една база. Извикването на модул е извикване на метод: бързо, без мрежа, в една транзакция, ако трябва.

Виж го

Складът като модул

// Модулът „склад“: данните са негови, навън е само API-то
class Warehouse {
  #stock = new Map();
  #reserved = new Map();


  receive(sku, qty) {
    this.#stock.set(sku, (this.#stock.get(sku) ?? 0) + qty);
  }


  reserve(sku, qty) {
    if (this.available(sku) < qty) return false;
    this.#reserved.set(sku, (this.#reserved.get(sku) ?? 0) + qty);
    return true;
  }


  available(sku) {
    return (this.#stock.get(sku) ?? 0) - (this.#reserved.get(sku) ?? 0);
  }
}


// Модулът „поръчки“: вика само API-то на склада
class Orders {
  constructor(warehouse) {
    this.warehouse = warehouse;
  }


  place(sku, qty) {
    if (!this.warehouse.reserve(sku, qty)) return "няма наличност";
    return "приета";
  }
}
const warehouse = new Warehouse();
warehouse.receive("KTL-100", 2);
const held = warehouse.reserve("KTL-100", 2);
console.log("Резервация за магазина: " + (held ? "да" : "не"));
const orders = new Orders(warehouse);
console.log("Онлайн поръчка: " + orders.place("KTL-100", 1));
console.log("Свободни в склада: " + warehouse.available("KTL-100"));
Изход
Резервация за магазина: да
Онлайн поръчка: няма наличност
Свободни в склада: 0

// Склад: наличността и резервациите на магазина в града
class Warehouse {
  stock = new Map();
  reserved = new Map();


  reserve(sku, qty) {
    if (this.free(sku) < qty) return false;
    this.reserved.set(sku, (this.reserved.get(sku) ?? 0) + qty);
    return true;
  }


  free(sku) {
    return (this.stock.get(sku) ?? 0) - (this.reserved.get(sku) ?? 0);
  }
}


// Поръчки: бъркат направо в таблицата на склада
class Orders {
  constructor(warehouse) {
    this.warehouse = warehouse;
  }


  place(sku, qty) {
    const left = this.warehouse.stock.get(sku);
    if (left < qty) return "няма наличност";
    this.warehouse.stock.set(sku, left - qty);
    return "приета";
  }
}
Стъпка по стъпка, с думи
  1. Един процес, една база. Складът пази наличността и резервациите, а таблиците му са отворени за всички.
  2. Магазинът запазва и двата чайника. Онлайн поръчката бърка направо в таблицата, не вижда резервацията и свободните стават -1.
  3. Модулен монолит: данните на склада стават негови. Навън остава само API-то: receive, reserve, available.
  4. Поръчките минават през reserve и складът пази правилото си: „няма наличност“, свободните остават 0. Още един процес, без мрежа.
  5. Складът излиза като отделна услуга: свой процес, свой deploy, свой екип. Извикването става съобщение по мрежата.
  6. Три поръчки, три съобщения: ok, мълчание, no. Извикване, което в монолита не можеше да се провали, сега се проваля.
  7. Модулите пазят границите без мрежа. Услугата добавя независим deploy, а плаща с мрежа, разделени данни и наблюдение.

Поръчката минава през reserve, а складът пази правилото си: двата чайника са запазени, затова онлайн поръчката получава „няма наличност“. Последните стъпки на сцената показват какво става, когато складът излезе като отделна услуга. Кодът им е по-надолу.

В JavaScript #stock е наистина скрито: извън класа не се стига. Модулът е файл или пакет, който изнася (export) само API-то си.

Пробвай

Намери грешката

Отчетът за склада иска да покаже цялата таблица, и някой добавя метод:

Избери реда с грешката.

Виж го

Проверка на границите

Границите не се пазят от добро желание. Ето малка проверка: какво дава всеки модул, кой от кои може да зависи и какво кодът ползва в действителност. В истински проект последният списък се чете от import-ите.

function check(api, allowed, uses) {
  const problems = [];
  for (const [from, to, name] of uses) {
    if (!allowed[from].includes(to))
      problems.push(`✗ ${from} → ${to}: зависимостта не е позволена`);
    else if (!api[to].includes(name))
      problems.push(`✗ ${from} → ${to}.${name}: не е в API-то`);
  }
  return problems;
}
// Какво всеки модул дава навън
const api = {
  orders: ["place"],
  warehouse: ["receive", "reserve", "available"],
  payments: ["charge"],
  invoices: ["issue"],
};
// Кой модул от кои може да зависи
const allowed = {
  orders: ["warehouse", "payments"],
  warehouse: [],
  payments: [],
  invoices: ["orders"],
};
// Какво ползва кодът в действителност (от import-ите)
const uses = [
  ["orders", "warehouse", "reserve"],
  ["orders", "warehouse", "stock"],
  ["orders", "payments", "charge"],
  ["invoices", "orders", "rows"],
  ["warehouse", "orders", "place"],
];


const problems = check(api, allowed, uses);
problems.forEach((problem) => console.log(problem));
console.log("Нарушения: " + problems.length);
Изход
✗ orders → warehouse.stock: не е в API-то
✗ invoices → orders.rows: не е в API-то
✗ warehouse → orders: зависимостта не е позволена
Нарушения: 3

Три нарушения: поръчките в таблицата на склада, фактурите в редовете на поръчките и склад, който вика поръчките (а поръчките вече викат склада). Такава проверка се пуска при всяка промяна и пада, щом някой мине през стената. Как става част от CI, има в урока Архитектурен преглед.

Идеята

Кога модулът става услуга

Услуга (microservice) е модул, който се пуска сам: свой процес, свой deploy, своя база. Другите го викат по мрежата. Струва си, когато:

  • екипите пречат един на друг: складът иска да пуска нова версия три пъти на ден, а магазинът веднъж седмично;
  • натоварването е различно: търсенето в каталога иска десет копия, а фактурите едно;
  • отказът трябва да се изолира: ако препоръките паднат, плащането трябва да работи.

И се плаща:

  • мрежа: извикването може да е бавно, да не стигне или да стигне два пъти;
  • данни: всяка услуга има своя база, затова няма JOIN между тях и няма една транзакция. Поръчка и резервация вече не се записват „заедно“. Как се живее с това, има в Събития и опашки, Изгубеното събитие и Saga;
  • наблюдение: една заявка минава през пет процеса, и грешката се търси в пет лога.

Сървърите, контейнерите, Kubernetes и наблюдението като инфраструктура са тема на курса ZeroToOps за DevOps, не на този урок.

Виж го

Складът по мрежата

Складът е отделна услуга. В програмата „мрежата“ е обект със записан сценарий: на всяко съобщение отговаря ok, no или мълчи (timeout). Поръчките виждат само API-то reserve и не знаят, че отзад е мрежа:

// Мрежата е записан сценарий: "ok", "no" или "timeout"
class Network {
  sent = 0;


  constructor(...script) {
    this.script = script;
  }


  send(message) {
    this.sent++;
    return this.script.shift();
  }
}


// Складът като отделна услуга: всяко извикване е съобщение
class RemoteWarehouse {
  constructor(network) {
    this.network = network;
  }


  reserve(sku, qty) {
    const answer = this.network.send(`reserve ${sku} ${qty}`);
    if (answer === "timeout") throw new Error("складът не отговаря");
    return answer === "ok";
  }
}


// Поръчките не знаят дали складът е модул, или услуга
class Orders {
  constructor(warehouse) {
    this.warehouse = warehouse;
  }


  place(sku, qty) {
    try {
      if (!this.warehouse.reserve(sku, qty)) return "няма наличност";
      return "приета";
    } catch (e) {
      return "чака: " + e.message;
    }
  }
}
const network = new Network("ok", "timeout", "no");
const orders = new Orders(new RemoteWarehouse(network));
for (let i = 1; i <= 3; i++)
  console.log(`Поръчка ${i}: ${orders.place("KTL-100", 1)}`);
console.log("Съобщения по мрежата: " + network.sent);
Изход
Поръчка 1: приета
Поръчка 2: чака: складът не отговаря
Поръчка 3: няма наличност
Съобщения по мрежата: 3

Втората поръчка не знае дали бройката е запазена: складът може да е получил съобщението и да е отговорил, а отговорът да се е изгубил. В модула този въпрос не съществуваше.

Пробвай

Предвиди изхода

Мрежата мълчи два пъти, после отговаря ok. Какво печата програмата?

const network = new Network("timeout", "timeout", "ok");
const orders = new Orders(new RemoteWarehouse(network));
for (let i = 1; i <= 3; i++)
  console.log(`Поръчка ${i}: ${orders.place("KTL-100", 1)}`);
console.log("Съобщения по мрежата: " + network.sent);
Отговор

Идеята

Кога услугите вредят

  • Твърде рано. Нов магазин с един екип и десет услуги плаща цялата цена на мрежата, без да има нужда от независим deploy. Границите още не са ясни, а преместването на граница между услуги е много по-скъпо, отколкото между модули.
  • Разпределен монолит. Услуги, които трябва да се пускат заедно и се викат една друга при всяка заявка, имат всички недостатъци на монолита и на услугите наведнъж.
  • Обща база. Две услуги, които пишат в едни и същи таблици, са проблемът от началото на урока, само че през мрежата.

Затова честият път е първо модулен монолит: ясни модули в един процес и проверка на границите. Модул, който наистина има нужда да е отделен, излиза като услуга. Това е лесно, ако вече има API и свои данни, както складът в сцената.

По-точно, за любопитните

Рамките. Една услуга е обикновено приложение: Spring Boot, ASP.NET Core, FastAPI или Django, Express или Nest. Услугите си говорят по HTTP (REST, gRPC) или през брокер на съобщения (Kafka, RabbitMQ). Отпред често стои API gateway: един вход, който пренасочва заявките към услугите и проверява входа.

Законът на Conway. Системите приличат на организацията, която ги прави: три екипа правят система от три части. Затова границите на услугите често следват екипите.

Проверка на границите. ArchUnit (Java) и ArchUnitNET или NetArchTest (C#) пишат проверката като тест. import-linter (Python) и dependency-cruiser (JavaScript) я пишат като правила в конфигурация. Spring Modulith (Java) и Nx (JavaScript) знаят и за модулите.

Колко голяма е услугата. „Micro“ не е размер в редове. Добрата граница е тази, през която минават малко извиквания, а зад която има данни, които никой друг не пише.

Упражнение

Цикъл между модулите

Реши задачата в редактора си.

Някой е позволил и warehouse → orders. Сега двата модула зависят един от друг. Напиши функция, която получава картата „кой от кои може да зависи“ и намира всяка двойка модули, които зависят един от друг. Всяка двойка се печата веднъж, по азбучен ред.

Изход
✗ orders ↔ warehouse
Нарушения: 1

Още задачи

  • Цикъл през три модула. orders → warehouse → invoices → orders също е цикъл. Намери го с обхождане в дълбочина (урокът DFS има намиране на цикъл).
  • Таблиците. Добави към проверката кой модул чия таблица чете (invoices чете orders.rows) и печатай всяка таблица, която ползва повече от един модул.

Тест

Провери се

1. Какво прави един модул модул, а не просто папка?
2. Поръчките пишат направо в таблицата stock. Каква е бедата?
3. Кое е добра причина да отделиш склада като услуга?
4. Складът е услуга и не отговаря. Какво от изброеното е нов проблем, който монолитът нямаше?
5. Проверката на границите е позволила orders → warehouse и warehouse → orders. Защо е лошо?

Създаден от Иво Гергов като част от кампанията на Evo Tech за достъпно обучение по програмиране ·