Хабр дэлхийг өөрчилж байна. Бид жил гаруй блог хөтөлж байна. Зургаан сарын өмнө бид Хабаровскийн оршин суугчдаас нэлээд логик санал хүсэлтийг хүлээн авсан: "Додо, та өөрийн гэсэн системтэй гэж хаа сайгүй хэлдэг. Энэ ямар систем вэ? Тэгээд пиццаны сүлжээ яагаад хэрэгтэй байгаа юм бэ?"
Бид суугаад бодоод таны зөв гэдгийг ойлгосон. Бид хуруугаараа бүх зүйлийг тайлбарлах гэж оролдож байгаа боловч энэ нь урагдсан хэсгүүдээр гарч ирдэг бөгөөд системийн тухай бүрэн тайлбар хаана ч байхгүй. Ийнхүү мэдээлэл цуглуулах, зохиолчдыг хайх, Додо IS-ийн тухай цуврал нийтлэл бичих урт удаан аялал эхэлсэн. Явцгаая!
Талархал: Санал хүсэлтээ бидэнтэй хуваалцсанд баярлалаа. Түүний ачаар бид эцэст нь системийг тайлбарлаж, технорадар эмхэтгэсэн бөгөөд удахгүй үйл явцынхаа томоохон тайлбарыг гаргах болно. Та нар байгаагүй бол бид дахиад 5 жил ингэж суух байсан.
Цуврал нийтлэл "Додо IS гэж юу вэ?" тухай өгүүлдэг:
- Додо IS дахь эртний цул (2011-2015). (Явж байна...)
- Backoffice зам: тусдаа бааз, автобус. (Та энд байна)
- Үйлчлүүлэгчийн хажуугийн зам: суурийн дээгүүр фасад (2016-2017). (Явж байна...)
- Бодит микро үйлчилгээний түүх. (2018-2019). (Явж байна...)
- Цул хөрөөдөж, архитектурыг тогтворжуулах ажил дууссан. (Явж байна...)
Хэрэв та өөр зүйл сурах сонирхолтой байгаа бол сэтгэгдэл дээр бичээрэй.
Зохиогчийн он цагийн тайлбарын талаархи санал бодол
Би "Системийн архитектур" сэдвээр шинэ ажилтнуудад зориулсан уулзалтыг тогтмол хийдэг. Бид үүнийг "Dodo IS Architecture-ийн танилцуулга" гэж нэрлэдэг бөгөөд энэ нь шинэ хөгжүүлэгчдэд зориулсан элсэлтийн үйл явцын нэг хэсэг юм. Манай архитектур, түүний онцлог шинж чанаруудын талаар нэг хэлбэрээр ярихдаа би тодорхой түүхэн хандлагыг боловсруулсан.
Уламжлал ёсоор бид системийг зарим зорилгод хүрэхийн тулд бие биетэйгээ харьцдаг бүрэлдэхүүн хэсгүүд (техникийн эсвэл дээд түвшний), бизнесийн модулиуд гэж үздэг. Хэдийгээр ийм үзэл бодол нь дизайны хувьд үндэслэлтэй боловч энэ нь дүрслэх, ойлгоход бүрэн тохиромжгүй юм. Үүнд хэд хэдэн шалтгаан бий:
- Бодит байдал нь цаасан дээрхээс өөр. Бүх зүйл төлөвлөсний дагуу болдоггүй. Бүх зүйл хэрхэн болж, хэрхэн ажилладагийг бид сонирхож байна.
- Мэдээллийн тууштай танилцуулга. Үнэн хэрэгтээ та эхнээс нь одоогийн байдал хүртэл он цагийн дарааллаар явж болно.
- Энгийнээс нарийн төвөгтэй рүү. Бүх нийтийнх биш, гэхдээ манай тохиолдолд ийм байна. Архитектур нь энгийн арга барилаас илүү төвөгтэй арга руу шилжсэн. Ихэнхдээ хүндрэлээс болж хэрэгжилтийн хурд, тогтвортой байдлын асуудал, түүнчлэн функциональ бус шаардлагын жагсаалтаас олон арван шинж чанарууд гарч ирдэг ( нарийн төвөгтэй байдлыг бусад шаардлагуудтай харьцуулах талаар сайн ярьсан).
2011 онд Dodo IS архитектур дараах байдалтай байв.
2020 он гэхэд энэ нь арай илүү төвөгтэй болж, ийм болсон.
Энэ хувьсал хэрхэн болсон бэ? Яагаад системийн өөр өөр хэсгүүд хэрэгтэй вэ? Архитектурын ямар шийдвэр гаргасан, яагаад? Энэ цуврал нийтлэлээс олж мэдье.
2016 оны эхний асуудал: үйлчилгээ яагаад цул орхих ёстой вэ?
Цувралын эхний нийтлэлүүд нь цулгаас хамгийн түрүүнд тусгаарлагдсан үйлчилгээний тухай байх болно. 2016 оны эхээр системд ямар асуудал тулгарсан, үйлчилгээгээ салгах асуудлыг шийдвэрлэх шаардлагатай байсныг би танд хэлэх болно.
Dodo IS-д тухайн үед байсан бүх програмууд бүртгэлээ бичсэн MySql мэдээллийн нэгдсэн сан. Үр дагавар нь:
- Ачаалал ихтэй (хүсэлтийн 85% -ийг уншиж байна).
- Суурь нь өсч байв. Үүнээс болоод зардал, дэмжлэг асуудал болсон.
- Нэг бүтэлгүйтлийн цэг. Хэрэв мэдээллийн санд бичиж буй нэг програм гэнэт үүнийг илүү идэвхтэй хийж эхэлсэн бол бусад програмууд нөлөөллийг мэдэрсэн.
- Хадгалалт, асуулгын үр ашиггүй байдал. Ихэнх тохиолдолд өгөгдөл нь зарим хувилбарт тохиромжтой байсан ч зарим нэг бүтцэд хадгалагддаг байсан. Индексүүд нь зарим үйлдлийг хурдасгадаг боловч заримыг удаашруулж чаддаг.
- Зарим асуудлыг яаран хийсэн кэш, мэдээллийн санд хуулбарлах замаар шийдсэн (үүнийг тусдаа нийтлэлд авч үзэх болно), гэхдээ тэдгээр нь зөвхөн цаг хугацаа хожих боломжийг олгосон бөгөөд асуудлыг үндсээр нь шийдэж чадаагүй юм.
Асуудал нь цул өөрөө байгаа явдал байв. Үр дагавар нь:
- Өвөрмөц бөгөөд ховор хувилбарууд.
- Олон тооны хүмүүсийн хамтын хөгжилд бэрхшээлтэй байдаг.
- Шинэ технологи, шинэ хүрээ, номын санг нэвтрүүлэх чадваргүй байх.
Суурь ба цултай холбоотой асуудлуудыг жишээлбэл, 2018 оны эхээр болсон ослын хүрээнд олон удаа тайлбарласан байдаг (, и ), тиймээс би нэг их суухгүй. Бид үйлчилгээг хөгжүүлэхдээ илүү уян хатан байдлыг өгөхийг хүссэн гэдгийг хэлье. Юуны өмнө энэ нь бүхэл бүтэн системд хамгийн их ачаалалтай, үндэстэй байсан - Auth and Tracker-тэй холбоотой юм.
Арын оффисын зам: Тусдаа бааз, автобус
Бүлэг навигаци
2016 оны цул хавтангийн схем
2016 оны Dodo IS цул гол блокуудыг энд оруулав, тэдгээрийн үндсэн ажлуудын задаргааг доор харуулав.
Хүргэлтийн касс. Илгээгчийн нягтлан бодох бүртгэл, шуудан зөөгч нарт захиалга өгөх.
Холбоо барих төв. Оператороор дамжуулан захиалга хүлээн авна.
Сайтын. Манай вэбсайтууд (dodopizza.ru, dodopizza.co.uk, dodopizza.by гэх мэт).
Зохиогч. Backoffice-ийн зөвшөөрөл, баталгаажуулалтын үйлчилгээ.
Tracker. Гал тогооны захиалга хянагч. Захиалга бэлтгэх үед бэлэн байдлын статусыг тэмдэглэх үйлчилгээ.
Рестораны бэлэн мөнгөний ширээ. Ресторанд захиалга авч байна, кассын интерфейс.
Экспорт. Нягтлан бодох бүртгэлд зориулж 1С-д тайлан байршуулах.
Анхааруулга, нэхэмжлэх. Гал тогооны өрөөнд дуут тушаал өгөх (жишээлбэл, "Шинэ пицца ирлээ") + шуудан зөөгчдөд зориулсан нэхэмжлэх хэвлэх.
Ээлжийн менежер. Ээлжийн менежерийн ажлын интерфейс: захиалгын жагсаалт, бүтээмжийн график, ажилчдыг ээлжинд хүргэх.
Оффис менежер. Франчайз эзэмшигчид болон менежерүүдийн ажлын интерфейс: ажилчдыг хүлээн авах, пиццаны ажлын тайлан.
Рестораны самбар. Пиццаны газруудын зурагтаар цэсийг үзүүлж байна.
админ. Тодорхой пиццаны тохиргоо: цэс, үнэ, нягтлан бодох бүртгэл, сурталчилгааны код, урамшуулал, сайтын баннер гэх мэт.
Ажилтны хувийн данс. Ажилчдын ажлын хуваарь, ажилчдын талаарх мэдээлэл.
Гал тогооны урам зориг өгөх самбар. Гал тогооны өрөөнд өлгөөтэй тусдаа дэлгэц нь пицца үйлдвэрлэгчдийн хурдыг харуулдаг.
харилцаа холбоо. SMS болон имэйл илгээх.
FileStorage. Статик файлуудыг хүлээн авах, гаргах өөрийн үйлчилгээ.
Асуудлыг шийдвэрлэх анхны оролдлого нь бидэнд тусалсан боловч энэ нь зөвхөн түр зуурын амралт байсан. Эдгээр нь системийн шийдэл болж чадаагүй тул суурьтай холбоотой ямар нэг зүйл хийх шаардлагатай байсан нь тодорхой байв. Жишээлбэл, ерөнхий мэдээллийн санг хэд хэдэн тусгайлан хуваах.
Бид цулыг буулгаж эхэлдэг: Auth болон Tracker-ийг тусгаарлах
Дараа нь мэдээллийн сангаас бусдаас илүү бичиж, уншдаг гол үйлчилгээнүүд:
- Aut. Backoffice-ийн зөвшөөрөл, баталгаажуулалтын үйлчилгээ.
- Мөрдөгч. Гал тогооны захиалга хянагч. Захиалга бэлтгэх үед бэлэн байдлын статусыг тэмдэглэх үйлчилгээ.
Auth юу хийдэг вэ?
Auth нь хэрэглэгчид арын албанд нэвтэрдэг үйлчилгээ юм (үйлчлүүлэгч тал дээр тусдаа бие даасан нэвтрэлт байдаг). Зөв хандалтын эрх байгаа эсэх, хамгийн сүүлд нэвтэрснээс хойш эдгээр эрх өөрчлөгдөөгүй эсэхийг шалгах хүсэлтэд мөн иш татсан болно. Төхөөрөмжүүд үүгээр дамжин пицца руу ордог.
Жишээлбэл, бид танхимд өлгөөтэй зурагт дээр дууссан захиалгын статустай дэлгэцийг нээхийг хүсч байна. Дараа нь бид auth.dodopizza.ru сайтыг нээж, "Төхөөрөмжөөр нэвтрэх" -ийг сонгоод, ээлжийн менежерийн компьютер дээрх тусгай хуудсанд төхөөрөмж (төхөөрөмж) төрлийг зааж өгөх код гарч ирнэ. ТВ өөрөө пиццаныхаа хүссэн интерфэйс рүү орж захиалга нь бэлэн болсон үйлчлүүлэгчдийн нэрийг тэнд үзүүлж эхэлнэ.
Ачаалал хаанаас ирдэг вэ?
Нэвтэрсэн backoffice хэрэглэгч бүр хүсэлт бүрийн мэдээллийн сан, хэрэглэгчийн хүснэгтэд очиж, sql query-ээр дамжуулан хэрэглэгчийг татан авч, түүнд энэ хуудсанд шаардлагатай хандалт, эрх байгаа эсэхийг шалгадаг.
Төхөөрөмж бүр нь зөвхөн төхөөрөмжийн хүснэгттэй ижил үйлдэл хийж, түүний үүрэг, хандалтыг шалгадаг. Мастер мэдээллийн санд олон тооны хүсэлтүүд нь түүнийг ачаалж, эдгээр үйл ажиллагаанд мэдээллийн сангийн ерөнхий нөөцийг үрэхэд хүргэдэг.
Auth буулгаж байна
Auth нь тусгаарлагдсан домэйнтэй, өөрөөр хэлбэл хэрэглэгчид, нэвтрэлтүүд эсвэл төхөөрөмжүүдийн талаарх мэдээлэл үйлчилгээнд (одоогийн ирээдүйд) орж, тэндээ үлддэг. Хэрэв хэн нэгэнд хэрэгтэй бол тэр мэдээлэл авахын тулд энэ үйлчилгээнд очно.
БАЙСАН. Ажлын урсгал эхлээд дараах байдалтай байсан.
Энэ нь хэрхэн ажилласныг би бага зэрэг тайлбарлахыг хүсч байна:
- Гадны хүсэлт арын хэсэгт (Asp.Net MVC тэнд) ирдэг бөгөөд энэ нь Redis(1)-ээс сессийн өгөгдлийг авахад хэрэглэгддэг сесс күүкийг авчирдаг. Энэ нь хандалтын талаарх мэдээллийг агуулсан бөгөөд дараа нь хянагч руу хандах хандалт нээлттэй байна (3,4) эсвэл үгүй.
- Хэрэв нэвтрэх эрх байхгүй бол та зөвшөөрлийн процедурыг давах хэрэгтэй. Энд хялбар болгох үүднээс үүнийг ижил шинж чанарт замын нэг хэсэг болгон харуулсан боловч энэ нь нэвтрэх хуудас руу шилжих явдал юм. Эерэг хувилбар гарсан тохиолдолд бид зөв бөглөсөн сессийг хүлээн аваад Backoffice Controller руу очно.
- Хэрэв өгөгдөл байгаа бол та хэрэглэгчийн мэдээллийн санд хамааралтай эсэхийг шалгах хэрэгтэй. Түүний үүрэг өөрчлөгдсөн үү, түүнийг одоо хуудсанд оруулахгүй байх ёстой юу? Энэ тохиолдолд сессийг (1) хүлээн авсны дараа та мэдээллийн сан руу шууд очиж, баталгаажуулалтын логик давхарга (2) ашиглан хэрэглэгчийн хандалтыг шалгах хэрэгтэй. Дараа нь нэвтрэх хуудас руу очих эсвэл хянагч руу очно уу. Энэ бол энгийн систем боловч бүхэлдээ стандарт биш юм.
- Хэрэв бүх процедур дууссан бол бид хянагч, аргуудын логикийг алгасах болно.
Хэрэглэгчийн өгөгдөл нь бусад бүх өгөгдлөөс тусгаарлагдсан, тусдаа гишүүнчлэлийн хүснэгтэд хадгалагддаг, AuthService логик давхаргын функцууд нь API аргууд болж магадгүй юм. Домэйн хил хязгаарыг маш тодорхой тодорхойлсон: хэрэглэгчид, тэдгээрийн үүрэг, хандалтын өгөгдөл, хандалтыг олгох, цуцлах. Бүх зүйл тусдаа үйлчилгээ рүү шилжиж болох юм шиг байна.
БОЛСОН. Тэд үүнийг хийсэн:
Энэ арга нь хэд хэдэн асуудалтай байдаг. Жишээлбэл, процесс доторх аргыг дуудах нь http-ээр дамжуулан гадны үйлчилгээг дуудахтай адил биш юм. Үйл ажиллагааны хоцрогдол, найдвартай байдал, дэмжлэг, ил тод байдал нь огт өөр юм. Андрей Моревский илтгэлдээ яг эдгээр асуудлын талаар илүү дэлгэрэнгүй ярьсан .
Баталгаажуулалтын үйлчилгээ болон түүнтэй хамт төхөөрөмжийн үйлчилгээг арын албанд, өөрөөр хэлбэл үйлдвэрлэлд ашигладаг үйлчилгээ, интерфэйсүүдэд ашигладаг. Үйлчлүүлэгчийн үйлчилгээ (вэбсайт эсвэл гар утасны програм гэх мэт) баталгаажуулалт нь Auth ашиглахгүйгээр тусад нь хийгддэг. Тусгаарлах ажил нэг жил орчим үргэлжилсэн бөгөөд одоо бид энэ сэдвээр дахин ажиллаж, системийг шинэ баталгаажуулалтын үйлчилгээнд (стандарт протоколоор) шилжүүлж байна.
Яагаад салалт ийм удаан үргэлжилсэн бэ?
Энэ замд биднийг удаашруулсан олон асуудал байсан:
- Бид улс орны мэдээллийн сангаас хэрэглэгчид, төхөөрөмж, баталгаажуулалтын талаарх мэдээллийг нэг рүү шилжүүлэхийг хүссэн. Үүнийг хийхийн тулд бид бүх хүснэгт болон хэрэглээг int танигчаас дэлхийн UUId танигч руу шилжүүлэх шаардлагатай болсон (бид саяхан энэ кодыг дахин боловсруулсан. болон нээлттэй эхийн төсөл ). Хэрэглэгчийн мэдээллийг (энэ нь хувийн мэдээлэл учраас) хадгалах нь хязгаарлалттай бөгөөд зарим улс оронд үүнийг тусад нь хадгалах шаардлагатай байдаг. Гэхдээ дэлхийн хэрэглэгчийн ID байх ёстой.
- Мэдээллийн сангийн олон хүснэгтэд тухайн үйлдлийг гүйцэтгэсэн хэрэглэгчийн талаарх аудитын мэдээлэл байдаг. Энэ нь тууштай байдлыг хангах нэмэлт механизмыг шаарддаг.
- API үйлчилгээг бий болгосны дараа өөр систем рүү шилжих удаан, аажмаар үе байсан. Шилжүүлэгч нь хэрэглэгчдэд саадгүй байх ёстой бөгөөд гарын авлагын ажлыг шаарддаг.
Пиццаны газарт төхөөрөмжийг бүртгүүлэх схем:
Auth болон Devices үйлчилгээг салгасны дараа ерөнхий архитектур:
тайлбар. 2020 онд бид OAuth 2.0 зөвшөөрлийн стандарт дээр суурилсан Auth-ийн шинэ хувилбар дээр ажиллаж байна. Энэ стандарт нь нэлээд төвөгтэй боловч төгсгөлөөс төгсгөлд баталгаажуулалтын үйлчилгээг хөгжүүлэхэд хэрэгтэй. Нийтлэлд "» Бид Алексей Черняев стандартын талаар аль болох энгийн бөгөөд ойлгомжтой ярихыг хичээсэн бөгөөд ингэснээр та үүнийг судлах цагийг хэмнэх болно.
Tracker юу хийдэг вэ?
Одоо ачаалагдсан үйлчилгээний хоёр дахь тухай. Мөрдөгч нь давхар үүрэг гүйцэтгэдэг:
- Нэг талаас, түүний даалгавар бол гал тогооны өрөөнд байгаа ажилчдад одоогоор ямар захиалга хийгдэж байгаа, ямар бүтээгдэхүүн бэлтгэх шаардлагатай байгааг харуулах явдал юм.
- Нөгөөтэйгүүр, гал тогооны бүх үйл явцыг дижитал болгох.
Шинэ бүтээгдэхүүн (жишээ нь, пицца) захиалгаар гарч ирэхэд "Rolling" tracker станц руу очдог. Энэ станцад пицца хийдэг хүн шаардлагатай хэмжээтэй боов аваад өнхрүүлсний дараа таблет дээр даалгавраа гүйцэтгэсэн гэж тэмдэглэж, цувисан зуурмагийн суурийг дараагийн станц руу дамжуулдаг "Дүүргэх" .
Тэнд дараагийн пицца үйлдвэрлэгч пиццаны дээгүүр орж, дараа нь таблет дээрээ даалгавраа гүйцэтгэсэн гэж тэмдэглээд пиццагаа зууханд хийнэ (энэ нь мөн таблет дээр тэмдэглэгдсэн байх ёстой тусдаа станц юм). Ийм систем Додод анхнаасаа болон Додо IS-ийн эхэн үеэс л байсан. Энэ нь бүх үйл ажиллагааг бүрэн хянах, дижитал хэлбэрт оруулах боломжийг танд олгоно. Нэмж дурдахад трекер нь тодорхой бүтээгдэхүүнийг хэрхэн бэлтгэхийг санал болгож, бүтээгдэхүүн тус бүрийг өөрийн үйлдвэрлэлийн схемийн дагуу хийж, бүтээгдэхүүнийг хамгийн оновчтой хоол хийх хугацааг хадгалж, бүтээгдэхүүн дээрх бүх үйл ажиллагааг хянадаг.
Raskatka tracker станц дээр таблетын дэлгэц иймэрхүү харагдаж байна.
Ачаалал хаанаас ирдэг вэ?
Пиццаны газар бүрт трекер бүхий таван шахмал байдаг. 2016 онд бид 100 гаруй пиццатай байсан (одоо 600 гаруй болсон). Таблет тус бүр 10 секунд тутамд арын хэсэгт хүсэлт гаргаж, захиалгын хүснэгт (үйлчлүүлэгч болон хаягтай холбогдох холбоос), захиалгын бүтэц (бүтээгдэхүүнтэй холбогдох холбоос, тоо хэмжээг зааж өгөх), урам зоригийн хүснэгтээс (үүнийг дагаж мөрддөг) өгөгдлийг цуглуулдаг. дарах цаг). Пицца үйлдвэрлэгч трекер дээрх бүтээгдэхүүн дээр дарахад эдгээр бүх хүснэгтийн бүртгэл шинэчлэгддэг. Захиалгын хүснэгт нь ерөнхий бөгөөд энэ нь захиалгыг хүлээн авах үед оруулсан оруулгууд, системийн бусад хэсгүүдийн шинэчлэлтүүд, жишээлбэл, пиццанд өлгөгдсөн зурагт, бэлэн захиалгыг үйлчлүүлэгчдэд үзүүлэх гэх мэт олон тооны уншилтуудыг агуулдаг.
Ачаалалтай тэмцэж байх үед бүх зүйл, бүх зүйлийг кэш болгож, мэдээллийн сангийн асинхрон хуулбар руу шилжүүлэх үед трекертэй хийсэн эдгээр үйлдлүүд мастер мэдээллийн сан руу явсаар байв. Энд ямар ч хоцрогдол байх ёсгүй, өгөгдөл нь шинэчлэгдсэн байх ёстой, синхрончлолгүй байх нь хүлээн зөвшөөрөгдөхгүй.
Мөн бидний өөрсдийн хүснэгт, тэдгээрийн индекс байхгүй байсан нь бидний хэрэглээнд тохирсон илүү тодорхой асуулга бичих боломжийг бидэнд олгосонгүй. Жишээлбэл, захиалгын хүснэгтэд пиццаны индекс байх нь трекерийн хувьд үр дүнтэй байж болох юм. Бид пиццаны захиалгыг трекерийн мэдээллийн сангаас байнга хусдаг. Үүний зэрэгцээ захиалгыг хүлээн авахын тулд аль пиццанд орох нь тийм ч чухал биш бөгөөд аль үйлчлүүлэгч энэ захиалгыг хийсэн нь илүү чухал юм. Энэ нь үйлчлүүлэгч дээр индекс байх ёстой гэсэн үг юм. Мөн захиалгын хүснэгтэд захиалгатай холбоотой хэвлэсэн баримт эсвэл урамшууллын урамшууллын ID-г мөрдөгч хадгалах шаардлагагүй. Манай трекер үйлчилгээ энэ мэдээллийг сонирхохгүй байна. Түгээмэл цул мэдээллийн санд хүснэгтүүд нь зөвхөн бүх хэрэглэгчдийн хоорондын тохироо байж болно. Энэ бол анхны бэрхшээлүүдийн нэг байсан.
БАЙСАН. Эхэндээ архитектур нь дараах байдалтай байсан.
Тусдаа процессуудад хуваагдсан ч ихэнх кодын суурь нь өөр өөр үйлчилгээнүүдэд нийтлэг хэвээр байв. Удирдлагын доор байгаа бүх зүйл нэгдмэл байсан бөгөөд нэг агуулахад амьдардаг байв. Үйлчилгээний нийтлэг аргууд, репозиторууд, нийтлэг хүснэгтүүдийг агуулсан нийтлэг мэдээллийн санг ашигласан.
Tracker-г буулгаж байна
Tracker-ийн гол асуудал бол өгөгдөл нь өөр өөр мэдээллийн баазуудын хооронд синхрончлогдсон байх ёстой. Энэ нь Auth үйлчилгээний хуваагдлаас гол ялгаа нь бөгөөд дараалал, статус нь өөрчлөгдөж болох бөгөөд үүнийг янз бүрийн үйлчилгээнд харуулах ёстой.
Бид рестораны касс дээр захиалга хүлээн авдаг (энэ нь үйлчилгээ), мэдээллийн санд "Хүлээн зөвшөөрсөн" төлөвт хадгалагддаг. Үүний дараа тэрээр "Гал тогоо" -оос "Савласан" гэсэн статусаа хэд хэдэн удаа өөрчлөх болно. Энэ тохиолдолд кассчин эсвэл ээлжийн менежерийн интерфейсээс зарим гадны нөлөөлөл нь захиалгатай холбоотой байж болно. Би захиалгын статусыг хүснэгтэд тайлбарын хамт өгөх болно.
Захиалгын статусыг өөрчлөх схем дараах байдалтай байна.
Төрөл бүрийн системүүдийн хооронд статус өөрчлөгддөг. Энд трекер нь өгөгдөл түгжигдсэн эцсийн систем биш юм. Ийм тохиолдолд салгах хэд хэдэн боломжит аргыг бид харсан:
- Бид захиалгын бүх үйлдлийг нэг үйлчилгээнд төвлөрүүлдэг. Манай тохиолдолд энэ сонголт нь захиалгыг боловсруулахад хэт их үйлчилгээ шаарддаг. Хэрэв бид тэнд зогссон бол хоёр дахь цултай болох байсан. Бид асуудлыг шийдэхгүй байсан.
- Нэг систем нөгөө рүү залгадаг. Хоёр дахь сонголт нь илүү сонирхолтой юм. Гэхдээ үүний тусламжтайгаар гинжин хэлхээ холбоо барих боломжтой (), бүрэлдэхүүн хэсгүүдийн холболт өндөр, удирдахад илүү төвөгтэй байдаг.
- Бид арга хэмжээ зохион байгуулдаг бөгөөд үйлчилгээ бүр эдгээр арга хэмжээнээр дамжуулан өөр хоорондоо солилцдог. Үүний үр дүнд гурав дахь сонголтыг сонгосон бөгөөд үүний дагуу бүх үйлчилгээ өөр хоорондоо үйл явдал солилцож эхэлдэг.
Бид гурав дахь сонголтыг сонгосон нь трекер өөрийн гэсэн мэдээллийн сантай байх бөгөөд дарааллыг өөрчлөх бүрт энэ тухай үйл явдал илгээх, бусад үйлчилгээнд бүртгүүлэх, мөн мастер мэдээллийн санд багтах болно гэсэн үг юм. Үүнийг хийхийн тулд бидэнд үйлчилгээнүүдийн хооронд мессежийг хүргэх үйлчилгээ хэрэгтэй байсан.
Тэр үед бид RabbitMQ-г аль хэдийн стект оруулсан байсан тул үүнийг мессеж брокер болгон ашиглах эцсийн шийдвэр гарсан. Диаграмм нь рестораны кассаас захиалгыг Tracker-ээр дамжуулж, статусаа өөрчилж, Менежерийн захиалгын интерфэйс дээр харуулахыг харуулж байна. БОЛСОН:
Замыг алхам алхмаар захиалаарай
Захиалгын зам нь захиалгын эх үүсвэрийн аль нэг үйлчилгээнээс эхэлдэг. Рестораны кассчин энд байна:
- Тооцоо хийх үед захиалга бүрэн бэлэн болсон бөгөөд үүнийг трекер рүү илгээх цаг болжээ. Tracker захиалсан үйл явдал хаягдсан байна.
- Захиалгыг хүлээн авч байгаа мөрдөгч нь өөрийн мэдээллийн санд хадгалж, "Захиалагч хүлээн авсан захиалга" үйл явдлыг хийж, RMQ руу илгээдэг.
- Хэд хэдэн зохицуулагчид захиалгат үйл явдлын автобусанд аль хэдийн бүртгүүлсэн байна. Бидний хувьд цул мэдээллийн сантай синхрончлох нь чухал юм.
- Зохицуулагч нь үйл явдлыг хүлээн авч, түүнд чухал ач холбогдолтой өгөгдлийг сонгоно: манай тохиолдолд энэ нь "Tracker хүлээн зөвшөөрсөн" захиалгын статус бөгөөд үндсэн мэдээллийн сан дахь захиалгын нэгжийг шинэчилдэг.
Хэрэв хэн нэгэнд цул захиалгын хүснэгтээс тусгайлан захиалга хэрэгтэй бол тэд үүнийг тэндээс уншиж болно. Жишээлбэл, Shift Manager дахь Захиалгын интерфэйс нь дараахь зүйлийг шаарддаг.
Бусад бүх үйлчилгээнүүд мөн дагаж мөрдөх арга хэмжээг өөрсдөө ашиглахын тулд захиалах боломжтой.
Хэсэг хугацааны дараа захиалга үйлдвэрлэлд орвол түүний статус эхлээд мэдээллийн санд (Tracker мэдээллийн сан) өөрчлөгдөж, дараа нь "OrderInWork" үйл явдал нэн даруй үүсдэг. Энэ нь мөн RMQ-д нэвтэрч, цул мэдээллийн санд синхрончлогдсон бөгөөд бусад үйлчилгээнд хүргэдэг. Энэ замд янз бүрийн асуудал тулгарч магадгүй бөгөөд тэдгээрийн талаарх дэлгэрэнгүй мэдээллийг Женя Пешковын илтгэлээс олж болно .
Auth болон Tracker-д өөрчлөлт оруулсны дараа эцсийн архитектур
Нэгтгэн дүгнэхэд: Анх Dodo IS системийн есөн жилийн түүхийг нэг нийтлэлд багтаах санаа төрсөн. Би хувьслын үе шатуудын талаар хурдан бөгөөд энгийнээр ярихыг хүссэн. Гэсэн хэдий ч материалыг судлахаар суугаад бүх зүйл санагдсанаас хамаагүй илүү төвөгтэй, сонирхолтой гэдгийг ойлгосон.
Ийм материалын ашиг тус (эсвэл дутмаг) талаар эргэцүүлэн бодоход үйл явдлын бүрэн түүх, нарийвчилсан ретроспектив, өнгөрсөн шийдвэрт дүн шинжилгээ хийхгүйгээр тасралтгүй хөгжил боломжгүй юм гэсэн дүгнэлтэд хүрсэн.
Бидний аяллын талаар суралцах нь танд хэрэгтэй бөгөөд сонирхолтой байсан гэж найдаж байна. Одоо би Dodo IS системийн аль хэсгийг дараагийн нийтлэлд тайлбарлах вэ гэсэн сонголттой тулгараад байна: сэтгэгдэл дээр бичих эсвэл санал өгөх.
Зөвхөн бүртгэлтэй хэрэглэгчид санал асуулгад оролцох боломжтой. , гуйя.
Та дараагийн нийтлэлээс Dodo IS-ийн аль хэсгийн талаар мэдэхийг хүсч байна вэ?
-
24,1%Додо IS дахь эртний цул (2011-2015)14
-
24,1%Анхны асуудлууд, тэдгээрийн шийдэл (2015-2016)14
-
20,7%Үйлчлүүлэгч хэсгийн зам: суурийн дээрх фасад (2016-2017)12
-
36,2%Бодит микро үйлчилгээний түүх (2018-2019)21
-
44,8%Цул чулууг огтолж, архитектурыг тогтворжуулж дууссан26
-
29,3%Системийг хөгжүүлэх цаашдын төлөвлөгөөний тухай17
-
19,0%Би Dodo IS11-ийн талаар юу ч мэдэхийг хүсэхгүй байна
58 хэрэглэгч санал өгсөн. 6 хэрэглэгч түдгэлзсэн.
Эх сурвалж: www.habr.com