|
|
Diposting pada 25/09/2019 16.11.58
|
|
|
|
Secara tradisional, sistem yang menangani satu miliar transaksi per hari dapat memerlukan ratusan VM, PayPal melakukan semuanya hanya dengan 8 VM, dan memberikan respons cepat pada penggunaan CPU 90%, kepadatan transaksi yang belum pernah dicapai PayPal sebelumnya, dan prosesnya membutuhkan 1/10 waktu untuk mencapai prosesnya, membantu organisasi mengikuti pertumbuhan tanpa harus meningkatkan infrastruktur komputasinya sambil mengurangi biaya. Bagaimana ini dilakukan?
PayPal telah memigrasikan sistemnya ke mode Aktor berbasis Akka. Dalam artikel Squbs: PayPal mengambil pendekatan reaktif baru untuk membangun aplikasi (Login hyperlink terlihat.PayPal menjelaskan seluk beluk prosesnya. Mereka sekarang memiliki Squbs sumber terbuka dan menerbitkannya di GitHub (Login hyperlink terlihat.)。
Ketika sebuah proyek perlu mengambil pendekatan langsung, model layanan stateful masih belum mendapatkan perhatian yang cukup. Untuk mempelajari selengkapnya tentang layanan stateful, sebaiknya baca alasan untuk terus membangun layanan stateful yang dapat diskalakan sekarang (Login hyperlink terlihat.), artikel ini didasarkan pada pidato Caitie McCaffrey. Jika artikel ini tidak meyakinkan Anda, ada juga WhatsApp yang menggunakan pesaing Akka Erlang untuk throughput yang sangat tinggi: arsitektur WhatsApp Facebook senilai $19 miliar (Login hyperlink terlihat.)。
Alasan untuk merekomendasikan artikel di atas adalah karena PayPal tidak memberikan pengantar terperinci tentang arsitektur, melainkan mencurahkan lebih banyak waktu untuk alasan mengapa mereka memilih Akka dan manfaat bermigrasi ke Akka. Tetapi artikel ini masih memberikan dorongan dan demonstrasi yang berharga untuk praktik "keluar dari jalur yang dipukul".
Apa salahnya menggunakan sejumlah besar mesin virtual untuk suatu layanan?
- Jalankan layanan dengan throughput yang sangat rendah, mesin virtual yang sangat kecil. Keuntungan terbesar dari sistem reaktif berbasis aktor adalah bahwa mereka dapat memanfaatkan sumber daya komputasi secara lebih efisien, yang dapat sangat mengurangi ukuran sistem dan menghindari penskalaan otomatis "sederhana dan kasar" dari praktik tradisional.
- Ini memberi banyak tekanan pada jaringan dan infrastruktur perutean Anda. Karena layanan cenderung lebih saling terhubung, permintaan mungkin perlu melalui sejumlah besar lompatan jaringan, yang meningkatkan latensi dan menurunkan pengalaman pengguna.
- Semakin besar, semakin mahal. Layanan dengan ratusan mesin virtual memiliki biaya inheren yang tinggi dalam hal manajemen, pemantauan, dan caching yang tidak efektif.
- Semakin kecil, semakin gesit. Menyebarkan layanan ke ratusan komputer virtual adalah proses yang memakan waktu.
- Dapatkan lebih banyak dari lebih banyak CPU di setiap mesin virtual. Karena CPU tidak dapat dipercepat lebih lanjut, infrastruktur harus dapat memanfaatkan lebih banyak CPU secara lebih efisien di setiap mesin virtual.
- Layanan mikro perlu dibangun dengan NanoServices yang digabungkan secara longgar yang mudah dirawat dan cepat dibangun. Tidak ada yang ingin berurusan dengan sistem yang kompleks dengan banyak lapisan, dan Anda memerlukan lebih banyak visibilitas ke dalam peran layanan yang berbeda tanpa harus masuk jauh ke lapisan kode.
Dengan mempertimbangkan faktor-faktor ini, PayPal ingin membangun sistem yang:
- Dapat diskalakan, tidak hanya untuk menskalakan secara horizontal ke ratusan node, tetapi juga untuk meningkatkan skala ke lebih banyak prosesor untuk mencapai tujuan memproses miliaran permintaan per hari.
- Latensi rendah dan dapat dikontrol dengan granularitas yang sangat halus.
- Jadilah tangguh dalam menghadapi kegagalan.
- Penyesuaian batas layanan yang fleksibel.
- Promosikan skalabilitas dan kesederhanaan melalui model dan budaya pemrograman, serta mekanisme penanganan kesalahan dan kesalahan yang lebih sederhana.
Tidak ada keraguan bahwa PayPal ingin menggunakan tumpukan yang lebih "tipis", dan mereka tidak ingin tumpukan mereka berisi banyak teknologi dan bagian yang bergerak pada tingkat yang berbeda. Secara umum, sistem berbasis Akka dan negara sangat cocok untuk kebutuhan ini, yang memungkinkan tumpukan komponen besar "dipecah" menjadi satu teknologi. PayPal memilih Akka daripada Erlang karena mereka memiliki lebih banyak pengalaman dengan Java, yang berjalan di atas Java. Bagi banyak orang, belajar Erlang dari nol tidaklah realistis.
Dengan Akka mereka dapat:
- Tulis kode yang lebih mudah dijelaskan
- Tulis kode yang lebih mudah diuji
- Skenario kesalahan dan kegagalan ditangani secara lebih alami daripada mode tradisional menggunakan JVM
- Tulis kode yang lebih cepat, lebih tangguh, dan lebih sederhana untuk menangani kesalahan dengan lebih lancar dan mengurangi jumlah bug
PayPal segera menulis kerangka kerjanya sendiri berdasarkan Akka, yang disebut Squbs, yang digunakan untuk berima dengan "Cubes". Ini memungkinkan Anda membuat lapisan teknologi modular untuk membangun NanoService yang disebut "Cube". Kubusnya simetris, dan dependensi antara kubus yang berbeda juga simetris dan longgar, hanya mengekspos antarmuka pesan yang sudah disediakan Akka.
Ini juga menjelaskan kesulitan yang dapat dihadapi pemrogram saat mengadopsi kode AKKA, karena Anda mungkin juga perlu mempekerjakan seseorang yang terlatih dalam Akka/Scala.
Karena sebagian besar layanan memiliki tujuan yang sama: menerima permintaan, memanggil dan membaca dan menulis database, memanggil layanan lain, memanggil mesin aturan panggilan, mendapatkan data dari cache, menulis ke cache... Akibatnya, layanan dapat diabstraksi melalui pola seperti Pola Orkestrator dan Aliran Abadi.
Squbs telah menjadi praktik standar bagi PayPal untuk membangun aplikasi reaktif berbasis Akka. Jika tim Anda belum mempertimbangkan sistem stateful, mungkin patut dicoba, karena berfungsi dengan baik di PayPal, Facebook, Uber, dan Microsoft.
|
Mantan:Tiga faktor yang membuat saya tidak memandang ChromeDepan:vs buat folder, dan saat membuat solusi, tidak ada seorang pun di bawah file bin
|
