"Alibaba Orta-Tayvan Stratejik Düşünme ve Mimari Gerçek Savaş" ı okumak: Strateji, Mimari, SOA, vb.
Geçenlerde "Kurumsal BT Mimarisinin Dönüşümü: Alibaba'nın Çin ve Tayvan'daki Stratejik Düşünme ve Mimari Uygulamaları" adlı bir kitap okuyordum. Bu makaleyi yazdığım sırada kitap okunmadı, çünkü kitabın tamamını okursam bunu yazacağımdan endişeliyim. Bu makale, birçok harika içerik unutulmuş olabilir, bu yüzden sizlerle paylaşmak için bir makale yazacağım.
Çin-Tayvan Stratejisi
Alibaba tarafından 2003 yılında kurulan Taobao İşleri Departmanı Şekil 1'de gösterilmektedir.
2008 yılında, B2C işi hızla büyüyordu ve Alibaba, Şekil 2'de gösterildiği gibi, daha sonra Taobao İş Birimi'nin bir bölümü olarak işletilen başlangıçta Taobao Alışveriş Merkezi olarak adlandırılan Tmall'ı kurdu.
B2C işinin sürekli artmasıyla Tmall bağımsız olmaya başladı. Alibaba, Şekil 3'te gösterildiği gibi Taobao'nun iş departmanının yanı sıra Tmall iş departmanını ayrı olarak kurdu. Şu anda, Taobao'nun teknoloji kısmı aynı anda her iki iş departmanını da destekliyor. Bu organizasyon yapısı Tmall'ın işinin gelişimini ciddi şekilde etkileyen Taobao'nun iş ihtiyaçlarını karşılamaya teknik ekibin öncelik vereceği belirlendi. Tmall ve Taobao kullanan herkes, Tmall ve Taobao gibi e-ticaret platformlarının tamamının emtia, işlemler, değerlendirme, ödeme ve lojistik gibi işlevleri içerdiğini bulabilmelidir.
2009 yılında, ortak iş bölümü oluştu.Ana üyeler Taobao teknik ekibine geldi ve organizasyon yapısı açısından, Şekil 4'te gösterildiği gibi, Taobao ve Tmall ile aynı seviyede bir bölüm haline geldi. Grup, bu şekilde, teknik ekibin hem Tmall hem de Taobao işlerini destekleyebileceğini ve aynı zamanda kamusal ve genel işletmeleri biriktirebileceğini ve kaynakları daha rasyonel kullanabileceğini umuyor.
Ama gerçekte, o zaman, paylaşılan iş bölümü Tmall ve Taobao'ya "teslim edildi". Paylaşılan iş bölümü, Tmall ve Taobao'nun büyük ihtiyaçlarını aynı anda karşılamalıydı. Ekip üyeleri genellikle fazla mesai yaptı ve Tmall ve Taobao'nun gereksinimlerini karşılayamayabilirdi. Talep, bu, Tmall ve Taobao'nun iş departmanlarının paylaşılan işletme departmanından memnun olmamasına neden oldu ve aynı zamanda, paylaşılan işletme departmanındaki meslektaşların yalnızca sorunları olabilir.
2010 yılında, Juhuasuan satın alma şirketi ortaya çıktı. Juhuasuan güçlü trafik çekme yeteneklerine sahip. Bu nedenle, Tmall, Taobao ve 1688, trafiklerini genişletmek için Juhuasuan platformuyla bağlantı kurmak istiyor. Juhuasuan, birdenbire böylesine büyük bir yanaşma talebiyle boğuldu. Şu anda Grup, üç büyük e-ticaret platformunun Juhuasuan platformuna bağlanmak istiyorsa, paylaşılan iş bölümünden geçmelerini gerektiriyor! Paylaşılan iş bölümünün güçlü bir iş kavrayışına sahip olduğu ve üç büyük e-ticaret platformundaki orijinal dengesizliği nispeten adil bir seviyeye getirdiği bu politikayla böyledir. Bu, bugün herkesin gördüğü paylaşılan iş bölümünün, aşağıdaki şekilde gösterildiği gibi, Alibaba Group'un işindeki temel iş platformu haline geldiğini ortaya koymuştur:
Yukarıdaki şekil Alibaba'nın "kalın platform, ince uygulama" yapısını açıkça tanımlamaktadır ve paylaşılan iş bölümü, "kalın platform" un gerçek somutlaşmış halidir. "Kalın platform", en profesyonel ve Kararlı iş hizmeti, bu Zhongtai . Çin-Tayvan stratejisinin bir gecede gerçekleşmediğini görebiliriz. 2009 yılında ortak iş bölümü kurulduğunda, Çin-Tayvan stratejisi için belirli bir temel oluşturmuştu.Aynı zamanda, Çin-Tayvan'ı inşa etmek için grubun güçlü desteğine de ihtiyacı vardı. Oluşum, işin gelişmesi için sağlam bir temel oluşturdu.
Baca mimarisi
2008 yılında, Taobaonun teknik ekibi hem Taobao hem de Tmallın iki büyük e-ticaret platformunu destekledi. Aynı zamanda, 1688 kendi teknik ekibine sahipti. Yapı aşağıdaki gibidir:
Bu mimari Baca mimarisi , Her işletme departmanı ve ilgili işletme departmanı orada bir baca gibi durur ve bu yapıya göre, işletmenin yeni işi genişletmesi gerektiğinde, yeni bir işletme departmanı ve buna karşılık gelen yeni teknik departman görünecektir, yani Bir baca daha. Şimdiye kadar, bu tür bir mimarinin hala bunun gibi birçok şirketi var.Bu tür bir mimarinin nedeninin avantajları olmalı:
- Şirketler farklı iş modellerini göz önünde bulundurarak bağımsız olarak inşa ediyorlar
- Yeni iş ekibi, önceki iş temelinde dönüşümün çok fazla teknik ve ticari tarihsel yüke sahip olacağına, yeniden inşa etmenin daha iyi olduğuna inanıyor.
Sadece bu mimarinin dezavantajları, avantajlarından çok daha ağır basmaktadır:
- Tekrarlayan işlev yapısı ve bakımı, tekrarlayan çalışma ve yatırım getirir. Tekrarlanan inşaatlar işletmeler için riskleri azaltabilir, ancak tekrarlanan maliyetleri artıracaktır.
- "Baca" sistemi etkileşime girerse, işbirliği maliyeti yüksektir.
- İşletmenin yağış ve sürdürülebilir gelişimi için elverişli değildir. Bir baca devreye girdikten sonra işletme ve bakım aşamasına girer, bu aşamada işletmeyi bu temelde değiştirmeniz gerekirse, işletmenin yayınlanması uzun zaman alacaktır.
İnternet çağında, kurumsal iç kaynakları daha iyi entegre etmek, kurumsal maliyetleri düşürmek ve çeşitli sistemler arasındaki etkileşimi gerçekleştirmek kaçınılmazdır. Bu durumla karşılaşan endüstri, 2004 yılında "baca" sistemleri arasındaki etkileşim sorununu çözmek için SOA konseptini ortaya koymuştur.
SOA
SOA'nın temel işlevleri:
- Hizmet odaklı dağıtılmış bilgi işlem
- Hizmetler arasında gevşek bağlantı
- Destek Hizmetlerinin Kapsüllenmesi
- Hizmet kaydı ve otomatik keşif
- Hizmet etkileşimi yöntemlerini hizmet sözleşmeleri biçiminde tanımlayın
Merkezi SOA
Birçok işletme, merkezi bir SOA olan ESB aracılığıyla SOA'yı uygular.
ESB bir kurumsal hizmet veri yoludur.Adından da anlaşılacağı gibi, ESB sistemi kuruluştaki çeşitli hizmetleri tek tip bir şekilde yönetebilir. ESB mimarisi, hizmet arayüzü değişikliklerinin hizmet tüketicileri üzerindeki etkisini korur ve farklı sistemlerin sorununu çözmektir. Aşağıdaki şekilde gösterildiği gibi, ara bağlantı için çok iyi bir mimari:
2004 yılında, birçok büyük yazılım şirketi, BT inşası yıllarında giderek daha fazla şirketin giderek daha fazla BT sistemi kurduğunu keşfetti.Bu BT sistemlerinin tümü, baca sistemi yapı modeliyle oluşturulmuştur. İşletmede çok sayıda sistem var.Bu sistemlerden bazıları ticari kitler satın alındı, bazıları bağımsız olarak geliştirildi ve bazıları dış kaynak şirketleri tarafından geliştirildi.Sonuç, her sistem tarafından kullanılan teknoloji platformları, çerçeveleri ve dillerinin farklı olmasıdır. Böylece yazılım şirketi geliştirdi ESB sistemi Bu şirketlerin bu sorunları çözmelerine yardımcı olmak için.
Servis sağlayıcının sadece arayüzü ve ESB sistemindeki arayüzün erişim yolunu tanımlaması yeterlidir.Bu servisin tüketicisinin kim olduğuna dikkat etmesine gerek yoktur ve bu servisin değiştirilmesinin ESB'de yalnızca bir kez ayarlanması gerekir. Servis arayüz değişikliklerini etkileyen izolasyonu gerçekleştirir. ESB, sistemler arasındaki bağlantıyı azaltır, sistem entegrasyonunu daha rahat ve verimli bir şekilde gerçekleştirir ve hizmet yük dengeleme ve hizmet yönetimi ve kontrolü açısından "noktadan noktaya" modelden daha profesyonel yetenekler sağlar.
ESB, çeşitli teknik arabirimlere (HTTP, Soket, JMS, JDBC, vb.) Adaptasyon ve erişim, veri formatı dönüştürme, veri uyarlama, hizmet talebi yönlendirme vb. Gibi işlevler sağlar. Amaç, kurumsal müşterilerin bu işlevlere dayalı olarak geliştirme verimliliğini artırmasına olanak sağlamaktır. , Proje inişini daha hızlı gerçekleştirin.
Bu nedenle ESB yaklaşımı, bu dönemde SOA uygulamasında ana akım haline geldi ve heterojen sistemler arasındaki etkileşimi çözdü.
Merkezi olmayan SOA
"Merkezi olmayan SOA", İnternet endüstrisi tarafından getirilir, çünkü İnternet endüstrisindeki kullanıcı grubu tüm İnternet halkıdır, bu nedenle sistem mimarları işe daha hızlı yanıt verebilmek için önce sistem ölçeklenebilirliği sorununu çözmelidir , İşletme yeniliği vb. İçin daha iyi destek
Bu nedenle, SOA'nın temel işlevlerini yerine getirmenin yanı sıra, "ademi merkeziyetçilik", "merkezileştirme" ve potansiyel "çığ" etkisinin neden olduğu ölçeklenebilirlik zorluğundan da kaçınmalıdır.
"Merkezi olmayan SOA", "noktadan noktaya" bir mimaridir, aşağıda gösterildiği gibi merkezi yoktur:
O halde şüpheler olabilir ... SOA'nın ortaya çıkışı, baca mimarisinin neden olduğu sorunları çözmektir ve baca sistemleri arasındaki çağrılar "noktadan noktaya" ... Bu geriye gitmiyor mu? İnternet sektöründe, Merkezi olmayan hizmet çerçevesi Kuruluşun içinde çalışır ve intranetler ve harici ağlar arasında nadiren hizmet etkileşimi vardır.Ayrıca, hizmet, hizmet arabiriminin kararlılığını belirli bir dereceye kadar garanti eden ve aynı zamanda hizmet arabirimi işlevleri üzerinde anlaşmaya varmak için ilk sözleşmedir. Merkezi olmayan hizmet çerçevesi artı çoklu sürüm, yük dengeleme ve diğer işlevler için destek, esasen önceki "noktadan noktaya" moddaki çeşitli sistem kararsızlığı sorunlarını korur.
"Merkezi mimaride", tüm mimarinin merkezi ESB'dir ve tüm hizmet çağrıları ve geri dönüşleri ESB'den geçmelidir, böylece hizmet arayan kişi "merkezi olmayan mimari" içindeyken bir hizmeti ararken çok fazla ağ ek yüküne sahip olacaktır. ", bu sorun ortaya çıkmayacak.
Ek olarak, tüm servis çağrıları ESB'den geçer, bu nedenle ESB küme dağıtımı kaçınılmazdır.Ayrıca, ESB ile ilgili herhangi bir sorun olmamasını sağlamak için, ESB sisteminin dağıtımının sunucu yapılandırması veya ağ yapılandırması daha iyi olacaktır, bu da işletmelerin ESB'yi genişletmesini gerekli kılar. , Yazılım ve donanım maliyetlerinde önemli bir artış sağlayacak.
Ek olarak, ESB sistemi yüksek kullanılabilirliği sağlamak için küme dağıtımını kullansa bile, yine de bir "çığ" etkisi olabilir. Bir "çığ" meydana geldiğinde, işletmedeki tüm hizmetler kullanılamayacak .
çığ
ESB kümesindeki her bir sunucunun maksimum eşzamanlılığının 100 olduğunu varsayıyoruz. Kümede şu anda 10 sunucu olduğunu varsayarsak, günlük kullanıcı istek hacmi sabit olduğunda, yük dengelemeden sonra her sunucunun ortalama eşzamanlılığı 80'dir, ancak küme ise Sunuculardan biri aniden başarısız oluyor. Şu anda, önceki eşzamanlılığı taşımak için 9 sunucu daha gerekiyor.Daha sonra kalan 9 sunucunun eşzamanlılığı artacak ve bu da 9 sunucudan birinin boğulmasına neden olabilir. Kalan 8 sunucunun birbiri ardına ezilmesiyle sonuçlanan bu "çığ". Bir "çığ" hatası oluştuğunda, sunucuyu yeniden başlatsanız bile çözmesi zordur, çünkü başlatma tamamlandıktan hemen sonra sunucunun trafik tarafından boğulma olasılığı çok yüksektir, bu nedenle şu anda yalnızca dış trafiğin sisteminize akmasını engelleyebilirsiniz. Trafiğe izin vermeden önce tüm sunucuların başarıyla başlamasını bekleyin. Ve bu olduğunda, sorunu bulmak için zamanınız olmayabilir Yeniden başlatılan küme aslında "kırılgan" durumdadır.
Bu, "merkezi" mimarinin sistem ölçeklenebilirliği sorununu iyi çözemeyeceği anlamına gelirken "merkezi olmayan" mimari daha iyi olacaktır, çünkü yukarıdaki durum ortaya çıksa bile, tüm hizmetleri etkilemeyecektir. İşte bu yüzden İnternet endüstrisi "ademi merkeziyetçi" bir mimari seçiyor.
Aşağıda tanıtıyoruz Alibaba Dağıtılmış Hizmet Çerçevesi HSF , Okumayı bitirene kadar bekle ... haha.
İnovasyon, yalnızca sorunlu noktalar olduğunda gerçekleşir ve bir teknoloji yalnızca belirli bir acı noktasını çözecek şekilde görünmelidir.
Bu kitabı iletmek isteyen arkadaşlar + takip ediyor ve sonra "mimari" ye özel mesajla cevap veriyorlar, size tam bir kitap PDF belgesi gönderebilirim.
Elbette fiziksel kitap satın almak daha çok destek oluyor, belgeleri aldıktan sonra sonuçlara bakan arkadaşlar da destek satın alabiliyor!
