Katmanlı mimari, neden veritabanı orta katmanını sunmalıyız?
- Neden veritabanı ara yazılımını sunmalıyız?
Sürekli katmanlı mimari evrimin ardından, DAO katmanı , Temel veri servisi , Genel iş hizmeti , Ön ve arka ayırma Bundan sonra, bir iş sisteminin arka uç yapısı yukarıdaki gibidir:
- Web görünümü katmanı, http arayüzü (ön uç ve arka uç ayrımı) aracılığıyla web verilerinden json verilerini alır
- Web veri katmanı, verileri RPC arabirimi (genel iş hizmeti) aracılığıyla biz hizmetinden alır.
- Biz-hizmet katmanı, RPC arayüzü (temel veri hizmeti) aracılığıyla temel hizmetten veri alır.
- Temel hizmet katmanı, verileri db'den DAO (DAO) aracılığıyla alır
- db veri depolamak
Mesai, Veri miktarı artacak Baz hizmet, DAO aracılığıyla db'ye erişir Performans düşecek ve düşecek , DB'nin yatay segmentasyonunu dikkate almaya başlamanız gerekiyor DB yatay olarak bölündüğünde, SQL'in orijinal olarak destekleyebileceği birçok işlev, temel hizmet katmanı tarafından özel işleme gerektirir:
- Bazı verilerin belirli bir yatay bölümleme kitaplığına yönlendirilmesi gerekiyor
- Bazı veriler, bölünmüş kitaplığın hangi düzeyinde olduğundan emin değildir, tüm kitaplıklara erişmeniz gerekir
- Bazı verilerin genel kitaplığa erişmesi, verilerin genel bir görünümünü alması ve ek işlemler için hizmet katmanına gitmesi gerekir
Daha spesifik olarak, ön uç yüksek eşzamanlılık işi için, db seviyesi ayrıldıktan sonra, birkaç tür tipik iş senaryosu ve çözümü vardır. Özellikle, burada uğraştığımız şey "Ön Plan", "Yüksek Eş Zamanlılık", "DB Yatay Segmentasyon" Senaryoda arka plan gereksinimleri, burada tartışılmayan ön plan ile arka planı ayıran mimari aracılığıyla ele alınacaktır.
Bir: Bölüm anahtarında tek satırlı sorgu
Tipik sahne : Kullanıcıyı kullanıcı kimliğine göre sorgula
Sahne özellikleri :
- Patition anahtarı ile sorgulama
- Bir seferde yalnızca bir satır döndür
çözüm : Temel hizmet katmanı, patent anahtarı aracılığıyla kitaplık yönlendirmesi gerçekleştirir
Yukarıda gösterildiği gibi:
- Kullanıcı-hizmet alt kullanıcı kitaplığı, alt kitaplık basım anahtarı uid'dir
- Kullanıcı kimliği sorgusu, kitaplığı doğrudan bulabilir
Açık olmayan anahtarda iki, tek satırlı sorgu
Tipik sahne : Login_name aracılığıyla kullanıcıyı sorgulayın
Sahne özellikleri :
- Patition olmayan anahtarla sorgulama
- Bir seferde yalnızca bir satır döndür
1.Çözüm : Temel hizmet katmanı tüm kitaplıklara erişir
Yukarıda gösterildiği gibi:
- user-service önce login_name ile tüm veritabanını kontrol edin
- Sonuç kümesi kullanıcı hizmetinde birleştirilir ve son olarak bir kayıt döndürülür
2.Çözüm : Temel hizmet, önce eşleme kitaplığını kontrol eder ve ardından patent anahtarı aracılığıyla yönlendirir
Yukarıda gösterildiği gibi:
- Login_name ve uid arasındaki eşleme ilişkisini kaydetmek için yeni bir eşleme kitaplığı oluşturun
- Patition olmayan bir anahtar sorgusu olduğunda, önce login_name aracılığıyla kullanıcı kimliğini sorgulayın
- Ardından patent anahtarını yönlendirin ve son olarak bir rekora geri dönün
3. Çözüm : Genetik yöntem
Kayıt dışı anahtarlar üzerindeki sorgu gereksinimlerini çözmek için "gen yöntemi" hakkında ayrıntılar için, lütfen "Alt Veritabanından Sonra Kayıt Dışı Anahtarlara Erişim İçin Çoklu Çözümler" bölümüne bakın.
Üç, atama anahtarında toplu sorgu
Tipik sahne : Kullanıcı listesi kullanıcı kimliği üzerinde IN sorgusu
Sahne özellikleri :
- Patition anahtarı ile sorgulama
- Bir seferde birden çok satırı döndür
1.Çözüm : Temel hizmet katmanı tüm kitaplıklara erişir ve sonuç kümesi temel hizmetle birleştirilir
2.Çözüm : Temel hizmet, yönlendirme kurallarını analiz eder ve talep üzerine erişim sağlar
Yukarıda gösterildiği gibi:
- Yönlendirme kurallarının analizine dayanarak, temel hizmet bazı verilerin kitaplık 1'e ve bazı verilerin kitaplık 2'ye düştüğüne karar verir.
- temel hizmet, tüm kitaplığa erişmek yerine talep üzerine ilgili kitaplıklara erişir
- temel hizmet birleştirme sonuç kümesi, iade listesi verileri
Dört, patentli olmayan anahtar çağrı gereksinimleri
Veritabanı bölünmesinden sonra Kuaku sayfalandırmasının sorgu gereksinimleri ile ilgili olarak, ayrıntılar için bkz. "Sektör Sorunları, Kuaku Sayfalandırma için Dört Çözüm".
5. Diğer ihtiyaçlar ...
Bu makalenin bu noktasında, yukarıdaki bir, iki, üç, dört ve beş aslında odak noktası değildir. Temel hizmet katmanı, çeşitli hileler ve püf noktaları aracılığıyla db düzeyinde bölümlemeden sonra veri erişim sorununu çözebilir, ancak:
- Temel hizmet katmanının karmaşıklığı arttı
- Veri toplama verimliliği azalır
İhtiyaç duyulduğunda Db yatay bölümleme için gittikçe daha fazla temel hizmet var. Şu anda katmanlı mimari şu şekilde olacak:
temel Karmaşıklık yayılacak Her temel hizmet için, tüm temel hizmetler söz konusu olmalıdır:
- atama anahtarı yönlendirme
- Patition olmayan anahtar sorgusu, önce eşleme, sonra yönlendirme
- Önce tam kitaplık, sonra birleştir
- Önce analiz edin, ardından talep üzerine yönlendirin
- Kuaku sayfalama işleme
Bu mimari diyagram garip görünüyor mu? Veri toplama nasıl daha verimli ve daha hızlı hale getirilir?
Veritabanı ara yazılımlarının tanıtılması zorunludur.
Bu, "sunucu tabanlı" bir veritabanı ara yazılım mimarisi diyagramıdır:
- Temel hizmet katmanı, verileri verimli bir şekilde elde etmek için db'ye erişmek, db-proxy'ye erişmek gibi
- Temeldeki tüm karmaşıklık, db-proxy katmanında korumalıdır
Bu, "istemci tabanlı" bir veritabanı ara yazılım mimarisi diyagramıdır:
- Temel hizmet katmanı, db-proxy.jar aracılığıyla verileri verimli bir şekilde elde eder
- Tüm temel karmaşıklık, db-proxy.jar katmanında korumalıdır
sonuç olarak :
ne zaman Veritabanı yatay olarak bölünmüştür ve temel hizmet katmanı, db verilerini elde etmek için çok karmaşıktır, bu da ortak bir sorun noktası haline gelir ne zaman Veritabanı ara yazılımı, veri toplama sürecini basitleştirmek, veri toplama verimliliğini artırmak ve yukarı akışta yatan karmaşıklığı korumak için soyutlanmalıdır.
İş dışı kalan herhangi bir mimari tasarım hayduttur .
"Neden", "nasıl" dan daha önemlidir.
-------------------------------------------------- -------------------------
Mimarın yolu olan WeChat kamu hesabından transfer
