Микро үйлчилгээний оргил үе ард хоцорч байх шиг байна. Бид "Би хэрхэн 150 үйлчилгээ рүү өөрийн цул шилжсэн" гэсэн нийтлэлийг долоо хоногт уншихаа больсон. Одоо би илүү үндэслэлтэй бодлыг сонсож байна: "Би цул чулууг үзэн яддаггүй, зөвхөн үр ашгийг анхаарч үздэг." Бид хэд хэдэн шилжилт хөдөлгөөнийг хүртэл харсан. Нэг том програмаас хэд хэдэн жижиг үйлчилгээ рүү шилжих үед та хэд хэдэн шинэ сорилтыг шийдвэрлэх шаардлагатай болно. Бид тэдгээрийг товчхон жагсаах болно.
Суурилуулалт: Хими үндсэн хичээлээс квант механик хүртэл
Суурь мэдээллийн сан болон суурь процесс бүхий програмыг тохируулах нь нэлээд энгийн үйл явц байсан. Би Github дээр уншсан нийтлэлээ нийтэлдэг бөгөөд ихэвчлэн нэг цагийн дотор, эсвэл хамгийн ихдээ хоёр цагийн дотор бүх зүйл хэвийн болж, шинэ төсөл рүү явж байна. Ядаж эхний орчинд код нэмэх, ажиллуулах нь эхний өдөр хийгддэг. Гэхдээ хэрэв бид микро үйлчилгээнд хамрагдах юм бол эхлүүлэх анхны хугацаа огцом өсдөг. Тийм ээ, бид одоогоор Docker-тэй, K8 машинуудын кластертай, гэхдээ шинэхэн програмистын хувьд энэ бүхэн илүү төвөгтэй байдаг. Олон залуу хөгжүүлэгчдийн хувьд энэ ачаалал үнэхээр шаардлагагүй нарийн төвөгтэй байдлыг илэрхийлдэг.
Системийг ойлгоход хэцүү байдаг
Хэсэгхэн хугацаанд бага насны төсөлдөө анхаарлаа хандуулцгаая. Цул программуудын тусламжтайгаар алдаа гарсан тохиолдолд шууд хайж олох, дибаг хийхэд хялбар байсан. Одоо бидэнд өөр үйлчилгээтэй ярилцдаг, мессежийн автобусанд ямар нэг зүйлийг дараалалд оруулдаг, өөр үйлчилгээг боловсруулдаг үйлчилгээ байдаг бөгөөд дараа нь алдаа гардаг. А үйлчилгээ нь 11-р хувилбарыг ажиллуулж байгаа бөгөөд E үйлчилгээ аль хэдийн 12-р хувилбарыг хүлээж байгаа гэдгийг ойлгохын тулд бид эдгээр бүх хэсгүүдийг нэгтгэх ёстой. Энэ нь миний стандарт нэгдсэн бүртгэлээс тэс өөр юм: Би үйл явцыг алхам алхмаар даван туулахын тулд интерактив терминал/дибаглагч ашиглах ёстой. Дибаг хийх, ойлгох нь угаасаа илүү хэцүү болсон.
Хэрэв бид тэдгээрийг дибаг хийх боломжгүй бол тэдгээрийг туршиж үзэх боломжтой.
Тасралтгүй интеграци, тасралтгүй хөгжил өнөө үед ердийн зүйл болж байна. Миний харж буй ихэнх шинэ программууд хувилбар бүрээр автоматаар тест үүсгэж, ажиллуулдаг бөгөөд бүртгүүлэхээс өмнө тестийг давж, шалгахыг шаарддаг. Эдгээр нь орхиж болохгүй маш сайн үйл явц юм; Тэд олон компанийн хувьд томоохон өөрчлөлт болсон. Харин одоо үйлчилгээг үнэхээр туршихын тулд би өөрийн программын бүрэн хувилбарыг ашиглах ёстой. 150 үйлчилгээний K8 кластер бүхий шинэ инженерийг санаж байна уу? За, одоо бид CI системдээ бүх зүйл үнэхээр ажиллаж байгаа эсэхийг шалгахын тулд эдгээр бүх системийг хэрхэн ашиглахыг заах болно. Энэ нь хэтэрхий их хүчин чармайлт гаргаж магадгүй тул бид хэсэг бүрийг тусад нь туршиж үзэх болно: Манай техникийн үзүүлэлтүүд сайн, API нь цэвэр, үйлчилгээний доголдол тусгаарлагдсан бөгөөд бусдад нөлөөлөхгүй гэдэгт би итгэлтэй байна.
Бүх буулт сайн шалтгаантай, тийм ээ?
Микро үйлчилгээ рүү шилжих олон шалтгаан бий. Би үүнийг илүү их авхаалж самбаа, багийн цар хүрээг нэмэгдүүлэх, гүйцэтгэлийн төлөө, илүү сайн тэсвэрлэхийн тулд хийснийг харсан. Гэвч бодит байдал дээр бид цул хөгжлийн хэрэгсэл, практикт хэдэн арван жил хөрөнгө оруулалт хийсэн бөгөөд тэдгээр нь өөрчлөгдсөөр байна. Би янз бүрийн технологийн чиглэлээр мэргэжлийн хүмүүстэй ажилладаг. Тэд нэг Postgres мэдээллийн сангийн зангилааны хязгаарт нэвтэрч байгаа тул бид ихэвчлэн масштабын тухай ярьдаг. Ярилцлагын ихэнх хэсэг нь эргэн тойронд эргэлддэг .
Гэхдээ би тэдний архитектурын талаар суралцах сонирхолтой байдаг. Тэд бичил үйлчилгээнд шилжих ямар үе шатанд байна. Цул хэрэглээнд сэтгэл хангалуун байгаа инженерүүд улам олон болж байгаа нь сонирхолтой юм. Бичил үйлчилгээ нь олон хүнд ашиг тустай байх бөгөөд үр өгөөж нь шилжилт хөдөлгөөний зам дахь овойлтоос илүү байх болно. Харин миний хувьд миний цул аппликейшн, далайн эрэг дээрх газар өг, би үнэхээр баяртай байна.
Эх сурвалж: www.habr.com
