Anda telah menghabiskan waktu berbulan-bulan untuk mendesain ulang monolit Anda menjadi layanan mikro, dan akhirnya semua orang bersatu untuk melakukan perubahan. Anda pergi ke halaman web pertama... dan tidak ada yang terjadi. Anda memuat ulang - dan sekali lagi tidak ada yang bagus, situs ini sangat lambat sehingga tidak merespons selama beberapa menit. Apa yang telah terjadi?
Dalam ceramahnya, Jimmy Bogard akan melakukan “otopsi” pada bencana layanan mikro di kehidupan nyata. Dia akan menunjukkan masalah pemodelan, pengembangan, dan produksi yang dia temukan, dan bagaimana timnya perlahan-lahan mengubah monolit terdistribusi baru menjadi gambaran akhir tentang kewarasan. Meskipun tidak mungkin untuk sepenuhnya mencegah kesalahan desain, Anda setidaknya dapat mengidentifikasi masalah di awal proses desain untuk memastikan produk akhir menjadi sistem terdistribusi yang andal.
Halo semuanya, saya Jimmy dan hari ini Anda akan mendengar bagaimana Anda dapat menghindari bencana besar saat membangun layanan mikro. Ini adalah kisah tentang perusahaan tempat saya bekerja selama sekitar satu setengah tahun untuk membantu mencegah kapal mereka bertabrakan dengan gunung es. Untuk menceritakan kisah ini dengan benar, kita harus kembali ke masa lalu dan membicarakan tentang di mana perusahaan ini dimulai dan bagaimana infrastruktur TI-nya berkembang seiring berjalannya waktu. Untuk melindungi nama mereka yang tidak bersalah dalam bencana ini, saya telah mengubah nama perusahaan ini menjadi Bell Computers. Slide berikutnya menunjukkan seperti apa infrastruktur TI perusahaan-perusahaan tersebut pada pertengahan tahun 90an. Ini adalah arsitektur khas dari server HP Tandem Mainframe universal yang toleran terhadap kesalahan untuk mengoperasikan penyimpanan perangkat keras komputer.
Mereka perlu membangun sistem untuk mengelola semua pesanan, penjualan, pengembalian, katalog produk, dan basis pelanggan, sehingga mereka memilih solusi mainframe yang paling umum pada saat itu. Sistem raksasa ini berisi setiap informasi tentang perusahaan, segala sesuatu yang mungkin, dan setiap transaksi dilakukan melalui mainframe ini. Mereka menyimpan semua telurnya dalam satu keranjang dan menganggap itu normal. Satu-satunya hal yang tidak termasuk di sini adalah katalog pesanan lewat pos dan pemesanan melalui telepon.
Seiring waktu, sistem menjadi semakin besar, dan sejumlah besar sampah menumpuk di dalamnya. Selain itu, COBOL bukanlah bahasa yang paling ekspresif di dunia, sehingga sistem tersebut berakhir menjadi sebuah sampah monolitik yang besar. Pada tahun 2000, mereka melihat bahwa banyak perusahaan memiliki situs web tempat mereka menjalankan seluruh bisnis mereka, dan memutuskan untuk membangun situs web dot-com komersial pertama mereka.
Desain awal tampak cukup bagus dan terdiri dari situs tingkat atas bell.com dan sejumlah subdomain untuk aplikasi individual: catalog.bell.com, akun.bell.com, pesanan.bell.com, pencarian produk search.bell. com. Setiap subdomain menggunakan kerangka kerja ASP.Net 1.0 dan databasenya sendiri, dan semuanya terhubung ke backend sistem. Namun, semua pesanan terus diproses dan dieksekusi dalam satu mainframe besar, di mana semua sampah tetap ada, tetapi bagian depannya adalah situs web terpisah dengan aplikasi individual dan database terpisah.
Jadi desain sistemnya terlihat teratur dan logis, namun sistem sebenarnya seperti yang ditunjukkan pada slide berikutnya.
Semua elemen menjawab panggilan satu sama lain, mengakses API, menyematkan dll pihak ketiga, dan sejenisnya. Sering terjadi bahwa sistem kontrol versi mengambil kode orang lain, memasukkannya ke dalam proyek, dan kemudian semuanya rusak. MS SQL Server 2005 menggunakan konsep link server, dan walaupun saya tidak menampilkan tanda panah pada slide, namun masing-masing database juga saling berkomunikasi, karena tidak ada salahnya membangun tabel berdasarkan data yang diperoleh dari beberapa database.
Karena mereka sekarang memiliki beberapa pemisahan antara area logis yang berbeda dari sistem, hal ini menjadi gumpalan kotoran yang terdistribusi, dengan potongan sampah terbesar masih tersisa di backend mainframe.
Lucunya mainframe ini dibuat oleh kompetitor Bell Computers dan masih dikelola oleh konsultan teknisnya. Yakin akan kinerja aplikasinya yang tidak memuaskan, perusahaan memutuskan untuk membuangnya dan mendesain ulang sistemnya.
Aplikasi yang ada telah diproduksi selama 15 tahun, yang merupakan rekor untuk aplikasi berbasis ASP.Net. Layanan ini menerima pesanan dari seluruh dunia, dan pendapatan tahunan dari aplikasi tunggal ini mencapai satu miliar dolar. Sebagian besar keuntungan dihasilkan oleh situs web bell.com. Pada Black Friday, jumlah pesanan yang dilakukan melalui situs ini mencapai beberapa juta. Namun, arsitektur yang ada tidak mengizinkan pengembangan apa pun, karena interkoneksi kaku elemen sistem praktis tidak memungkinkan perubahan apa pun pada layanan.
Masalah yang paling serius adalah ketidakmampuan untuk memesan dari satu negara, membayarnya di negara lain, dan mengirimkannya ke negara ketiga, meskipun faktanya skema perdagangan seperti itu sangat umum terjadi di perusahaan global. Situs web yang ada tidak mengizinkan hal seperti ini, jadi mereka harus menerima dan melakukan pemesanan melalui telepon. Hal ini menyebabkan perusahaan semakin berpikir untuk mengubah arsitekturnya, khususnya beralih ke layanan mikro.
Mereka melakukan hal yang cerdas dengan melihat perusahaan lain untuk melihat bagaimana mereka memecahkan masalah serupa. Salah satu solusinya adalah arsitektur layanan Netflix, yang terdiri dari layanan mikro yang terhubung melalui API dan database eksternal.
Manajemen Bell Computers memutuskan untuk membangun arsitektur seperti itu, dengan mengikuti prinsip dasar tertentu. Pertama, mereka menghilangkan duplikasi data dengan menggunakan pendekatan database bersama. Tidak ada data yang dikirim; sebaliknya, setiap orang yang memerlukannya harus pergi ke sumber yang terpusat. Hal ini diikuti oleh isolasi dan otonomi - masing-masing layanan independen satu sama lain. Mereka memutuskan untuk menggunakan Web API untuk segala hal - jika Anda ingin mendapatkan data atau membuat perubahan pada sistem lain, semuanya dilakukan melalui Web API. Hal besar terakhir adalah mainframe baru yang disebut "Bell on Bell" sebagai lawan dari mainframe "Bell" yang didasarkan pada perangkat keras pesaing.
Jadi, selama 18 bulan, mereka membangun sistem berdasarkan prinsip-prinsip inti ini dan membawanya ke praproduksi. Kembali bekerja setelah akhir pekan, para pengembang berkumpul dan menyalakan semua server yang terhubung dengan sistem baru. 18 bulan kerja, ratusan pengembang, perangkat keras Bell paling modern - dan tidak ada hasil positif! Hal ini mengecewakan banyak orang karena mereka telah menjalankan sistem ini di laptop mereka berkali-kali dan semuanya baik-baik saja.
Mereka pintar mengeluarkan seluruh uangnya untuk menyelesaikan masalah ini. Mereka memasang rak server paling modern dengan sakelar, menggunakan serat optik gigabit, perangkat keras server paling kuat dengan jumlah RAM yang sangat besar, menghubungkan semuanya, mengkonfigurasinya - dan sekali lagi, tidak ada apa-apa! Kemudian mereka mulai curiga bahwa alasannya mungkin adalah waktu tunggu, jadi mereka masuk ke semua pengaturan web, semua pengaturan API dan memperbarui seluruh konfigurasi waktu tunggu ke nilai maksimum, sehingga yang bisa mereka lakukan hanyalah duduk dan menunggu sesuatu terjadi. ke situs. Mereka menunggu dan menunggu selama 9 setengah menit hingga website akhirnya dimuat.
Setelah itu, mereka sadar bahwa situasi saat ini memerlukan analisis menyeluruh, dan mereka mengundang kami. Hal pertama yang kami temukan adalah bahwa selama 18 bulan pengembangan, tidak ada satu pun “mikro” nyata yang tercipta - semuanya menjadi lebih besar. Setelah itu, kami mulai menulis bedah mayat, yang juga dikenal sebagai “reretrospektif”, atau “retrospektif menyedihkan”, juga dikenal sebagai “badai menyalahkan”, mirip dengan “badai otak”, untuk memahami penyebab bencana tersebut.
Kami memiliki beberapa petunjuk, salah satunya adalah saturasi lalu lintas total pada saat panggilan API dilakukan. Saat Anda menggunakan arsitektur layanan monolitik, Anda dapat segera memahami apa yang sebenarnya salah karena Anda memiliki satu pelacakan tumpukan yang melaporkan segala sesuatu yang dapat menyebabkan kegagalan. Jika sekelompok layanan mengakses API yang sama secara bersamaan, tidak ada cara untuk melacak jejak tersebut kecuali menggunakan alat pemantauan jaringan tambahan seperti WireShark, berkat itu Anda dapat memeriksa satu permintaan dan mencari tahu apa yang terjadi selama implementasinya. Jadi kami mengambil satu halaman web dan menghabiskan hampir 2 minggu untuk menyusun potongan-potongan teka-teki itu, membuat berbagai panggilan ke sana, dan menganalisis apa yang menyebabkan masing-masing halaman tersebut.
Lihatlah foto ini. Hal ini menunjukkan bahwa satu permintaan eksternal meminta layanan untuk melakukan banyak panggilan internal yang kembali. Ternyata setiap panggilan internal membuat hop tambahan agar dapat melayani permintaan ini secara mandiri, karena tidak dapat berpaling ke tempat lain untuk mendapatkan informasi yang diperlukan. Gambaran ini terlihat seperti rangkaian panggilan yang tidak berarti, karena permintaan eksternal memanggil layanan tambahan, yang memanggil layanan tambahan lainnya, dan seterusnya, hampir tanpa batas.
Warna hijau pada diagram ini menunjukkan setengah lingkaran di mana layanan saling memanggil - layanan A memanggil layanan B, layanan B memanggil layanan C, dan memanggil layanan A lagi. Hasilnya, kita mendapatkan “kebuntuan terdistribusi”. Satu permintaan menciptakan seribu panggilan API jaringan, dan karena sistem tidak memiliki toleransi kesalahan dan perlindungan loop bawaan, permintaan akan gagal jika salah satu dari panggilan API ini gagal.
Kami melakukan perhitungan. Setiap panggilan API memiliki SLA tidak lebih dari 150 ms dan waktu aktif 99,9%. Satu permintaan menyebabkan 200 panggilan berbeda, dan dalam kasus terbaik, halaman dapat ditampilkan dalam 200 x 150 ms = 30 detik. Tentu saja, ini tidak bagus. Mengalikan 99,9% waktu aktif dengan 200, kami mendapatkan ketersediaan 0%. Ternyata arsitektur ini sudah ditakdirkan untuk gagal sejak awal.
Kami bertanya kepada para pengembang bagaimana mereka gagal mengenali masalah ini setelah 18 bulan bekerja? Ternyata mereka hanya menghitung SLA untuk kode yang mereka jalankan, namun jika layanan mereka memanggil layanan lain, mereka tidak menghitung waktu tersebut di SLA mereka. Segala sesuatu yang diluncurkan dalam satu proses mematuhi nilai 150 ms, namun akses ke proses layanan lainnya meningkatkan total penundaan berkali-kali lipat. Pelajaran pertama yang didapat adalah: “Apakah Anda mengendalikan SLA Anda, atau SLA yang mengendalikan Anda?” Dalam kasus kami, yang terakhir adalah yang terakhir.
Hal berikutnya yang kami temukan adalah mereka mengetahui konsep kesalahpahaman komputasi terdistribusi, yang dirumuskan oleh Peter Deitch dan James Gosling, tetapi mereka mengabaikan bagian pertama. Pernyataan tersebut menyatakan bahwa pernyataan “jaringan dapat diandalkan”, “latensi nol”, dan “throughput tak terbatas” adalah kesalahpahaman. Kesalahpahaman lainnya mencakup pernyataan “jaringan aman”, “topologi tidak pernah berubah”, “selalu hanya ada satu administrator”, “biaya transfer data nol”, dan “jaringan homogen”.
Mereka melakukan kesalahan karena mereka menguji layanan mereka pada mesin lokal dan tidak pernah terhubung dengan layanan eksternal. Saat mengembangkan secara lokal dan menggunakan cache lokal, mereka tidak pernah mengalami lompatan jaringan. Selama 18 bulan pengembangan, mereka tidak pernah bertanya-tanya apa yang mungkin terjadi jika layanan eksternal terpengaruh.
Jika Anda melihat batasan layanan pada gambar sebelumnya, Anda dapat melihat bahwa semuanya salah. Ada banyak sumber yang memberi saran tentang cara menentukan batasan layanan, dan sebagian besar melakukan kesalahan, seperti Microsoft pada slide berikutnya.
Gambar ini berasal dari blog MS dengan topik “Bagaimana membangun layanan mikro”. Ini menunjukkan aplikasi web sederhana, blok logika bisnis, dan database. Permintaannya datang langsung, mungkin ada satu server untuk web, satu server untuk bisnis, dan satu lagi untuk database. Jika Anda meningkatkan lalu lintas, gambarannya akan sedikit berubah.
Inilah penyeimbang beban untuk mendistribusikan lalu lintas antara dua server web, cache yang terletak di antara layanan web dan logika bisnis, dan cache lain antara logika bisnis dan database. Ini persis dengan arsitektur yang digunakan Bell untuk penyeimbangan beban dan aplikasi penerapan biru/hijau pada pertengahan tahun 2000-an. Sampai beberapa waktu semuanya berjalan dengan baik, karena skema ini ditujukan untuk struktur monolitik.
Gambar berikut menunjukkan bagaimana MS merekomendasikan perpindahan dari monolit ke layanan mikro - cukup pisahkan setiap layanan utama menjadi layanan mikro terpisah. Selama penerapan skema inilah Bell melakukan kesalahan.
Mereka membagi semua layanan mereka ke dalam tingkatan yang berbeda, yang masing-masing terdiri dari banyak layanan individual. Misalnya, layanan web menyertakan layanan mikro untuk rendering dan autentikasi konten, layanan logika bisnis terdiri dari layanan mikro untuk memproses pesanan dan informasi akun, database dibagi menjadi beberapa layanan mikro dengan data khusus. Baik web, logika bisnis, dan database adalah layanan tanpa kewarganegaraan.
Namun gambaran tersebut sepenuhnya salah karena tidak memetakan satu pun unit bisnis di luar klaster TI perusahaan. Skema ini tidak memperhitungkan hubungan apa pun dengan dunia luar, sehingga tidak jelas bagaimana, misalnya, cara memperoleh analisis bisnis pihak ketiga. Saya perhatikan bahwa mereka juga memiliki beberapa layanan yang diciptakan hanya untuk mengembangkan karier masing-masing karyawan yang berusaha mengelola orang sebanyak mungkin untuk mendapatkan lebih banyak uang darinya.
Mereka percaya bahwa berpindah ke layanan mikro semudah menggunakan infrastruktur lapisan fisik tingkat N internal dan menempelkan Docker ke dalamnya. Mari kita lihat seperti apa arsitektur N-tier tradisional.
Ini terdiri dari 4 level: level antarmuka pengguna UI, level logika bisnis, level akses data, dan database. Yang lebih progresif adalah DDD (Domain-Driven Design), atau arsitektur berorientasi perangkat lunak, di mana dua tingkat menengahnya adalah objek domain dan repositori.
Saya mencoba melihat area perubahan yang berbeda, area tanggung jawab yang berbeda dalam arsitektur ini. Dalam aplikasi tingkat-N pada umumnya, area perubahan berbeda diklasifikasikan yang menembus struktur secara vertikal dari atas ke bawah. Ini adalah Katalog, pengaturan Konfigurasi yang dilakukan pada masing-masing komputer, dan pemeriksaan Checkout, yang ditangani oleh tim saya.
Keunikan skema ini adalah bahwa batas-batas area perubahan ini tidak hanya mempengaruhi tingkat logika bisnis, namun juga meluas ke database.
Mari kita lihat apa artinya menjadi sebuah layanan. Ada 6 sifat karakteristik dari definisi layanan - perangkat lunaklah yang:
- dibuat dan digunakan oleh organisasi tertentu;
- bertanggung jawab atas konten, pemrosesan dan/atau penyediaan jenis informasi tertentu dalam sistem;
- dapat dibangun, dikerahkan, dan dijalankan secara mandiri untuk memenuhi kebutuhan operasional tertentu;
- berkomunikasi dengan konsumen dan layanan lainnya, memberikan informasi berdasarkan perjanjian atau jaminan kontrak;
- melindungi dirinya dari akses yang tidak sah, dan informasinya dari kehilangan;
- menangani kegagalan sedemikian rupa sehingga tidak menyebabkan kerusakan informasi.
Semua sifat ini dapat diungkapkan dalam satu kata “otonomi”. Layanan beroperasi secara independen satu sama lain, memenuhi batasan tertentu, dan menentukan kontrak yang menjadi dasar masyarakat dapat menerima informasi yang mereka butuhkan. Saya tidak menyebutkan teknologi spesifik, yang penggunaannya sudah terbukti dengan sendirinya.
Sekarang mari kita lihat definisi layanan mikro:
- layanan mikro berukuran kecil dan dirancang untuk memecahkan satu masalah tertentu;
- Layanan mikro bersifat otonom;
- Saat membuat arsitektur layanan mikro, metafora perencanaan kota digunakan. Ini adalah definisi dari buku Sam Newman, Building Microservices.
Definisi Bounded Context diambil dari buku Domain-Driven Design karya Eric Evans. Ini adalah pola inti dalam DDD, pusat desain arsitektur yang bekerja dengan model arsitektur volumetrik, membaginya ke dalam Konteks Terikat yang berbeda dan secara eksplisit mendefinisikan interaksi di antara model tersebut.
Sederhananya, Konteks Terikat menunjukkan cakupan di mana modul tertentu dapat digunakan. Dalam konteks ini terdapat model terpadu secara logis yang dapat dilihat, misalnya, di domain bisnis Anda. Jika Anda bertanya “siapa klien” kepada personel yang terlibat dalam pesanan, Anda akan mendapatkan satu definisi, jika Anda bertanya kepada mereka yang terlibat dalam penjualan, Anda akan mendapatkan definisi lain, dan pelaku akan memberi Anda definisi ketiga.
Jadi, Bounded Context mengatakan bahwa jika kita tidak dapat memberikan definisi yang jelas tentang apa itu konsumen layanan kita, mari kita tentukan batasan di mana kita dapat membicarakan arti istilah ini, dan kemudian tentukan titik transisi antara definisi yang berbeda tersebut. Artinya, jika kita berbicara tentang klien dari sudut pandang penempatan pesanan, ini berarti ini dan itu, dan jika dari sudut pandang penjualan, ini berarti ini dan itu.
Definisi layanan mikro berikutnya adalah enkapsulasi segala jenis operasi internal, mencegah “kebocoran” komponen proses kerja ke lingkungan. Berikutnya adalah “definisi kontrak eksplisit untuk interaksi eksternal, atau komunikasi eksternal,” yang diwakili oleh gagasan kontrak yang kembali dari SLA. Definisi terakhir adalah metafora sel, atau sel, yang berarti enkapsulasi lengkap dari serangkaian operasi dalam layanan mikro dan keberadaan reseptor untuk komunikasi dengan dunia luar di dalamnya.
Jadi kami berkata kepada orang-orang di Bell Computers, “Kami tidak dapat memperbaiki kekacauan apa pun yang Anda buat karena Anda tidak punya uang untuk melakukannya, tapi kami hanya akan memperbaiki satu layanan agar semuanya berhasil. nalar." Pada titik ini, saya akan mulai dengan memberi tahu Anda bagaimana kami memperbaiki satu-satunya layanan kami sehingga merespons permintaan lebih cepat dari 9 setengah menit.
22:30 menit
Akan segera dilanjutkan...
Beberapa iklan
Terima kasih untuk tetap bersama kami. Apakah Anda menyukai artikel kami? Ingin melihat konten yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikan kepada teman, , analog unik dari server level awal, yang kami temukan untuk Anda: (tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).
Dell R730xd 2x 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 - mulai $99! Membaca tentang
Sumber: www.habr.com