Kredit: Vektor teknologi yang dibuat oleh pikisuperstar — www.freepik.com

Sebagai pengembang, kita sering menemukan diri kita dalam situasi di mana kita harus membangun sesuatu, tetapi kita tidak memiliki waktu yang cukup untuk mengembangkan dengan cara yang kita inginkan. Dan kita tidak bisa selalu memundurkan jadwal, karena “ waktu ke pasar ” terkadang memainkan peran penting dalam keberhasilan produk. Jadi apa yang kita lakukan? Kami mengambil jalan pintas, mengambil risiko yang diperhitungkan, melepaskan kemurnian dalam diri Anda (praktik terbaik, cakupan pengujian unit, dan bla bla bla). Saya kira itu akan sangat mirip untuk sebagian besar dari kalian juga.

Cerita hari ini adalah tentang bagaimana kita membangun Skala Tinggi , Toleransi kegagalan , Distributed sistem Leaderboard / Scoring, di sekitar waktu satu minggu di tim tiga orang.

Akan ada ember pembelajaran ini di blog ini

  1. Teknis : Bagaimana Anda benar-benar membangun sistem seperti itu, topik seperti desain sistem terdistribusi, skalabilitas, ketahanan, ketersediaan akan dibahas.
  2. Bekerja melawan waktu : Bagaimana Anda memberikan dalam waktu singkat, jenis pertukaran apa yang Anda buat, bagaimana membuat keputusan lebih cepat.
  3. Siklus hidup pengembangan : Anda juga dapat mengintip siklus hidup pengembangan produk, hal-hal apa saja yang diperlukan untuk membangun perangkat lunak yang baik.

Bab 1: Persyaratan

Semuanya dimulai ketika tim produk kami mengatakan ini adalah musim piala dunia T20 dan kami ingin membangun sistem kuis untuk pengguna kami, untuk prediksi jangka pendek.

Kasus penggunaannya adalah bahwa pada awal pengguna akan diminta untuk memprediksi skenario di mana mereka akan memiliki 20/30 detik. Dan di akhir over moderator akan menyampaikan, apa yang sebenarnya terjadi di antara semua skenario yang diprediksi. Dan penilaian akan bekerja berdasarkan siapa yang menjawab dengan benar dan berapa banyak waktu yang dibutuhkan untuk menjawab.

Jadi segera setelah mendapatkan persyaratan, kami melakukan estimasi usaha dan itu jelas tidak sesuai dengan anggaran kami, jadi kami memotong fitur yang bisa kami lewati di v0. Ini penting karena dalam tenggat waktu yang ketat Anda mungkin ingin memberikan lebih sedikit fitur daripada memberikan fitur setengah matang.

Ini akan menjadi blog yang berfokus pada backend, maaf saya tidak dapat menjelaskan bagaimana UI yang indah itu dibuat.

Bab 2: Desain

Selanjutnya adalah merancang Sistem, yang dikenal sebagai Desain Tingkat Tinggi. Ini adalah bagian yang paling menantang sekaligus bagian yang paling menyenangkan bagi saya. Kami tidak melakukan desain tingkat rendah yang ekstensif dan mengambil semua panggilan pemodelan dengan cepat saat menerapkan.

Langkah 1: Estimasi skala

Sebelum memulai apa pun, kami melakukan perkiraan kasar tentang lalu lintas seperti apa yang akan menimpa kami. Mengingat skala sistem kami, kami memperkirakan mungkin 50k orang akan terlibat dengan kuis. Jadi kami menargetkan untuk membangun untuk 100k pengguna. Tetapi kebanyakan orang mungkin akan menjawab dalam 10 detik pertama dalam jendela 30 detik. Yang kira-kira memberi kita target qps 20k.

Saya aturan praktis adalah untuk sistem baru selalu merancang sistem untuk dua kali jumlah pengguna diantisipasi. Sehingga jika Anda akhirnya memiliki lebih banyak pengguna, sistem Anda tidak gagal untuk diskalakan. Dan pengguna umumnya bertambah dari waktu ke waktu sehingga Anda tidak harus terus-menerus mengubah sistem. Tapi itu tidak berarti bahwa Anda menempatkan dua kali infrastruktur di tempat yang sebenarnya dibutuhkan. Saya kebanyakan akan mengaktifkan penskalaan otomatis di sistem saya sehingga setiap kali ada lonjakan lalu lintas, sistem akan menskalakan sendiri.

(Kami melakukan perkiraan lain untuk penyimpanan di cache juga, tetapi melewatkannya untuk menjaga artikel tetap singkat)

Langkah 2: Mengidentifikasi API skala tinggi

Setelah estimasi skala, kami dengan cepat mengidentifikasi apa itu API skala tinggi, dan di mana pemrosesannya bisa tinggi sehingga kami dapat secara selektif melakukan desain yang skalabel untuk itu. API skala rendah lainnya yang tidak kami pedulikan atau habiskan banyak waktu.

Jadi ini adalah API skala tinggi yang kami identifikasi

  1. Dapatkan skor dan peringkat pengguna
  2. Dapatkan papan peringkat
  3. Hitung papan peringkat (kebanyakan pemrosesan data bukan API)
  4. Posting jawaban pengguna

Langkah 3: Pertimbangan desain

Segera setelah melihat persyaratan dua hal yang sangat jelas bagi saya.

  1. Kami akan membutuhkan pemrosesan asinkron dan terdistribusi untuk penghitungan skor dan papan peringkat untuk alasan yang paling jelas. Jika Anda berencana untuk menjalankan penghitungan skor secara serempak pada satu node untuk 1 juta pengguna atau lebih, semoga sukses untuk Anda . Idenya sederhana, kami membagi tugas besar menjadi tugas-tugas yang lebih kecil dan menjalankannya pada node yang berbeda, dan membiarkan mereka melakukan ini dengan kecepatan mereka sendiri. Dan kami juga ingin proses ini toleran terhadap kesalahan .
  2. Cache akan menjadi teman kita untuk membaca peringkat pengguna dan papan peringkat. Karena dua alasan terutama, kecepatan dan kemudahan penskalaan . Cache jauh lebih cepat daripada DB untuk operasi baca sederhana dan umumnya, lebih mudah untuk menskalakan cluster Redis/ Memcached/ Hazelcast daripada Postgres .

Langkah 4: Rancang Sistem

Saat mengambil keputusan desain kali ini, saya memilih untuk menggunakan teknisi yang saya kenal dan tidak ingin mencari tahu apa yang bisa menjadi teknologi terbaik untuk kasus penggunaan ini. Misalnya, saya sudah familiar dengan Redis , jadi untuk cache, itu adalah pilihan yang jelas. Juga setiap kali saya mendengar papan peringkat, itu secara otomatis diterjemahkan ke set yang diurutkan Redis di pikiran saya. Dan untuk proses async, Kafka tetap menjadi pilihan nomor satu saya. Dengan waktu yang tepat, saya mungkin akan melakukan eksplorasi lebih banyak, tetapi untuk kali ini saya tidak akan berkeliaran di alam liar untuk menemukan teknologi terbaik karena saya tidak punya WAKTU!!!!

A. Kirimkan API jawaban pengguna

Jadi API ini akan membiarkan pengguna kami mengirimkan jawaban untuk kuis. Tantangan utama di sini adalah this akan menghasilkan banyak operasi penulisan bersamaan , yang akan banyak meningkatkan beban pada database kami. Jadi kami harus melakukan dua hal

  1. Kurangi beban pada DB
  2. Hasilkan semacam tekanan balik atau biarkan operator DB bekerja dengan kecepatan mereka sendiri, sehingga DB tidak kewalahan

Solusi goto saya untuk mengurangi beban tulis adalah dengan melakukan batching . Jadi jika saya harus melakukan 10 operasi tulis, saya akan mengelompokkannya untuk mendapatkan satu kueri dan kemudian menjalankan 1 operasi tulis DB.

Dan Tekanan balik hampir meneriakkan antrian pesan .

Jadi menggabungkan keduanya, solusi yang kami dapatkan adalah ini…

Jangan panik, izinkan saya menjelaskan apa yang terjadi

  1. Respons pengguna diterima oleh penerima respons dan kode status HTTP 202 dikembalikan. Yang seperti mengatakan saya menerima permintaan Anda dan saya akan memprosesnya, tetapi Anda teruskan dan lakukan apa yang Anda lakukan. Ini adalah langkah pertama dalam pemrosesan async, bahwa kami tidak memblokir penelepon.
  2. Penerima respons menempatkan respons pengguna dalam antrian pesan, yang lagi-lagi dipartisi untuk tujuan skalabilitas/ ketersediaan/ redundansi . Anda dapat memahami partisi dengan cukup mudah jika Anda sudah mengetahui Kafka. Jika tidak, anggap saja itu sebagai cara untuk mendistribusikan pesan Anda dalam antrean Anda ke beberapa antrean terisolasi yang lebih kecil yang secara teknis dapat berada di node yang berbeda. Jika Anda tahu DB sharding maka itu hal yang sama tetapi kebanyakan untuk antrian pesan. Jangan ragu untuk membaca lebih lanjut tentang Kafka di sini .
  3. Sekarang, tanggapan mentah ini diterima oleh batcher. Dan kemudian itu membuat kumpulan 10 pesan dan mendorongnya ke tahap pemrosesan berikutnya.
  4. Penulis DB mengambil kumpulan dan membuat kueri penyisipan ke dalam DB. Tekanan balik terutama diperkenalkan oleh penulis DB, ia mengambil pesan dengan kecepatannya sendiri karena konsumen pesan berbasis tarik . Dan dengan demikian kami mencegah kelebihan DB. Dan karena ini bekerja pada batch alih-alih menjalankan 100 kueri DB, kami hanya menjalankan 10 kueri DB.

Ini memecahkan 30% dari masalah kita, mari kita beralih ke yang berikutnya.

B. Perhitungan Skor dan Papan Peringkat

Sekarang gajah di dalam ruangan, masalah utama, perhitungan Leaderboard. Jika Anda melihat sistem ini, tidak seperti sistem kuis tradisional di mana kita tahu jawaban yang benar sebelumnya. Jadi kami tidak bisa benar-benar menghitung skor dan papan peringkat segera setelah seseorang menjawab. Kami harus menghitung skor dan peringkat semua pengguna setelah moderator mengirimkan jawaban yang benar. Jadi sebagian besar pekerjaan dalam satu kesempatan. Cukup jelas bahwa baik node maupun server DB kami tidak dapat menanganinya dengan benar dalam sinkronisasimode. Jadi apa yang kita lakukan? Kami kembali ke Antrian Pesan teman kami untuk pemrosesan asinkron lagi. Keren jadi kita bisa menghitung skor secara asinkron, tapi bagaimana dengan papan peringkat? Itu harus tersedia setiap saat bukan? Dan bagaimana dengan peringkat? Sampai dan kecuali skor untuk semua pengguna telah dihitung, Anda tidak dapat benar-benar menempatkan peringkat, bukan? Dan menghitung peringkat secara khusus bisa menjadi masalah yang sulit.

Sekarang, siapa yang akan menyelamatkan kita dari ini? Jangan khawatir sobat, ingatkah saya menyebutkan Redis secara singkat saat berbicara tentang cache? Mereka memiliki hal indah yang disebut set yang diurutkan (kreasi yang luar biasa, terima kasih Redis Labs ). Dalam set yang diurutkan, Anda dapat menambahkan kunci dengan skor, dan Redis akan mengurutkannya sesuai di O(log(N)) . Itu akan mengurutkan masalah peringkat kita . Ini juga memungkinkan kami untuk menjalankan kueri rentang, seperti memberi saya 5 teratas, atau memberi saya peringkat untuk kunci tertentu, dan semua ini terjadi di O(log(N)). Itulah yang kita butuhkan di sini.

Elemen ditambahkan ke tabel hash yang memetakan objek Redis ke skor. Pada saat yang sama elemen ditambahkan ke skor pemetaan daftar lewati ke objek Redis (sehingga objek diurutkan berdasarkan skor dalam "tampilan" ini) — Set internal yang diurutkan

Bammmmmm masalah papan peringkat juga terpecahkan.

Baiklah baiklah, itu tidak mudah, saya hanya senang bahwa saya bisa mendapatkan solusi yang bisa diterapkan dengan cepat. Sekarang mari kita melompat kembali ke papan gambar kita.

Terlihat sedikit mengintimidasi bukan? Izinkan saya untuk menjelaskan

  1. Segera setelah moderator mengirimkan jawaban yang benar, pesan pemicu penghitungan skor didorong, yaitu untuk memulai seluruh alur pemrosesan .
  2. Pengumpul menerima pesan pemicu dan menghasilkan sepasang objek offset dan batas DB tergantung pada berapa banyak orang yang menjawab dengan benar. Misalnya, jika 10 orang menjawab dengan benar dan ukuran batch adalah 5 maka akan menghasilkan dua objek (batch). Batch 1 {offset: 0, batas: 5}, batch 2 {offset: 5, batas 5}. Mengapa kita melakukan ini? Sehingga kami dapat menjalankan pemrosesan batch atau menjalankan kueri DB paginasi dan kami tidak berakhir memanggil DB tanpa batas. Jadi jika saya harus mendapatkan 1 juta catatan dari DB, dan saya melakukannya dalam satu kesempatan, itu akan menimbulkan banyak masalah di banyak tempat. Jadi kami memecahnya menjadi bagian-bagian yang lebih kecil dan menjalankan kueri yang lebih kecil tetapi banyak, yang akan mengembalikan jumlah baris yang lebih sedikit.
  3. Prosesor batch pengguna sekarang akan menerima pesan batch ini dan akan menjalankan kueri DB yang sesuai. Prosesor yang menerima pesan {offset: 0, limit: 5}, akan mendapatkan 5 id pengguna pertama dari DB (akan melakukan operasi batch lain juga tetapi itu agak sulit dijelaskan di sini, jadi lewati). Dan setelah ini kami mengucapkan selamat tinggal pada pemrosesan batch dan beralih ke pemrosesan aliran . Karena prosesor batch sekarang akan memasukkan 5 id pengguna ke dalam antrian yang akan diproses oleh prosesor berikutnya.
  4. Sekarang kalkulator skor Pengguna menerima id pengguna individu, menjalankan logika penilaian untuk menghitung skor pengguna individu. Kemudian buat pembaruan 1 DB untuk mengubah skor pengguna. Ini kemudian memperbarui skor untuk pengguna tertentu di set yang diurutkan, dan Redis secara internal menetapkan atau memperbarui peringkat. Dan setelah tahap ini selesai diproses, kami akan memiliki skor semua pengguna di DB kami dan peringkat + skor semua pengguna di Redis kami. Dan karena kami memiliki peringkat semua orang di kumpulan yang diurutkan, kami hanya dapat menjalankan kueri rentang di atasnya untuk mendapatkan papan peringkat dengan kecepatan yang sangat cepat .

Sebagian besar masalah kami terpecahkan sekarang karena untuk mendapatkan skor dan peringkat pengguna, kami hanya dapat membuat kueri Redis dan tidak mencapai DB. Dan ini membuat waktu respon kami cepat juga .

Ini menyimpulkan fase desain utama. Ada juga DB, desain API, dan hal-hal lain yang saya lewati di sini.

Bab 4: Implementasi

Penyelesaian desain memecahkan 70% dari masalah kami, dan kami tahu kami dapat memecahkannya, jadi kami akan melompat ke pengembangan dengan cepat.

Di dunia yang ideal, saya akan pergi dan membuat layanan baru, mencoba bahasa baru seperti Go , untuk pemrosesan paralel yang lebih baik dan lebih cepat dan hal-hal lain. Tapi mengingat timeline, itu bukan hal yang benar untuk dilakukan. Kami tetap pada layanan inti NodeJS kami dan meletakkan semuanya di sana. Puritan layanan mikro mungkin kehilangan itu setelah melihat pernyataan ini, tetapi dalam berpacu dengan waktu, kepala sekolah Anda kadang-kadang harus mengambil kursi belakang. Di antara banyak pengorbanan , ini adalah salah satu panggilan utama yang kami ambil.

Selain itu, kami juga harus mengurangi tes unit dan integrasi , kesalahan yang masih menghantui kami. Tapi kami mengisi ulang tes secara bertahap setelah rilis.

Saya kira setelah melihat detail desain yang diposting di atas, Anda harus dapat mengimplementasikannya sendiri, maka saya tidak akan melakukan deep dive kode kali ini

Bab 5: Penerapan dan Pemantauan

Setelah beberapa perbaikan bug dan persetujuan QA, kami siap melakukannya. Pekerjaan selesai dengan benar? Tidak, teman saya, kami masih harus mengatur pemantauan berat untuk bagian ini. Karena dikembangkan dalam waktu yang sangat singkat, setidaknya saya sedikit kurang percaya diri. Kami secara default telah mengaktifkan pelacakan pada layanan ini melalui LightStep . Jadi selain pelacakan , saya telah menyiapkan pemantauan lalu lintas khusus, tingkat kesalahan, dasbor latensi, peringatan untuk semua API. Dan setelah go-live saya dan rekan tim saya, kami mendapat panggilan dan kami memantau sistem masuk dan keluar setidaknya selama satu jam, dari penggunaan RAM dan CPU hingga Log kesalahan . Jadi selalu berikan bobot yang sama untuk observabilitasdan juga pemantauan. Ada masalah kecil pada sistem produksi dan kami hanya dapat menangkapnya lebih awal karena pemantauan.

Bab 6: Retrospektif

Sistem bekerja, tetapi setelah istirahat, penting untuk melakukan retrospeksi dan mengidentifikasi hal-hal yang kita lewatkan dan mengatasinya. Saya yakin kami melewatkan banyak hal dan mengambil banyak tikungan dan mendapat banyak peningkatan. Sebagai contoh berikut adalah beberapa…

Hal-hal yang bisa kita lakukan lebih baik

  1. Kami menggunakan DB Postgres yang sudah ada untuk ini karena driver, ORM, dan infrastruktur pendukung sudah ada di sana. Tapi saya mungkin akan sedikit mengeksplorasi solusi database.
  2. NodeJS luar biasa, tetapi saya merasa Go akan menjadi solusi yang lebih baik untuk ini. Kita bisa menjelajahi ini.
  3. Saya mencoba menulis kueri untuk menghitung skor di DB saja dan gagal total. Saya mungkin bisa menulis itu dan bisa melakukan pemrosesan batch untuk perhitungan skor juga, mengurangi operasi DB lebih jauh.
  4. Kami tidak dapat menjalankan pengujian beban dan kinerja yang ekstensif, yang merupakan suatu keharusan.
  5. Kami dapat menulis dua tahap berbeda untuk pembaruan skor DB dan pembaruan set yang diurutkan Redis, itu akan menjadi implementasi yang lebih bersih.

Catatan perpisahan

Kami melakukan yang terbaik yang kami bisa dalam waktu singkat itu. Bahkan implementasinya sedikit menyimpang dari desain aslinya. Tapi tidak apa-apa, trade-off akan selalu ada. Meskipun kami menyelesaikan fungsionalitas inti dalam waktu sekitar seminggu, ada tambalan kecil yang harus kami lakukan untuk mempostingnya.

Saya harap Anda dapat mempelajari satu atau dua hal tentang desain sistem dan pengembangan perangkat lunak hari ini

Kredit

Berteriak kepada rekan tim saya yang luar biasa Akash Raj dan Aashirwad Kashyap , kami semua bekerja sama untuk membangun ini hanya dalam waktu sekitar seminggu.

Terima kasih sudah membaca!

Saya Aritra Das, saya seorang Pengembang, dan saya sangat menikmati membangun Sistem Terdistribusi yang kompleks. Jangan ragu untuk menghubungi saya di Linkedin atau Twitter untuk apa pun yang terkait dengan teknologi.

Selamat belajar…

Suggested posts

6 keunggulan utama pengembang dari Eropa Timur

6 keunggulan utama pengembang dari Eropa Timur

Memahami mengapa perusahaan asing ingin merekrut pengembang dari Rusia, Ukraina, dan Belarusia Selama lebih dari 6 tahun, saya telah mengelola Pengembangan Perangkat Lunak Rocketech dengan seorang mitra, yang berkantor pusat di Singapura dan tim yang terdistribusi sepenuhnya. Kami sedang mengembangkan produk IT dan mengembangkan dua format layanan: outstaff dan Dedicated Team.

Buku Python Dijual 25 November

Penawaran Black Friday Awal dari Rak Buku Pragmatis

Buku Python Dijual 25 November

Tulis kode yang lebih baik, intuitif, dan lebih andal dengan Python. Dari proyek perangkat keras langsung hingga ilmu data, Rak Buku Pragmatis memberi Anda diskon 40 persen untuk semua judul Python selama acara Black Friday Early Bird kami! Beli ebook berikut untuk mengklaim tabungan Anda: Catatan: Kode promo turkeysale2021 berlaku hingga 29 November 2021, untuk ebook di situs web The Pragmatic Bookshelf.

Related posts

AI di Smartphone

AI di Smartphone

Smartphone telah berevolusi dari waktu ke waktu, dan mereka terus menjadi perangkat paling populer di pasar. Namun, dalam beberapa tahun terakhir, kecerdasan buatan telah membangkitkan minat orang.

Menjembatani yang Baik dan jalan ke depan: Tujuan Jangka Panjang dan bagaimana kita akan mencapainya!

Menjembatani yang Baik dan jalan ke depan: Tujuan Jangka Panjang dan bagaimana kita akan mencapainya!

Tim Good Bridging telah mendiskusikan beberapa minggu terakhir ini apa yang ingin dicapai oleh proyek ini. Setelah beberapa kali berbicara dengan pengembang, pakar pemasaran, dan manajer proyek kami, kami telah memutuskan untuk membawa Good Bridging ke tingkat berikutnya.

Bagaimana memiliki kontrol keuangan untuk menghemat uang dan mewujudkan impian!

Bagaimana memiliki kontrol keuangan untuk menghemat uang dan mewujudkan impian!

Menggunakan Desain UX untuk memahami masalah orang dalam mengendalikan uang mereka dan menciptakan kebiasaan menabung memikirkan masa depan mereka. Tantangan Berapa kali kita melepaskan keinginan untuk bepergian, membeli sesuatu yang selalu kita inginkan, atau mulai berinvestasi memikirkan masa depan hanya karena kita tidak dapat memiliki kendali nyata atas uang kita? Berdasarkan hal itu, kami memikirkan bagaimana cara menghadirkan cara agar Anda dapat mengontrol uang Anda dan dapat menyimpan “uang” di akhir bulan.

Daftar periksa bagi manajer produk AI untuk mendapatkan hasil maksimal dari sprint desain

Bagaimana memuaskan semua pemangku kepentingan dengan produk hebat

Daftar periksa bagi manajer produk AI untuk mendapatkan hasil maksimal dari sprint desain

Membuat kata kunci sebagai "digitalisasi", "inovasi", dan "data besar" menjadi produk yang hidup dan menguntungkan itu sulit. Dan biasanya, bukan teknologinya yang gagal, tetapi penyelarasan antara pemilik, manajer, klien, karyawan, dan terkadang masyarakat.

MORE COOL STUFF

Apakah Pelatih Basket Duke Blue Devils Mike Krzyzewski Menikah?

Apakah Pelatih Basket Duke Blue Devils Mike Krzyzewski Menikah?

Pensiunnya Mike Krzyzewski dari bola basket Duke pada akhir musim ini akan memberinya lebih banyak waktu bersama istri dan keluarganya.

Seberapa Tinggi Nicholas Braun Dari 'Succession'?

Seberapa Tinggi Nicholas Braun Dari 'Succession'?

Penggemar 'Succession' tidak bisa tidak memperhatikan tinggi badan Greg alias Nicholas Braun yang luar biasa tinggi. Apakah dia benar-benar menjulang di atas anggota pemerannya?

Lauk Thanksgiving 'The Pioneer Woman' Ree Drummond untuk Musim Liburan 2021

Lauk Thanksgiving 'The Pioneer Woman' Ree Drummond untuk Musim Liburan 2021

Wanita Perintis Ree Drummond ada di sini untuk membuat Anda siap untuk Thanksgiving. Berikut adalah beberapa lauk pauk terbaiknya.

'90 Day Fiancé': Pembaruan Status Hubungan Mike Youngquist Saat Istri Asing Natalie Menggoda di 'The Single Life'

Natalie ada di '90 Day: The Single Life', tapi apa yang dilakukan Mike Youngquist? Inilah yang kami ketahui tentang status hubungan Mike saat ini.

Coba Teka Teki Silang Mini Kami

Coba Teka Teki Silang Mini Kami

Diperbarui setiap minggu, teka-teki silang mini kami menggabungkan bacaan HowStuffWorks favorit kami dengan petunjuk cerdas!

Mana yang Paling Cocok: Pod Binatu, Deterjen Bubuk atau Cair?

Mana yang Paling Cocok: Pod Binatu, Deterjen Bubuk atau Cair?

Mencuci pakaian sudah cukup buruk tanpa harus khawatir memilih deterjen yang tepat. Jadi mana yang terbaik? Atau apakah itu penting?

Kisah Nyata Orang Biru Kentucky

Kisah Nyata Orang Biru Kentucky

Keluarga Fugates dan Combs di pedesaan Kentucky kalah dalam lotere genetik, keduanya memiliki sifat resesif langka yang membuat kulit mereka terlihat biru saat mereka menikah. Apa penyebabnya? Dan apa yang terjadi dengan keluarga?

Bisakah California Condor 'Virgin Birth' Menyelamatkan Spesies?

Bisakah California Condor 'Virgin Birth' Menyelamatkan Spesies?

Dua anak ayam jantan tanpa ayah dibesarkan dalam program untuk menyelamatkan condor California dari kepunahan. Bagaimana mungkin kelahiran 'perawan' seperti itu?

Dengan $ 125.000, Anda Dapat Membelikan Miniatur Truk Monster untuk Anak Anda

Dengan $ 125.000, Anda Dapat Membelikan Miniatur Truk Monster untuk Anak Anda

Kita semua tahu apa artinya manja, tetapi untuk definisi yang paling benar dari kata tersebut, Anda tidak perlu melihat lebih jauh dari miniatur truk monster ini yang dirancang untuk anak-anak yang didukung oleh mesin Ford empat silinder sungguhan yang mendorongnya hingga kecepatan tertinggi 25 mil per jam. Ukurannya kira-kira setengah dari ukuran truk monster asli seperti Bigfoot dan Grave Digger, dan dibuat khusus dengan rangka gulungan tabung baja dua inci mulus yang cukup kuat untuk menahan benturan dan terguling.

Will Smith, orc dan mafia elf: ini adalah trailer kedua dari produksi terbesar dalam sejarah Netflix

Will Smith, orc dan mafia elf: ini adalah trailer kedua dari produksi terbesar dalam sejarah Netflix

Beberapa bulan yang lalu, Netflix merilis trailer pertama untuk Bright, produksi paling ambisius dari rantai tersebut yang menampilkan Will Smith sebagai protagonisnya. Sekarang kami dapat mengonfirmasi sebagian dari apa yang kami lihat di pratinjau pertama itu: potongan film fantastis lebih jarang dari yang kami kira.

Gunakan 444 Horsepower BMW M3 Anda Sebagai Bajak Salju

Gunakan 444 Horsepower BMW M3 Anda Sebagai Bajak Salju

GIF melalui Tom Lawrowski Sebagian besar wilayah timur laut berada dalam mode ledakan musim dingin penuh, dan bagi pembaca Tom Lawrowski, itu berarti cuaca yang sempurna untuk BMW M3 generasi F80-nya. Jelas, penghilangan salju adalah penggunaan terbaik dari 444 tenaga kuda.

Saya, Seperti Susan Sarandon, Tidak Berseteru Dengan Julia Roberts di Lokasi Film Ibu Tiri 1998

Saya, Seperti Susan Sarandon, Tidak Berseteru Dengan Julia Roberts di Lokasi Film Ibu Tiri 1998

Gambar melalui 1492 Pictures. Kembali pada tahun 1998, gosip besar di mingguan selebriti adalah bahwa Susan Sarandon dan Julia Roberts berselisih di set ibu tiri dramedy mereka.

Cardi B dan Kulture Putri Offset Pamer Kepang Baru yang Cantik di Instagram

Cardi B dan Kulture Putri Offset Pamer Kepang Baru yang Cantik di Instagram

Putri Cardi B dan Offset yang berusia 3 tahun, Kulture, memamerkan gaya rambut kepang barunya di Instagram.

Selena Gomez Memberi Cara Delevingne Kecupan di Pipi untuk Kiss Cam di Knicks Game

Selena Gomez Memberi Cara Delevingne Kecupan di Pipi untuk Kiss Cam di Knicks Game

"Dia sangat menyenangkan dan dia sangat suka berpetualang," kata Selena Gomez sebelumnya tentang sahabatnya, Cara Delevingne.

Madonna Minum Gin dari Botol di Gymnya: 'Latihan Hari Ini'

Madonna Minum Gin dari Botol di Gymnya: 'Latihan Hari Ini'

Penyanyi itu memutuskan untuk mengubah rutinitas kebugarannya pada hari Kamis

Jamie Dornan Mengatakan Dia Kehilangan Peran Superman dari Henry Cavill dan Telah Mendekati Marvel untuk Peran Superhero

Jamie Dornan Mengatakan Dia Kehilangan Peran Superman dari Henry Cavill dan Telah Mendekati Marvel untuk Peran Superhero

Jamie Dornan mengungkapkan dia mengikuti audisi untuk peran Superman tetapi kalah dari Henry Cavill; dan dia telah berbicara dengan Marvel tentang bergabung dengan MCU.

Languages

野花在线观看免费观看大全-野花视频在线观看免费观看8
国足最新出线概率0.08% 北京冬奥火炬宣传片获金花环奖 速度与激情9 得知母亲出事男子在地铁痛哭 国足战澳大利亚大名单:4归化在列 周冠宇成为中国首位F1车手 安娜贝尔 尚气与十环传奇 胡锡进谈中美元首会晤 红色通缉令 尚气与十环传奇 印度首都准备封城 房价上涨城市创七年新低 拐点来了? 24岁救人牺牲消防员获批为烈士 扫黑风暴 我要我们在一起 意大利错失直接晋级世界杯资格 中美元首会谈重点内容 中国共产党第三个历史决议全文发布 灵媒 意大利错失直接晋级世界杯资格 俄方回应卫星碎片危及国际空间站 中美元首是否达成新共识?中方回应 男子写80页PPT拯救爱情却离婚 动保组织向上饶信州区申请信息公开 许家印为恒大注入超70亿续命资金 动保组织向上饶信州区申请信息公开 千与千寻 意大利错失直接晋级世界杯资格 两个女人 浦发银行回应近3亿存款莫名被质押 罗永浩吐槽苹果文案没文化 大连现超级传播者26人在同一传播链 扫黑风暴 安娜贝尔 中美元首会谈重点内容 长津湖 图兰朵 24岁救人牺牲消防员获批为烈士 房价上涨城市创七年新低 拐点来了? 五个扑水的少年 大连一密接者擅自点外卖聚餐被调查 男子写80页PPT拯救爱情却离婚 #耿直真香哥黑化卖惨# 动保组织向上饶信州区申请信息公开 扫黑风暴 失控玩家 扫黑风暴 许家印为恒大注入超70亿续命资金 外交部回应拜登重申不支持台独 加拿大一枝黄花到底是什么? 中国医生 男子体检血中抽出2升油浆 红色通缉令 大连现超级传播者26人在同一传播链 国际人士热议中共十九届六中全会 俄方回应卫星碎片危及国际空间站 怒火·重案 得知母亲出事男子在地铁痛哭 嘉南传 中美元首是否达成新共识?中方回应 浦发银行回应近3亿存款莫名被质押 斗破苍穹 蜘蛛侠:英雄归来 扫黑风暴 林丹世界排名被正式移除 男子体检血中抽出2升油浆 大连现超级传播者26人在同一传播链 扫黑风暴 林丹世界排名被正式移除 国足战澳大利亚大名单:4归化在列
阿巴嘎旗| 大安市| 江阴市| 团风县| 吉水县| 武安市| 合肥市| 汉中市| 兖州市| 十堰市| 无极县| 安多县| 托克托县| 类乌齐县| 荣昌县| 谢通门县| 岱山县| 镇原县| 德令哈市| 扎赉特旗| 肇东市| 岳阳市| 博爱县| 大邑县|