WordPress ile mikro hizmetin mimari modelini kucaklayın
Daha olgun WordPress ile birlikte, onu bir uygulama platformu olarak daha fazla kullanan kişi. Matt Mullenweg’in WordPress hakkındaki OS açık kaynak web olarak vizyonuna doğru ilerlediğimizde, WordPress’i nasıl kullanma eğiliminde olduğumuza dair bazı anlayışlarımızı sorgulamak önemli olduğunu düşünüyorum. Geleneksel olarak WordPress sitesi tek bir monolitik birim olarak çalıştırılır. Bu, Web’in mikro hizmete doğru geliştirilmesinde gelişen eğilime aykırıdır – birçok küçük tek hedef uygulama tek bir birim olarak hareket edecek şekilde yapılandırılmıştır. Örneğin, statik HTML önbelleğini düşünün. Monolitik yaklaşımı izlerseniz, WordPress’te önbellek üreten ve sunan bir eklenti ekleyeceksiniz. Veya önbellek HTML’yi sunmak için sunucunuzda Vernik veya Nginx’i yapılandırabilirsiniz. Öte yandan, bir mikro hizmet yaklaşımı kullanırken, CDN ile gönderilen önbelleği uygulamak için ayrı bir sunucu veya sunucu ağı kullanacaksınız.
Geliştirdiğim web uygulaması için Caldera Forms Pro, mikro hizmet yaklaşımına doğru ilerliyoruz. Bu uygulama başlangıçta e -ticaret için WordPress sitemizi kullanan Merkezi Laravel uygulamalarından biri olmasına rağmen, uyguladığımız son özellik – artan hata kaydı – lümen mikriframe çalışması üzerine inşa edilmiş ayrı bir mikro hizmet olarak uygulanmaktadır. Mikro hizmet mimarisini kucaklamak, WordCamp Montreal görüşmelerimin konusudur – Hibrit Geleceğimiz: STAC’ın bir parçası olarak WordPress. Bu makalede, Microservice Mimarisinin ne olduğunu ve WordPress uygulamanızın geliştirilmesini geliştirmek için nasıl kullanılacağını tartışacağım.
Monolitik Mimari Desenler Monolitik bir uygulama birim olarak inşa edilmiştir. Sunucu tarafı uygulaması HTTP isteklerini işleyecek, etki alanı mantığını çalıştıracak, veritabanından verileri alacak ve güncelleyecek ve tarayıcıya gönderilecek HTML ekranını seçecek ve dolduracak. Martin Fowler, ilk önce – monolitik mimariyi tanımlarsak mikro hizmet modelinin daha kolay olduğunu anlıyor. Web uygulamaları, tek bir varlık olarak yapılır ve çalıştırılırsa monolitik olarak kabul edilir. Geleneksel WordPress mimarisi buna göre birçok yönden. Tüm programı çalıştıran PHP, MySQL ve Web Server – Apache, Nginx, vb. Çalışan bir sunucunuz – özellikle VPS veya Ortak Sunucunun bir kısmı – var. Sunucuya başka programlar yükleyerek programa işlevsellik ekledik – redis, vernik vb. – ve WordPress – IE eklentisine daha fazla kod ekleyin. Monolitik mimarinin ana yararı basitliktir. Bir programınız, bir sunucunuz ve bir dizi teknolojiniz var. Mikro Hizmet Yaklaşımı Mimari tarzı Mikro Servis, her biri kendi sürecinde çalışan ve genellikle HTTP kaynaklarının yangını olan hafif bir mekanizma ile iletişim kuran bir dizi küçük hizmet olarak tek bir uygulamanın geliştirilmesi için bir yaklaşımdır. ” Martin Fowler, Web Uygulama Tasarımına Mikro Hizmet Yaklaşımı, her uygulama biriminin sunucu veya sunucu ağında çalışan kendi programı olması gerektiğini söylüyor.
Ana fayda, artan kapsülleme. Bu kapsülleme zorlu zorluklara yardımcı olur. Programın her kısmı kendi sunucusunda çalıştığından, her sunucu ağı kendi ihtiyaçlarına göre bağımsız olarak optimize edilebilir ve boşaltılabilir. Artan kapsüllemenin ölçeklendirmenin yanı sıra birçok faydası vardır. Programın her bir bölümünü ayrı bir kod tabanı olarak oluşturarak, bağımsız bir programla geliştirilebilir ve kullanılabilir. Ayrıca, bu hizmet tasarıma göre ücretsiz ve bağımsız olduğu için, diğer uygulamalarda yeniden kullanılabilirler. Amazon.com, mikro servis mimarisi kullanılarak yapılan büyük ölçekli bir web uygulamasının bir örneğidir. Uygulamanın her bölümünü ayrı bir hizmet olarak oluştururlar ve birçoğunu Amazon Web Services aracılığıyla sunulan bir stant ürününe dönüştürürler. Amazon bir şekilde mikro hizmet kullanmadan ölçeğine ulaşırsa, dosya depolama çözümlerini – S3 – veya e -posta çözümlerini bize satamazlar.
Mikro hizmetler de maliyet tasarrufu sağlayabilir. Sitenin önemli işlevlerini yerine getirmek için MailChimp’i kullanmak – e -posta pazarlaması – her site için kendi e -posta pazarlama hizmetlerinizi oluşturmaktan çok daha ucuz. WordPress tamamen monolitik değil WordPress.com ilk büyük ölçekli WordPress sitesidir – milyonlarca kullanıcıyla bir çoklu kurulum. Kesinlikle bundan çok daha karmaşık. Otomattik, işlemi dağıtmak ve mikro hizmetleri kullanmak için araçlar geliştirmez ve uygulamazsa, teknolojileri tam anlamıyla işlev görmez. Mikro hizmet mimarisine doğru ilk adım, işlemi ağ boyunca dağıtmaktır. HyperDB, WordPress site veritabanlarını dağıtmak için aşırı MySQL Server ağlarının kullanılmasına izin vermek için otomatikte geliştirilmiştir. HyperDB ve benzer sistemler bugün WordPress’te her yerde. Statik dosya sunumunu sökmek için CDN’yi de kullanıyoruz. Ödemeleri işlemek ve abonelikleri yönetmek için üçüncü taraf ödeme ağ geçidi kullanırız. E -posta göndermek için işlem e -posta sağlayıcılarını kullanıyoruz. Kaliteli WordPress barındırma artık sunucu hakkında değil. Bu, siteleri dağıtmak ve küresel olarak tutarlı performans sağlamak için kullanılan hizmet ağı ile ilgilidir. Şirketin WordPress Geliştirme Ajansı olan Human Made, WordPress’i kaydetmek için harika bir rehbere sahiptir. WordPress’i dağıtmak için eklentilerinin listesi neredeyse tüm özel hizmetlerde WordPress işlemeyi dağıtmaktır.
WordPress Geliştiricileri için Mikro Hizmet Neden Önemlidir?
Genellikle mikro hizmeti düşündüğümüzde sunucu ölçeklendirme hakkında konuşuruz.Ben DevOps değilim.Bu nedenle, sunucu yığınınızın dağıtımını veya depolamasını tartışmayacağım.Neden bunu yapmanız gerektiğini anlıyorum ve bu konuda başka birçok kaynak var.Öte yandan WordPress eklentileri ve web uygulamaları oluşturdum.Mikro hizmet açısından düşünmek, bu soruna nasıl yaklaştığımı yeniden düşünmeme yardımcı oldu.Tartışmak istediğim şey bu. Verdiğimiz her teknik karar, zayıflıkları olan bir uzlaşma.Bundan kaçınamayız.Ancak, mikro hizmet uzlaşma kapsamını azaltır.Her mikro hizmet, minimum sorumluluklara sahip kendi bağımsız programı olduğundan, seçilen teknoloji ve uygulamasının yalnızca daha büyük program gereksinimlerinden küçük bir alt kümeyi dikkate alması gerekir.
WordPress geliştiricileri açısından, mikro hizmetleri WordPress’in sınırlamalarının üstesinden gelmenin bir yolu olarak görebiliriz. Ürünün reklamını yapan, ürünü satan ve ürün için aboneliğin işlenmesi ana ölçeklendirme sorunudur. Ürün bir uygulama ise ve uygulama WordPress’te oluşturulursa, şimdi daha büyük bir zorluktur. Peki ya WordPress REST API ile bağlanan dört veya daha fazla WordPress sitesi olarak yeniden düşünürsek? Örneğin, abonelik yönetimini ayrı bir siteye taşırsanız ne olur? O zaman sitede birçok potansiyel müşteriniz olduğunda aynı anda çok sayıda güncellemenin işlendiğinden endişe etmeyeceksiniz. Abonelik güncellemelerinin etkisi, güncellemelerin işlenmesini yavaşlatacaktır, site ön ucunun çok yavaş yüklenmesi değil. WordPress ile bir arka uç olarak bir uygulama oluşturursanız ve satmak, pazar ve WordPress’i kullanırsanız bu daha da önemlidir. uygulamayı destekleyin. Bu senaryoda, artan site trafiği uygulama performansını azaltacak ve bunun tersi de geçerlidir. WordPress sitelerini statik içerik sunmak için optimize etmek, uygulama veri sağlayıcıları olmak için siteleri optimize etmekten çok farklıdır. İkisini ayrı bir siteye ayırmak, her siteye bağımsız olarak kaynakları optimize etmenizi ve tahsis etmenizi sağlar. Ayrıca, her birini bağımsız olarak geliştirebileceğiniz anlamına gelir.
WordPress’in son bölümde önerdiğim gibi birkaç WordPress’te nasıl paylaşılacağını düşünmeye başladıktan sonra, tüm bu hizmetlerin neden WordPress üzerine inşa edilmesi gerektiğini sormaya başlamak doğaldır. Cevap değiller. WordPress’i seviyorum, ama bence her iş için doğru araç değil. Caldera Forms Pro’yu geliştirdiğim web uygulaması birçok yığın için WordPress kullanıyor, ancak hepsi değil. WordPress, e -ticaret, pazarlama otomasyonu, belgeler ve diğerlerini ele alır. Ancak ana uygulama Laravel üzerine inşa edildi. Sonuç olarak, uygulamaların kullanımının ana WordPress sitemiz üzerinde hiçbir etkisi yoktur. Temel olarak WordPress sitemizi, diğer birçok hizmete köprü kuran bir mikro hizmete dönüştürüyoruz – şerit, paypal, convertKit, vb. Ana uygulamamız hala oldukça monolitik olmasına rağmen, son zamanlarda dağıtılmış hata kayıt sistemini ana uygulamadan çekiyorum ve Lümen tarafından desteklenen mikro hizmetlere giriyorum. Mikro hizmet mimarisi işlevi yapmak için minimum merkezi kimlik doğrulama ve yönetim sağlayıcısı olarak ana uygulamaya sahip bir mikro hizmet olarak bu uygulama için yeni özellikler geliştirmeyi planlıyorum. Her zaman HTTP API üzerinden iletişim kurun Mikro hizmetlerle çalışırken, diğer hizmetlerdeki süreçleri tetiklemek için nasıl bir hizmet alacağınız sorunları çözmeniz gerekir. Caldera Forms Pro üzerinde çalışırken, WordPress sitesinde WP-CHLI komutunu çalıştırmak için Laravel’i kullanmayı düşündüm. Bu, iki uygulamanın o sırada aynı VM’de çalıştığı yerel geliştirme ortamımda çalışacaktır.
CLI’leri aracılığıyla uygulamalar arasında iletişim kurmaya karar verdiysem, onu ayrı bir sunucuya yayamayacağım, yaptığımız şey ve her zaman plan. Bu kısayol, ayırma işlevinin ana avantajlarını farklı hizmetlere çıkaracaktır. Tersine, farklı hizmetler her zaman dinlenme yangınları yoluyla iletişim kurar. WordPress sitemize bitiş noktası eklemek için WordPress Rest API kullanıyorum. Laravel ve lümen uygulamaları temel olarak kafası olmayan CM’lerdir – bunlar dinlenme yangınları ile erişilebilen veri depolamadır. Ana uygulamanın yalnızca bir görünümü vardır, bu da tek sayfa web uygulaması Vuejs. Komple hizmet, mikro hizmet ile bina ile ilgili harika bir şey içerir Her hizmetin çok az sorumluluğu olmasıdır. Bu, kapsamda pratik minimalizm getirir. Bir hizmet bir şey yaparsa ve bir şeyi iyi yaparsa, bırakabilirsiniz. Evet, işletmeniz yeni ihtiyaçlar geliştirebilir. Sorulduğunda, yeni hizmetler için.
