g u t x .com.tr İpek yolu - Çin'i anlamaya götürürüm

You Yun I Yun Brothers Night Talks 3. Sezon Kurumsal BT Mimarisi

Yazar: Sammy Liu "İnsanlar bulut bilişim dünyası hakkında konuşuyor," köşe yazarı

0. Genel Bakış

Zaman: 23 Şubat 201922:00 ~ 23:30
Konu: Kurumsal BT Mimarisi
Kardeşlik:
Sun Jie: Bu tartışmanın moderatörü, CNPC Ruifei kıdemli bulut bilişim uzmanı, mimar ve işletim ve bakım uzmanı, "Kurumsal Özel Bulut İnşaatı Rehberi" nin yazarı
Zhou Jian: Sektördeki Kıdemli Bulut Bilişim Uzmanı
Lou Wei: Yunxing Data Başkan Yardımcısı, sektördeki kıdemli bulut bilişim uzmanı
Xiao Li: Yeni Titanyum Bulut Hizmetinin teknik lideri, "Deep Practice KVM" nin yazarı
Shan Jinxiao: Sektördeki kıdemli bulut bilişim uzmanı, "OpenStack High Availability Cluster" yazarı
Polar Bear: Cloud Technology Community'nin kurucu ortağı
Liu Shimin: "Shimin Talks about Cloud Computing" blog yazarı

1. Kurumsal BT mimarisiyle ilgili bazı kavramlar

1.1 Mikro hizmetler ve SOA arasındaki ilişki nedir?

SOA, Servis Odaklı Mimari'nin kısaltmasıdır ve mimari bir konsepttir. İlk günlerdeki ana biçimi Enterprise Service Bus (ESB) idi. Esas olarak, kuruluştaki birden çok heterojen iş sistemi arasındaki ara bağlantı gereksinimlerini karşılamaktır. ESB, ağdaki en temel bağlantı merkezini sağlar ve bir işletmenin sinir sistemini kurmak için gerekli bir unsurdur. ESB, mesaj, olay ve hizmet seviyelerindeki uygulamalar arasında dinamik ara bağlantı ve iç iletişimi desteklemek için yaygın olarak kabul edilen açık standartlara dayalı olarak uygulamalar arasındaki entegrasyon topolojisini yönetmek ve basitleştirmek için bir "veri yolu" modeli benimser. Gevşek bağlanmış hizmetler ve uygulamalar arasında standart bir entegrasyon yoludur. Aşağıdakilere göre hareket edebilir:

Hizmet odaklı mimari - dağıtılmış uygulamalar yeniden kullanılabilir hizmetlerden oluşur
Mesaj odaklı mimari - uygulamalar, ESB aracılığıyla mesaj gönderir ve alır
Olay odaklı mimari uygulamalar mesajları eşzamansız olarak oluşturur ve alır

ESB'nin bankalardaki uygulamasını örnek alalım,

ESB'nin görevi, entegre sistemin hizmetlerini sağlamak ve aramaktır. ESB kullanılır.Çoğu durumda, her sistem ile ESB arasında yalnızca bir erişim yöntemi ve bir arayüz tanımlanması gerekir.

Bununla birlikte, İnternet mimarisi altında, ESB'nin performans baskısı gibi bazı dezavantajları vardır. ESB'nin kendisi de tek bir nokta olduğundan, küme dağıtımında bile, performans sorunları tamamen çözülemez. Şu anda mikro hizmetler ortaya çıktı.

Mikro hizmetlerin aynı zamanda yeni bir hizmet odaklı uygulama mimarisi türü olan yeni bir SOA konsepti biçimi olduğuna inanıyoruz. Bir uygulamayı birden çok hizmete ayırır, her hizmet bağımsızdır, ancak hizmetler birbirine bağlıdır. Faydaları açıktır: Kendi ölçeklenebilirliği, yükseltilebilirliği, kolay bakımı, arıza ve kaynak izolasyonu ve diğer birçok özelliği ürünün üretim ve geliştirme verimliliğini büyük ölçüde artırmıştır. Bu nedenle, İnternet mimarisi altında yüksek eşzamanlılık sorununu çözebilir.

1.2. Kubernetes ile neden bir hizmet ağı var?

Chris Richardson bir keresinde şöyle demişti: "Mikro hizmet uygulamaları, doğasında karmaşıklık getirecek dağıtılmış sistemlerdir. Geliştiricilerin RPC veya mesaj geçişi arasında seçim yapmaları ve süreçler arası iletişim mekanizmasını tamamlamaları gerekir. Ayrıca, işlemek için kod yazmaları gerekir. İleti tesliminde yavaşlık veya kullanılamama gibi yerel hatalar. "

Bulut yerel modelinde, bir uygulama yüzlerce hizmetten oluşabilir, her hizmet binlerce örneğe sahip olabilir ve her örnek sürekli değişebilir. Bu durumda, hizmetler arasındaki iletişim yalnızca aşırı derecede karmaşık değil, aynı zamanda çalışma zamanı davranışının da temelini oluşturur. Hizmetler arasındaki iletişimi yönetmek, uçtan uca performans ve güvenilirliği sağlamak için şüphesiz çok önemlidir.

Yukarıdaki karmaşık durum, hizmetler arasındaki iletişim katmanının ortaya çıkmasına yol açmıştır.Bu katman, uygulama koduyla birleştirilmeyecek, ancak aynı zamanda temel ortamın son derece dinamik özelliklerini yakalayabilir ve iş geliştiricilerin yalnızca kendi iş kodlarına odaklanmalarına olanak tanır ve Bulut uygulamasından kaynaklanan birçok sorun, iş kodunu istila etmeyecek şekilde geliştiricilere sunulmaktadır.

Bu hizmetler arası iletişim katmanı, güvenli, hızlı ve güvenilir hizmetten hizmete iletişim sağlayabilen Hizmet Ağıdır.

Bu nedenle, Hizmet ağı ayrıca mikro hizmetlerin iş mantığı katmanını ve mikro hizmetlerin iletişim katmanını ayıran bir mikro hizmet mimarisi konseptidir. Uygulama geliştiricileri iş mantığına odaklanırken, servis ızgarası iletişim katmanı sorununu çözer.

Hizmet ağı tarafından uygulanan altyapı katmanı genellikle bir kontrol düzlemi ve bir veri düzlemi olarak bölünür. Kontrol düzlemi altyapıyı kontrol etmek için kullanılır ve veri platformu ağ iletişim yeteneklerini uygulamak için kullanılır. Aynı zamanda, Servcie ağını uygulamanın birçok yolu vardır ve sepet, daha yaygın olanıdır.

Hizmet ağı, Kubernetes'in benzersiz bir ürünü değil, mikro hizmet mimarisinin kendisinin bir gereksinimidir. Kubernetes, mikro hizmetleri çalıştırmak için bir platformdur. Mikro hizmetleri çalıştırmak için kapsayıcıları kullanır ve esas olarak kapsayıcı düzenleme yetenekleri sağlar. Istio, bir yardımcı araç yöntemi kullanan Kuberntes için bir hizmet ağı uygulamasıdır.

Şu anda, istio'nun temsil ettiği Hizmet ağı hala yeni ortaya çıkan yeni bir şey ve hala birçok eksiklik ve kusur var. Performans sorunları, kararlılık sorunları ve kullanım kolaylığı sorunları gibi. Özellikle, uygulama sistemine müdahaleci, yani onu kullanmak için mikro hizmet mimarisinin yeniden tasarlanması gerekiyor. Bu nedenle, şimdiye kadar çok fazla üretim vakası görmedik.

Bununla birlikte, mikro hizmetler + hizmet ızgarasının uzun vadede kaçınılmaz bir form olduğuna inanıyoruz, çünkü iki kaçınılmaz eğilimi temsil ediyor:

Birincisi, bileşenlerdeki ortak şeyleri teknik mimari seviyesinden ayırmak ve entegre etmektir.
İkincisi, iş gereksinimleri düzeyinden, iş mikro hizmet ekibi iş mantığına odaklanır ve iş dışı mantığın uygulanmasını diğerlerine devreder (alt katman).

1.3. PaaS ve Sunucusuz arasındaki ilişki nedir?

Sunucusuzun ne olduğu ve tanımı hakkında birçok tartışma ve farklı görüş vardır.

(1) Bazı insanlar, sunucusuzun mikro hizmet mimarisinden sonra her mikro hizmeti yeniden işlevselleştiren yeni bir BT mimarisi biçimi olduğuna inanıyor.

Bu açıdan, Sunucusuz bir uygulama mimarisidir ve PaaS, bu mimarinin uygulamaları için çalışan bir platformdur.

(2) Sunucusuzluğun, bulut sağlayıcılarının uygulamalar için dinamik olarak sunucuları oluşturup yönettiği bir bulut bilişim yürütme modeli olduğuna dair görüşler de vardır. Sunucusuz bir uygulama, durum bilgisiz bir konteynerde çalışır, olay odaklı çalışır ve bulut sağlayıcısı tarafından tamamen yönetilir. Sunucusuz faturalandırılır, önceden satın alınan bilgi işlem kapasitesine göre değil yürütme sayısına göre yapılır.

Bu açıdan Sunucusuz, PaaS ile SaaS arasında bir model ve aşamadır.

(3) Büyük bulut satıcıları tarafından sağlanan sunucusuz ürünlere bakıldığında, sunucusuzluğun mevcut uygulama senaryoları, özellikle kısa çalıştırma süresine sahip nispeten basit iş mantığına sahip bazı olay odaklı senaryolar için hala nispeten sınırlıdır.

Bu nedenle şuna inanıyoruz:

Kısa ve orta vadede sunucusuz, çoğu uygulama için uygun bir mimari haline gelmeyebilir, ancak belirli iş senaryolarında değerini gösterecektir.
Uzun vadede, Sunucusuz hala bir geliştirme eğilimini temsil ediyor, bu nedenle büyümesini dört gözle beklemeye değer. Çünkü:

Bulut kullanıcıları için:

Bulut altyapısı, dağıtım vb. Hakkında herhangi bir bilgiye ihtiyacınız yok, sadece işleve odaklanın.
Başvuruların daha kolay yazılması ana motivasyondur.
Daha kısa çalışma süresi, hafızanın boyutu, vatansızlığın doğal özellikleri ile ilgilenmeye gerek yok.
para biriktir

Bulut sağlayıcıları için:

X86 sunucularının benimsenme oranını azaltmak, maliyetleri etkin bir şekilde azaltabilir.
Yeni hesaplama soyutlaması, gelecekte sınırsız olanaklar anlamına gelir.

1.4 Özet

Yukarıdaki sınıflandırma esas olarak teknik düzeyden gerçekleştirilir:

İkinci mimarinin amacı, eski mimarinin eksikliklerini ve sınırlamalarını çözmektir.
Uygulama mimarisi ve temel alınan platform arasında bir bağlantı var, ancak ikisi güçlü bir şekilde bağlı değil

2. Kurumsal işletme orta ofisi

Genel olarak işletme orta istasyonlarının teknik orta istasyonlara ve iş orta istasyonlarına bölünebileceğine inanılmaktadır.

2.1 Kurumsal işin ortası nedir

Alibaba'nın orta aşamadaki işini kapsamlı bir şekilde tanıtması ve sektörün bu konuda daha derin ve daha derin araştırması ile bu sorunun cevabı daha net hale geldi. Kurumsal işletmenin orta ofisi, kuruluşun ön uç sisteminin ortak parçalarını çıkarmak ve bunu paylaşılan bir iş hizmetine dönüştürerek ön uç işi desteklemek için bir hizmet orta ofisi oluşturmaktır.

2.2 Kurumsal işin amacı

İşletmenin ortasında işin temel amacı ile ilgili olarak, esas olarak aşağıdaki noktaları tartıştık:

Grubun iş yönetimi ve kontrolünü güçlendirmeye yönelik gereksinimleri. Kurumsal iş merkezi olmadığında, her bir iş birimi (BU) tüm işi kontrol eder. Örneğin, her BU'nun kendi kullanıcı merkezi, işlem merkezi ve değerlendirme merkezi vardır. Ancak aslında bunlar grubun çok temel ve temel şeyleridir. E-ticaret sektörünü örnek olarak ele alalım, kullanıcılar neredeyse can damarlarıdır. Bu nedenle, grup yönetimi tüm grubun temel iş ve verilerini kontrol etmelidir. Bu noktadan hareket etmek, bu işleri çıkarmak ve birleşik yönetimi yürütmek daha mantıklı. Politik bir ihtiyaç olarak kabul edilebilir.
Yeni iş esnekliği gereksinimleri. İnternet çağında şirketler, kullanıcı ihtiyaçlarını hızlı bir şekilde karşılamak ve kullanıcı odaklılık elde etmek istiyorlarsa, kullanıcıların yeni ihtiyaçlarını karşılayan yeni iş sistemlerini hızlı bir şekilde başlatmaları gerekmektedir. İşletme orta istasyonu tarafından sağlanan çeşitli temel hizmetler ile, işletmelerin yapı taşları gibi yeni iş sistemlerini hızla inşa etmeleri mümkündür. Bu bir iş gereğidir.
İş sistemi teknik mimari optimizasyon gereksinimleri. Teknik bir mimarın bakış açısından, çeşitli iş sistemlerinde ortak modülleri çıkarmak yaygın bir uygulamadır. Bu teknik bir gerekliliktir.

2.3 Kurumsal işletmenin orta aşaması, işletmenin lider projesidir

Yukarıdaki üç işletmenin bariz birincil ve ikincil ayrımları vardır, yani grup kontrol gereksinimleri > İş esnekliği gereksinimleri > Teknik mimari gereksinimleri.

Başka bir deyişle, yalnızca işletmenin BT departmanının veya bir veya iki işletme departmanının tanıtımına güvenerek kurumsal işin orta aşamasına geçmek neredeyse imkansızdır. Bunun nedeni, birçok işletme departmanının çıkarlarının yeniden dağıtımını içermesidir. Geçmişte BU, tüm işlerini bağımsız olarak kontrol edebiliyordu, ancak iş merkezi ile BU'nun işlerinin büyük bir kısmı başkalarına tahsis edilecek. Bu nedenle, ileriye doğru ilerlerken, genellikle çeşitli BU'lardan güçlü bir direnç alırlar.

İlk gereksinimle birleştirildiğinde, kurumsal işin orta aşamasını yalnızca işletmenin lideri tarafından teşvik etmek mümkündür.

Alibaba'nın organizasyon yapısının en son düzenlemesinden yola çıkarak, "Alibaba Cloud Business Group, Alibaba Cloud Intelligent Business Group'a yükseltildi. Group CTO'su Zhang Jianfeng, aynı zamanda Alibaba Cloud Intelligent Business Group'un Başkanı olarak görev yapacak ve doğrudan Zhang Yong'a rapor verecek." Zhang Jianfeng'in aynı zamanda grubun CTO'su (teknik hat) ve Alibaba Cloud Intelligent Business Group'un (iş kolu) başkanı olduğu görülüyor. Alibaba Cloud'un gelecekteki gelişiminin ana yönü, teknolojiden (platform) işletmeye (orta aşama) kayacak.

3. Kurumsal BT Mimarisi

Teknoloji sürekli gelişiyor, ancak teknolojinin işletmeye hizmet etme amacı değişmeyecek. Bir işletmenin iş durumu, kurumsal BT sisteminin mimari durumunu belirler. basit ifadeyle:

Geleneksel işletmeler yalnızca geleneksel BT sistemlerine ihtiyaç duyar
İnternet işi İnternet tabanlı bir BT sistemi gerektirir
BT mimarisi iyi veya kötü değil, yalnızca uygun ve uygunsuz
Her işletmenin kendi iş özellikleri ve BT mimarisi özellikleri vardır

3.1 Kurumsal iş özellikleri, kurumsal BT mimarisinin özelliklerini belirler

Örneğin, bir işletmenin İnternet işi kabaca% 10'luk bir paya sahipse, sahip olduğu mikro hizmet BT sistemlerinin oranı da% 10'dur. Örnek olarak bankaları ele alalım: Çoğu bankanın temel iş sistemleri hala küçük bilgisayarlarda.

Kurumsal BT mimarisinin gelişimi, esas olarak iş ve maliyete bağlıdır. Mevcut BT sistemi mevcut işi destekleyebiliyorsa, değişiklik ihtiyacı çok azdır. Şu anda istikrar ilk şarttır.

3.2 Farklı kurumsal mimarilerin itici rolleri farklıdır

Farklı kurumsal BT tesisleri, yönetmek için farklı roller gerektirir:

Temel bulut platformu için temel gereksinimleri ve özellikleri şunlardır:

Sanallaştırma yoluyla ekipman maliyetlerini azaltın
Merkezi yönetim ve kontrol yoluyla yönetimi ve tekrarlanan inşaat maliyetlerini azaltın
Statüko üzerindeki etkisi (kullanıcılar, geliştirme ekipleri, uygulama sistemleri, operasyon ve bakım ekipleri, vb.) Nispeten küçüktür.

PaaS platformu için temel gereksinimleri ve özellikleri şunlardır:

Uygulama geliştirme, işletim ve bakım maliyetlerini azaltın
Geliştirme süreci, uygulama mimarisi ve ekibin (proje ekibi, operasyon ve bakım ekibi, geliştirme ekibi) beceri gereksinimleri üzerinde büyük etkisi vardır.

İşletme orta ofisi için temel gereksinimleri ve özellikleri şunlardır:

Grubun merkezi yönetimi ve iş ve veri kontrolü
İşletme standardizasyonu, esneklik ve hızlı çevrimiçi gereksinimler
İş sistemi mimarisi optimizasyonu
İşletme departmanlarının çıkarlarını ve şirketin organizasyon yapısını doğrudan etkilemek

3.3 Bazı esinlenmeler ve gereksinimler

Şirkete tanıtmak istediğiniz şey, bu konuda karar verebilecek şirkette bulunmalıdır. Yanlış kişiyi bulursanız işler biter.

İşletmenin teknik kadrosu, işletmenin liderleri için materyaller yazar ve teknolojiden çok işle başlar, aksi takdirde patron dinlemekle ilgilenmez. Teknoloji, ancak işin talep ettiği noktayı bulduğunda değerlidir, aksi takdirde teknisyenlerin arzulu düşüncesidir.

Kurumsal teknik personel, işletmenin işini anlamayı öğrenmeli, işin gereksinimlerini anlamaya başlamalı ve ardından iş sistemini tasarlamalıdır.

Referans malzemeleri: