ми повернулися до повного кола з мікросервісами, повертаючись до дуже старих підходів до школи?

Що стосується архітектури та дизайну програмного забезпечення, то як мікросервіси "складаються" (призначені каламбури) проти проміжного програмного забезпечення? Я приїжджаю з Java, і здається, що, як ви віддаляєтесь від прямої програми REST як API, і абстрагуєтесь від різних шарів та параметрів підключення, принаймні на Java, ви майже повернулися до повного кола до деяких дуже старих шкільних ідей . Ми повернулися до віртуалізації ... коли JVM вже віртуальний.

Агностично, ви можете, і я можу стверджувати свої переваги, абстрагуючи RESTful API на CORBA. Або, більш орієнтованим на Java, JMS або MDB.

Свого часу EJB була великою справою в Java, тоді вона була визнана трохи кластерним eff, але тепер ми повернулися до початку?

Або пропонують мікросервіси те, чого бракує CORBA, а ще краще, MDB? Коли я читаю (TLDR) Мартіна Фаулера, що пояснює мікросервіси, це вважає мене гарним рішенням поганої проблеми, якщо ви хочете. А точніше, закритий підхід, який вводить рівень складності, лише розсуваючи проблему. Якщо послуги справді є мікро- та численними, то для запуску та утримання кожного з них має долар.

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

Звичайно, між цими крайнощами існує невизначена кількість варіантів.

Акула проти горили ... йди! (Для педантичності це означає бути іронічним, і це зовсім не мій намір. Питання має бути прийнято за номінал. Якщо питання можна вдосконалити, будь ласка, зробіть це, або прокоментуйте, і я виправлю. )

Уявіть безліч мікросервісів, що працюють у докері, все на одній машині, спілкуючись один з одним ... божевілля. Складно підтримувати чи адмініструвати, а поруч неможливо ніколи щось змінити, оскільки будь-яка зміна стане каскадом і спричинить непередбачувані помилки. Як якось краще, що ці служби розкидані по різних машинах? І якщо вони розподілені, то, безумовно, деякі дуже, дуже старі шкільні методи вирішили, принаймні, до певної міри, розподілили обчислення.

Чому горизонтальне масштабування настільки поширене або хоча б бажане?

TL; DR. Мені було приємно пити багато ароматизованих Kool-Aid ароматизованих мікросервером, тож я можу трохи поговорити про причини, які стоять за ними.

Плюси:

• Служби знають, що їх залежність стабільна і встигли виправитись
• Дозволити розгортання нових версій
• Дозвольте повернути компоненти, не впливаючи на більш високі шари.

Мінуси:

• Ви не можете використовувати нові та блискучі функції своїх залежностей.
• Ніколи не можна порушувати сумісність API назад (або принаймні не для багатьох циклів розвитку).

Я думаю, що ви принципово неправильно розумієте, як має працювати мікросервісна архітектура. Як його слід запускати, це те, що кожен мікросервіс (згаданий тут як MS) має жорсткий API, з яким погоджуються всі його клієнти. MS може вносити будь-які потрібні зміни, поки API зберігається. MS можуть бути викинуті та переписані з нуля, доки API зберігається.

Щоб допомогти в розв'язанні зв'язку, кожна MS залежить від версії n-1 її залежностей. Це дозволяє поточній версії послуги бути менш стабільною та трохи більш ризикованою. Це також дозволяє версії виходити хвилями. Спочатку оновлено 1 сервер, потім половину і, нарешті, решту. Якщо в поточній версії колись виникають якісь серйозні проблеми, MS можна повернути до попередньої версії, не втрачаючи функціональності в інших шарах.

Якщо API потрібно змінити, він повинен бути змінений таким чином, щоб він був сумісний назад.

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

Щодо слабкої зв'язку, я думаю, ви трохи зрозуміли мету. Якщо завдання A потребує виклику завдання B, способи зробити А і В 100% роз'єднаними, ніколи не буде. Ніколи не відбудеться. Що ви можете зробити, це переконатися, що якщо завдання B називає завдання C, то завдання C ніколи не повинно турбуватися про зміни в A. Якщо ці три завдання пов'язані між собою в одну велику крапку, передаючи структури один одному, тоді є великий шанс, що їм доведеться все змінити, якщо хтось із них зробить це. Але якщо всі три мікросервіси, то ви, в основному, гарантовані, що зміна на A змусить B лише оновитись (якщо тільки це не така велика зміна основних функціональних можливостей A, що ви, мабуть, мали б зробити це абсолютно новим сервісом). Особливо це стосується тих випадків, коли всі оновлення мікросервісів проводяться на сумісному рівні, яким вони повинні бути.

Щодо спритного коментаря, я можу вам сказати з особистого досвіду, що наш код мікросервісу-y грає набагато краще з гнучким, ніж наш код, "пов'язаний у велику крапку". В останньому, кожен раз, коли хтось виправить помилку у функції низького рівня, він буквально повинен надіслати цілий відділ НДДКР електронною поштою із повідомленням: "Будь ласка, перейдіть наново свої завдання, інакше всі вони завершаться в п’ятницю". Ми отримуємо пару таких щотижня . Якби його код знаходився в мікросервісі, ми автоматично отримали б користь від виправлення, як тільки він розгорнув нову версію.

Я не повністю розумію коментар щодо COBRA та MDB, оскільки вони, здається, не є архітектурою програмного забезпечення, а скоріше компонентами однієї; наскільки я розумію, вони є потенційними способами визначення протоколів обміну повідомленнями ваших мікросервісів та / або реалізації зазначених мікросервісів, а не самі по собі альтернативи мікросервісам.

Як якось краще, що ці служби розкидані по різних машинах?

Через хмару.

Ви ще сміялися? Але якщо серйозно - для багатьох підприємств найбільша вартість програмного забезпечення вже не є програмним забезпеченням. Це пропускна здатність, апаратне забезпечення, вартість CDN і т. Д. Тепер, коли кожен має мобільний пристрій, трафіку є набагато більше. І це тільки погіршиться, коли ваш тостер набуде власного підключення до Інтернету.

Тож бізнес прагне керувати цими витратами. Зокрема, вони намагаються вирішити бізнес-проблему: "якщо ця річ підірється, як я можу обслуговувати мільйони людей, які отримують / користуються моїм програмним забезпеченням, - не платячи достроково серверам, щоб обслуговувати мільйони людей, які отримують / використовують моє програмне забезпечення ? ".

Чому горизонтальне масштабування настільки поширене або хоча б бажане?

Тому що це відповідає на цю (величезну і зростаючу) проблему бізнесу.

Коли у вас є десяток користувачів, ви можете кинути всі сервіси за один ящик. Це добре, оскільки ви хочете заплатити лише за одну коробку. І ви також не хочете платити за зміни в додатку, щоб розділити різні послуги, коли ваш бізнес масштабується. У наші дні у вас немає часу на це, перш ніж натовп клієнтів запалює ваші сервери.

Це також добре, тому що дозволяє перевмикати розподіли сервера, щоб ви могли:

1. використовуйте більшість серверів, які у вас є, залишаючи мало «витрачати».
2. вимірюйте ефективність окремих елементів вашого програмного забезпечення.
3. скоротити час розгортання / зупинки, спричинене випусками.

Наявність дуже деталізованих розгортань робить ці дві речі легшими / кращими (крім того, що допомагають забезпечити кращий розбір проблем).