Anda telah menghabiskan masa berbulan-bulan untuk mereka bentuk semula monolit anda menjadi perkhidmatan mikro, dan akhirnya semua orang telah berkumpul untuk menukar suis. Anda pergi ke halaman web pertama... dan tiada apa yang berlaku. Anda memuat semulanya - dan sekali lagi tiada apa yang baik, tapak ini sangat perlahan sehingga ia tidak bertindak balas selama beberapa minit. Apa yang berlaku?
Dalam ceramahnya, Jimmy Bogard akan menjalankan "bedah siasat" mengenai bencana perkhidmatan mikro kehidupan sebenar. Dia akan menunjukkan masalah pemodelan, pembangunan dan pengeluaran yang ditemuinya, dan cara pasukannya perlahan-lahan mengubah monolit teragih baharu kepada gambaran akhir tentang kewarasan. Walaupun adalah mustahil untuk menghalang kesilapan reka bentuk sepenuhnya, anda sekurang-kurangnya boleh mengenal pasti masalah pada awal proses reka bentuk untuk memastikan produk akhir menjadi sistem pengedaran yang boleh dipercayai.
Helo semua, saya Jimmy dan hari ini anda akan mendengar cara anda boleh mengelakkan bencana besar apabila membina perkhidmatan mikro. Ini adalah kisah sebuah syarikat yang saya bekerja selama kira-kira satu setengah tahun untuk membantu menghalang kapal mereka daripada berlanggar dengan gunung ais. Untuk menceritakan kisah ini dengan betul, kita perlu kembali ke masa lalu dan bercakap tentang tempat syarikat ini bermula dan cara infrastruktur ITnya telah berkembang dari semasa ke semasa. Untuk melindungi nama mereka yang tidak bersalah dalam bencana ini, saya telah menukar nama syarikat ini kepada Bell Computers. Slaid seterusnya menunjukkan rupa infrastruktur IT syarikat sedemikian pada pertengahan 90-an. Ini ialah seni bina tipikal pelayan Rangka Utama HP Tandem tahan kerosakan universal yang besar untuk mengendalikan kedai perkakasan komputer.
Mereka perlu membina sistem untuk mengurus semua pesanan, jualan, pemulangan, katalog produk dan pangkalan pelanggan, jadi mereka memilih penyelesaian kerangka utama yang paling biasa pada masa itu. Sistem gergasi ini mengandungi setiap maklumat tentang syarikat, segala yang mungkin, dan setiap transaksi telah dijalankan melalui kerangka utama ini. Mereka menyimpan semua telur mereka dalam satu bakul dan menganggap itu perkara biasa. Satu-satunya perkara yang tidak disertakan di sini ialah katalog pesanan mel dan membuat pesanan melalui telefon.
Dari masa ke masa, sistem menjadi lebih besar dan lebih besar, dan sejumlah besar sampah terkumpul di dalamnya. Selain itu, COBOL bukanlah bahasa yang paling ekspresif di dunia, jadi sistem itu akhirnya menjadi sekeping sampah monolitik yang besar. Menjelang tahun 2000, mereka melihat bahawa banyak syarikat mempunyai tapak web yang melaluinya mereka menjalankan sepenuhnya semua perniagaan mereka, dan memutuskan untuk membina laman web dot-com komersial pertama mereka.
Reka bentuk awal kelihatan agak bagus dan terdiri daripada tapak peringkat atas bell.com dan beberapa subdomain untuk aplikasi individu: catalog.bell.com, accounts.bell.com, orders.bell.com, carian produk.bell. com. Setiap subdomain menggunakan rangka kerja ASP.Net 1.0 dan pangkalan datanya sendiri, dan mereka semua bercakap dengan bahagian belakang sistem. Walau bagaimanapun, semua pesanan terus diproses dan dilaksanakan dalam satu kerangka utama yang besar, di mana semua sampah kekal, tetapi bahagian hadapan adalah tapak web yang berasingan dengan aplikasi individu dan pangkalan data yang berasingan.
Jadi reka bentuk sistem kelihatan teratur dan logik, tetapi sistem sebenar adalah seperti yang ditunjukkan dalam slaid seterusnya.
Semua elemen menangani panggilan antara satu sama lain, API yang diakses, dll pihak ketiga yang dibenamkan dan seumpamanya. Selalunya berlaku bahawa sistem kawalan versi akan mengambil kod orang lain, memasukkannya ke dalam projek, dan kemudian semuanya akan pecah. MS SQL Server 2005 menggunakan konsep pelayan pautan, dan walaupun saya tidak menunjukkan anak panah pada slaid, setiap pangkalan data juga bercakap antara satu sama lain, kerana tidak ada yang salah dengan membina jadual berdasarkan data yang diperoleh daripada beberapa pangkalan data .
Memandangkan mereka kini mempunyai beberapa pemisahan antara kawasan logik sistem yang berbeza, ini menjadi gumpalan kotoran yang diedarkan, dengan sekeping sampah terbesar masih tinggal di bahagian belakang kerangka utama.
Yang lucunya ialah kerangka utama ini dibina oleh pesaing Bell Computers dan masih diselenggara oleh perunding teknikal mereka. Yakin dengan prestasi aplikasinya yang tidak memuaskan, syarikat itu memutuskan untuk menyingkirkannya dan mereka bentuk semula sistem.
Aplikasi sedia ada telah dikeluarkan selama 15 tahun, yang merupakan rekod untuk aplikasi berasaskan ASP.Net. Perkhidmatan ini menerima tempahan dari seluruh dunia, dan hasil tahunan daripada aplikasi tunggal ini mencecah satu bilion dolar. Sebahagian besar daripada keuntungan telah dijana oleh laman web bell.com. Pada Black Fridays, bilangan pesanan yang dibuat melalui laman web tersebut mencecah beberapa juta. Walau bagaimanapun, seni bina sedia ada tidak membenarkan apa-apa pembangunan, kerana interkoneksi tegar elemen sistem secara praktikal tidak membenarkan sebarang perubahan dibuat pada perkhidmatan.
Masalah yang paling serius ialah ketidakupayaan untuk membuat pesanan dari satu negara, membayarnya di negara lain dan menghantarnya ke negara yang ketiga, walaupun pada hakikatnya skim perdagangan sedemikian sangat biasa di syarikat global. Laman web sedia ada tidak membenarkan apa-apa seperti ini, jadi mereka terpaksa menerima dan membuat pesanan ini melalui telefon. Ini membawa kepada syarikat semakin berfikir tentang mengubah seni bina, khususnya tentang beralih kepada perkhidmatan mikro.
Mereka melakukan perkara yang bijak dengan melihat syarikat lain untuk melihat bagaimana mereka telah menyelesaikan masalah yang sama. Salah satu daripada penyelesaian ini ialah seni bina perkhidmatan Netflix, yang terdiri daripada perkhidmatan mikro yang disambungkan melalui API dan pangkalan data luaran.
Pengurusan Bell Computers memutuskan untuk membina seni bina sedemikian, mematuhi prinsip asas tertentu. Pertama, mereka menghapuskan pertindihan data dengan menggunakan pendekatan pangkalan data yang dikongsi. Tiada data dihantar; sebaliknya, setiap orang yang memerlukannya perlu pergi ke sumber terpusat. Ini diikuti dengan pengasingan dan autonomi - setiap perkhidmatan adalah bebas daripada yang lain. Mereka memutuskan untuk menggunakan API Web untuk segala-galanya - jika anda ingin mendapatkan data atau membuat perubahan pada sistem lain, semuanya dilakukan melalui API Web. Perkara besar terakhir ialah kerangka utama baharu yang dipanggil "Bell on Bell" berbanding kerangka utama "Bell" yang berdasarkan perkakasan pesaing.
Jadi, dalam tempoh 18 bulan, mereka membina sistem berdasarkan prinsip teras ini dan membawanya ke pra-pengeluaran. Kembali bekerja selepas hujung minggu, pembangun berkumpul dan menghidupkan semua pelayan yang sistem baharu itu disambungkan. 18 bulan bekerja, beratus-ratus pembangun, perkakasan Bell paling moden - dan tiada hasil yang positif! Ini telah mengecewakan ramai orang kerana mereka telah menjalankan sistem ini pada komputer riba mereka berkali-kali dan semuanya baik-baik saja.
Mereka bijak membuang semua wang mereka untuk menyelesaikan masalah ini. Mereka memasang rak pelayan paling moden dengan suis, gentian optik gigabit terpakai, perkakasan pelayan paling berkuasa dengan jumlah RAM yang gila, menyambung semuanya, mengkonfigurasinya - dan sekali lagi, tiada apa-apa! Kemudian mereka mula mengesyaki bahawa sebabnya mungkin tamat masa, jadi mereka pergi ke semua tetapan web, semua tetapan API dan mengemas kini keseluruhan konfigurasi tamat masa kepada nilai maksimum, supaya mereka hanya boleh duduk dan menunggu sesuatu berlaku. ke tapak. Mereka menunggu dan menunggu dan menunggu selama 9 setengah minit sehingga laman web akhirnya dimuatkan.
Selepas itu, mereka sedar bahawa keadaan semasa memerlukan analisis yang teliti, dan mereka menjemput kami. Perkara pertama yang kami dapati ialah sepanjang 18 bulan pembangunan, tiada satu pun "mikro" sebenar dicipta - semuanya menjadi lebih besar. Selepas ini, kami mula menulis bedah siasat, juga dikenali sebagai "regretrospektif", atau "retrospektif sedih", juga dikenali sebagai "ribut menyalahkan", serupa dengan "ribut otak", untuk memahami punca bencana.
Kami mempunyai beberapa petunjuk, salah satunya ialah ketepuan trafik yang lengkap pada masa panggilan API. Apabila anda menggunakan seni bina perkhidmatan monolitik, anda boleh memahami dengan segera perkara yang salah kerana anda mempunyai satu surih tindanan yang melaporkan segala-galanya yang boleh menyebabkan kegagalan. Dalam kes di mana sekumpulan perkhidmatan mengakses API yang sama secara serentak, tiada cara untuk menjejaki jejak kecuali menggunakan alat pemantauan rangkaian tambahan seperti WireShark, yang mana anda boleh memeriksa satu permintaan dan mengetahui perkara yang berlaku semasa pelaksanaannya. Oleh itu, kami mengambil satu halaman web dan menghabiskan hampir 2 minggu menyusun kepingan teka-teki itu bersama-sama, membuat pelbagai panggilan kepadanya dan menganalisis perkara yang dibawa oleh setiap satu daripada mereka.
Tengok gambar ni. Ia menunjukkan bahawa satu permintaan luaran menggesa perkhidmatan untuk membuat banyak panggilan dalaman yang kembali semula. Ternyata setiap panggilan dalaman membuat lompatan tambahan untuk dapat melayani permintaan ini secara bebas, kerana ia tidak dapat beralih ke tempat lain untuk mendapatkan maklumat yang diperlukan. Gambar ini kelihatan seperti rangkaian panggilan yang tidak bermakna, kerana permintaan luaran memanggil perkhidmatan tambahan, yang memanggil perkhidmatan tambahan lain, dan seterusnya, hampir ad infinitum.
Warna hijau dalam rajah ini menunjukkan separuh bulatan di mana perkhidmatan memanggil satu sama lain - perkhidmatan A memanggil perkhidmatan B, perkhidmatan B memanggil perkhidmatan C, dan ia memanggil perkhidmatan A semula. Akibatnya, kami mendapat "kematian terbahagi". Satu permintaan mencipta seribu panggilan API rangkaian, dan memandangkan sistem tidak mempunyai toleransi kesalahan terbina dalam dan perlindungan gelung, permintaan itu akan gagal jika walaupun satu daripada panggilan API ini gagal.
Kami membuat beberapa matematik. Setiap panggilan API mempunyai SLA tidak lebih daripada 150 ms dan 99,9% masa beroperasi. Satu permintaan menyebabkan 200 panggilan berbeza, dan dalam kes terbaik, halaman boleh ditunjukkan dalam 200 x 150 ms = 30 saat. Sememangnya, ini tidak baik. Dengan mendarabkan 99,9% masa operasi dengan 200, kami mendapat 0% ketersediaan. Ternyata seni bina ini telah ditakdirkan untuk gagal sejak awal lagi.
Kami bertanya kepada pembangun bagaimana mereka gagal mengenali masalah ini selepas 18 bulan bekerja? Ternyata mereka hanya mengira SLA untuk kod yang mereka jalankan, tetapi jika perkhidmatan mereka memanggil perkhidmatan lain, mereka tidak mengira masa itu dalam SLA mereka. Semua yang dilancarkan dalam satu proses mematuhi nilai 150 ms, tetapi akses kepada proses perkhidmatan lain meningkatkan jumlah kelewatan berkali-kali ganda. Pelajaran pertama yang dipelajari ialah: "Adakah anda mengawal SLA anda, atau adakah SLA mengawal anda?" Dalam kes kami, ia adalah yang terakhir.
Perkara seterusnya yang kami temui ialah mereka tahu tentang konsep salah tanggapan pengkomputeran teragih, yang dirumuskan oleh Peter Deitch dan James Gosling, tetapi mereka mengabaikan bahagian pertamanya. Ia menyatakan bahawa pernyataan "rangkaian boleh dipercayai," "kependaman sifar," dan "daya tampung tak terhingga" adalah salah tanggapan. Salah tanggapan lain termasuk pernyataan "rangkaian selamat," "topologi tidak pernah berubah," "sentiasa hanya ada satu pentadbir," "kos pemindahan data adalah sifar," dan "rangkaian adalah homogen."
Mereka membuat kesilapan kerana mereka menguji perkhidmatan mereka pada mesin tempatan dan tidak pernah menyambung dengan perkhidmatan luaran. Apabila membangun secara tempatan dan menggunakan cache tempatan, mereka tidak pernah menemui lompatan rangkaian. Dalam semua 18 bulan pembangunan, mereka tidak pernah terfikir apa yang mungkin berlaku jika perkhidmatan luar terjejas.
Jika anda melihat sempadan perkhidmatan dalam gambar sebelum ini, anda boleh melihat bahawa semuanya tidak betul. Terdapat banyak sumber yang memberi nasihat tentang cara untuk menentukan sempadan perkhidmatan, dan kebanyakannya melakukannya dengan salah, seperti Microsoft pada slaid seterusnya.
Gambar ini adalah dari blog MS mengenai topik "Cara membina perkhidmatan mikro". Ini menunjukkan aplikasi web mudah, blok logik perniagaan dan pangkalan data. Permintaan datang terus, mungkin terdapat satu pelayan untuk web, satu pelayan untuk perniagaan dan satu untuk pangkalan data. Jika anda meningkatkan trafik, gambar akan berubah sedikit.
Di sini datang pengimbang beban untuk mengagihkan trafik antara dua pelayan web, cache yang terletak di antara perkhidmatan web dan logik perniagaan, dan cache lain antara logik perniagaan dan pangkalan data. Ini betul-betul seni bina Bell yang digunakan untuk pengimbangan beban dan aplikasi penggunaan biru/hijau pada pertengahan 2000-an. Sehingga beberapa ketika semuanya berfungsi dengan baik, kerana skema ini bertujuan untuk struktur monolitik.
Gambar berikut menunjukkan cara MS mengesyorkan beralih daripada monolit kepada perkhidmatan mikro - hanya membahagikan setiap perkhidmatan utama kepada perkhidmatan mikro yang berasingan. Semasa pelaksanaan skim ini Bell melakukan kesilapan.
Mereka membahagikan semua perkhidmatan mereka kepada peringkat yang berbeza, setiap satunya terdiri daripada banyak perkhidmatan individu. Sebagai contoh, perkhidmatan web termasuk perkhidmatan mikro untuk rendering dan pengesahan kandungan, perkhidmatan logik perniagaan terdiri daripada perkhidmatan mikro untuk memproses pesanan dan maklumat akaun, pangkalan data dibahagikan kepada sekumpulan perkhidmatan mikro dengan data khusus. Kedua-dua web, logik perniagaan dan pangkalan data adalah perkhidmatan tanpa negara.
Walau bagaimanapun, gambar ini adalah salah sama sekali kerana ia tidak memetakan mana-mana unit perniagaan di luar kelompok IT syarikat. Skim ini tidak mengambil kira sebarang kaitan dengan dunia luar, jadi tidak jelas bagaimana, sebagai contoh, untuk mendapatkan analisis perniagaan pihak ketiga. Saya perhatikan bahawa mereka juga mempunyai beberapa perkhidmatan yang dicipta semata-mata untuk membangunkan kerjaya pekerja individu yang berusaha untuk mengurus seramai mungkin orang untuk mendapatkan lebih banyak wang untuknya.
Mereka percaya bahawa beralih kepada perkhidmatan mikro adalah semudah mengambil infrastruktur lapisan fizikal N-peringkat dalaman mereka dan melekat Docker padanya. Mari kita lihat rupa seni bina tradisional N-tier.
Ia terdiri daripada 4 peringkat: tahap antara muka pengguna UI, tahap logik perniagaan, tahap akses data dan pangkalan data. Lebih progresif ialah DDD (Reka Bentuk Dipacu Domain), atau seni bina berorientasikan perisian, dengan dua peringkat pertengahan ialah objek domain dan repositori.
Saya cuba melihat bidang perubahan yang berbeza, bidang tanggungjawab yang berbeza dalam seni bina ini. Dalam aplikasi peringkat N biasa, kawasan perubahan yang berbeza dikelaskan yang meresap struktur secara menegak dari atas ke bawah. Ini ialah Katalog, tetapan Konfig yang dilakukan pada komputer individu dan semakan Checkout, yang dikendalikan oleh pasukan saya.
Keistimewaan skim ini adalah bahawa sempadan kawasan perubahan ini bukan sahaja mempengaruhi tahap logik perniagaan, tetapi juga meluas ke pangkalan data.
Mari lihat apa yang dimaksudkan dengan perkhidmatan. Terdapat 6 ciri ciri definisi perkhidmatan - ia adalah perisian yang:
- dicipta dan digunakan oleh organisasi tertentu;
- bertanggungjawab ke atas kandungan, pemprosesan dan/atau penyediaan jenis maklumat tertentu dalam sistem;
- boleh dibina, digunakan dan dijalankan secara bebas untuk memenuhi keperluan operasi tertentu;
- berkomunikasi dengan pengguna dan perkhidmatan lain, memberikan maklumat berdasarkan perjanjian atau jaminan kontrak;
- melindungi dirinya daripada capaian yang tidak dibenarkan, dan maklumatnya daripada kehilangan;
- mengendalikan kegagalan dengan cara yang tidak membawa kepada kerosakan maklumat.
Semua sifat ini boleh dinyatakan dalam satu perkataan "autonomi". Perkhidmatan beroperasi secara bebas antara satu sama lain, memenuhi sekatan tertentu dan menentukan kontrak berdasarkan mana orang boleh menerima maklumat yang mereka perlukan. Saya tidak menyebut teknologi tertentu, yang penggunaannya jelas.
Sekarang mari kita lihat definisi perkhidmatan mikro:
- perkhidmatan mikro bersaiz kecil dan direka untuk menyelesaikan satu masalah tertentu;
- Perkhidmatan mikro adalah autonomi;
- Apabila mencipta seni bina perkhidmatan mikro, metafora perancangan bandar digunakan. Ini adalah definisi daripada buku Sam Newman, Building Microservices.
Takrif Konteks Terbatas diambil daripada buku Eric Evans Reka Bentuk Didorong Domain. Ini ialah corak teras dalam DDD, pusat reka bentuk seni bina yang berfungsi dengan model seni bina volumetrik, membahagikannya kepada Konteks Terhad yang berbeza dan mentakrifkan interaksi antara mereka dengan jelas.
Ringkasnya, Konteks Terhad menandakan skop di mana modul tertentu boleh digunakan. Dalam konteks ini ialah model bersatu secara logik yang boleh dilihat, sebagai contoh, dalam domain perniagaan anda. Jika anda bertanya "siapa pelanggan" kepada kakitangan yang terlibat dalam pesanan, anda akan mendapat satu definisi, jika anda bertanya kepada mereka yang terlibat dalam jualan, anda akan mendapat yang lain, dan penghibur akan memberikan anda definisi ketiga.
Jadi, Konteks Terbatas mengatakan bahawa jika kita tidak dapat memberikan takrifan yang jelas tentang pengguna perkhidmatan kita, mari kita tentukan sempadan yang boleh kita bincangkan tentang maksud istilah ini, dan kemudian tentukan titik peralihan antara takrifan berbeza ini. Iaitu, jika kita bercakap tentang pelanggan dari sudut membuat pesanan, ini bermakna ini dan itu, dan jika dari sudut jualan, ini bermakna ini dan itu.
Takrif perkhidmatan mikro yang seterusnya ialah pengkapsulan sebarang jenis operasi dalaman, menghalang "kebocoran" komponen proses kerja ke dalam persekitaran. Seterusnya datang "takrif kontrak eksplisit untuk interaksi luaran, atau komunikasi luaran," yang diwakili oleh idea kontrak yang kembali daripada SLA. Takrifan terakhir ialah metafora sel, atau sel, yang bermaksud enkapsulasi lengkap set operasi dalam perkhidmatan mikro dan kehadiran di dalamnya reseptor untuk komunikasi dengan dunia luar.
Oleh itu, kami berkata kepada lelaki di Bell Computers, βKami tidak boleh membetulkan sebarang kekacauan yang anda buat kerana anda tidak mempunyai wang untuk melakukannya, tetapi kami akan membetulkan hanya satu perkhidmatan untuk membuat semuanya selesai. rasa.β Pada ketika ini, saya akan mulakan dengan memberitahu anda cara kami membetulkan satu-satunya perkhidmatan kami supaya ia bertindak balas kepada permintaan lebih cepat daripada 9 setengah minit.
22:30 min
Akan diteruskan tidak lama lagi...
Sedikit pengiklanan
Terima kasih kerana tinggal bersama kami. Adakah anda suka artikel kami? Ingin melihat kandungan yang lebih menarik? Sokong kami dengan membuat pesanan atau mengesyorkan kepada rakan, , analog unik pelayan peringkat permulaan, yang kami cipta untuk anda: (tersedia dengan RAID1 dan RAID10, sehingga 24 teras dan sehingga 40GB DDR4).
Dell R730xd 2 kali lebih murah di pusat data Equinix Tier IV di Amsterdam? Hanya disini di Belanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - daripada $99! Baca tentang
Sumber: www.habr.com