Интернет дээр (үйлчилгээний тор), энд өөр нэг нь байна. Өө! Гэхдээ яагаад? Дараа нь Docker, Kubernetes зэрэг контейнер платформууд гарч ирэхээс өмнө 10 жилийн өмнө үйлчилгээний торон гарч ирсэн бол илүү дээр байх байсан гэж би бодлоо хэлмээр байна. Миний үзэл бодлыг бусдаас илүү сайн эсвэл муу гэж би хэлээгүй ч үйлчилгээний тор нь нэлээд төвөгтэй амьтад учраас олон үзэл бодол нь тэднийг илүү сайн ойлгоход тусална.
Би зуу гаруй микро үйлчилгээн дээр бүтээгдсэн, мянга мянган контейнержүүлсэн програмуудыг дэмждэг dotCloud платформын талаар ярих болно. Би үүнийг хөгжүүлж, эхлүүлэхэд тулгарч байсан бэрхшээлүүд болон үйлчилгээний сүлжээнүүд хэрхэн тусалж болох (эсвэл чадахгүй) талаар тайлбарлах болно.
DotCloud-ийн түүх
Би dotCloud-ийн түүх болон энэ платформын архитектурын сонголтуудын талаар бичсэн боловч сүлжээний давхаргын талаар нэг их яриагүй. Хэрэв та уншихыг хүсэхгүй байгаа бол dotCloud-ийн талаар товчхондоо: энэ нь үйлчлүүлэгчдэд өргөн хүрээний өгөгдлийн дэмжлэгтэйгээр өргөн хүрээний програмуудыг (Java, PHP, Python...) ажиллуулах боломжийг олгодог үйлчилгээ хэлбэрээр PaaS платформ юм. үйлчилгээнүүд (MongoDB, MySQL, Redis...) болон Heroku гэх мэт ажлын урсгал: Та платформ дээр кодоо байршуулах бөгөөд энэ нь контейнерийн дүрсийг бүтээж, тэдгээрийг байрлуулдаг.
Траффикийг dotCloud платформ руу хэрхэн чиглүүлснийг би танд хэлэх болно. Энэ нь маш гайхалтай байсан учраас биш (хэдийгээр систем нь тухайн цаг үедээ сайн ажиллаж байсан!), гэхдээ юуны түрүүнд орчин үеийн хэрэгслүүдийн тусламжтайгаар ийм загварыг даруухан баг богино хугацаанд хялбархан хэрэгжүүлэх боломжтой тул замын хөдөлгөөнийг бөөгнөрөл хооронд чиглүүлэх арга зам хэрэгтэй болно. микро үйлчилгээ эсвэл олон тооны програмууд. Ингэснээр та сонголтуудыг харьцуулж болно: хэрэв та бүх зүйлийг өөрөө боловсруулж эсвэл одоо байгаа үйлчилгээний торыг ашиглавал юу болох вэ. Стандарт сонголт бол өөрөө хийх эсвэл худалдаж авах явдал юм.
Байршсан програмуудын замын хөдөлгөөний чиглүүлэлт
DotCloud дээрх програмууд нь HTTP болон TCP төгсгөлийн цэгүүдийг ил гаргах боломжтой.
HTTP төгсгөлийн цэгүүд ачаалал тэнцвэржүүлэгч кластерийн тохиргоонд динамикаар нэмэгдсэн . Энэ нь өнөөдөр нөөц бололцоотой төстэй юм Kubernetes болон ачааллын тэнцвэржүүлэгч гэх мэт .
Домэйн нэр нь dotCloud ачааллын тэнцвэржүүлэгчийг зааж өгсөн тохиолдолд үйлчлүүлэгчид тохирох домайнаар дамжуулан HTTP төгсгөлийн цэгүүдтэй холбогддог. Гоц гойд зүйлгүй.
TCP төгсгөлийн цэгүүд портын дугаартай холбоотой бөгөөд дараа нь орчны хувьсагчаар дамжуулан тухайн стек дэх бүх контейнерт дамждаг.
Үйлчлүүлэгчид тохирох хостын нэр (gateway-X.dotcloud.com гэх мэт) болон портын дугаарыг ашиглан TCP төгсгөлийн цэгүүдэд холбогдох боломжтой.
Энэ хостын нэр нь "nats" серверийн кластерт ( ), ирж буй TCP холболтыг зөв контейнерт (эсвэл ачааллыг тэнцвэржүүлсэн үйлчилгээний хувьд зөв контейнерт) чиглүүлэх болно.
Хэрэв та Kubernetes-ийг мэддэг бол энэ нь танд Үйлчилгээг сануулах байх .
dotCloud платформ дээр ижил төстэй үйлчилгээ байхгүй байсан : Энгийн болгох үүднээс үйлчилгээнүүдийг платформ дотор болон гадна талаас нь ижил аргаар ашиглаж болно.
Бүх зүйл маш энгийн байдлаар зохион байгуулагдсан: HTTP болон TCP чиглүүлэлтийн сүлжээнүүдийн анхны хэрэгжилт нь Python-ийн хэдхэн зуун мөр байж магадгүй юм. Платформ өсч, нэмэлт шаардлага гарч ирэх тусам боловсронгуй болсон энгийн (би гэнэн хэлнэ) алгоритмууд.
Одоо байгаа кодын өргөн цар хүрээтэй дахин засварлах шаардлагагүй. Тухайлбал, орчны хувьсагчаар дамжуулан олж авсан хаягийг шууд ашиглах боломжтой.
Энэ нь орчин үеийн үйлчилгээний сүлжээнээс юугаараа ялгаатай вэ?
Хязгаарлагдмал харагдац. Бидэнд TCP чиглүүлэлтийн сүлжээний хэмжүүр огт байхгүй байсан. HTTP чиглүүлэлтийн тухай ярихад, дараагийн хувилбарууд нь алдааны код, хариу өгөх хугацаа бүхий нарийвчилсан HTTP хэмжигдэхүүнийг нэвтрүүлсэн боловч орчин үеийн үйлчилгээний сүлжээнүүд нь жишээлбэл Prometheus гэх мэт хэмжигдэхүүн цуглуулах системтэй нэгтгэх боломжийг олгодог.
Харагдах байдал нь зөвхөн үйл ажиллагааны үүднээс (асуудлыг шийдвэрлэхэд туслах) төдийгүй шинэ функцуудыг гаргахад чухал ач холбогдолтой. Энэ нь аюулгүй байдлын тухай юм и .
Чиглүүлэлтийн үр ашиг бас хязгаарлагдмал. DotCloud чиглүүлэлтийн сүлжээнд бүх урсгал нь зориулалтын чиглүүлэлтийн зангилааны кластераар дамжих ёстой байв. Энэ нь олон тооны AZ (Availability Zone) хил хязгаарыг давж, хоцролтыг мэдэгдэхүйц нэмэгдүүлж болзошгүй гэсэн үг юм. Хуудас бүрт зуу гаруй SQL асуулга хийж, асуулга болгонд SQL сервертэй шинэ холболт нээсэн кодыг алдааг олж засварлаж байснаа санаж байна. Орон нутагт ажиллах үед хуудас шууд ачаалагддаг боловч dotCloud дээр TCP холболт (болон дараагийн SQL асуулга) бүр хэдэн арван миллисекунд болдог тул ачаалахад хэдхэн секунд шаардлагатай. Энэ тохиолдолд байнгын холболтууд нь асуудлыг шийдсэн.
Орчин үеийн үйлчилгээний тор нь иймэрхүү асуудлыг шийдвэрлэхэд илүү дээр юм. Юуны өмнө тэд холболтыг чиглүүлсэн эсэхийг шалгадаг эх сурвалжид. Логик урсгал нь ижил байна: клиент → меш → сервис, гэхдээ одоо тор нь орон нутгийн хэмжээнд ажилладаг бөгөөд алсын зангилаанууд дээр биш, тиймээс холболт клиент → меш орон нутгийн бөгөөд маш хурдан (миллисекундын оронд микросекунд).
Орчин үеийн үйлчилгээний торууд нь илүү ухаалаг ачаалал тэнцвэржүүлэх алгоритмуудыг хэрэгжүүлдэг. Backends-ийн эрүүл мэндийг хянаснаар тэд илүү хурдан backends рүү илүү их траффик илгээж, үр дүнд нь ерөнхий гүйцэтгэл сайжирна.
Аюулгүй байдал бас дээр. DotCloud чиглүүлэлтийн тор нь бүхэлдээ EC2 Classic дээр ажилладаг бөгөөд траффикийг шифрлэдэггүй (хэрэв хэн нэгэн EC2 сүлжээний траффик дээр sniffer тавьж чадсан бол та аль хэдийн том асуудалд орсон гэсэн таамаглал дээр үндэслэн). Орчин үеийн үйлчилгээний тор нь бидний бүх урсгалыг ил тод хамгаалдаг, жишээлбэл, харилцан TLS баталгаажуулалт болон дараагийн шифрлэлт.
Платформын үйлчилгээнд зориулсан урсгалыг чиглүүлэх
За, бид програмуудын хоорондох замын хөдөлгөөний талаар ярилцсан, гэхдээ dotCloud платформ өөрөө яах вэ?
Платформ нь өөрөө янз бүрийн функцийг хариуцдаг зуу орчим микро үйлчилгээнээс бүрддэг. Зарим нь бусдын хүсэлтийг хүлээн авч, зарим нь бусад үйлчилгээнд холбогдсон суурь ажилтан байсан ч өөрөө холболтыг хүлээж аваагүй. Ямар ч тохиолдолд үйлчилгээ бүр холбогдох шаардлагатай хаягуудын төгсгөлийн цэгүүдийг мэддэг байх ёстой.
Өндөр түвшний олон үйлчилгээнүүд дээр дурдсан чиглүүлэлтийн сүлжээг ашиглаж болно. Үнэн хэрэгтээ, dotCloud-ийн зуу гаруй микро үйлчилгээний ихэнх нь dotCloud платформ дээр энгийн програмууд хэлбэрээр ашиглагдаж байсан. Гэхдээ цөөн тооны доод түвшний үйлчилгээнд (ялангуяа энэ чиглүүлэлтийн сүлжээг хэрэгжүүлдэг үйлчилгээнд) илүү хялбар, бага хамааралтай зүйл хэрэгтэй байсан (учир нь тэд өөрсдөө ажиллах боломжгүй байсан - хуучин тахиа, өндөгний асуудал).
Эдгээр доод түвшний, нэн чухал үйлчилгээнүүд нь цөөхөн гол зангилаанууд дээр шууд контейнер ажиллуулах замаар байрлуулсан. Энэ тохиолдолд стандарт платформын үйлчилгээг ашиглаагүй: холбогч, төлөвлөгч, гүйгч. Хэрэв та орчин үеийн чингэлэг платформтой харьцуулахыг хүсвэл энэ нь удирдлагын онгоцтой адил юм docker run Kubernetes-д даалгавар өгөхийн оронд шууд зангилаанууд дээр. Энэ нь үзэл баримтлалын хувьд нэлээд төстэй юм , түүний ашигладаг буюу бие даасан кластер ачаалах үед.
Эдгээр үйлчилгээг энгийн бөгөөд бүдүүлэг байдлаар харуулсан: YAML файлд тэдний нэр, хаягийг жагсаасан; мөн үйлчлүүлэгч бүр байршуулахын тулд энэ YAML файлын хуулбарыг авах шаардлагатай болсон.
Нэг талаас, энэ нь Zookeeper гэх мэт гадаад түлхүүр/үнэ цэнийн дэлгүүрийн дэмжлэг шаарддаггүй (тэр үед etcd эсвэл Consul байгаагүй гэдгийг санаарай) маш найдвартай. Нөгөөтэйгүүр үйлчилгээг шилжүүлэхэд хүндрэл учруулсан. Шилжүүлэлт хийх бүрд бүх үйлчлүүлэгчид шинэчлэгдсэн YAML файлыг хүлээн авах (мөн дахин ачаалах боломжтой). Маш тухтай биш!
Үүний дараа бид үйлчлүүлэгч бүрийг локал прокси серверт холбосон шинэ схемийг хэрэгжүүлж эхэлсэн. Хаяг, портын оронд зөвхөн үйлчилгээний портын дугаарыг мэдэж, дамжуулан холбогдох шаардлагатай localhost. Орон нутгийн прокси нь энэ холболтыг зохицуулж, бодит сервер рүү дамжуулдаг. Одоо арын хэсгийг өөр машин руу шилжүүлэх эсвэл масштаблахдаа бүх үйлчлүүлэгчдийг шинэчлэхийн оронд зөвхөн эдгээр бүх локал проксиг шинэчлэх хэрэгтэй; дахин ачаалах шаардлагагүй болсон.
(Мөн TLS холболтууд дахь траффикийг багтааж, өөр прокси серверийг хүлээн авагч талд байрлуулахаас гадна зөвхөн холболтыг хүлээн авахаар тохируулсан хүлээн авагч үйлчилгээний оролцоогүйгээр TLS гэрчилгээг шалгахаар төлөвлөж байсан. localhost. Энэ талаар дараа нь дэлгэрэнгүй).
Энэ нь маш төстэй юм Airbnb-ээс авсан боловч SmartStack-ийг үйлдвэрлэлд нэвтрүүлж, ашиглаж байгаа нь чухал ялгаа юм, харин dotCloud-ийн дотоод чиглүүлэлтийн систем нь dotCloud Docker болсон үед хаагдсан.
Би хувьдаа SmartStack-ийг Istio, Linkerd, Consul Connect зэрэг системүүдийн өмнөх хувилбаруудын нэг гэж үздэг, учир нь тэд бүгд ижил загвартай байдаг.
- Зангилаа бүр дээр прокси ажиллуулна уу.
- Үйлчлүүлэгчид прокси руу холбогдоно.
- Удирдлагын хавтгай нь арын хэсэг өөрчлөгдөх үед прокси тохиргоог шинэчилдэг.
- ... Ашиг!
Үйлчилгээний торны орчин үеийн хэрэгжилт
Хэрэв бид өнөөдөр ижил төстэй сүлжээг хэрэгжүүлэх шаардлагатай бол ижил төстэй зарчмуудыг ашиглаж болно. Жишээлбэл, үйлчилгээний нэрийг орон зайд байгаа хаягуудад буулгах замаар дотоод DNS бүсийг тохируулна уу 127.0.0.0/8. Дараа нь HAProxy-г кластерын зангилаа бүр дээр ажиллуулж, үйлчилгээний хаяг бүр дээр (тэр дэд сүлжээнд) холболтыг хүлээн авна уу. 127.0.0.0/8) болон ачааллыг тохирох арын хэсэгт дахин чиглүүлэх/тэнцвэржүүлэх. HAProxy тохиргоог хянах боломжтой , танд backend мэдээллийг etcd эсвэл Consul-д хадгалах, шаардлагатай үед шинэчлэгдсэн тохиргоог HAProxy руу автоматаар оруулах боломжийг олгоно.
Istio яг ингэж ажилладаг! Гэхдээ зарим нэг ялгаа нь:
- Хэрэглээ HAProxy-ийн оронд.
- Backend тохиргоог etcd эсвэл Consul-ын оронд Kubernetes API-ээр хадгалдаг.
- Үйлчилгээнүүд нь 127.0.0.0/8-ийн оронд дотоод дэд сүлжээнд (Kubernetes ClusterIP хаягууд) хаягуудыг хуваарилдаг.
- Үйлчлүүлэгч болон серверүүдийн хооронд харилцан TLS баталгаажуулалтыг нэмэх нэмэлт бүрэлдэхүүн хэсэгтэй (Citadel).
- Хэлхээ таслах, тархсан мөшгих, канарын байршуулалт гэх мэт шинэ функцуудыг дэмждэг.
Зарим ялгааг хурдан харцгаая.
Элч төлөөлөгч
Envoy Proxy-г Lyft [Таксины зах зээл дэх Uber-ийн өрсөлдөгч - ойролцоогоор бичсэн. эгнээ]. Энэ нь бусад прокситэй (жишээ нь, HAProxy, Nginx, Traefik...) олон талаараа төстэй боловч Lyft өөр проксид дутагдаж байсан функцүүд хэрэгтэй байсан тул Lyft өөрсдийнхөө проксиг бичсэн бөгөөд одоо байгаа проксиг сунгахаас илүү шинийг хийх нь илүү ухаалаг санагдсан.
Элчийг дангаар нь ашиглаж болно. Хэрэв надад өөр үйлчилгээнд холбогдох шаардлагатай тусгай үйлчилгээ байгаа бол би үүнийг Envoy-д холбогдохоор тохируулж, дараа нь бусад үйлчилгээний байршлаар Envoy-г динамикаар тохируулж, дахин тохируулахын зэрэгцээ харагдах байдал гэх мэт маш олон нэмэлт функцүүдийг авах боломжтой. Үйлчлүүлэгчийн тусгай номын сан эсвэл код руу дуудлагын ул мөр оруулахын оронд бид Envoy руу траффик илгээдэг бөгөөд энэ нь бидний хэмжүүрийг цуглуулдаг.
Гэхдээ элч бас ажиллах чадвартай өгөгдлийн хавтгай (өгөгдлийн хавтгай) үйлчилгээний торонд зориулсан. Энэ нь элчийг одоо энэ үйлчилгээний торонд тохируулсан гэсэн үг хяналтын онгоц (хяналтын онгоц).
Хяналтын онгоц
Хяналтын онгоцны хувьд Istio нь Kubernetes API дээр тулгуурладаг. Энэ нь confd ашиглахаас тийм ч их ялгаатай биш юм, өгөгдлийн сан дахь түлхүүрүүдийн багцыг үзэхийн тулд etcd эсвэл Consul дээр тулгуурладаг. Istio нь Kubernetes API-г ашиглан Kubernetes нөөцийн багцыг үзэх боломжтой.
Энэ хооронд: Би хувьдаа үүнийг хэрэгтэй гэж үзсэн уншдаг:
Kubernetes API сервер нь API нөөцөд хадгалах, хувилбар гаргах, баталгаажуулах, шинэчлэх, семантикийг санал болгодог "дүлий сервер" юм.
Istio нь Kubernetes-тэй ажиллахад зориулагдсан; Хэрэв та үүнийг Kubernetes-ээс гадуур ашиглахыг хүсвэл Kubernetes API серверийн жишээг (болон etcd туслах үйлчилгээ) ажиллуулах хэрэгтэй.
Үйлчилгээний хаягууд
Istio нь Kubernetes-ийн хуваарилдаг ClusterIP хаягууд дээр тулгуурладаг тул Istio үйлчилгээ нь дотоод хаягийг хүлээн авдаг (хамгийн хүрээнд биш) 127.0.0.0/8).
Istio-гүй Kubernetes кластер дахь тодорхой үйлчилгээний ClusterIP хаяг руу чиглэсэн урсгалыг kube-proxy-ээр таслан зогсоож, тухайн проксины арын хэсэг рүү илгээдэг. Хэрэв та техникийн нарийн ширийнийг сонирхож байгаа бол kube-proxy нь ClusterIP хаяг руу очих холболтын очих IP хаягийг дахин бичихийн тулд iptables дүрмийг (эсвэл IPVS ачааллын тэнцвэржүүлэгчийг хэрхэн тохируулснаас хамааран) тохируулдаг.
Istio-г Kubernetes кластер дээр суулгасны дараа түүнийг тухайн хэрэглэгч, тэр ч байтугай бүхэл бүтэн нэрийн орон зайд зориулж контейнер нэвтрүүлэх хүртэл идэвхжүүлэх хүртэл юу ч өөрчлөгдөхгүй. sidecar захиалгат pods руу. Энэ контейнер нь Envoy-ийн жишээг эргүүлж, бусад үйлчилгээ рүү явж буй траффикийг таслан зогсоохын тулд iptables-ийн багц дүрмийг тохируулж, тэр траффикийг Envoy руу дахин чиглүүлэх болно.
Kubernetes DNS-тэй нэгдсэн бол манай код үйлчилгээний нэрээр холбогдож, бүх зүйл "зүгээр л ажилладаг" гэсэн үг юм. Өөрөөр хэлбэл, манай код гэх мэт асуулга гаргадаг http://api/v1/users/4242Дараа нь api хүсэлтийг шийдвэрлэх 10.97.105.48, iptables дүрмүүд нь 10.97.105.48-аас гарсан холболтуудыг таслан локал Envoy прокси рүү дамжуулах ба тэр локал прокси нь хүсэлтийг бодит арын API руу дамжуулах болно. Өө!
Нэмэлт үс засалт
Istio нь мөн mTLS (харилцан TLS)-ээр дамжуулан төгсгөл хоорондын шифрлэлт, баталгаажуулалтыг хангадаг. гэж нэрлэдэг бүрэлдэхүүн хэсэг Citadel.
Мөн бүрэлдэхүүн хэсэг байдаг Холигч, Элч ямар хүсэлт гаргаж болно тус бүрээс Толгой хэсэг, арын ачаалал гэх мэт янз бүрийн хүчин зүйлээс хамааран тухайн хүсэлтийн талаар тусгай шийдвэр гаргах хүсэлт гаргах прокси хувьд сайн).
Мэдээжийн хэрэг, бид харагдах байдлын талаар дурьдсан: Элч нь тархсан мөрийг өгөхийн зэрэгцээ асар их хэмжээний хэмжүүр цуглуулдаг. Микро үйлчилгээний архитектурт хэрэв нэг API хүсэлт нь A, B, C, D микро үйлчилгээнүүдээр дамжих ёстой бол нэвтэрсний дараа тархсан мөшгих нь хүсэлтэд өвөрмөц танигч нэмж, эдгээр бүх микро үйлчилгээний дэд хүсэлтээр дамжуулан энэ танигчийг хадгалах боломжийг олгоно. холбогдох бүх дуудлагыг авах. саатал гэх мэт.
Хөгжүүлэх эсвэл худалдаж авах
Истио нь нарийн төвөгтэй гэдгээрээ алдартай. Үүний эсрэгээр, миний энэ нийтлэлийн эхэнд тайлбарласан чиглүүлэлтийн сүлжээг бий болгох нь одоо байгаа хэрэгслийг ашиглан харьцангуй хялбар юм. Тэгвэл үүний оронд өөрийн үйлчилгээний сүлжээг бий болгох нь утга учиртай юу?
Хэрэв бидэнд даруухан хэрэгцээ байгаа бол (бидэнд харагдах байдал, таслуур болон бусад нарийн ширийн зүйлс хэрэггүй) бол өөрийн хэрэгсэлээ хөгжүүлэх бодол төрдөг. Гэхдээ хэрэв бид Kubernetes ашигладаг бол энэ нь шаардлагагүй байж магадгүй, учир нь Kubernetes нь үйлчилгээг илрүүлэх, ачааллыг тэнцвэржүүлэх үндсэн хэрэгслүүдийг аль хэдийн хангасан байдаг.
Гэхдээ хэрэв бидэнд дэвшилтэт шаардлага байгаа бол үйлчилгээний торыг "худалдан авах" нь илүү сайн сонголт юм шиг санагддаг. (Istio нь нээлттэй эх сурвалж учраас энэ нь үргэлж "худалдан авах" биш, гэхдээ бид үүнийг ойлгох, байршуулах, удирдахад инженерийн цагийг зарцуулах шаардлагатай хэвээр байна.)
Би Istio, Linkerd эсвэл Consul Connect-ийг сонгох уу?
Одоогоор бид зөвхөн Istio-ийн тухай ярьсан боловч энэ нь цорын ганц үйлчилгээний тор биш юм. Алдартай хувилбар - , мөн илүү олон зүйл бий .
Ямар сонголт хийх вэ?
Үнэнийг хэлэхэд би мэдэхгүй. Одоогоор би өөрийгөө энэ асуултад хариулах хангалттай чадвартай гэж бодохгүй байна. Цөөн хэдэн байна Эдгээр хэрэгслүүдийн харьцуулалт болон тэр ч байтугай .
Нэг ирээдүйтэй арга бол ийм хэрэгслийг ашиглах явдал юм . Энэ нь үйлчилгээний торонд илэрсэн API-г хялбаршуулах, нэгтгэхийн тулд хийсвэрлэх давхаргыг хэрэгжүүлдэг. Янз бүрийн үйлчилгээний сүлжээнүүдийн тусгай (мөн миний бодлоор харьцангуй төвөгтэй) API-г сурахын оронд бид SuperGloo-ийн энгийн бүтцийг ашиглаж, HTTP интерфэйсүүд болон арын төгсгөлүүдийг дүрсэлсэн завсрын тохиргооны форматтай юм шиг нэгээс нөгөө рүү амархан шилжих боломжтой. Nginx, HAProxy, Traefik, Apache-д зориулсан бодит тохиргоог бий болгох ...
Би Istio болон SuperGloo-ийн талаар бага зэрэг судалж үзсэн бөгөөд дараагийн өгүүллээр би SuperGloo-г ашиглан одоо байгаа кластерт Istio эсвэл Linkerd-ийг хэрхэн нэмэх, мөн сүүлийнх нь ажлыг хэрхэн гүйцэтгэдэг, өөрөөр хэлбэл танд дараахаас шилжих боломжийг олгодог болохыг харуулахыг хүсч байна. тохиргоог дарж бичихгүйгээр нэг үйлчилгээний торыг нөгөө рүү шилжүүлэх.
Эх сурвалж: www.habr.com