Перше спостереження

У свій час похерив Ubuntu при спробі знести системний python. В результаті відвалилась курсор і ще щось. Була доступна консоль без мережі.

Ось зараз дійшли руки поставити нову убунту. І тут стикнувся цікавою штукою, яка відповіла мені на питання навіщо потрібно логічний розділ і що primary може бути три. 

EFI потрібно ставити на primary і треба бути уважний скільки в наявності primary розділів.

https://www.pcmag.com/encyclopedia/term/extended-partition

Прочитав чудову статтю про мікросервіси в uber. Вони застосували DDD для мікросервісної архітектури. Тобто домени будуються на рівні мікросервісів. Назвали її “Domain-Oriented Microservice Architecture” (DOMA). 

Для взаємозв'язку використовують RPC мабуть gRPC.

Що вони спробували вирішити

• Availability Risks. Одинарна регресія в межах монолітної кодової бази може зруйнувати всю систему (в даному випадку весь Uber).
• Risky, expensive deployments. Були болючими та трудомісткими для виконання, з частими потребами у відкатах.
• Poor separation of concerns.  Важко підтрумвати розділ між логічними межами фіч.
• Inefficient execution. Моноліт не дає можливості збільшувати команду і без конфлікту в розробці.

Що вийшло по їх словам:

• System reliability. Загальна надійність системи зростає в архітектурі мікросервісу. Окремий сервіс може впасти (і відкотитися назад), не виводячи з ладу всю систему.
• Separation of concerns. Архітектурно мікросервісні архітектури змушують вас поставити запитання "чому ця послуга існує?" більш чітко визначити ролі різних компонентів.
• Clear Ownership. Стає набагато зрозуміліше, кому який код належав. Послуги, як правило, належать особі, команді чи організації, що забезпечує швидше зростання.
• Autonomous execution. Незалежні розгортання + чіткіші форми власності розблоковують автономне виконання різними командами продуктів і платформ.
• Developer Velocity. Команди можуть розгортати свій код самостійно, що дозволяє їм виконувати у своєму власному темпі.

Дуже непогано, на перший погляд. Але для підтримання порядку потрібно створити певну команду диригентів архітекторів, які повинні контролювати всю систему взагалі. Цікаво як там насправді побудований цей контроль.

Архітектурний базис:

• Domain-driven Design,
• Clean Architecture,
• Service-Oriented Architecture,
• object- and interface-oriented design patterns

1. Замість того, щоб зорієнтуватися навколо окремих мікропослуг, ми зосередилися на колекціях відповідних мікропослуг. Ми називаємо це домен.
2. Далі ми створюємо колекції доменів, які ми називаємо шарами. Шар, до якого належить домен, встановлює, які залежності можуть приймати мікросервіси в цьому домені. Ми називаємо цей дизайн шару.
3. Ми пропонуємо чисті інтерфейси для доменів, які ми розглядаємо як єдину точку входу до колекції. Ми називаємо це шлюзом.
4. Нарешті, ми встановлюємо, що кожен домен повинен бути агностичним щодо інших доменів, тобто домен не повинен мати логіки, пов’язаної з іншим доменом, кодованим всередині його кодової бази чи моделей даних. Оскільки часто командам потрібно включати логіку в домен іншої команди (наприклад, власну логіку перевірки або якийсь мета-контекст у моделі даних), ми пропонуємо архітектуру розширення для підтримки чітко визначених точок розширення в домені.

Дизайн шарів відповідає на питання "яка служба може назвати якусь іншу послугу?"

1. Infrastructure layer. Забезпечує функціональність, яку може використовувати будь-яка інженерна організація. Це відповідь Uber на великі інженерні питання, такі як зберігання даних або мережеві зв’язки.
2. Business layer. Забезпечує функціональність, яку Uber як організація може використовувати, але яка не є специфічною для певної категорії товару або напряму діяльності (LOB)
3. Product layer. Забезпечує функціональність, яка стосується певної категорії товару або LOB, але є агностичною для мобільного додатка, наприклад, логіка "запитувати поїздку", яка використовується декількома програмами для подорожей (Rider, Rider “Lite”, m.uber.com, etc).
4. Presentation. Надайте функціональність, яка безпосередньо пов’язана з функціями, які існують у програмі, спрямованій на споживача (mobile/web). 
5. Edge Layer. Безпечно піддає послуги Uber зовнішньому світу. Цей рівень також відомий мобільним додаткам.

Шлюзи

Термін "Gateway API" - це вже загальноприйняте поняття в архітектурі мікросервісів. Наше визначення не сильно відрізняється від усталеного визначення, за винятком того, що ми, як правило, думаємо про шлюзи виключно як про єдину точку входу до набору базових служб, які ми називаємо доменом

Розширення представляють механізм розширення доменів. Основне визначення розширення полягає в тому, що воно забезпечує механізм розширення функціональності базової послуги без зміни фактичної реалізації цієї послуги та не впливаючи на її загальну надійність. В Uber ми пропонуємо дві різні моделі розширень: логічні розширення та розширення даних. Концепція розширень дозволила нам масштабувати нашу архітектуру до кількох команд, здатних працювати незалежно одна від одної.

Результати перекладу

По-суті винесення програмних принципів з коду на рівень сервісів. Що на мою думку дуже логічний розвиток архітектури.

https://eng.uber.com/microservice-architecture/

image source by https://unsplash.com/@purzlbaum