Hai Habr!

Berdasarkan peristiwa semasa akibat coronavirus, beberapa perkhidmatan Internet telah mula menerima peningkatan beban. Sebagai contoh, Salah satu rangkaian runcit UK hanya menghentikan tapak pesanan dalam taliannya., kerana kapasiti tidak mencukupi. Dan tidak selalu mungkin untuk mempercepatkan pelayan dengan hanya menambah peralatan yang lebih berkuasa, tetapi permintaan pelanggan mesti diproses (atau mereka akan pergi ke pesaing).

Dalam artikel ini saya akan bercakap secara ringkas tentang amalan popular yang akan membolehkan anda membuat perkhidmatan yang pantas dan bertolak ansur. Walau bagaimanapun, daripada skim pembangunan yang mungkin, saya hanya memilih yang ada pada masa ini mudah untuk digunakan. Untuk setiap item, anda sama ada mempunyai perpustakaan sedia, atau anda berpeluang menyelesaikan masalah menggunakan platform awan.

Skala mendatar

Perkara yang paling mudah dan paling terkenal. Secara konvensional, dua skim pengagihan beban yang paling biasa ialah penskalaan mendatar dan menegak. Dalam kes pertama anda membenarkan perkhidmatan berjalan selari, dengan itu mengagihkan beban di antara mereka. Pada yang kedua anda memesan pelayan yang lebih berkuasa atau mengoptimumkan kod.

Sebagai contoh, saya akan mengambil storan fail awan abstrak, iaitu, beberapa analog OwnCloud, OneDrive dan sebagainya.

Gambar standard litar sedemikian adalah di bawah, tetapi ia hanya menunjukkan kerumitan sistem. Lagipun, kita perlu menyegerakkan perkhidmatan. Apakah yang berlaku jika pengguna menyimpan fail daripada tablet dan kemudian mahu melihatnya daripada telefon?

Perbezaan antara pendekatan: dalam penskalaan menegak, kami bersedia untuk meningkatkan kuasa nod, dan dalam penskalaan mendatar, kami bersedia untuk menambah nod baharu untuk mengagihkan beban.

CQRS

Pengasingan Tanggungjawab Pertanyaan Perintah Corak yang agak penting, kerana ia membolehkan pelanggan yang berbeza bukan sahaja menyambung ke perkhidmatan yang berbeza, tetapi juga untuk menerima aliran acara yang sama. Faedahnya tidak begitu jelas untuk aplikasi yang mudah, tetapi ia amat penting (dan mudah) untuk perkhidmatan yang sibuk. Intipatinya: aliran data masuk dan keluar tidak boleh bersilang. Iaitu, anda tidak boleh menghantar permintaan dan mengharapkan balasan; sebaliknya, anda menghantar permintaan kepada perkhidmatan A, tetapi menerima respons daripada perkhidmatan B.

Bonus pertama pendekatan ini ialah keupayaan untuk memutuskan sambungan (dalam erti kata yang luas) semasa melaksanakan permintaan yang panjang. Sebagai contoh, mari kita ambil lebih kurang urutan standard:

1. Pelanggan menghantar permintaan kepada pelayan.
2. Pelayan memulakan masa pemprosesan yang lama.
3. Pelayan bertindak balas kepada pelanggan dengan hasilnya.

Mari kita bayangkan bahawa dalam titik 2 sambungan telah terputus (atau rangkaian disambung semula, atau pengguna pergi ke halaman lain, memutuskan sambungan). Dalam kes ini, sukar bagi pelayan untuk menghantar respons kepada pengguna dengan maklumat tentang perkara yang sebenarnya diproses. Menggunakan CQRS, urutannya akan berbeza sedikit:

1. Pelanggan telah melanggan kemas kini.
2. Pelanggan menghantar permintaan kepada pelayan.
3. Pelayan menjawab "permintaan diterima."
4. Pelayan membalas dengan keputusan melalui saluran dari titik "1".

Seperti yang anda lihat, skema ini sedikit lebih kompleks. Selain itu, pendekatan permintaan-tindak balas intuitif tiada di sini. Walau bagaimanapun, seperti yang anda lihat, putus sambungan semasa memproses permintaan tidak akan membawa kepada ralat. Lebih-lebih lagi, jika sebenarnya pengguna disambungkan kepada perkhidmatan daripada beberapa peranti (contohnya, dari telefon mudah alih dan dari tablet), anda boleh memastikan bahawa respons datang kepada kedua-dua peranti.

Menariknya, kod untuk memproses mesej masuk menjadi sama (bukan 100%) untuk acara yang dipengaruhi oleh pelanggan itu sendiri dan untuk acara lain, termasuk acara daripada pelanggan lain.

Walau bagaimanapun, pada hakikatnya kami mendapat bonus tambahan kerana fakta bahawa aliran satu arah boleh dikendalikan dalam gaya berfungsi (menggunakan RX dan yang serupa). Dan ini sudah menjadi tambahan yang serius, kerana pada dasarnya aplikasi boleh dibuat sepenuhnya reaktif, dan juga menggunakan pendekatan berfungsi. Untuk program gemuk, ini boleh menjimatkan pembangunan dan sumber sokongan dengan ketara.

Jika kami menggabungkan pendekatan ini dengan penskalaan mendatar, maka sebagai bonus kami mendapat keupayaan untuk menghantar permintaan ke satu pelayan dan menerima respons daripada yang lain. Oleh itu, pelanggan boleh memilih perkhidmatan yang sesuai untuknya, dan sistem di dalamnya masih akan dapat memproses acara dengan betul.

Penyumberan Acara

Seperti yang anda ketahui, salah satu ciri utama sistem teragih ialah ketiadaan masa biasa, bahagian kritikal biasa. Untuk satu proses, anda boleh melakukan penyegerakan (pada mutex yang sama), di mana anda pasti bahawa tiada orang lain yang melaksanakan kod ini. Walau bagaimanapun, ini berbahaya untuk sistem teragih, kerana ia memerlukan overhed, dan juga akan membunuh semua keindahan penskalaan - semua komponen masih akan menunggu untuk satu.

Dari sini kita mendapat fakta penting - sistem pengedaran cepat tidak boleh disegerakkan, kerana kemudian kita akan mengurangkan prestasi. Sebaliknya, kita sering memerlukan konsistensi tertentu antara komponen. Dan untuk ini anda boleh menggunakan pendekatan dengan konsisten akhirnya, di mana ia dijamin bahawa jika tiada perubahan data untuk beberapa tempoh masa selepas kemas kini terakhir ("akhirnya"), semua pertanyaan akan mengembalikan nilai kemas kini terakhir.

Adalah penting untuk memahami bahawa untuk pangkalan data klasik ia agak kerap digunakan konsistensi yang kuat, di mana setiap nod mempunyai maklumat yang sama (ini selalunya dicapai dalam kes di mana transaksi dianggap ditubuhkan hanya selepas pelayan kedua bertindak balas). Terdapat beberapa kelonggaran di sini disebabkan oleh tahap pengasingan, tetapi idea umum tetap sama - anda boleh hidup dalam dunia yang harmoni sepenuhnya.

Walau bagaimanapun, mari kita kembali kepada tugas asal. Jika sebahagian daripada sistem boleh dibina dengan konsisten akhirnya, maka kita boleh membina rajah berikut.

Ciri penting pendekatan ini:

• Setiap permintaan masuk diletakkan dalam satu baris gilir.
• Semasa memproses permintaan, perkhidmatan juga boleh meletakkan tugas dalam baris gilir lain.
• Setiap peristiwa masuk mempunyai pengecam (yang diperlukan untuk penyahduplikasian).
• Barisan gilir secara ideologi berfungsi mengikut skema "tambah sahaja". Anda tidak boleh mengalih keluar elemen daripadanya atau menyusunnya semula.
• Barisan beratur berfungsi mengikut skema FIFO (maaf atas tautologi). Jika anda perlu melakukan pelaksanaan selari, maka pada satu peringkat anda harus memindahkan objek ke baris gilir yang berbeza.

Biar saya ingatkan anda bahawa kami sedang mempertimbangkan kes penyimpanan fail dalam talian. Dalam kes ini, sistem akan kelihatan seperti ini:

Adalah penting bahawa perkhidmatan dalam rajah tidak semestinya bermaksud pelayan yang berasingan. Malah prosesnya mungkin sama. Perkara lain yang penting: dari segi ideologi, perkara ini dipisahkan sedemikian rupa sehingga penskalaan mendatar boleh digunakan dengan mudah.

Dan untuk dua pengguna, rajah akan kelihatan seperti ini (perkhidmatan yang ditujukan untuk pengguna yang berbeza ditunjukkan dalam warna yang berbeza):

Bonus daripada gabungan tersebut:

• Perkhidmatan pemprosesan maklumat diasingkan. Barisan beratur juga dipisahkan. Jika kita perlu meningkatkan daya pengeluaran sistem, maka kita hanya perlu melancarkan lebih banyak perkhidmatan pada lebih banyak pelayan.
• Apabila kami menerima maklumat daripada pengguna, kami tidak perlu menunggu sehingga data disimpan sepenuhnya. Sebaliknya, kita hanya perlu menjawab "ok" dan kemudian secara beransur-ansur mula bekerja. Pada masa yang sama, baris gilir melancarkan puncak, kerana penambahan objek baharu berlaku dengan cepat, dan pengguna tidak perlu menunggu untuk lulus lengkap melalui keseluruhan kitaran.
• Sebagai contoh, saya menambah perkhidmatan deduplikasi yang cuba menggabungkan fail yang sama. Jika ia berfungsi untuk masa yang lama dalam 1% kes, pelanggan tidak akan menyedarinya (lihat di atas), yang merupakan kelebihan besar, kerana kami tidak lagi perlu XNUMX% kelajuan dan boleh dipercayai.

Walau bagaimanapun, kelemahannya dapat dilihat dengan serta-merta:

• Sistem kami telah kehilangan konsistensi yang ketat. Ini bermakna jika, sebagai contoh, anda melanggan perkhidmatan yang berbeza, maka secara teorinya anda boleh mendapatkan keadaan yang berbeza (kerana salah satu perkhidmatan mungkin tidak mempunyai masa untuk menerima pemberitahuan daripada baris gilir dalaman). Akibat lain, sistem kini tidak mempunyai masa biasa. Iaitu, adalah mustahil, sebagai contoh, untuk mengisih semua acara hanya dengan masa ketibaan, kerana jam antara pelayan mungkin tidak segerak (lebih-lebih lagi, masa yang sama pada dua pelayan adalah utopia).
• Tiada peristiwa kini boleh digulung semula (seperti yang boleh dilakukan dengan pangkalan data). Sebaliknya, anda perlu menambah acara baharu − acara pampasan, yang akan menukar keadaan terakhir kepada yang diperlukan. Sebagai contoh dari kawasan yang sama: tanpa menulis semula sejarah (yang buruk dalam beberapa kes), anda tidak boleh melancarkan semula komit dalam git, tetapi anda boleh membuat komit balik, yang pada asasnya hanya mengembalikan keadaan lama. Walau bagaimanapun, kedua-dua komitmen yang salah dan pemulangan semula akan kekal dalam sejarah.
• Skema data mungkin berubah dari keluaran ke keluaran, tetapi peristiwa lama tidak lagi dapat dikemas kini kepada standard baharu (kerana peristiwa tidak boleh diubah pada dasarnya).

Seperti yang anda lihat, Penyumberan Acara berfungsi dengan baik dengan CQRS. Lebih-lebih lagi, melaksanakan sistem dengan baris gilir yang cekap dan mudah, tetapi tanpa memisahkan aliran data, sudah sukar dengan sendirinya, kerana anda perlu menambah titik penyegerakan yang akan meneutralkan keseluruhan kesan positif baris gilir. Menggunakan kedua-dua pendekatan sekaligus, adalah perlu untuk melaraskan sedikit kod program. Dalam kes kami, apabila menghantar fail ke pelayan, jawapan hanya datang "ok", yang hanya bermaksud bahawa "operasi menambah fail telah disimpan." Secara rasmi, ini tidak bermakna bahawa data sudah tersedia pada peranti lain (contohnya, perkhidmatan penduadua boleh membina semula indeks). Walau bagaimanapun, selepas beberapa lama, pelanggan akan menerima pemberitahuan dalam gaya "fail X telah disimpan."

Akibatnya:

• Bilangan status penghantaran fail semakin meningkat: bukannya "fail dihantar" klasik, kami mendapat dua: "fail telah ditambahkan pada baris gilir pada pelayan" dan "fail telah disimpan dalam storan." Yang terakhir ini bermakna peranti lain sudah boleh mula menerima fail (dilaraskan untuk fakta bahawa barisan beroperasi pada kelajuan yang berbeza).
• Disebabkan fakta bahawa maklumat penyerahan kini datang melalui saluran yang berbeza, kami perlu menghasilkan penyelesaian untuk menerima status pemprosesan fail. Akibat daripada ini: tidak seperti jawapan permintaan klasik, pelanggan boleh dimulakan semula semasa memproses fail, tetapi status pemprosesan ini sendiri akan betul. Lebih-lebih lagi, item ini berfungsi, pada asasnya, di luar kotak. Akibatnya: kita kini lebih bertolak ansur dengan kegagalan.

Sharding

Seperti yang diterangkan di atas, sistem penyumberan acara tidak mempunyai konsistensi yang ketat. Ini bermakna kita boleh menggunakan beberapa storan tanpa sebarang penyegerakan antaranya. Mendekati masalah kita, kita boleh:

• Asingkan fail mengikut jenis. Contohnya, gambar/video boleh dinyahkod dan format yang lebih cekap boleh dipilih.
• Asingkan akaun mengikut negara. Oleh kerana banyak undang-undang, ini mungkin diperlukan, tetapi skema seni bina ini memberikan peluang sedemikian secara automatik

Jika anda ingin memindahkan data dari satu storan ke storan lain, maka cara standard tidak lagi mencukupi. Malangnya, dalam kes ini, anda perlu menghentikan baris gilir, melakukan penghijrahan, dan kemudian memulakannya. Dalam kes umum, data tidak boleh dipindahkan "dengan cepat", namun, jika baris gilir acara disimpan sepenuhnya, dan anda mempunyai syot kilat keadaan storan sebelumnya, maka kami boleh memainkan semula peristiwa seperti berikut:

• Dalam Sumber Peristiwa, setiap peristiwa mempunyai pengecamnya sendiri (sebaik-baiknya, tidak berkurangan). Ini bermakna kita boleh menambah medan pada storan - id elemen terakhir yang diproses.
• Kami menduplikasi baris gilir supaya semua acara boleh diproses untuk beberapa storan bebas (yang pertama ialah yang mana data telah disimpan, dan yang kedua adalah baharu, tetapi masih kosong). Barisan gilir kedua, sudah tentu, belum diproses lagi.
• Kami melancarkan baris gilir kedua (iaitu, kami mula memainkan semula acara).
• Apabila baris gilir baharu agak kosong (iaitu, purata perbezaan masa antara menambah elemen dan mendapatkannya boleh diterima), anda boleh mula menukar pembaca kepada storan baharu.

Seperti yang anda lihat, kami tidak mempunyai, dan masih tidak mempunyai, konsistensi yang ketat dalam sistem kami. Hanya ada ketekalan akhirnya, iaitu, jaminan bahawa acara diproses dalam susunan yang sama (tetapi mungkin dengan kelewatan yang berbeza). Dan, menggunakan ini, kita boleh memindahkan data dengan mudah tanpa menghentikan sistem ke bahagian lain dunia.

Oleh itu, meneruskan contoh kami tentang storan dalam talian untuk fail, seni bina sedemikian sudah memberi kami beberapa bonus:

• Kami boleh mengalihkan objek lebih dekat kepada pengguna dengan cara yang dinamik. Dengan cara ini anda boleh meningkatkan kualiti perkhidmatan.
• Kami mungkin menyimpan beberapa data dalam syarikat. Sebagai contoh, pengguna Perusahaan sering memerlukan data mereka disimpan di pusat data terkawal (untuk mengelakkan kebocoran data). Melalui sharding kita boleh menyokong ini dengan mudah. Dan tugas itu lebih mudah jika pelanggan mempunyai awan yang serasi (contohnya, Azure dihoskan sendiri).
• Dan perkara yang paling penting ialah kita tidak perlu melakukan ini. Lagipun, sebagai permulaan, kami agak gembira dengan satu storan untuk semua akaun (untuk mula bekerja dengan cepat). Dan ciri utama sistem ini ialah walaupun ia boleh dikembangkan, pada peringkat awal ia agak mudah. Anda tidak perlu segera menulis kod yang berfungsi dengan sejuta baris gilir bebas berasingan, dsb. Jika perlu, ini boleh dilakukan pada masa hadapan.

Pengehosan Kandungan Statik

Perkara ini mungkin kelihatan agak jelas, tetapi ia masih diperlukan untuk aplikasi dimuatkan lebih kurang standard. Intipatinya adalah mudah: semua kandungan statik diedarkan bukan dari pelayan yang sama di mana aplikasi berada, tetapi dari yang istimewa yang didedikasikan khusus untuk tugas ini. Akibatnya, operasi ini dilakukan dengan lebih pantas (nginx bersyarat menyediakan fail dengan lebih cepat dan lebih murah daripada pelayan Java). Selain seni bina CDN (Rangkaian Penyampaian Kandungan) membolehkan kami mencari fail kami lebih dekat dengan pengguna akhir, yang memberi kesan positif terhadap kemudahan bekerja dengan perkhidmatan tersebut.

Contoh kandungan statik yang paling mudah dan paling standard ialah satu set skrip dan imej untuk tapak web. Segala-galanya mudah dengan mereka - mereka diketahui terlebih dahulu, kemudian arkib itu dimuat naik ke pelayan CDN, dari mana ia diedarkan kepada pengguna akhir.

Walau bagaimanapun, pada hakikatnya, untuk kandungan statik, anda boleh menggunakan pendekatan yang agak serupa dengan seni bina lambda. Mari kita kembali ke tugas kita (storan fail dalam talian), di mana kita perlu mengedarkan fail kepada pengguna. Penyelesaian paling mudah ialah mencipta perkhidmatan yang, untuk setiap permintaan pengguna, melakukan semua pemeriksaan yang diperlukan (kebenaran, dsb.), dan kemudian memuat turun fail terus dari storan kami. Kelemahan utama pendekatan ini ialah kandungan statik (dan fail dengan semakan tertentu, sebenarnya, kandungan statik) diedarkan oleh pelayan yang sama yang mengandungi logik perniagaan. Sebaliknya, anda boleh membuat rajah berikut:

• Pelayan menyediakan URL muat turun. Ia boleh dalam bentuk fail_id + kunci, dengan kunci ialah tandatangan digital mini yang memberikan hak untuk mengakses sumber untuk XNUMX jam seterusnya.
• Fail diedarkan oleh nginx mudah dengan pilihan berikut:
  • Caching kandungan. Memandangkan perkhidmatan ini boleh ditempatkan pada pelayan yang berasingan, kami telah meninggalkan diri kami sebagai simpanan untuk masa hadapan dengan keupayaan untuk menyimpan semua fail yang dimuat turun terkini pada cakera.
  • Menyemak kunci semasa membuat sambungan
• Pilihan: pemprosesan kandungan penstriman. Sebagai contoh, jika kita memampatkan semua fail dalam perkhidmatan, maka kita boleh melakukan unzip terus dalam modul ini. Akibatnya: operasi IO dilakukan di tempat yang sepatutnya. Pengarkib di Java dengan mudah akan memperuntukkan banyak memori tambahan, tetapi menulis semula perkhidmatan dengan logik perniagaan ke dalam syarat Rust/C++ juga mungkin tidak berkesan. Dalam kes kami, proses yang berbeza (atau perkhidmatan) digunakan, dan oleh itu kami boleh memisahkan logik perniagaan dan operasi IO dengan agak berkesan.

Skim ini tidak begitu serupa dengan mengedarkan kandungan statik (kerana kami tidak memuat naik keseluruhan pakej statik di suatu tempat), tetapi pada hakikatnya, pendekatan ini betul-betul berkenaan dengan pengagihan data tidak berubah. Selain itu, skema ini boleh digeneralisasikan kepada kes lain di mana kandungannya bukan sekadar statik, tetapi boleh diwakili sebagai satu set blok tidak boleh diubah dan tidak boleh dipadam (walaupun boleh ditambah).

Sebagai contoh lain (untuk pengukuhan): jika anda telah bekerja dengan Jenkins/TeamCity, maka anda tahu bahawa kedua-dua penyelesaian ditulis dalam Java. Kedua-duanya adalah proses Java yang mengendalikan kedua-dua orkestra binaan dan pengurusan kandungan. Khususnya, kedua-duanya mempunyai tugas seperti "memindahkan fail/folder dari pelayan." Sebagai contoh: mengeluarkan artifak, memindahkan kod sumber (apabila ejen tidak memuat turun kod terus dari repositori, tetapi pelayan melakukannya untuknya), akses kepada log. Semua tugas ini berbeza dalam beban IO mereka. Iaitu, ternyata pelayan yang bertanggungjawab untuk logik perniagaan yang kompleks mesti pada masa yang sama dapat secara berkesan menolak aliran data yang besar melalui dirinya sendiri. Dan yang paling menarik ialah operasi sedemikian boleh diwakilkan kepada nginx yang sama mengikut skema yang sama (kecuali kunci data harus ditambahkan pada permintaan).

Walau bagaimanapun, jika kami kembali ke sistem kami, kami mendapat rajah yang serupa:

Seperti yang anda lihat, sistem telah menjadi lebih kompleks secara radikal. Kini ia bukan sekadar proses mini yang menyimpan fail secara tempatan. Sekarang apa yang diperlukan bukanlah sokongan paling mudah, kawalan versi API, dsb. Oleh itu, selepas semua rajah telah dilukis, adalah lebih baik untuk menilai secara terperinci sama ada kebolehlanjutan berbaloi dengan kos. Walau bagaimanapun, jika anda ingin dapat mengembangkan sistem (termasuk untuk bekerja dengan bilangan pengguna yang lebih besar), maka anda perlu menggunakan penyelesaian yang serupa. Tetapi, akibatnya, sistem ini bersedia dari segi seni bina untuk peningkatan beban (hampir setiap komponen boleh diklon untuk penskalaan mendatar). Sistem boleh dikemas kini tanpa menghentikannya (hanya beberapa operasi akan diperlahankan sedikit).

Seperti yang saya katakan pada awal-awal lagi, kini beberapa perkhidmatan Internet telah mula menerima peningkatan beban. Dan sebahagian daripada mereka mula berhenti bekerja dengan betul. Malah, sistem gagal tepat pada masa ini apabila perniagaan sepatutnya menjana wang. Iaitu, bukannya penghantaran tertunda, bukannya mencadangkan kepada pelanggan "rancang penghantaran anda untuk bulan-bulan akan datang," sistem hanya berkata "pergi ke pesaing anda." Sebenarnya, ini adalah harga produktiviti yang rendah: kerugian akan berlaku tepat apabila keuntungan akan menjadi tertinggi.

Kesimpulan

Semua pendekatan ini diketahui sebelum ini. VK yang sama telah lama menggunakan idea Pengehosan Kandungan Statik untuk memaparkan imej. Banyak permainan dalam talian menggunakan skim Sharding untuk membahagikan pemain kepada wilayah atau untuk memisahkan lokasi permainan (jika dunia itu sendiri adalah satu). Pendekatan Penyumberan Acara digunakan secara aktif dalam e-mel. Kebanyakan aplikasi perdagangan di mana data sentiasa diterima sebenarnya dibina pada pendekatan CQRS untuk dapat menapis data yang diterima. Nah, penskalaan mendatar telah digunakan dalam banyak perkhidmatan untuk masa yang agak lama.

Walau bagaimanapun, yang paling penting, semua corak ini telah menjadi sangat mudah untuk digunakan dalam aplikasi moden (jika ia sesuai, sudah tentu). Clouds menawarkan Sharding dan penskalaan mendatar serta-merta, yang jauh lebih mudah daripada memesan pelayan khusus yang berbeza di pusat data yang berbeza sendiri. CQRS telah menjadi lebih mudah, jika hanya kerana pembangunan perpustakaan seperti RX. Kira-kira 10 tahun yang lalu, laman web yang jarang ditemui boleh menyokong perkara ini. Penyumberan Acara juga sangat mudah disediakan berkat bekas siap pakai dengan Apache Kafka. 10 tahun dahulu ini akan menjadi satu inovasi, kini ia adalah perkara biasa. Ia sama dengan Pengehosan Kandungan Statik: disebabkan oleh teknologi yang lebih mudah (termasuk fakta bahawa terdapat dokumentasi terperinci dan pangkalan data jawapan yang besar), pendekatan ini menjadi lebih mudah.

Akibatnya, pelaksanaan beberapa corak seni bina yang agak kompleks kini menjadi lebih mudah, yang bermaksud adalah lebih baik untuk melihatnya dengan lebih dekat terlebih dahulu. Jika dalam aplikasi berusia sepuluh tahun salah satu daripada penyelesaian di atas telah ditinggalkan kerana kos pelaksanaan dan operasi yang tinggi, kini, dalam aplikasi baharu, atau selepas pemfaktoran semula, anda boleh mencipta perkhidmatan yang sudah boleh diperluaskan secara seni bina ( dari segi prestasi) dan sedia dibuat kepada permintaan baharu daripada pelanggan (contohnya, untuk menyetempatkan data peribadi).

Dan yang paling penting: jangan gunakan pendekatan ini jika anda mempunyai aplikasi yang mudah. Ya, mereka cantik dan menarik, tetapi untuk tapak dengan kunjungan puncak 100 orang, anda sering boleh bertahan dengan monolit klasik (sekurang-kurangnya di luar, segala-galanya di dalam boleh dibahagikan kepada modul, dll.).

Sumber: www.habr.com