Архитектурын хэв маягийг сонгох (3-р хэсэг)

Сайн уу, Хабр. Өнөөдөр би хичээлийн шинэ урсгалыг эхлүүлэхийн тулд тусгайлан бичсэн цуврал нийтлэлээ үргэлжлүүлж байна. "Програм хангамжийн архитектор".

Танилцуулга

Архитектурын хэв маягийг сонгох нь мэдээллийн системийг бий болгох техникийн үндсэн шийдвэрүүдийн нэг юм. Энэхүү цуврал нийтлэлд би барилгын хэрэглээний хамгийн алдартай архитектурын хэв маягт дүн шинжилгээ хийж, аль архитектурын хэв маягийг хэзээ илүүд үздэг вэ гэсэн асуултанд хариулахыг санал болгож байна. Танилцуулгын явцад би цул хэлбэрээс микро үйлчилгээ хүртэлх архитектурын хэв маягийн хөгжлийг тайлбарласан логик хэлхээг зурахыг хичээх болно.

Өнгөрсөн удаад бид цулуудын янз бүрийн төрлүүд болон тэдгээрийг бүтээхэд ашигладаг бүрэлдэхүүн хэсгүүдийн талаар, угсралтын бүрэлдэхүүн хэсгүүд болон байршуулах бүрэлдэхүүн хэсгүүдийн талаар ярилцсан. Бид үйлчилгээнд чиглэсэн архитектурыг ойлгодог.

Одоо бид эцэст нь микро үйлчилгээний архитектурын үндсэн шинж чанаруудыг тодорхойлох болно.

Архитектуруудын харилцаа

Өмнөх нийтлэлүүдэд өгөгдсөн тодорхойлолтууд дээр үндэслэн аливаа үйлчилгээ нь бүрэлдэхүүн хэсэг боловч үйлчилгээ бүр микро үйлчилгээ биш гэдгийг ойлгох шаардлагатай.

Микросервис архитектурын шинж чанарууд

Микро үйлчилгээний архитектурын үндсэн шинж чанарууд нь:

  • Бизнесийн чадавхийн хүрээнд зохион байгуулагдсан
  • Төсөл биш бүтээгдэхүүн
  • Ухаалаг төгсгөлийн цэгүүд ба дүлий хоолой
  • Төвлөрсөн бус засаглал
  • Төвлөрсөн бус мэдээллийн менежмент
  • Дэд бүтцийн автоматжуулалт
  • Бүтэлгүйтэлд зориулсан загвар
  • Хувьслын хөгжил бүхий архитектур (Evolutionary Design)

1-р цэг нь үйлчилгээнд чиглэсэн архитектураас гаралтай, учир нь микро үйлчилгээ нь үйлчилгээний онцгой тохиолдол юм. Бусад цэгүүдийг тусад нь авч үзэх нь зүйтэй.

Бизнесийн чадавхийн хүрээнд зохион байгуулагдсан

Одоо Конвейн хуулийг санаж байх хэрэгтэй: системийг бий болгодог байгууллагууд тэдгээрийн архитектурыг зохион байгуулж, эдгээр байгууллагуудын харилцан үйлчлэлийн бүтцийг хуулбарладаг. Жишээлбэл, бид эмхэтгэгчийг бүтээсэн тохиолдлыг санаж болно: долоон хүний ​​бүрэлдэхүүнтэй баг долоон дамжуулалттай хөрвүүлэгчийг, таван хүний ​​баг таван дамжилттай хөрвүүлэгчийг боловсруулсан.

Хэрэв бид цул болон микро үйлчилгээний талаар ярьж байгаа бол хөгжүүлэлтийг функциональ хэлтсүүд (арын хэсэг, фронт, мэдээллийн баазын администраторууд) зохион байгуулдаг бол бид сонгодог цул хэлбэрийг авах болно.

Бичил үйлчилгээ авахын тулд багууд бизнесийн чадвараар (захиалга, тээвэрлэлт, каталогийн баг) зохион байгуулагдах ёстой. Энэ байгууллага нь багууд програмын тодорхой хэсгийг бүтээхэд анхаарлаа төвлөрүүлэх боломжийг олгоно.

Төсөл биш бүтээгдэхүүн

Баг нь боловсруулсан функцийг бусад баг руу шилжүүлэх төслийн арга нь микро үйлчилгээний архитектурын хувьд огт тохиромжгүй юм. Баг нь системийг амьдралынхаа туршид дэмжих ёстой. Микросервисийг хэрэгжүүлэх тэргүүлэгчдийн нэг Амазон: "Чи барьдаг, та үүнийг ажиллуулдаг" гэж хэлсэн. Бүтээгдэхүүний хандлага нь багийнханд бизнесийн хэрэгцээг мэдрэх боломжийг олгодог.

Ухаалаг төгсгөлийн цэгүүд ба дүлий хоолой

SOA архитектур нь харилцааны суваг, ялангуяа Enterprise Service Bus-д ихээхэн анхаарал хандуулсан. Энэ нь ихэвчлэн алдаатай спагетти хайрцагт хүргэдэг, өөрөөр хэлбэл цул хэлбэрийн нарийн төвөгтэй байдал нь үйлчилгээний хоорондын холболтын нарийн төвөгтэй байдал болж хувирдаг. Микросервис архитектур нь зөвхөн энгийн харилцааны аргуудыг ашигладаг.

Төвлөрсөн бус засаглал

Микро үйлчилгээний талаарх гол шийдвэрийг тухайн микро үйлчилгээг хөгжүүлдэг хүмүүс гаргах ёстой. Энд гол шийдвэр нь сонголт гэсэн үг
програмчлалын хэл, байршуулах арга зүй, нийтийн интерфейсийн гэрээ гэх мэт.

Төвлөрсөн бус мэдээллийн менежмент

Програм нь нэг мэдээллийн санд тулгуурладаг стандарт арга нь тодорхой үйлчилгээ бүрийн онцлогийг харгалзан үзэх боломжгүй юм. MSA нь янз бүрийн технологийг ашиглах зэрэг төвлөрсөн бус мэдээллийн менежментийг хамардаг.

Дэд бүтцийн автоматжуулалт

MSA нь тасралтгүй байршуулах, хүргэх үйл явцыг дэмждэг. Үүнийг зөвхөн процессыг автоматжуулах замаар л хийх боломжтой. Үүний зэрэгцээ олон тооны үйлчилгээг ашиглах нь аймшигтай зүйл мэт харагдахаа больсон. Байршуулах үйл явц нь уйтгартай байх ёстой. Хоёрдахь тал нь бүтээгдэхүүний орчин дахь үйлчилгээний менежменттэй холбоотой. Автоматжуулалтгүйгээр янз бүрийн үйлдлийн орчинд ажиллаж буй процессуудыг удирдах боломжгүй болно.

Бүтэлгүйтэлд зориулсан загвар

Олон тооны MSA үйлчилгээ нь бүтэлгүйтэх хандлагатай байдаг. Үүний зэрэгцээ тархсан систем дэх алдаатай ажиллах нь тийм ч энгийн ажил биш юм. Хэрэглээний архитектур нь ийм бүтэлгүйтэлд тэсвэртэй байх ёстой. Ребекка Парсонс бид үйлчилгээнүүдийн хооронд үйл явцын харилцаа холбоог ашиглахаа больсон нь маш чухал гэж үзэж байгаа бөгөөд үүний оронд бид HTTP холболтыг ашигладаг бөгөөд энэ нь тийм ч найдвартай биш юм.

Хувьслын хөгжил бүхий архитектур (Evolutionary Design)

MSA системийн архитектур хувьслын замаар хөгжих ёстой. Нэг үйлчилгээний хил хязгаарт шаардлагатай өөрчлөлтүүдийг хязгаарлах нь зүйтэй. Бусад үйлчилгээнд үзүүлэх нөлөөллийг бас анхаарч үзэх хэрэгтэй. Уламжлалт арга бол энэ асуудлыг хувилбараар шийдэхийг оролдох боловч MSA хувилбарыг ашиглахыг санал болгож байна
эцсийн арга зам.

дүгнэлт

Дээр дурдсан бүхний дараа бид микро үйлчилгээ гэж юу болохыг томъёолж болно. Микросервис архитектур нь нэг программыг жижиг үйлчилгээнүүдийн цуглуулга болгон хөгжүүлэх хандлага бөгөөд тус бүр нь өөрийн процессоор ажилладаг бөгөөд хөнгөн механизмууд, ихэвчлэн HTTP нөөцийн API-ээр дамжуулан харилцан үйлчилдэг. Эдгээр үйлчилгээнүүд нь бизнесийн чадавх дээр суурилагдсан бөгөөд тэдгээрийг бүрэн ашиглан бие даан ашиглах боломжтой
автоматжуулсан байршуулах механизм. Эдгээр үйлчилгээний төвлөрсөн удирдлагын доод түвшин байдаг бөгөөд үүнийг өөр өөр програмчлалын хэлээр бичиж, өөр өөр өгөгдөл хадгалах технологийг ашиглаж болно.

Архитектурын хэв маягийг сонгох (3-р хэсэг)

2-р хэсгийг уншина уу

Эх сурвалж: www.habr.com

сэтгэгдэл нэмэх