Amalan terbaik

Panduan ini membincangkan corak, prinsip dan strategi yang terbukti dalam ribuan pelaksanaan.

Prinsip reka bentuk

1. Mulakan ringkas dan berkembang berperingkat

Jangan merumitkan seni bina sejak awal. Mulakan dengan reka bentuk paling ringkas yang memenuhi keperluan semasa, kemudian kembangkan.

Baik: satu pangkalan data, satu pelayan aplikasi dan pengimbang beban. Buruk: mikroperkhidmatan di 5 rantau dengan penyimpanan berasaskan peristiwa sejak hari pertama.

2. Reka untuk menghadapi kegagalan

Anggap komponen akan gagal. Sediakan redundansi dan kemerosotan fungsi terkawal.

Baik: pangkalan data Multi-AZ, replika failover dan pemutus litar. Buruk: titik kegagalan tunggal di mana-mana bahagian.

3. Ukur sebelum mengoptimumkan

Jangan mengoptimumkan tanpa data. Gunakan modul analisis dan pemantauan.

Baik: jalankan penganalisis kebolehskalaan untuk mencari kesesakan sebenar. Buruk: “Pangkalan data mungkin perlahan, tambah cache sahaja.”

4. Fahami kelebihan dan kekurangan

Setiap keputusan melibatkan pertimbangan. Dokumentasikannya.

Baik: “Kami memilih monolit untuk pelancaran pantas dan beralih kepada mikroperkhidmatan pada 100k pengguna.” Buruk: “Tambah mikroperkhidmatan untuk skala,” tanpa memahami kerumitannya.

5. Automatikkan semuanya

Proses manual tidak berskala. Automatikkan pelaksanaan, pemantauan dan penskalaan.

Baik: infrastruktur sebagai kod dengan Terraform, kumpulan penskalaan automatik dan saluran CI/CD. Buruk: penyediaan pelayan dan keputusan kapasiti manual.

Corak seni bina lazim

Corak: aplikasi web monolitik

Bila digunakan: MVP, satu pasukan dan <100k pengguna.

Topologi:

Users
  ↓
Load Balancer (ELB)
  ↓
App Servers (3+ instances, auto-scaled)
  ↓
Cache Layer (Redis)
  ↓
Database (Primary + Read Replicas)
  ↓
Object Storage (S3)

Kelebihan:

• Pembangunan dan penyahpepijatan mudah.
• Pelaksanaan dan penskalaan mendatar mudah.
• Beban operasi rendah.

Kekurangan:

• Pangkalan kod besar sukar disenggara.
• Pangkalan data bersama mengehadkan skala.
• Terikat pada bahasa dan rangka kerja.

Bila berkembang: apabila pangkalan data menjadi kesesakan pada 50k+ pengguna.

Corak: seni bina mikroperkhidmatan

Bila digunakan: pasukan besar, >100k pengguna dan pelbagai perkhidmatan.

Topologi:

API Gateway
├─ Auth Service
├─ User Service
├─ Product Service
├─ Order Service
├─ Payment Service
├─ Notification Service
└─ Analytics Service

Shared Infrastructure:
- Service Mesh (Istio, Linkerd)
- Message Bus (Kafka, RabbitMQ)
- Distributed Tracing
- Centralized Logging

Kelebihan:

• Skala setiap perkhidmatan secara bebas.
• Pasukan berautonomi.
• Teknologi dan bahasa fleksibel.
• Pelaksanaan individu mudah.

Kekurangan:

• Operasi lebih rumit.
• Cabaran teragih seperti ketekalan akhirnya dan penyahpepijatan.
• Kependaman rangkaian antara perkhidmatan.
• Memerlukan amalan DevOps matang.

Bila digunakan: monolit menjadi kesesakan DAN struktur pasukan menyokong perubahan.

Corak: tanpa pelayan, FaaS

Bila digunakan: beban dipacu peristiwa, permintaan berubah dan penekanan kos.

Topologi:

API Gateway
  ↓
Lambda Functions (auto-scaled to zero)
  ├─ DynamoDB (serverless database)
  ├─ S3 (object storage)
  ├─ SQS/SNS (messaging)
  └─ CloudWatch Logs

Kelebihan:

• Bayar masa pengkomputeran yang digunakan sahaja.
• Skala automatik kepada sifar semasa melahu.
• Pembangunan dan pelaksanaan mudah.
• Tiada pengurusan infrastruktur.

Kekurangan:

• Kependaman permulaan sejuk.
• Penyesuaian persekitaran terhad.
• Kebergantungan penyedia seperti AWS Lambda dan GCP Functions.
• Penyahpepijatan lebih sukar daripada pelayan biasa.

Bila digunakan: lonjakan mendadak, tugas jarang dan syarikat baharu dengan operasi terhad.

Corak: tasik data dan analitik

Bila digunakan: data raya, pembelajaran mesin dan beban analitik.

Topologi:

Data Sources (streaming + batch)
  ↓
Data Ingestion (Kafka, Kinesis, SQS)
  ↓
Data Lake (S3, Blob Storage)
  ↓
ETL/Transform (Spark, Glue, Dataflow)
  ↓
Data Warehouse (Redshift, BigQuery, Snowflake)
  ↓
BI/ML Tools (Tableau, DataStudio, SageMaker)

Pertimbangan:

• Kualiti dan tadbir urus data.
• Skema semasa membaca atau menulis.
• Maklumat peribadi dan pematuhan privasi.
• Pengoptimuman prestasi pertanyaan.

Strategi pengoptimuman

Pengoptimuman kos

1. Saiz bersesuaian

• Pantau penggunaan sebenar, bukan kapasiti maksimum.
• Kenal pasti corak dengan CloudWatch atau setara.
• Kecilkan instans yang terlebih kapasiti.

2. Instans ditempah

• Ramalkan beban stabil.
• Tempah 1-3 tahun dengan diskaun 20-40%.
• Gabungkan dengan skala automatik bagi beban berubah.

3. Instans Spot

• Untuk beban toleran kegagalan dan tidak kritikal.
• 70% lebih murah daripada atas permintaan.
• Jangkakan gangguan 2-5%.

4. Strategi cache

• Simpan data kerap dicapai dalam memori Redis.
• Kurangkan beban pangkalan data 50-80%.
• CDN untuk aset statik: pengurangan kos 80%+.

5. Pemindahan data

• Komponen kos tinggi ini sering terlepas pandang.
• Gunakan titik akhir VPC untuk mengelakkan caj pemindahan.
• Mampatkan data dalam transit.
• Gunakan CloudFront untuk edaran global.

Pengoptimuman kebolehskalaan

1. Penskalaan mendatar

• Tambah pelayan di belakang pengimbang.
• Pangkalan data: replika baca dengan utama dan sekunder.
• Cache: tambah nod cache.

2. Pembahagian pangkalan data

• Bahagi mengikut ID pengguna, rantau atau tarikh.
• Setiap bahagian berskala bebas.
• Pertimbangan: penyelarasan lebih rumit.

3. Pengumpulan sambungan

• Guna semula sambungan pangkalan data.
• Daya pemprosesan meningkat 2-3x.
• Kurang overhed sambungan.

4. Strategi cache

• Cache data kerap dicapai di lapisan aplikasi.
• Cache respons API dengan strategi pembatalan.
• Cache pertanyaan pada ORM.

Amalan keselamatan terbaik

1. Penyulitan

• Dalam transit: TLS 1.3 pada semua titik akhir.
• Semasa disimpan: AES-256 dengan kekunci KMS.
• Pangkalan data: volum disulitkan dan penyulitan maklumat peribadi pada aplikasi.

2. Pengesahan dan keizinan

• MFA pada semua akaun.
• OAuth 2.0 untuk pihak ketiga.
• IAM dengan keistimewaan minimum.
• RBAC untuk pengguna aplikasi.

3. Rangkaian

• Pengasingan VPC dan subnet persendirian untuk pangkalan data.
• Kumpulan keselamatan dengan port minimum.
• NACL sebagai lapisan tambahan.
• WAF untuk aplikasi web pada pengimbang.

4. Perlindungan data

• Pentokenan dan penyamaran maklumat peribadi.
• Penyulitan medan sensitif.
• Dasar pengekalan dan pemadaman data lama.
• Uji pemulihan sandaran.

5. Pemantauan dan audit

• CloudTrail atau log audit untuk semua panggilan API.
• Penggera CloudWatch untuk anomali.
• Audit berkala.
• Panduan respons insiden.

Amalan prestasi terbaik

1. Kependaman

• CDN untuk aset statik.
• Indeks bagi pertanyaan lazim.
• Optimumkan pertanyaan dan elakkan N+1.
• Kelompokkan permintaan API.

2. Daya pemprosesan

• Seimbangkan beban antara pelayan.
• Kumpulkan sambungan pangkalan data.
• Proses tugas panjang secara tak segerak.
• Skala beban terikat CPU secara menegak.

3. Kebolehpercayaan

• Semakan kesihatan dan pemulihan automatik.
• Pemutus litar untuk kebergantungan.
• Cuba semula dengan sela eksponen.
• Kemerosotan fungsi terkawal.

Amalan pelaksanaan terbaik

1. Infrastruktur sebagai kod

• Semua dalam Terraform atau CloudFormation.
• Kawalan versi.
• Semakan rakan sebelum digunakan.
• Uji dalam pementasan dahulu.

2. Pelaksanaan berterusan

• Ujian unit, penyepaduan dan e2e automatik.
• Pelaksanaan kanari berperingkat.
• Pelaksanaan biru-hijau tanpa masa henti.
• Strategi kembali ke versi terdahulu.

3. Pemantauan dan kebolehcerapan

• Log berstruktur JSON.
• Penjejakan teragih X-Ray atau Jaeger.
• Metrik Prometheus atau CloudWatch.
• Amaran SLO, bukan ralat sahaja.

Anticorak yang perlu dielakkan

❌ Titik kegagalan tunggal tanpa redundansi. ❌ Kejuruteraan berlebihan sebelum pertumbuhan memerlukannya. ❌ Mengabaikan kos demi ciri tidak diperlukan. ❌ Skala manual yang sepatutnya automatik. ❌ Tiada pemantauan, tanpa keterlihatan. ❌ Tiada pelan pemulihan bencana: harapan bukan strategi. ❌ Semua dalam satu zon, terdedah kepada gangguan pusat data.

Langkah seterusnya

• Terokai corak → Pustaka corak
• Pelajari analisis → Modul analisis
• Amalan tadbir urus → Tadbir urus