Микросервистердин туу чокусу артта калды окшойт. Биз мындан ары жумасына бир нече жолу "Мен монолитимди 150 кызматка кантип жылдырдым" деген постторду окубайбыз. Азыр мен көбүрөөк акылдуу ойлорду угуп жатам: "Мен монолитти жек көрбөйм, мен жөн гана натыйжалуулукка кам көрөм". Атүгүл бир нече миграцияны байкадык . Бир чоң тиркемеден бир нече кичине кызматтарга өтүүдө сиз бир нече жаңы маселелерди чечүүгө туура келет. Аларды мүмкүн болушунча кыскача тизмелеп берели.
Орнотуу: негизги химиядан кванттык механикага чейин
Фон процесси менен негизги маалымат базасын жана тиркемени түзүү абдан жөнөкөй процесс болгон. Мен Readmeди Githubда жарыялайм - жана көбүнчө бир сааттан кийин, эң көп дегенде бир-эки сааттан кийин баары иштейт жана мен жаңы долбоорду баштайм. Кодду кошуу жана иштетүү, жок эле дегенде, баштапкы чөйрө үчүн, биринчи күнү жасалат. Бирок, эгерде биз микросервистерге кирсек, баштапкы ишке киргизүү убактысы асмандап кетет. Ооба, азыр бизде оркестри бар Docker жана K8 машиналарынын кластери бар, бирок башталгыч программист үчүн мунун баары алда канча татаал. Көптөгөн юниорлор үчүн бул, чынында эле, керексиз татаалдык болуп саналат.
Системаны түшүнүү оңой эмес
Бир азга кенжебизге токтололу. Монолиттик тиркемелерде ката кетсе, аны байкап, дароо мүчүлүштүктөрдү оңдоого өтүү оңой эле. Азыр бизде башка кызмат менен сүйлөшүп жаткан кызмат бар, ал башка кызматты иштетип жаткан билдирүү автобусунда бир нерсе кезекте турат - анан ката пайда болот. Мы должны собрать воедино все эти части, чтобы в конечном итоге узнать, что служба А работает в версии 11, а служба Е уже ожидает версию 12. Это сильно отличается от моего стандартного консолидированного журнала: приходится использовать интерактивный терминал/отладчик, чтобы пройти через процесс кадам артынан кадам. Мүчүлүштүктөрдү оңдоо жана түшүнүү табиятынан кыйыныраак болуп калды.
Эгер аны оңдоо мүмкүн болбосо, балким, биз аларды сынап көрөбүз
Үзгүлтүксүз интеграция жана үзгүлтүксүз өнүгүү азыр көнүмүш көрүнүшкө айланууда. Мен көргөн жаңы колдонмолордун көбү автоматтык түрдө ар бир жаңы чыгарылыш менен тесттерди түзүп, иштетет жана каттоодон мурун тесттерди тапшырып, карап чыгууну талап кылат. Бул чоң процесстер, аларды таштап коюуга болбойт жана көптөгөн компаниялар үчүн чоң өзгөрүү болгон. Бирок азыр, кызматты чындап сынап көрүү үчүн, мен колдонмомдун толук жумушчу версиясын чыгарышым керек. 8 кызматтын K150 кластери менен жаңы инженер эсиңиздеби? Эми биз CI тутумубузга бул системалардын бардыгын чындап эле иштеп жатканын текшерүү үчүн кантип үйрөтөбүз. Бул өтө эле көп күч-аракет жумшоо, ошондуктан биз ар бир бөлүктү өзүнчө сынап көрөбүз: мен биздин спецификацияларыбыз жетиштүү, API'лер таза жана кызматтын бузулушу обочолонуп, башкаларга таасирин тийгизбейт деп ишенем.
Бардык компромисстердин жакшы себеби бар. Туурабы?
Микросервистерге өтүүгө көптөгөн себептер бар. Мен муну ийкемдүүлүк үчүн, командаларды масштабдоо үчүн, аткарууну жакшыртуу жана туруктуулукту камсыз кылуу үчүн жасаганын көрдүм. Бирок, чындыгында, биз өнүгүп келе жаткан монолиттерди иштеп чыгуу үчүн ондогон жылдарды инструменттерге жана практикага жумшадык. Мен ар кандай технологиялар боюнча адистер менен иштейм. Биз, адатта, масштабдоо жөнүндө сүйлөшөбүз, анткени алар бир Postgres маалымат базасынын түйүнүнүн чегине кирет. Сүйлөшүүлөрдүн көбү жөнүндө .
Бирок мен ар дайым алардын архитектурасы менен таанышууга кызыгам. Алар микросервистерге өтүүнүн кайсы баскычында турат? Көбүрөөк инженерлердин монолиттүү колдонууга ыраазы экенин айтышы кызыктуу. Көптөгөн адамдар микросервистерден пайда көрүшөт, ал эми пайда миграция жолундагы кыйынчылыктардан ашып түшөт. Бирок жеке менин монолиттүү арызымды, пляждан орун бериңиз - мен толугу менен бактылуумун.
Source: www.habr.com