Dunia modern tidak dapat dibayangkan tanpa menggunakan sistem terdistribusi. Bahkan aplikasi seluler yang paling sederhana pun memiliki API yang terhubung dengan penyimpanan cloud. Namun, desain sistem terdistribusi masih merupakan seni, bukan ilmu pasti. Kebutuhan untuk membawa dasar yang serius di bawahnya sudah lama tertunda, dan jika Anda ingin mendapatkan kepercayaan dalam penciptaan, dukungan dan pengoperasian sistem terdistribusi - mulailah dengan buku ini!
Brendan Burns, spesialis terkemuka dalam teknologi cloud dan Kubernetes, menetapkan dalam karya kecil ini minimum absolut yang diperlukan untuk desain sistem terdistribusi yang tepat. Buku ini menjelaskan pola awet muda dalam merancang sistem terdistribusi. Ini akan membantu Anda tidak hanya membuat sistem seperti itu dari awal, tetapi juga secara efektif mengubah yang sudah ada.
Kutipan. Pola dekorator. Ubah permintaan atau tanggapan
FaaS ideal ketika Anda membutuhkan fungsi sederhana yang memproses input data dan kemudian mentransfernya ke layanan lain. Pola semacam ini dapat digunakan untuk memperluas atau menghias permintaan HTTP yang dikirim atau diterima oleh layanan lain. Pola ini secara skematis ditunjukkan pada Gambar. 8.1.
Omong-omong, dalam bahasa pemrograman ada beberapa analogi dengan pola ini. Secara khusus, Python memiliki dekorator fungsi yang secara fungsional mirip dengan dekorator permintaan atau respons. Karena transformasi dekorasi tidak menyimpan keadaan dan sering ditambahkan secara ex-facto ketika layanan berkembang, mereka sangat cocok untuk implementasi sebagai FaaS. Selain itu, cahaya FaaS berarti Anda dapat bereksperimen dengan dekorator yang berbeda hingga Anda menemukan yang terintegrasi lebih dekat dengan layanan.
Menambahkan nilai default ke parameter input permintaan HTTP RESTful API menunjukkan manfaat dari pola Penghias. Banyak permintaan API memiliki bidang yang perlu diisi dengan nilai wajar jika tidak ditentukan oleh pemanggil. Misalnya, Anda ingin bidang menjadi default ke true. Ini sulit dicapai dengan JSON klasik, karena bidang kosong default adalah nol, yang biasanya ditafsirkan sebagai salah. Untuk mengatasi masalah ini, Anda dapat menambahkan logika penggantian nilai default baik di depan server API atau dalam kode aplikasi (misalnya, jika (bidang == null) bidang = benar). Namun, kedua pendekatan ini tidak optimal, karena mekanisme substitusi default secara konseptual independen dari pemrosesan permintaan. Sebagai gantinya, kita bisa menggunakan pola FaaS Decorator, yang mengubah permintaan di jalan antara pengguna dan implementasi layanan.
Mempertimbangkan apa yang dikatakan sebelumnya pada bagian pola single-node, Anda mungkin bertanya-tanya mengapa kami tidak merancang layanan substitusi default dalam bentuk wadah adaptor. Pendekatan ini masuk akal, tetapi itu juga berarti bahwa penskalaan layanan pencarian standar dan penskalaan layanan API itu sendiri menjadi saling bergantung satu sama lain. Mengganti nilai default adalah operasi yang mudah secara komputasi, dan untuk itu, kemungkinan besar, Anda tidak akan membutuhkan banyak contoh layanan.
Dalam contoh di bab ini, kita akan menggunakan kerangka FaaS kubeless (https://github.com/kubeless/kubeless). Kubeless dikerahkan di atas layanan orkestra wadah Kubernetes. Jika Anda sudah menyiapkan kluster Kubernetes, maka lanjutkan dengan instalasi Kubeless, yang dapat diunduh dari situs yang sesuai (https://github.com/kubeless/kubeless/releases). Setelah Anda memiliki executable kubeless, Anda dapat menginstalnya di cluster dengan perintah install kubeless.
Kubeless diinstal sebagai add-on API pihak ketiga Kubernetes. Ini berarti bahwa setelah instalasi dapat digunakan sebagai bagian dari alat baris perintah kubectl. Sebagai contoh, fungsi yang digunakan dalam cluster dapat dilihat dengan menjalankan perintah fungsi kubectl. Saat ini tidak ada fungsi yang digunakan di cluster Anda.
Bengkel Substitusi nilai default sebelum memproses permintaan
Anda bisa mendemonstrasikan kegunaan pola Dekorator dalam FaaS dengan contoh mengganti nilai default di panggilan RESTful untuk parameter yang nilainya tidak ditetapkan oleh pengguna. Dengan FaaS, ini cukup sederhana. Fungsi pencarian standar ditulis dalam Python:
# -, # def handler(context): # obj = context.json # "name" , # if obj.get("name", None) is None: obj["name"] = random_name() # 'color', # 'blue' if obj.get("color", None) is None: obj["color"] = "blue" # API- # # return call_my_api(obj)
Simpan fungsi ini ke file yang disebut defaults.py. Ingatlah untuk mengganti panggilan call_my_api dengan API yang Anda inginkan. Fungsi substitusi default ini dapat didaftarkan sebagai fungsi kubeless dengan perintah berikut:
kubeless function deploy add-defaults \ --runtime python27 \ --handler defaults.handler \ --from-file defaults.py \ --trigger-http
Untuk mengujinya, Anda dapat menggunakan alat kubeless:
kubeless function call add-defaults --data '{"name": "foo"}'
Pola Penghias menunjukkan betapa mudahnya untuk beradaptasi dan memperluas API yang ada dengan fitur tambahan seperti memvalidasi atau mengganti nilai default.
Penanganan acara
Sebagian besar sistem berorientasi pada permintaan - mereka memproses aliran berkelanjutan permintaan pengguna dan API. Meskipun demikian, ada beberapa sistem yang berorientasi pada peristiwa. Perbedaan antara permintaan dan acara, menurut saya, terletak pada konsep sesi. Permintaan adalah bagian dari proses interaksi yang lebih besar (sesi). Dalam kasus umum, setiap permintaan pengguna adalah bagian dari proses berinteraksi dengan aplikasi web atau API secara keseluruhan. Saya melihat acara sebagai lebih “satu kali”, asinkron. Peristiwa penting dan harus ditangani sebagaimana mestinya, tetapi mereka disingkirkan dari konteks utama interaksi dan jawaban kepada mereka datang hanya setelah beberapa waktu. Contoh acara adalah berlangganan pengguna ke layanan tertentu, yang akan menyebabkan pengiriman surat ucapan; mengunggah file ke folder bersama, yang akan menyebabkan pengiriman pemberitahuan ke semua pengguna folder ini; atau bahkan mempersiapkan komputer untuk reboot, yang akan memberi tahu operator atau sistem otomatis bahwa tindakan yang sesuai diperlukan.
Karena acara ini sebagian besar independen dan tidak memiliki keadaan internal, dan frekuensinya sangat bervariasi, mereka ideal untuk bekerja dalam arsitektur FaaS yang berorientasi pada peristiwa. Mereka sering ditempatkan di sebelah server aplikasi "pertempuran" untuk memberikan kemampuan tambahan atau untuk pemrosesan data di latar belakang sebagai tanggapan terhadap peristiwa yang muncul. Selain itu, karena jenis baru dari acara yang diproses secara konstan ditambahkan ke layanan, kesederhanaan dari penyebaran fungsi membuatnya cocok untuk mengimplementasikan penangan acara. Dan karena setiap peristiwa secara konseptual independen dari yang lain, melemahnya paksa hubungan dalam suatu sistem yang dibangun berdasarkan fungsi memungkinkan kita untuk mengurangi kompleksitas konseptualnya, memungkinkan pengembang untuk fokus pada langkah-langkah yang diperlukan untuk memproses hanya satu jenis peristiwa tertentu.
Contoh spesifik mengintegrasikan komponen berorientasi peristiwa ke dalam layanan yang ada adalah penerapan otentikasi dua faktor. Dalam hal ini, acara tersebut akan menjadi login pengguna ke sistem. Suatu layanan dapat menghasilkan suatu peristiwa untuk tindakan ini dan meneruskannya ke fungsi penangan. Prosesor, berdasarkan kode yang ditransmisikan dan rincian kontak pengguna, akan mengirimnya kode otentikasi dalam bentuk pesan teks.
Bengkel Menerapkan Otentikasi Dua Faktor
Otentikasi dua faktor menunjukkan bahwa bagi pengguna untuk memasuki sistem, ia memerlukan sesuatu yang ia ketahui (misalnya, kata sandi), dan sesuatu yang ia miliki (misalnya, nomor telepon). Otentikasi dua faktor jauh lebih baik daripada hanya kata sandi, karena penyerang harus mencuri kata sandi dan nomor telepon Anda untuk mendapatkan akses.
Saat merencanakan implementasi otentikasi dua faktor, Anda perlu memproses permintaan untuk membuat kode acak, mendaftarkannya dengan layanan login dan mengirim pesan kepada pengguna. Anda dapat menambahkan kode yang mengimplementasikan fungsi ini langsung ke layanan login itu sendiri. Ini menyulitkan sistem, membuatnya lebih monolitik. Mengirim pesan harus dilakukan bersamaan dengan kode yang menghasilkan halaman web login, yang dapat menyebabkan penundaan tertentu. Penundaan ini menurunkan kualitas interaksi pengguna dengan sistem.
Akan lebih baik untuk membuat layanan FaaS yang akan menghasilkan nomor acak secara tidak sinkron, mendaftarkannya dengan layanan login dan mengirimkannya ke telepon pengguna. Dengan demikian, server login hanya dapat menjalankan permintaan asinkron ke layanan FaaS, yang secara paralel akan melakukan tugas yang relatif lambat untuk mendaftarkan dan mengirim kode.
Untuk melihat bagaimana ini bekerja, pertimbangkan kode berikut:
def two_factor(context): # code = random.randint(1 00000, 9 99999) # user = context.json["user"] register_code_with_login_service(user, code) # Twillio account = "my-account-sid" token = "my-token" client = twilio.rest.Client(account, token) user_number = context.json["phoneNumber"] msg = ", {}, : {}.".format(user, code) message = client.api.account.messages.create(to=user_number, from_="+1 20652 51212", body=msg) return {"status": "ok"}
Kemudian daftarkan FaaS di kubeless:
kubeless function deploy add-two-factor \ --runtime python27 \ --handler two_factor.two_factor \ --from-file two_factor.py \ --trigger-http
Sebuah instance dari fungsi ini dapat secara asinkron dihasilkan dari kode JavaScript sisi klien setelah pengguna memasukkan kata sandi yang benar. Antarmuka web dapat segera menampilkan halaman untuk memasukkan kode, dan pengguna, segera setelah ia menerima kode, dapat memberitahukan kepadanya tentang layanan login di mana kode ini sudah terdaftar.
Jadi, pendekatan FaaS telah sangat memfasilitasi pengembangan layanan yang sederhana, asinkron, dan berorientasi peristiwa yang dimulai ketika pengguna masuk ke sistem.
Konveyor Acara
Ada sejumlah aplikasi yang, pada kenyataannya, lebih mudah untuk dipertimbangkan sebagai saluran pipa dari peristiwa yang digabungkan secara longgar. Pipa-pipa acara sering kali menyerupai bagan alur lama yang baik. Mereka dapat direpresentasikan sebagai grafik diarahkan sinkronisasi acara terkait. Dalam kerangka pola Pipa Acara, node terkait dengan fungsi, dan busur yang menghubungkannya sesuai dengan permintaan HTTP atau jenis panggilan jaringan lainnya.
Di antara elemen-elemen wadah, sebagai suatu peraturan, tidak ada keadaan umum, tetapi mungkin ada konteks umum atau titik referensi lainnya, atas dasar di mana pencarian dalam penyimpanan akan dilakukan.
Apa perbedaan antara pipeline dan microservice architecture? Ada dua perbedaan penting. Perbedaan pertama dan paling penting antara fungsi layanan dan layanan yang terus berjalan adalah bahwa pipa acara pada dasarnya didorong oleh peristiwa. Arsitektur microservice, sebaliknya, menyiratkan seperangkat layanan yang terus bekerja. Selain itu, pipeline acara dapat disinkronkan dan mengikat berbagai acara. Sulit membayangkan bagaimana persetujuan aplikasi Jira dapat diintegrasikan ke dalam aplikasi layanan mikro. Pada saat yang sama, mudah untuk membayangkan bagaimana itu terintegrasi ke dalam pipeline acara.
Sebagai contoh, pertimbangkan pipa di mana sumber acara adalah pemuatan kode ke dalam sistem kontrol versi. Peristiwa ini menyebabkan pembangunan kembali kode. Majelis dapat berlangsung beberapa menit, setelah peristiwa yang dihasilkan yang memicu fungsi pengujian aplikasi yang dirakit. Bergantung pada keberhasilan perakitan, fungsi pengujian mengambil tindakan yang berbeda. Jika perakitan berhasil, aplikasi dibuat, yang harus disetujui oleh orang tersebut agar versi baru aplikasi dapat dioperasikan. Menutup aplikasi berfungsi sebagai sinyal untuk mengaktifkan versi baru. Jika perakitan gagal, Jira membuat permintaan untuk kesalahan yang terdeteksi dan pipa keluar.
Bengkel Menerapkan saluran pipa untuk mendaftarkan pengguna baru
Pertimbangkan tugas menerapkan urutan tindakan untuk mendaftarkan pengguna baru. Saat membuat akun baru, serangkaian tindakan selalu dilakukan, misalnya, mengirim email selamat datang. Ada juga sejumlah tindakan yang tidak dapat dilakukan setiap kali, misalnya, berlangganan newsletter email tentang versi baru suatu produk (juga dikenal sebagai spam).
Salah satu pendekatan melibatkan pembuatan layanan monolitik untuk membuat akun baru. Dengan pendekatan ini, satu tim pengembangan bertanggung jawab untuk seluruh layanan, yang juga digunakan secara keseluruhan. Ini membuatnya sulit untuk melakukan percobaan dan membuat perubahan pada proses interaksi pengguna dengan aplikasi.
Pertimbangkan implementasi login pengguna sebagai saluran acara dari beberapa layanan FaaS. Dengan pemisahan ini, fungsi pembuatan pengguna tidak tahu apa yang terjadi selama login pengguna. Dia memiliki dua daftar:
- daftar tindakan yang diperlukan (misalnya, mengirim email selamat datang);
- daftar tindakan opsional (misalnya, berlangganan buletin).
Setiap tindakan ini juga diimplementasikan sebagai FaaS, dan daftar tindakan tidak lebih dari daftar fungsi panggilan balik HTTP. Oleh karena itu, fungsi pembuatan pengguna memiliki bentuk berikut:
def create_user(context): # for key, value in required.items(): call_function(value.webhook, context.json) # # for key, value in optional.items(): if context.json.get(key, None) is not None: call_function(value.webhook, context.json)
Masing-masing penangan sekarang juga dapat diimplementasikan sesuai dengan prinsip FaaS:
def email_user(context): # user = context.json['username'] msg = ', {}, , !".format(user) send_email(msg, contex.json['email]) def subscribe_user(context): # email = context.json['email'] subscribe_user(email)
Didekomposisi dengan cara ini layanan FaaS menjadi lebih sederhana, mengandung lebih sedikit baris kode dan berfokus pada implementasi satu fungsi spesifik. Pendekatan microservice menyederhanakan penulisan kode, tetapi dapat menyebabkan kesulitan dalam menggunakan dan mengelola tiga layanan microser yang berbeda. Di sini pendekatan FaaS membuktikan dirinya dengan segala kemuliaan, karena sebagai akibat penggunaannya menjadi sangat mudah untuk mengelola potongan-potongan kode kecil. Visualisasi proses menciptakan pengguna dalam bentuk pipeline peristiwa juga memungkinkan kita untuk memahami secara umum apa yang sebenarnya terjadi ketika pengguna login, hanya dengan melacak perubahan konteks dari fungsi ke fungsi dalam pipa.
»Informasi lebih lanjut tentang buku ini dapat ditemukan di
situs web penerbit»
Isi»
Kutipan20% diskon kupon untuk Desainer -
Pola desainSetelah pembayaran versi kertas buku, versi elektronik buku dikirim melalui email.