Pengkomputeran awan dijelaskan: 11 konsep seni bina yang mesti anda tahu (4K Masterclass).

Apa yang diliputi video ini

• - The Architecture Wall & Master Blueprint
• - 01. Pensskalaan Menegak vs. Mendatar
• - 02. Seni Bina Pengimbangan Beban (L4 vs. L7 & Pemeriksaan Kesihatan)
• - 03. Penskalaan Automatik & Keanjalan
• - 04. Tanpa Pelayan (FaaS & MicroVM Firecracker)

Transkrip terjemahan

Diterjemahkan daripada penceritaan asal Bahasa Inggeris. Audio dan kapsyen yang tersedia dikawal oleh YouTube.

- The Architecture Wall & Master Blueprint

0:00 Setiap jurutera perisian akhirnya berdepan dengan tembok seni bina awan. Anda membina aplikasi pada komputer riba anda, menolaknya ke pengeluaran, dan sebaik sahaja pengguna sebenar tiba, pelayan ranap, sambungan pangkalan data habis, dan bil AWS anda kelihatan seperti nombor telefon. Kebanyakan pembangun cuba menyelesaikan kejuruteraan awan dengan menghafal tiga ratus akronim produk AWS yang berbeza. Tetapi pengkomputeran awan sebenar bukan tentang menghafal katalog vendor: ia dibina di atas sebelas primitif seni bina asas.

0:34 Dalam kelas master ini, kami akan meneroka keseluruhan pelan induk perusahaan: daripada penskalaan dan pengimbangan beban kepada tanpa pelayan, penyahgandingan berasaskan acara, hierarki storan, dan rangkaian awan. Kuasai sebelas konsep ini, dan anda boleh mereka bentuk sebarang bahagian belakang di AWS, GCP, atau Azure. Ini ialah The Daily Diff, di sebalik tabir.

- 01. Penskalaan Menegak vs. Mendatar

0:57 Konsep nombor satu: Penskalaan. Apabila aplikasi web anda mengalami pertumbuhan trafik, anda mempunyai dua cara yang berbeza untuk mengendalikan beban: penskalaan menegak, atau penskalaan mendatar. Penskalaan menegak, atau scaling up, bermaksud mengambil mesin sedia ada anda dan menambah lebih banyak sumber: menaik taraf daripada empat teras CPU kepada tiga puluh dua, atau menukar tiga puluh dua gigabait RAM untuk seratus dua puluh lapan. Penskalaan menegak tidak memerlukan perubahan seni bina: kod dan pangkalan

1:28 data anda kekal sama. Tetapi ia mencecah had perkakasan yang kejam. Tiada satu mesin pun di dunia mempunyai sepuluh ribu teras CPU, dan instans peringkat teratas membawa premium harga eksponen. Penskalaan mendatar, atau scaling out, bermaksud mengekalkan pelayan anda kecil dan berharga komoditi, tetapi menjalankan pelbagai instans secara selari di belakang penghala. Jika satu instans ranap, nod yang tinggal menyerap trafik dengan masa henti sifar. Peraturan emas penskalaan mendatar ialah

2:01 ketiadaan keadaan (statelessness): pelayan aplikasi anda tidak boleh menyimpan sesi pengguna, fail yang dimuat naik, atau keadaan pada cakera tempatan mereka. Keadaan mesti berada dalam pangkalan data atau cache luaran, membenarkan mana-mana nod untuk mengendalikan sebarang permintaan pengguna.

- 02. Seni Bina Pengimbangan Beban (L4 vs. L7 & Pemeriksaan Kesihatan)

2:17 Konsep nombor dua: Pengimbangan Beban. Penskalaan mendatar kedengaran hebat di atas kertas, tetapi ia menimbulkan masalah serta-merta: apabila sepuluh ribu pengguna melawat nama domain anda, pelayan mana yang akan menerima trafik mereka? Pengimbang beban bertindak sebagai proksi terbalik yang terletak di antara internet awam dan kluster belakang persendirian anda. Ia menerima sambungan TCP atau HTTP masuk dan mengedarkan permintaan ke seluruh instans sihat anda.

2:47 Pengimbang beban beroperasi pada dua lapisan rangkaian utama. Pengimbang Beban Rangkaian Lapisan 4 beroperasi pada lapisan pengangkutan, menghala paket TCP dan UDP mentah berdasarkan alamat IP dan port dengan kependaman mikrosaat dan berjuta-juta permintaan sesaat. Pengimbang Beban Aplikasi Lapisan 7 memeriksa protokol HTTP itu sendiri: membaca laluan URL, pengepala permintaan, kuki, dan kaedah HTTP. Ini membolehkan penghalaan berasaskan laluan: menghantar permintaan slash-api ke kluster belakang anda dan permintaan slash-static ke

3:25 storan objek. Yang penting, pengimbang beban melakukan pemeriksaan kesihatan aktif. Setiap beberapa saat, pengimbang beban menghantar ping ke titik akhir kesihatan pada setiap instans. Jika satu instans membuang tiga ralat lima ratus berturut-turut atau gagal memberi respons, ia secara automatik dikeluarkan daripada kumpulan dengan sifar permintaan yang digugurkan.

- 03. Penskalaan Automatik & Keanjalan

3:45 Konsep nombor tiga: Penskalaan Automatik. Jika aplikasi web anda memerlukan dua pelayan pada pukul tiga pagi, tetapi dua puluh pelayan semasa pelancaran tengah hari, mengklik butang secara manual dalam konsol awan adalah jalan yang pasti menuju masa henti dan kebankrapan. Penskalaan automatik membawa keanjalan dinamik kepada kumpulan pelayan mendatar. Kumpulan Penskalaan Automatik memantau metrik prestasi seperti penggunaan CPU purata, I/O rangkaian, atau kedalaman tunggakan barisan. Apabila CPU purata melepasi ambang yang ditetapkan — contohnya,

4:19 tujuh puluh peratus selama tiga minit berturut-turut — penskala automatik secara automatik melancarkan mesin maya baharu, mendaftarkannya dengan pengimbang beban anda, dan mula menghala trafik. Sama pentingnya ialah penskalaan masuk: apabila gelombang trafik surut, penskala automatik menamatkan instans yang berlebihan supaya anda berhenti membayar untuk pengiraan yang tidak aktif. Untuk mengelakkan flapping — di mana pelayan dicipta dan dimusnahkan dengan pantas dalam gelung thrashing yang tidak berkesudahan — arkitek awan mengkonfigurasi tempoh bertenang. Konsep nombor empat: Tanpa Pelayan.

- 04. Tanpa Pelayan (FaaS & MicroVM Firecracker)

4:53 Selama bertahun-tahun, pasukan pemasaran mempromosikan tanpa pelayan sebagai kod ajaib yang berjalan di langit. Pada hakikatnya, tanpa pelayan masih menggunakan pelayan — tetapi anda tidak memiliki, menampal, atau membayarnya apabila tiada kod yang berjalan. Dengan Fungsi sebagai Perkhidmatan seperti AWS Lambda atau Google Cloud Functions, anda menulis fungsi pengendali kendiri. Apabila permintaan HTTP, muat naik fail S3, atau perubahan pangkalan data berlaku, runtime awan memulakan mesin maya mikro

5:23 ephemeral seperti Firecracker dalam masa kurang lima milisaat. Kod anda berjalan, mengembalikan respons, dan dimatikan. Jika tiada siapa yang melawat tapak web anda selama tiga bulan, bil pengkomputeran anda adalah tepat sifar dolar dan sifar sen. Jika sejuta pengguna mengunjunginya serentak, penyedia melancarkan sejuta microVM serentak. Pertukaran kejuruteraan adalah nyata: kependaman permulaan sejuk apabila memulakan runtime baharu, had pelaksanaan lima belas minit yang ketat pada Lambda, dan ketiadaan keadaan yang ketat.

5:55 Tanpa pelayan tidak dapat ditandingi untuk saluran paip acara dan API sporadis, tetapi lemah untuk WebSockets berterusan atau larian latihan berbilang jam.

- 05. Seni Bina Pemacu Acara (EDA & Penyahgandingan)

6:05 Konsep nombor lima: Seni Bina Berasaskan Acara, atau EDA. Dalam seni bina tradisional, perkhidmatan berkomunikasi secara segerak. Perkhidmatan pembayaran anda memanggil pembayaran, pembayaran memanggil inventori, inventori memanggil penipuan, dan penipuan memanggil e-mel. Ini mewujudkan cascading synchronous of doom. Jika pembekal e-mel pihak ketiga mengalami masalah rangkaian dan mengambil sepuluh saat untuk membalas, keseluruhan permintaan pembayaran pelanggan anda tamat masa dengan ralat. Dalam seni bina berasaskan acara, perkhidmatan dipisahkan sepenuhnya.

6:37 Apabila pelanggan mengklik beli, perkhidmatan pembayaran tidak memanggil perkhidmatan hiliran. Ia hanya menerbitkan acara bernama OrderPlaced ke Bus Acara pusat seperti Amazon EventBridge atau topik SNS. Pembayaran selesai dalam lima puluh milisaat. Pekerja hiliran untuk pembayaran, pengurangan inventori, dan resit e-mel menarik mesej secara bebas daripada barisan SQS khusus mereka sendiri. Jika perkhidmatan e-mel tergendala selama sejam, mesej menunggu dengan selamat dibuffer dalam barisan tanpa sebarang pesanan yang digugurkan.

- 06. Orkestrasi Kontena (Docker & Kubernetes)

7:13 Konsep nombor enam: Orkestrasi Kontena. Docker menyelesaikan pembungkusan: ia membalut kod aplikasi anda, perpustakaan sistem, konfigurasi, dan runtime ke dalam imej kekal yang berjalan sama pada MacBook anda dan di awan. Tetapi membungkus kontena adalah mudah. Menjalankan lima ratus kontena merentasi lima puluh mesin maya fizikal adalah di mana kejuruteraan gagal. Itulah sebabnya orkestrator kontena seperti Kubernetes dan AWS ECS

7:41 wujud. Orkestrator menyediakan satah kawalan: pelayan API, penyimpan keadaan etcd, dan penjadual pintar. Anda mengisytiharkan keadaan yang anda inginkan: Saya mahukan sepuluh replika perkhidmatan auth saya dengan dua gigabait RAM setiap satu. Penjadual memeriksa kluster, meletakkan pod pada nod dengan memori bebas, mengkonfigurasi rangkaian dalaman, dan secara berterusan mendamaikan realiti. Jika nod mengalami kegagalan perkakasan, Kubernetes mengesan kehilangan itu dan serta-merta menjadualkan semula semua pod yang dipindahkan ke

- 07. 4 Tonggak Penyimpanan Awan (S3, EBS, DB & Redis)

8:16 nod yang sihat. Konsep nombor tujuh: Hierarki Penyimpanan Awan. Pemula sering menganggap penyimpanan awan sebagai satu baldi di mana anda membuang fail. Dalam seni bina pengeluaran, penyimpanan dibahagikan kepada empat tonggak yang berbeza berdasarkan corak akses dan kependaman. Pertama adalah Penyimpanan Objek, seperti Amazon S3 atau Google Cloud Storage. Anda mengakses fail melalui API REST HTTP menggunakan panggilan PUT dan GET yang mudah. Ia menawarkan kapasiti mendatar tanpa had pada dua sen per gigabait sebulan,

8:49 menjadikannya sesuai untuk video, muat naik pengguna, log, dan sandaran. Kedua adalah Penyimpanan Blok, seperti Amazon EBS. Ini adalah cakera keras maya yang dipasang secara langsung ke mesin maya tertentu melalui sambungan berkelajuan tinggi. Ia diformat menjadi sistem fail standard seperti ext4, menyokong akses baca dan tulis rawak pantas yang diperlukan oleh enjin pangkalan data. Ketiga adalah Pangkalan Data Terurus: enjin hubungan seperti PostgreSQL pada RDS yang menyediakan transaksi ACID dan gabungan kompleks,

9:21 dan enjin NoSQL seperti DynamoDB yang memberikan kependaman milisaat satu digit pada skala besar. Dan keempat adalah Cache Dalam Memori seperti Redis. Membaca data dari RAM mengambil mikrosaat berbanding milisaat. Cache berada di hadapan pangkalan data anda, melindunginya daripada trafik baca berulang dan menguruskan token sesi pengguna yang tidak stabil.

- 08. Ketersediaan Tinggi & Nines (Failover Berbilang AZ)

9:44 Konsep nombor lapan: Ketersediaan Tinggi, atau HA. Ketersediaan menjawab satu soalan: berapa peratus masa aplikasi anda beroperasi dan boleh dicapai oleh pengguna? Dalam kontrak perusahaan, ketersediaan diukur dalam 'nines'. Dua 'nines', atau sembilan puluh sembilan peratus ketersediaan, membenarkan lebih daripada tiga setengah hari masa henti setiap tahun. Empat 'nines' mengurangkan masa henti yang dibenarkan kepada lima puluh dua minit, dan lima 'nines' membenarkan hanya lima minit jumlah masa henti setiap

10:15 tahun. Untuk mencapai ketersediaan tinggi, anda mesti menghapuskan titik kegagalan tunggal merentasi domain kesalahan. Dalam awan, ini bermaksud menempatkan merentasi beberapa Zon Ketersediaan. Zon Ketersediaan bukan satu rak: ia adalah satu atau lebih pusat data fizikal berasingan yang berjauhan dengan kuasa dan penyejukan bebas. Dengan menjalankan instans aktif di Zon A dan Zon B dengan replikasi pangkalan data segerak, sambaran kilat atau kerosakan gentian yang menjatuhkan keseluruhan kemudahan fizikal mengakibatkan failover automatik

10:50 dalam tiga puluh saat tanpa campur tangan manusia.

- 09. Ketahanan vs. Ketersediaan (Mengapa 11 Nines Bukan Uptime)

10:53 Konsep nombor sembilan: Ketahanan lawan Ketersediaan. Ini adalah perangkap konseptual yang paling biasa dalam seni bina awan temu bual. Jurutera kerap menggunakan perkataan secara bergantian, tetapi ia mengukur sifat yang sama sekali berbeza. Ketersediaan mengukur masa beroperasi: bolehkah saya membuat panggilan API untuk membaca atau menulis data saya pada saat ini? Ketahanan mengukur pemeliharaan: adakah data saya akan bertahan tanpa kerosakan kekal, kerosakan bit, atau pemusnahan selama sepuluh tahun?

11:24 Lihat Amazon S3 Standard. Perjanjian Tahap Perkhidmatannya menawarkan sembilan puluh sembilan peratus sembilan ketersediaan, yang membenarkan kira-kira empat puluh tiga minit masa henti setiap bulan di mana permintaan API mungkin mengembalikan ralat lima ratus. Tetapi S3 menjanjikan ketahanan sebelas sembilan: sembilan puluh sembilan titik sembilan sembilan sembilan sembilan sembilan sembilan sembilan sembilan sembilan peratus. Jika anda menyimpan sepuluh juta fail dalam S3, anda boleh menjangkakan secara statistik untuk kehilangan

11:56 purata satu fail setiap sepuluh ribu tahun. S3 mencapai ini dengan objek pengekodan pemadaman dan mereplikasi cebisan di seluruh sekurang-kurangnya tiga kemudahan data yang dipisahkan secara geografi. Semasa gangguan rangkaian serantau utama, S3 mungkin sementara tidak tersedia, tetapi data anda tidak pernah musnah.

- 10. Infrastruktur sebagai Kod (Terraform vs. Console Drift)

12:14 Konsep nombor sepuluh: Infrastruktur sebagai Kod, atau IaC. Pada awal pengkomputeran awan, jurutera log masuk ke konsol pengurusan web AWS dan mengklik secara manual untuk mencipta mesin maya, mengkonfigurasi subrangkaian, dan melampirkan kumpulan keselamatan. Industri memanggil ini ClickOps, dan dalam pengeluaran, ia adalah bencana mutlak. Perubahan konsol manual tidak mempunyai jejak audit, tiada mekanisme balik, dan pasti menyebabkan penyimpangan konfigurasi antara persekitaran pementasan dan pengeluaran. Dengan alat Infrastruktur sebagai Kod seperti Terraform,

12:48 OpenTofu, Pulumi, atau AWS CDK, anda mentakrifkan keseluruhan seni bina awan anda dalam fail konfigurasi deklaratif yang disimpan dalam Git. Setiap perubahan kepada port terbuka atau replika pangkalan data melalui permintaan tarik dan semakan rakan sebaya. Menjalankan rancangan terraform pratonton perbezaan API yang tepat sebelum apa-apa disentuh, dan menghidupkan replika yang sama bagi tumpukan pengeluaran anda mengambil masa empat minit dan bukannya empat minggu. Konsep nombor sebelas: Rangkaian Awan dan Awan Peribadi Maya.

- 11. Rangkaian Awan (VPC, Subnet, NAT & Kumpulan Keselamatan)

13:20 Apabila anda menggunakan pelayan ke awan, ia tidak terdedah pada internet awam mentah. Ia hidup di dalam sempadan terpencil yang ditakrifkan oleh perisian yang dipanggil VPC. Di dalam VPC anda, anda memperuntukkan ruang alamat IP peribadi seperti sepuluh-titik-kosong-titik-kosong-titik-kosong sengkang enam belas, dan membahagikannya kepada subrangkaian awam dan peribadi. Subrangkaian awam mempunyai laluan terus ke Gerbang Internet. Ia memegang aset yang menghadap awam seperti Application Load Balancers dan NAT

13:51 Gateways anda. Ia adalah satu-satunya bahagian rangkaian anda yang memiliki alamat IP awam. Pelayan aplikasi dan pangkalan data pengeluaran anda hidup secara ketat dalam subrangkaian peribadi tanpa IP awam dan sifar laluan masuk dari internet. Apabila pelayan belakang anda perlu memuat turun kemas kini keselamatan, trafik keluar mereka melalui NAT Gateway dalam subrangkaian awam. Mengelilingi setiap instans adalah Kumpulan Keselamatan: firewall maya berkeadaan yang menguatkuasakan prinsip keistimewaan paling sedikit. Kumpulan keselamatan pangkalan data anda hanya menerima sambungan pada port

- 12. Pelan Induk Perusahaan Lengkap & Keputusan

14:28 5432 secara ketat dari kumpulan keselamatan pelayan aplikasi anda, menjadikan penembusan luaran secara matematik mustahil. Apabila anda mengezum keluar, sebelas primitif ini bersambung menjadi satu sistem yang kohesif. DNS anda menghala ke Load Balancer dalam subrangkaian awam, kumpulan penskalaan automatik mengendalikan lonjakan trafik merentasi beberapa Zon Ketersediaan, bas acara memisahkan pekerja belakang, dan seluruh tumpukan anda digunakan dari Git menggunakan Infrastruktur sebagai Kod.

15:02 Keputusan kelas induk hari ini: SHIP IT. Berhenti menghafal ratusan akronim pemasaran awan. Kuasai sebelas corak seni bina ini, pisahkan keadaan anda, dan bina sistem yang tidak boleh gagal. Beritahu saya konsep awan mana yang memberi anda masalah terbesar apabila anda mula membina dalam komen. Dan untuk mendapatkan helaian seni bina lengkap, langgan surat berita di the daily diff dot dev,

15:28 pautan di bawah. Dan itulah perbezaan untuk hari ini. Saya Niko dari Axrisi. Gabungkan secara bertanggungjawab.

Sumber

1. AWS Well-Architected Framework (Reliability & Performance Pillars)aws.amazon.com
2. Kubernetes Architecture & Control Plane Conceptskubernetes.io
3. Martin Fowler: What is Event-Driven Architecture?martinfowler.com
4. Amazon S3 Data Durability & Availability Technical Whitepaperaws.amazon.com
5. HashiCorp: Declarative Infrastructure as Code with Terraformwww.terraform.io