Tek noktadan ayrıntılı açıklama - eksiksiz bir İnternet arka uç altyapısı seti. Giriş mimarını okuduktan sonra!
1.1 Arka uç altyapısı
Java arka uç teknolojisini kullanmanın amacı, kullanıcılara çevrimiçi veya çevrimdışı hizmetler sağlamak için iş uygulamaları oluşturmaktır. Bu nedenle, bir iş uygulamasının hangi teknolojilere ve hangi altyapıya ihtiyaç duyduğu, hangi arka uç teknolojilere hakim olunması gerektiğini belirler. Yazar, şirketin mevcut durumu ile birlikte tüm İnternet teknolojisi sistemine bakıldığında, vazgeçilmez veya çok kritik olan arka uç temel teknolojilerin / tesislerin aşağıdaki şekilde gösterildiğine inanmaktadır:
Buradaki arka uç altyapısı, temel olarak uygulamaların kararlı çevrimiçi çalışma için güvenmesi gereken temel bileşenlere veya hizmetlere atıfta bulunur. Yukarıdaki arka uç altyapısının geliştirilmesi veya kurulması, genellikle işi uzun bir süre destekleyebilir. Ek olarak, eksiksiz bir mimari için yük dengeleme, otomatik dağıtım ve sistem güvenliği gibi uygulamalar tarafından algılanmayan ve bu bölümün kapsamına girmeyen birçok temel sistem hizmeti vardır.
1.1.1 Birleşik İstek Giriş-API Ağ Geçidi
Mobil APP geliştirme sürecinde, genellikle arka uç tarafından sağlanan arayüz aşağıdaki işlevlerin desteğine ihtiyaç duyar:
- Yük dengeleme
- API erişim kontrolü
- Kullanıcı doğrulama
Genel yaklaşım, yük dengeleme için Nginx kullanmak ve ardından her iş uygulamasında API arabirimi erişim kontrolü ve kullanıcı kimlik doğrulaması yapmaktır.Daha optimize bir yol, tüm iş çağrıları için son iki halk kitaplığını yapmaktır. Ancak genel bir bakış açısıyla, bu üç özellik işletmenin ortak ihtiyaçlarına aittir.Daha tercih edilen yol, otorite kontrol ve kimlik doğrulama mekanizmasını dinamik olarak değiştirebilen ve her işletmenin entegrasyonunu azaltabilen bir hizmet olarak bir araya getirmektir. Mekanizmanın maliyeti. Bu tür bir hizmet bir API ağ geçididir ve bunu kendiniz uygulamayı seçebilirsiniz. Ayrıca Kong ve Netflix Zuul gibi açık kaynaklı yazılımlar kullanılarak da uygulanabilir. API ağ geçidinin genel yapısı aşağıdaki şekilde gösterilmektedir:
Ancak yukarıdaki şemayla ilgili bir sorun, tüm API isteklerinin ağ geçidinden geçmesi gerektiğinden, sistemin kolayca bir performans darboğazı haline gelebilmesidir. Bu nedenle, benimsenebilecek çözüm şudur: API ağ geçidini kaldırın, iş uygulamalarının doğrudan birleşik sertifika merkezine bağlanmasına izin verin ve her API çağrısının birleşik sertifika merkezinin sertifikasını temel çerçeve düzeyinde geçmesini sağlayın. Burada, kimlik doğrulama sonucu önbelleğe alınabilir. Birleşik sertifika merkezi, aşırı talep baskısı oluşturur.
1.1.2 İş uygulamaları ve arka uç altyapısı
İş uygulamaları, çevrimiçi iş uygulamaları ve dahili iş uygulamaları olarak ikiye ayrılır.
- Çevrimiçi iş uygulamaları: İnternet kullanıcılarının doğrudan karşılaştığı uygulamalar ve arayüzler Tipik özellikler şunlardır: büyük istek hacmi, yüksek eşzamanlılık ve arızalara karşı düşük tolerans.
- Dahili iş uygulamaları: esas olarak şirketin dahili kullanıcıları için uygulamalar. Örneğin, dahili veri yönetimi platformu, reklam platformu vb. Çevrimiçi iş uygulamalarıyla karşılaştırıldığında, özellikleri: yüksek veri gizliliği, düşük basınç, düşük eşzamanlılık ve arızalara izin verme.
İş uygulamaları, temel arka uç çerçevesine göre geliştirilir. Java arka uç için aşağıdaki çerçeveler olmalıdır:
- MVC çerçevesi: geliştirme sürecini birleştiren, geliştirme verimliliğini artıran ve bazı önemli ayrıntıları koruyan bir Web / arka uç çerçevesi. Tipik örnekler, Chinese ve Ali's WebX tarafından geliştirilen SpringMVC, Jersey ve JFinal'dir.
- IOC çerçevesi: Bağımlılık enjeksiyonu / kontrolü tersine çevirmek için bir çerçeve. Java'daki en popüler Spring çerçevesinin özü, IOC işlevidir.
- ORM çerçevesi: Temel veritabanının ayrıntılarını koruyabilen, birleşik bir veri erişim arabirimi sağlayan ve ayrıca istemci tarafı ana-bağımlı, alt veritabanı ve alt tablo gibi dağıtılmış özellikleri destekleyen bir veritabanı işlem çerçevesi. MyBatis şu anda en popüler ORM çerçevesidir. Ek olarak, Spring ORM'de sağlanan JdbcTemplate de çok iyi. Tabii ki, alt veritabanı alt tablosu ve ana-köle ayrımı gereksinimleri için, genellikle bunu kendiniz uygulamanız gerekir.Açık kaynak, Ali'nin TDDL'sini ve Dangdang'ın sharding-jdbc'sini içerir (veri kaynağı düzeyinden, alt veritabanı, tablo ve okuma-yazma ayrımı sorunlarını çözer. Uygulamaya şeffaf, sıfır izinsiz giriş). Ayrıca, birçok şirketin Alis Cobar, 360ın Atlas'ı gibi kendi veritabanı ara yazılımları vardır. MySQL-Proxy), NetEase'in DDB'si vb .; açık kaynak, MyCat (Cobar'a dayalı) ve Kingshard'tır, aralarında Kingshard'ın belirli bir çevrimiçi kullanım ölçeği vardır. MySQL yetkilisi ayrıca MySQL Proxy sağlar, master-slave, okuma-yazma ayrımı ve bölümleme mantığını özelleştirmek için lua betiklerini kullanabilirsiniz, ancak performansı zayıf ve şu anda daha az kullanılıyor.
- Önbellek çerçevesi: Redis ve Memcached önbellek yazılımının işlemleri için birleşik bir paket, istemci tarafında dağıtılmış çözümleri, ana-bağımlı vb. Destekleyebilir. Genel olarak, Spring'in RedisTemplate'ini kullanabilir veya istemci tarafında dağıtılmış çözümleri, ana-köle vb. Desteklemek için kendi paketlemenizi yapmak için Jedis'i kullanabilirsiniz.
- JavaEE uygulama performans testi çerçevesi: Çevrimiçi JavaEE uygulamaları için, her bir isteğin, yöntem çağrısının, JDBC bağlantısının, Redis bağlantısının vb. Zaman alıcı ve durumunu tespit etmek için her işletmeye birleşik bir çerçevenin entegre edilmesi gerekir. Jwebap, kullanılabilen bir performans tespit aracıdır, ancak uzun yıllardır güncellenmediği için mümkünse bu projeye dayalı olarak ikincil geliştirme yapılması önerilir.
Genel olarak konuşursak, yukarıdaki birkaç çerçeve, bir arka uç uygulamasının prototipini tamamlayabilir.
1.1.3 Önbellek, veritabanı, arama motoru, mesaj kuyruğu
Önbellekler, veritabanları, arama motorları ve mesaj kuyrukları, uygulamaların dayandığı arka uç temel hizmetlerdir. Performansları doğrudan uygulamanın genel performansını etkiler. Bazen kodunuz daha iyi olabilir çünkü bu hizmetler uygulama performansının başarısız olmasına neden olur. Yükselin.
- Önbelleğe alma: Önbelleğe alma, genellikle etkin nokta veri erişim sorunlarını çözmek için kullanılır ve veri sorgu performansını iyileştirmek için güçlü bir silahtır. Yüksek eşzamanlı arka uç uygulamalarında, veri kalıcılığı katmanının verilerini önbelleğe yüklemek, yüksek eşzamanlılık isteklerini arka uç veritabanından izole edebilir ve veritabanının çok sayıda istekle boğulmasını önleyebilir. Şu anda, bellekteki yerel önbelleğe ek olarak, daha yaygın olan merkezi önbelleğe alma yazılımı Memcached ve Redis'i içerir. Bunların arasında Redis, en yaygın önbellekleme yazılımı haline geldi.
- Veritabanı: Veritabanının, arka uç uygulamaları için en temel altyapı olduğu söylenebilir. Temel olarak, çoğu iş verisi sürekli olarak veritabanında saklanır. Yaygın veritabanları, son yıllarda popüler hale gelen geleneksel ilişkisel veritabanları (MySQL, PostgreSQL) ve NoSQL (MongoDB, HBase) içerir. Bunlar arasında HBase, büyük veri alanında kullanılan bir sütun veritabanıdır ve sorgu performansından dolayı genellikle bir iş veritabanı olarak kullanılmaz.
- Arama motoru: Bir arama motoru, tam metin alma ve çeşitli boyutlu veri sorguları için tasarlanmış bir yazılımdır. Şu anda en çok kullanılan açık kaynaklı yazılımlar, her ikisi de Lucence temel alınarak uygulanan Solr ve Elasticsearch'tür. Asıl fark, termIndex'in depolanması ve dağıtılmış mimarinin desteklenmesidir. Elasticsearch, kümeler için iyi desteği ve yüksek performansı nedeniyle, arama motorları için giderek yaygınlaşan açık kaynak çözümü haline geldi.
- Mesaj kuyruğu: Veri aktarımının bir yolu mesaj kuyruğudur. Şu anda kullanılan daha yaygın mesaj kuyrukları arasında günlük kaydı için tasarlanmış Kafka ve ağır işlemler için RabbitMQ bulunmaktadır. Mesaj kaybına karşı özellikle hassas olmayan ve mesaj işlemleri gerektirmeyen senaryolarda Kafka'yı seçmek daha yüksek performans sağlayabilir; aksi takdirde RabbitMQ daha iyi bir seçimdir. Buna ek olarak ZeroMQ, Soket'in üstünde ve MQ'nun altında bulunan mesaj kuyruklarını uygulayan bir ağ programlama Kalıp kitaplığıdır.
1.1.4 Dosya depolama
Bir iş uygulaması, bağımlı bir arka uç hizmeti veya çeşitli diğer hizmetler, sonuçta temeldeki dosya depolamasına bağlıdır. Genel olarak, dosya depolamanın karşılaması gereken özellikler şunlardır: güvenilirlik, felaket toleransı ve istikrar, yani saklanan verilerin bir arıza olsa bile kolayca kaybolmamasını sağlamak, bir geri alma planı olabilir ve yüksek kullanılabilirlik sağlanmalıdır. Alt katmanda, geleneksel RAID'i bir çözüm olarak kullanabilirsiniz ve bir sonraki aşamada, Hadoop'un HDFS'si en yaygın dağıtılmış dosya depolama çözümüdür.Elbette, NFS ve Samba gibi paylaşılan dosya sistemleri de basit dağıtılmış depolama sağlar. Özellikler.
Buna ek olarak, dosya depolaması uygulamanın darboğazı haline gelirse veya tüm sistemin performansını iyileştirmek için dosya depolama performansının iyileştirilmesi gerekiyorsa, en doğrudan ve basit yol geleneksel mekanik sabit diski terk etmek ve bir SSD sabit diskle değiştirmektir. Artık birçok şirket iş performansı sorunlarını çözdüğünde, nihai anahtar nokta genellikle SSD'dir. Bu aynı zamanda zaman ve işçilik maliyetleri için para takas etmenin en doğrudan ve etkili yoludur. Veritabanı bölümünde açıklanan SSDB, LevelDB paketlendikten sonra SSD sabit disklerin özelliklerini kullanan yüksek performanslı bir KV veritabanıdır.
HDFS'ye gelince, yukarıdaki verileri kullanmak istiyorsanız, Hadoop'tan geçmeniz gerekir. Xx on Yarn gibi bazı teknolojiler, HDFS üzerinde Hadoop dışı teknolojileri çalıştıran çözümlerdir.
1.1.5 Birleşik Sertifikasyon Merkezi
Birleşik kimlik doğrulama merkezi temel olarak APP kullanıcıları, dahili kullanıcılar, APP vb. İçin kimlik doğrulama hizmetleri sağlar.
- Kullanıcı kaydı, giriş doğrulama, Token doğrulama
- Dahili bilgi sistemi kullanıcılarının yönetimi ve oturum açma kimlik doğrulaması
- APP gizli oluşturma, APP bilgi doğrulama (arayüz imzalarının doğrulanması gibi) dahil olmak üzere APP yönetimi
Birleşik bir sertifika merkezine duyulan ihtiyacın nedeni, tüm bu uygulamalar tarafından kullanılan bilgileri merkezi olarak yönetmek ve tüm uygulamalar için birleşik sertifika hizmetleri sağlamaktır. Özellikle kullanıcı verilerini paylaşması gereken birçok işletme olduğunda, birleşik bir kimlik doğrulama merkezi oluşturmak çok gereklidir. Buna ek olarak, birleşik bir kimlik doğrulama merkezi aracılığıyla mobil uygulamalar için tek bir oturum açma oluşturmak elbette bir meseledir: Web mekanizmasını taklit etmek, kimliği doğrulanmış bilgileri şifrelemek ve birden fazla uygulamanın kullanılması için yerel depolamada saklamak.
1.1.6 Tek oturum açma sistemi
Şu anda, birçok büyük çevrimiçi Web sitesinde tek oturum açma sistemleri vardır Genel olarak konuşursak, birden çok iş uygulamasına girmek için yalnızca bir kullanıcının oturum açması gerekir (izinler farklı olabilir) ve bu, kullanıcıların çalışması için çok uygundur. Mobil İnternet şirketlerinde, çeşitli dahili yönetim, bilgi sistemleri ve hatta harici uygulamalar da tek oturum açma sistemleri gerektirir.
Şu anda, daha olgun ve en çok kullanılan tek oturum açma sistemi, https://github.com/apereo/cas/tree/master/cas-server-webapp'a göre özelleştirilebilen Yale Üniversitesi'nin açık kaynaklı CAS'ı olmalıdır.
Temel olarak, tek oturum açma ilkesi aşağıdaki şekle benzer:
1.1.7 Birleşik Yapılandırma Merkezi
Java arka uç uygulamalarında, yapılandırmayı okumanın ve yazmanın daha yaygın bir yolu, yapılandırma dosyalarını Özellikler, YAML, HCON ve diğer dosyalara yazmaktır.Değiştirirken, yalnızca dosyayı güncellemeniz ve yeniden konuşlandırmanız gerekir; bu, kod düzeyini dahil etmeden yapılabilir. Değişimin amacı. Birleşik yapılandırma merkezi, tüm iş veya temel arka uç hizmetleriyle ilgili yapılandırma dosyalarını tek tip olarak yöneten, bu yöntemi temel alan birleşik bir hizmettir. Aşağıdaki özelliklere sahiptir:
- Yapılandırma dosyalarını çevrimiçi olarak dinamik olarak değiştirme ve etkinleştirme yeteneği
- Yapılandırma dosyaları ortamları (geliştirme, test, üretim vb.)
- İlgili yapılandırmalar, açıklamalar ve XML yapılandırması aracılığıyla Java'da tanıtılabilir
Baidu'nun açık kaynaklı Disconf ve Ctrip'in Apollo'su, üretim ortamında kullanılabilen çözümlerdir.Ayrıca kendi konfigürasyon merkezinizi kendi ihtiyaçlarınıza göre geliştirebilir ve konfigürasyon depolaması olarak genellikle Zookeeper'ı seçebilirsiniz.
1.1.8 Hizmet yönetişim çerçevesi
Harici API çağrıları veya arka uç API'ye istemci erişimi için HTTP protokolü veya RESTful kullanılabilir (tabii ki doğrudan en ilkel soket aracılığıyla da çağrılabilir). Bununla birlikte, dahili hizmetler arasındaki çağrılar genellikle RPC mekanizması aracılığıyla çağrılır. Mevcut genel RPC protokolleri şunlardır:
- RMI
- Hessian
- Tasarruf
- Dubbo
Bu RPC protokollerinin kendi avantajları ve dezavantajları vardır ve iş ihtiyaçları için en iyi seçimi yapmanız gerekir.
Bu şekilde, sistem hizmetleriniz kademeli olarak arttığında, RPC çağrı zinciri gittikçe daha karmaşık hale gelir.Birçok durumda, bu çağrı ilişkilerini sürdürmek için belgeyi sürekli güncellemeniz gerekir. Bu hizmetleri yönetmek için bir çerçeve, bunun neden olduğu hantal insan gücünü büyük ölçüde azaltabilir.
Geleneksel ESB'nin (Kurumsal Hizmet Veriyolu) özü bir hizmet yönetişim çözümüdür, ancak ESB'nin bir proxy olarak rolü İstemci ve Sunucu arasında mevcuttur ve tüm taleplerin ESB'den geçmesi gerekir, bu da ESB'yi kolayca bir performans darboğazı haline getirir. Bu nedenle, geleneksel ESB'ye dayalı olarak, aşağıdaki şekilde daha iyi bir tasarım gösterilmektedir:
Şekilde gösterildiği gibi, konfigürasyon merkezi hub olarak kullanıldığında, çağrı ilişkisi yalnızca İstemci ile hizmeti sağlayan sunucu arasında mevcuttur ve bu da geleneksel ESB'nin performans darboğaz sorununu ortadan kaldırır. Bu tasarım için ESB'nin desteklemesi gereken özellikler aşağıdaki gibidir:
- Hizmet sağlayıcıların kaydı ve yönetimi
- Hizmet tüketicilerinin kaydı ve yönetimi
- Hizmet sürümü yönetimi, yük dengeleme, akış denetimi, hizmet bozulması, kaynak yalıtımı
- Servis hatası toleransı ve birleştirme
Alibaba'nın açık kaynak Dubbo'su yukarıdakileri çok iyi uyguladı ve aynı zamanda birçok şirketin şu anda kullandığı bir çözüm; Dangdang'ın genişletilmiş projesi Dubbox, Dubbo'ya bazı yeni özellikler ekledi. Şu anda Dubbo, Ali tarafından Apache'ye katkıda bulunmuştur ve kuluçka aşamasındadır. İşletme ve bakım izleme açısından Dubbo'nun kendisi basit bir yönetim konsolu dubbo-admin ve dubbo-monitor-simple izleme merkezi sağlar. Github'daki dubboclub / dubbokeeper, yönetimi ve izlemeyi entegre eden daha güçlü bir hizmet yönetimi ve izleme sistemidir.
Buna ek olarak, Netflix'in Eureka'sı hizmet kaydı keşfi işlevini de sağlar.Hizmetin istemci yumuşak yük dengelemesini gerçekleştirmek ve çeşitli esnek dinamik yönlendirme ve yük dengeleme stratejilerini desteklemek için Ribbon ile işbirliği yapabilir.
1.1.9 Birleşik Sevkiyat Merkezi
Birçok işletmede, planlı planlama, verileri düzenli olarak getirmek ve siparişlerin durumunu düzenli olarak yenilemek gibi çok yaygın bir senaryodur. Genel yaklaşım, kendi işleri için Java'daki Linux veya Quartz'ın Cron mekanizmasına güvenmektir. Birleşik planlama merkezi, tüm zamanlama görevlerini yönetir, böylece planlama kümesini tek tip bir şekilde optimize edebilir, genişletebilir ve yönetebilir. Azkaban ve Yahoo'nun Oozie'si, Hadoop'un akışlı iş yönetimi motorlarıdır ve aynı zamanda birleşik bir planlama merkezi olarak da kullanılabilir. Elbette, kendi birleşik sevk merkezinizi uygulamak için Cron veya Quartz'ı da kullanabilirsiniz.
- Görevleri cron ifadelerine göre planlayın
- Görevleri dinamik olarak değiştirin, durdurun ve silin
- Görev parçalama yürütmesini destekleyin
- Destek görevi iş akışı: örneğin, bir görev tamamlandıktan sonra sonraki görevi gerçekleştirin
- Görevler komut dosyalarını, kodları, URL'leri ve diğer formları destekler
- Görev yürütme günlük kaydı, arıza alarmı
Java Quartz için açıklamamız gerekiyor: Bu Quartz'ın, Spring'in Quartz çerçevesinin basit bir uygulaması olan ve şu anda en çok kullanılan zamanlama yöntemi olan Spring Quartz'dan ayırt edilmesi gerekiyor. Ancak yüksek kullanılabilirlikli kümeleri desteklemez. Quartz'ın küme desteği olmasına rağmen, yapılandırması çok karmaşıktır. Pek çok çözüm artık Spring Quartz dağıtılmış kümeleri uygulamak için Zookeeper'ı kullanıyor.
Ek olarak, Dangdang.com'un açık kaynaklı esnek işi, temel dağıtılmış zamanlamaya esnek kaynak kullanımı gibi daha güçlü işlevler ekler.
1.1.10 Birleşik Günlük Hizmeti
Günlükler, geliştirme süreci için çok önemlidir. Günlüğü yazdırmanın zamanlaması ve becerisi, mühendisin kodlama seviyesini yansıtabilir. Sonuçta, günlükler, çevrimiçi hizmetlerin anormallikleri bulup giderebileceği en doğrudan bilgilerdir.
Genellikle, günlükleri çeşitli işletmelerde dağıtarak sorunları yönetmek ve gidermek çok sakıncalıdır. Birleşik günlük hizmeti, günlükleri kaydetmek için ayrı bir günlük sunucusu kullanır ve her işletme, birleşik bir günlük çerçevesi aracılığıyla günlük sunucusuna günlükler çıkarır.
Log4j veya Logback Appender uygulayarak birleşik bir günlük çerçevesi uygulayabilir ve ardından günlüğü RPC çağrıları aracılığıyla günlük sunucusuna yazdırabilirsiniz.
1.1.11 Veri Altyapısı
Veriler, son yıllarda çok sıcak bir alan. "Yalın Veri Analizinden" "Growth Hacking" e kadar hepsi, verilerin olağanüstü rolünü vurguluyor. Birçok şirket, ürün tasarımını, pazar operasyonlarını ve araştırma ve geliştirmeyi teşvik etmek için de verileri kullanıyor. Burada dikkat edilmesi gereken bir nokta, büyük veriyle ilgili teknolojileri yalnızca verilerinizin ölçeği gerçekten tek bir makinenin başa çıkamayacağı bir ölçeğe ulaştığında kullanmanız gerektiğidir. Büyük veri için büyük veriyi kullanmayın. Çoğu durumda, bağımsız bir program + MySQL kullanılarak çözülebilecek sorun, zaman ve insan gücü kaybı olan Hadoop olmalıdır.
Burada eklenmesi gereken, birçok şirket için, özellikle daha az yoğun çevrimdışı işi olanlar için, büyük veri kümelerinin kaynaklarının birçok durumda israf edilmesidir. Bu nedenle, Hadoop dışı teknolojilerin Dockeron Yarn gibi kaynak kullanımını büyük ölçüde artırabilen büyük veri kümelerinin kaynaklarını kullanabilmesi için İplik teknolojileri üzerine bir dizi xx doğmuştur.
Veri karayolu
Yukarıda bahsedilen birleşik günlük hizmetini takiben, çıktı günlüğü en sonunda sonraki veri işleme programları tarafından tüketilmek üzere veri yoluna veri haline gelecektir. Ara süreç, günlük toplama ve iletimini içerir.
- Toplama: Birleşik günlük hizmeti, günlük hizmetindeki günlükleri yazdırdıktan sonra, bunları toplamak için bir günlük toplama mekanizmasına ihtiyaç duyar. Şu anda, yaygın günlük toplama şemaları şunlardır: Scribe, Chukwa, Kakfa ve Flume. Karşılaştırma aşağıdaki şekilde gösterilmektedir: Ek olarak, Logstash ayrıca isteğe bağlı bir günlük toplama çözümüdür. Yukarıdakilerin aksine, veri ön işlemeye daha meyillidir ve konfigürasyon basit ve açıktır. Genellikle ELK'ye (Elasticsearch + Logstash + Kibana) dayanmaktadır. Mimari, işletim ve bakım senaryolarında kullanılır.
- İletim: Veriler, veri işleme hizmetine mesaj kuyruğu aracılığıyla iletilir. Günlükler için Kafka genellikle bir mesaj kuyruğudur.
Ek olarak, burada önemli bir teknoloji var, veritabanı ile veri ambarı arasında veri senkronizasyonu sorunu, yani analiz edilmesi gereken verilerin veritabanından Hive gibi bir veri ambarına senkronize edilmesi. Verileri zaman damgalarına göre senkronize etmek için Apache Sqoop'u kullanabilirsiniz.Ayrıca, Alibaba'nın açık kaynaklı Canal'ı, genel senkronizasyon senaryoları için daha uygun olan, ancak Canal'a dayalı olan binlog'a dayalı artımlı senkronizasyon uygular, ancak yine de birçok iş geliştirme çalışmasının yapılması gerekiyor.
Çevrimdışı veri analizi
Çevrimdışı veri analizi geciktirilebilir.Genelde gerçek zamanlı ihtiyaçlarda olmayan veri analizi çalışmalarını hedefler ve bir gün gecikmeli raporlar üretir. Hadoop'a ek olarak, Spark en yaygın kullanılan çevrimdışı veri analizi teknolojisidir. Hadoop ile karşılaştırıldığında, Spark büyük performans avantajlarına sahiptir ve elbette yüksek donanım kaynakları da gerektirir. Bunların arasında, bir kaynak yönetimi planlama bileşeni olarak Hadoop'ta Yarn, MR hizmetine ek olarak Spark (Spark on Yarn) içinde kullanılabilir ve Mesos başka bir kaynak yönetimi planlama sistemidir.
Hadoop için geleneksel MR yazımı çok karmaşıktır ve bakım için elverişli değildir. SQL yerine MR yazmak için Hive'ı kullanmayı seçebilirsiniz. Spark için Hive'a benzer Spark SQL var.
Ek olarak, çevrimdışı veri analizi için, çok kritik bir veri çarpıklığı sorunu da vardır. Sözde veri çarpıklığı, bir bölgedeki verilerin eşit olmayan dağılımını ifade eder, bu da bazı düğümlerin düşük yüke sahip olmasına neden olurken, bazılarının yüksek yüke sahip olmasına neden olur ve bu da genel performansı etkiler. Veri çarpıklığı probleminin üstesinden gelmek, veri işleme açısından kritiktir.
Gerçek zamanlı veri analizi
Çevrimdışı veri analizi ile karşılaştırıldığında, gerçek zamanlı veri analizi, çevrimiçi veri analizi olarak da adlandırılır.Reklam yerleşimi ve sipariş mutabakatı gibi gerçek zamanlı veriler gerektiren iş senaryolarına yöneliktir. Şu anda, daha olgun gerçek zamanlı teknolojiler arasında Storm ve Spark Streaming bulunmaktadır. Storm ile karşılaştırıldığında, Spark Streaming temelde toplu hesaplamaya dayalıdır. Gecikmeye duyarlı bir sahneyse, yine de Storm kullanılmalıdır. Bu ikisine ek olarak, Flink son zamanlarda popüler olan bir dağıtılmış gerçek zamanlı hesaplama çerçevesidir. Exactly Once'ın anlamını destekler, büyük miktarda veri altında yüksek verim ve düşük gecikme avantajlarına sahiptir ve durum yönetimi ile pencere istatistiklerini iyi bir şekilde destekleyebilir. , Ancak belgelerinin ve API yönetim platformunun hala iyileştirilmesi gerekiyor.
Gerçek zamanlı veri işleme genellikle, çevrimdışına kıyasla güvenilir olmayan artımlı işlemeye dayanır. Bir arıza (küme çökmesi gibi) veya veri işleme başarısız olduğunda, verileri kurtarmak veya anormal verileri onarmak zordur. Bu nedenle, çevrimdışı + gerçek zamanı birleştirmek şu anda en yaygın kullanılan veri işleme çözümüdür. Lambda mimarisi, çevrimdışı ve gerçek zamanlı veri işlemeyi birleştiren bir mimari çözümdür.
Ek olarak, gerçek zamanlı veri analizinde çok yaygın bir senaryo vardır: çok boyutlu verilerin gerçek zamanlı analizi, yani veri görüntüleme ve analiz için herhangi bir boyutu birleştirme yeteneği. Şu anda bu sorunun iki çözümü vardır: ROLAP ve MOLAP.
- ROLAP: Hive, Spark SQL ve Presto ile temsil edilen veri ambarı verilerini yönetmek için ilişkisel veritabanlarını veya genişletilmiş ilişkisel veritabanlarını kullanın.
- MOLAP: Veri küplerine dayalı, zaman için alan kullanan ve tüm analiz durumlarını fiziksel tablolara veya görünümlere dönüştüren çok bitli bir depolama motoru. Çok boyutlu veri sorgusunu yerel olarak destekleyen ROLAP'tan (Hive, Spark SQL) farklı olan Druid, Pinot ve Kylin ile temsil edilir.
Önceki bölümde belirtildiği gibi, çoğu durumda, ROLAP çözümleri çevrimdışı veri analizi için gerçek zamanlı gereksinimleri karşılayamaz.Bu nedenle, MOLAP, çok boyutlu verilerin gerçek zamanlı analizi için ortak bir çözümdür. Yaygın olarak kullanılan üç çerçeve için karşılaştırma aşağıdaki gibidir:
Sahne dili protokol özelliklerini kullanın Druid gerçek zamanlı işleme ve analiz JavaJSON gerçek zamanlı toplama Pinot gerçek zamanlı işleme analizi JavaJSON gerçek zamanlı toplama KylinOLAP analiz motoru JavaJDBC / OLAP ön işleme, önbellek
Bunlar arasında, Druid nispeten hafiftir, daha fazla insan kullanır ve daha olgun.
Veri geçici analizi
Çevrimdışı ve gerçek zamanlı veri analizi ile oluşturulan bazı raporlar, veri analistleri ve ürün yöneticileri tarafından referans olarak kullanılır, ancak çoğu durumda, çevrimiçi programlar bu talep edenlerin ihtiyaçlarını karşılayamaz. Şu anda, talep tarafının veri ambarını kendi kendine sorgulaması gerekiyor. Bu talepte bulunanlar için SQL, kullanımı ve tanımlaması kolay olduğu için en uygun yöntem olabilir. Bu nedenle, bir SQL ad hoc sorgu aracı sağlamak, veri analistlerinin ve ürün yöneticilerinin iş verimliliğini büyük ölçüde artırabilir. Presto, Impala ve Hive bu tür araçlardır. Talep edene daha sezgisel bir UI işlem arayüzü sağlamak istiyorsanız, dahili bir Hue oluşturabilirsiniz.
1.1.12 Hata izleme
Kullanıcı odaklı çevrimiçi hizmetler için başarısızlık ciddi bir konudur. Bu nedenle, çevrimiçi hizmetler için iyi bir arıza tespiti ve alarm işi yapmak çok önemlidir. Hata izleme, aşağıdaki iki izleme seviyesine ayrılabilir:
- Sistem izleme: esas olarak ana bilgisayarın bant genişliği, CPU, bellek, sabit disk ve GÇ gibi donanım kaynaklarının izlenmesini ifade eder. Nagios ve Cacti gibi açık kaynaklı yazılımlar izleme için kullanılabilir. Şu anda, piyasada hazinenin izlenmesi gibi ana bilgisayar kaynaklarının izlenmesini sağlayabilen birçok üçüncü taraf hizmeti de bulunmaktadır. Dağıtık hizmet kümelerinin (Hadoop, Storm, Kafka, Flume vb.) İzlenmesi için Ganglia'yı kullanabilirsiniz. Ek olarak, Xiaomi'nin açık kaynaklı OpenFalcon'u da çok iyidir, sistem izleme, JVM izleme, uygulama izleme vb. Konuları kapsar ve ayrıca özel izleme mekanizmalarını destekler.
- İş izleme: APP PV, anormal UV verileri, işlem hatası vb. Gibi ana kaynak seviyesinin üzerinde izleme. İşletmeye ilgili izleme kodunu eklemeniz gerekir, örneğin, istisnanın atıldığı bir günlük kaydı ekleyin.
İzlemede bir diğer önemli adım uyarı vermektir. Uyarı vermenin birçok yolu vardır: e-posta, anlık mesajlaşma, SMS vb. Hataların farklı önemi, alarmların rasyonelliği ve sorunların bulunmasındaki kolaylık göz önüne alındığında aşağıdaki önerilerimiz var:
- Alarm günlüğü, özellikle küme hizmetinde başarısız olan makine kimliğini kaydetmelidir.Makine kimliği kaydedilmezse, sonraki sorunu bulmak zor olacaktır.
- Alarmları bir araya getirmek ve her arızayı ayrı ayrı alarm vermemek gerekir ki bu da mühendis için büyük sıkıntıya neden olacaktır.
- Alarmları sınıflandırmak için, tüm alarmları aynı önceliğe göre ele almak mümkün değildir.
- WeChat'i alarm yazılımı olarak kullanmak, SMS maliyetinden tasarruf ederken alarmların geliş oranını da sağlayabilir.
Arıza alarmından sonra, en kritik şey bununla ilgilenmektir. Yeni kurulan firmalar için 24 saat bekleme gerekli bir kalitedir.Bir alarmla karşılaşıldığında, arızaya en kısa sürede cevap vermesi, sorunu bulması ve kontrol edilebilir bir süre içerisinde sorunu çözmesi gerekir. Sorun giderme için temel olarak günlüklere güvenin. Günlük düzgün bir şekilde yazıldığı sürece, normal koşullar altında sorun hızlı bir şekilde tespit edilebilir, ancak bu dağıtılmış bir hizmetse ve günlük verilerinin miktarı özellikle büyükse, günlüğün nasıl bulunacağı bir sorun haline gelir. Birkaç seçenek var:
- Günlüklerin hızlı aranmasını ve konumlandırılmasını kolaylaştırmak için ELK (Elasticsearch + Logstash + Kibana) günlük merkezi analiz platformu kurun. Yelp'in açık kaynak Elastalert ile alarm işlevi gerçekleştirilebilir.
- Dağıtılmış bir istek izleme sistemi kurun (tam bağlantılı izleme sistemi olarak da adlandırılır) Dağıtılmış sistemler için, özellikle mikro hizmet mimarisi için, çok sayıda aramada tek bir anormal istek bilgisinin hızlı bir şekilde konumlandırılmasını ve toplanmasını büyük ölçüde kolaylaştırabilir ve ayrıca birini hızlı bir şekilde bulabilir. İstek bağlantısının performans darboğazı. Vipshoptan Mercury, Alinin Hawkeyeı, Sinanın WatchManı ve Twitterın açık kaynak Zipkini temelde Google'ın Dapper belgelerine dayalıdır ve Dianpingin gerçek zamanlı uygulama izleme platformu CAT, dağıtılmış istek izlemeyi destekler (kod müdahalesi) Ayrıntılı arama performansı veri istatistikleri ekleme temelinde. Ayrıca Apache tarafından kuluçkaya yatırılmakta olan HTrace, HDFS dosya sistemi ve HBase depolama motoru gibi büyük dağıtılmış sistemler için tasarlanmış dağıtılmış bir izleme çözümüdür. Mikro hizmet uygulamanız Spring Cloud kullanıyorsa, Spring Cloud Sleuth en iyi dağıtılmış izleme çözümüdür. Ayrıca Apache inkübasyonunda SkyWalking'in dağıtılmış izlemeye dayalı eksiksiz bir APM (uygulama performansı izleme) sistemi olduğu da belirtilmelidir.Bunun en büyük özelliklerinden biri, iş koduna, Pinpoint'e herhangi bir müdahalede bulunmadan, Java ajanı + araç api'sine dayanmasıdır. Üretim ortamlarında kullanılan başka bir APM sistemine benzer.
Konu hakkında konuşmak gerekirse, Brother Bird atmayı seven bir programcıdır.Amatör olarak kendi web sitesini, küçük programını, Uygulamasını vb. Son zamanlarda, sunucular teması etrafında bir WeChat grubu oluşturuldu.Sunucu oynamayı seven veya kendi başına bir ürün geliştirmek isteyen okuyucular içeri girip birbirlerinden öğrenebilirler! Ayrıca size zaman zaman sunucuyla ilgili kuponlar da getireceğim! Eğer ilgilenmiyorsan, atmayı sevmiyorsan, belaya katılmana gerek yok!
