Alibaba Cloud uzmanları size BT mimarisini nasıl yeniden şekillendireceğinizi öğretiyor
Yazar | Yi Li
Sorumlu Editör | Hu Weiwei
Bu makale yazarın katkılarıyla hazırlanmıştır
21. yüzyıla girdiğimizden beri, kurumsal dağıtılmış uygulama mimarisinin SOA'dan (Servis Odaklı Mimari) mikro hizmet mimarisine ve ardından bulut yerel uygulama mimarisine evrimine tanık olduk.
Kurumsal mimarinin evriminin arkasındaki düşünceyi göstermek için, biraz "metafizik" hakkında konuşalım:
l Kurumsal BT sisteminin karmaşıklığı (entropi), termodinamiğin ikinci yasasına uygundur. Zaman ilerledikçe ve iş değiştikçe, kurumsal BT sistemlerinin karmaşıklığı artacaktır.
l Bilgisayar etkileşimi tasarımında iyi bilinen bir karmaşıklığın korunması yasası vardır: uygulama etkileşiminin karmaşıklığı ortadan kalkmayacak, ancak başka bir şekilde var olacaktır. Bu ilke aynı zamanda yazılım mimarisi için de geçerlidir, yani yeni bir yazılım mimarisinin getirilmesi, BT sisteminin genel karmaşıklığını azaltmayacaktır.
Bunu duymak, bize biraz soğukkanlılık hissettiriyor mu, kim sürekli yaşıyor ve savuruyor?
Modern yazılım mimarisinin temel görevlerinden biri, altyapı ve uygulamalar arasındaki sınırı tanımlamak, karmaşıklığı makul bir şekilde bölümlere ayırmak ve uygulama geliştiricilerin karşılaşması gereken karmaşıklığı azaltmaktır. Diğer bir deyişle, geliştiricilerin temel değer yeniliğine odaklanmalarına ve bazı sorunları çözmeleri için daha uygun kişilere ve sistemlere bırakmalarına izin vermektir.
Şekil I-1 ile başlayalım ve kurumsal dağıtılmış uygulama mimarisinin gelişimini inceleyelim.
Dönüşümün acısı - SOA
2004'te IBM, SOA Küresel Tasarım Merkezi'ni kurdu.Ar-Ge TL'si ve mimar olarak, küresel müşteriler için bir dizi pilot projeye katıldım, PepBoys ve Office Depot gibi uluslararası şirketlerin dahili ve kurumlar arası iş süreçlerini optimize etmek ve iş çevikliğini geliştirmek için SOA'yı kullanmalarına yardımcı oldum. Seks.
O zamanki genel arka plan, ekonomik küreselleşmenin giderek derinleşmesiyle, işletmelerin karşılaştığı rekabetin yoğunlaşması ve iş dönüşümünün hızlanmaya başlamasıydı. Büyük şirketlerin iç BT sistemleri onlarca yıllık bir evrim geçirdi. Ana bilgisayar sistemindeki CISC ve Cobol işlem uygulamaları, AS / 400 mini bilgisayardaki RPG iş sistemleri ve X86 veya Power gibi dağıtılmış sistemlerin C, J2EE ve .Net uygulamaları gibi tüm teknik sistem son derece karmaşık hale geldi. Üç taraf tedarikçiler tarafından çok sayıda uygulama sistemi sağlanır ve hatta bazı sistemler bakıma alınmamıştır. Dahası, iş yinelemeleri ile bazı yeni iş sistemleri sürekli olarak inşa edilmiştir.Makul metodolojik rehberlik eksikliği ve sistemler arasında organik bağlantıların olmaması nedeniyle, BT mimarisinin karmaşıklığını artırmaya devam eden bir dizi "bilgi adası" oluşturulmuştur. İş geliştirmenin taleplerini destekleyin. Sanki çeşitli grupların efendileri, yaralı Linghu Chong'a yardım etmek için vücuda farklı türlerde zhenqi enjekte ediyor gibidir.Yaralanmalar kısa sürede giderilebilmesine rağmen, birden fazla zhenqi birleştirilemez, birbirleriyle kabarır ve yaralanmaları uzun süre incitir ve arttırır.
Bu nedenle, kurumsal BT'nin karşılaştığı başlıca zorluk, verimli iş kararları ve hızlı iş değişiklikleri için giderek karmaşıklaşan iş süreçlerini desteklemek için kuruluşa çok sayıda silo BT sistemini entegre etmektir. Bu bağlamda, IBM gibi şirketler, uygulama sistemlerini kaba hizmetlere ayıran ve gevşek bağlı hizmet mimarisi oluşturan, hizmetleri iş süreçleri aracılığıyla esnek bir şekilde birleştirebilen ve işletmeyi geliştirebilen SOA (Hizmet Odaklı Mimari) konseptini ortaya koydu. BT varlıklarının yeniden kullanımı sistemin uyarlanabilirliğini, esnekliğini ve ölçeklenebilirliğini geliştirir ve "bilgi adaları" sorununu çözer.
SOA, dağıtılmış sistemler oluşturmak için bugün hala geçerli olan bir dizi ilke önerdi:
1) Hizmet, açıkça tanımlanmış ve standartlaştırılmış bir arayüze sahiptir ve hizmet tüketicisinin (tüketici) ve hizmet sağlayıcının (sağlayıcı) gerçekleştirilmesi, hizmet tanımı açıklamasıyla ayrıştırılır. Ve hizmet, kod önceliği yerine sözleşme öncelikli olarak geliştirilmelidir. Hizmetler arasındaki iletişim, belirli dil RPC protokolleri yerine belge odaklı mesajlar kullanır.Bir yandan, hizmetlerin ve uygulama dillerinin ayrıştırılmasını çözebilir, diğer yandan, sistem kullanılabilirliğini ve ölçeklenebilirliğini iyileştirmek için esnek bir şekilde eşzamanlı veya eşzamansız iletişimi seçebilir.
2) Hizmetler gevşek bir şekilde birleştirilmeli ve hizmetler arasında zaman, alan, teknoloji ve ekip bağımlılıkları olmamalıdır.
3) Hizmet çağrısının konuşma bağlamı durumundan ayrılması için hizmet durumsuz olmalıdır.
4) Hizmetler yeniden kullanılabilir olmalı ve iş mantığı bir dizi yeniden kullanılabilir hizmete bölünmelidir.
5) Hizmet özerk ve bağımsız olmalıdır ve hizmetin uygulanması bağımsız olarak dağıtılabilir, sürüm kontrollü, kendi kendine yönetilebilir ve geri yüklenebilir.
6) Hizmetler keşfedilebilir ve oluşturulabilir. Örneğin, hizmet keşfi, hizmet tüketicilerinin ve hizmet sağlayıcılarının dinamik bağlanmasını gerçekleştiren Hizmet Kaydı aracılığıyla gerçekleştirilebilir. İş sürecinde, farklı sistemlerden iş hizmetleri düzenlenebilir ve birleştirilebilir.
SOA sistemlerinin ilk yapımında, çoğu sistem noktadan noktaya iletişim bağlantılarını kullanır ve hizmet çağırma ve entegrasyon mantığı, uygulama uygulamasında yerleşiktir. Bu yöntem, hizmetlerin sayısı nispeten az olduğunda gerçekten de basit ve verimli bir geliştirme yöntemidir. Ancak en büyük sorun, hizmetlerin ölçeği büyüdükçe hizmetler arasındaki iletişimin gittikçe daha karmaşık hale gelmesi ve bağlantı yolu ve karmaşıklığın keskin bir şekilde artması ve bu da hizmet yönetimine büyük zorluklar getirmesidir.
Yukarıdaki zorlukları çözmek için, Şekil I-2'de gösterildiği gibi Enterprise Service Bus (ESB) tanıtıldı. Kurumsal hizmet veriyolu, hizmetler arasında bağlanma, dönüştürme ve aracı işleme yeteneği sağlar. İşletmenin dahili ve çeşitli hizmetlerini hizmet veriyoluna bağlayabilir, bilgi sistemleri arasında gevşek bağlı mimariyi gerçekleştirebilir, sistem entegrasyonunun karmaşıklığını koruyabilir, BT sistem mimarisinin esnekliğini artırabilir ve işletme içindeki bilgi paylaşım maliyetini azaltabilir.
SOA metodolojisinin amacı, farklı zhenqileri ayıklamaya ve toplamaya, onları bütünleştirmeye ve benim kullanımım için kullanmaya yardımcı olabilecek Yi Jin Jing gibidir. Bununla birlikte, xiulian süreci hiçbir şekilde kolay değildir. Çok sayıda iddialı SOA projesi beklenen sonuçlara ulaşamadı, bunun arkasındaki sebepler nelerdir?
Herhangi bir BT mimarisinin başarısı, iş hedefleri, teknik temeller ve organizasyonel yeteneklerle işbirliğinden ayrılamaz.
İş dünyasında SOA, kurumsal BT borsası sorununu çözmeye odaklandı. Bu, SOA metodolojisinin büyük ölçüde Kurumsal Uygulama Entegrasyonuna daraltılmasını sağlar. SOA konseptinde, bilgi sistemleri arasındaki meridyenlerin açılması sadece ilk adımdır. Ayrıca, kurumsal BT mimarisinin çevikliğini ve esnekliğini korumak ve iş geliştirme ve değişiklikleri desteklemeye devam etmek için dahili becerilerin özenle onarılmasını ve yinelemeli kurumsal BT mimarisinin sürekli yeniden yapılandırılmasını gerektirir.
Organizasyon yapısı açısından, o dönemdeki çoğu işletmenin BT departmanı hala maliyet merkezine ait olduğundan, işletme destek departmanı idi. Çoğu şirket, uzun vadeli BT stratejik planlamasından yoksundur ve BT ekipleri de büyümeyi tanımaktan yoksundur SOA, kurumsal garantiler ve sürekli yatırım olmaksızın proje tabanlı bir operasyona indirgenmiştir. O dönemdeki başarılı projeler bile karmaşıklık birikiminin erozyonu altında yavaş yavaş canlılıklarını kaybedecek. Amerika Birleşik Devletleri'nde yaşayan arkadaşlar geçen yıl fotoğraf gönderdiler. 15 yıl önce müşterilerimiz için kurduğumuz iş sistemi, ülke çapındaki mevcut mağazalarının işini hala destekliyor. Bu teknoloji projelerinin başarısı, ancak kurumsal teknoloji stratejisinin eksikliğini yansıtıyor.
Teknik olarak, ESB mimarisi iş mantığı ve hizmet entegrasyonunun ayrıştırılmasını gerçekleştirse de, merkezi hizmet yönetişimini daha iyi yürütebilir. Ayrıca bazı ciddi problemler ortaya çıktı:
1) Kurumsal BT mimarisinin yönetişimi ve yeniden yapılandırılmasından ziyade, iş sistemlerinin yeniden kullanılabilirliğine aşırı vurgu nedeniyle. ESB'ye çok sayıda hizmet entegrasyon uygulama mantığı batırılmış ve bu da ESB'nin kötüye kullanılmasına yol açmaktadır.Şekil I-2'deki en sağdaki şekilde gösterildiği gibi, bu mantıkların sürdürülmesi çok zordur, nakledilmesi ve genişletilmesi zordur ve ESB için dayanılmaz bir yük haline gelir. Karmaşıklıkla doğru yerde makul bir şekilde başa çıkmalıyız, basitçe aktarmamalıyız.
2) ESB, merkezi bir mesaj işleme sistemine dayanmaktadır.İnternetin hızlı gelişimi ile ESB, kurumsal BT'nin büyük ölçekli büyümesinin zorluklarıyla baş edememiştir.
3) ESB gibi "akıllı borular, sessiz uç noktalar" ın sistem mimarisi, hızlı değişimlere ve popüler yeniliklere uyum sağlayamayan bir mimaridir. Benzetme yoluyla, telekom operatörleri bir zamanlar video iletişimi ve telekonferans gibi karmaşık işlevleri telekom altyapısına dahil etmeyi umuyorlardı ve zengin iletişim hizmetlerinin keyfini çıkarmak için yalnızca "aptal" bir telefon terminaline ihtiyaç duyuyorlardı. Bununla birlikte, akıllı telefonların yaygınlaşmasıyla birlikte WeChat ve Dingding gibi dağıtılmış iş birliği araçlarındaki yenilikler, insanların iletişim şeklini tamamen altüst etti ve telekomünikasyon ağları boru hatlarının kaderine geri döndü.
Ortaya çıkış-mikro hizmetlerin güzelliği
İnternetin gelişmesiyle, özellikle mobil İnternet çağının ortaya çıkmasıyla birlikte, tüm dünyanın ekonomik formu muazzam değişikliklere uğradı. Kurumsal BT'nin odak noktası, geleneksel işlem sistemlerinden (ERP, SCM vb.) Etkileşimli sistemlere (çok kanallı pazarlama gibi) doğru gelişmiştir. Bu sistemlerin İnternet ölçeğindeki hızlı büyümeyle başa çıkabilmeleri ve hızlı ve uygun maliyetli deneme yanılma yöntemlerini yineleyebilmeleri gerekir. Kurumsal BT, inovasyonun yönlendirdiği motorlardan biri haline geldi ve iş sınırlarını genişletmek için teknoloji ideali, BT ekiplerinin bir misyon duygusuna sahip olmasına yardımcı oldu ve kurumsal BT'nin gelişimini daha da hızlandırdı.
Netflix ve Alibaba liderliğindeki bir dizi İnternet şirketi, Şekil I-3'te gösterildiği gibi, kurumsal mimaride yeni bir mikro hizmet mimarisi dönüşümüne öncülük etti. Apache Dubbo ve Spring Cloud gibi mikro hizmet çerçeveleri yaygın olarak kullanılmaktadır.
Mikro hizmetlerin temel fikri, iş sistemi uygulamasının karmaşıklığını azaltmak için uygulama işlevlerini bölmek ve ayırmaktır. Mikro hizmetler, uygulama işlevlerinin gevşek bir şekilde bağlı hizmetler kümesine ayrılmasını vurgular ve her hizmet tek sorumluluk ilkesini izler. Mikro hizmet mimarisi, geleneksel monolitik mimarinin birçok doğal sorununu çözer: her hizmet bağımsız olarak dağıtılabilir ve sunulabilir, bu da iş çevikliğini büyük ölçüde artırır; her hizmet, İnternet ölçeğinin zorluklarını karşılamak için bağımsız olarak genişletilebilir ve yatay olarak daraltılabilir.
Mikro hizmet mimarisi, SOA'nın mimari ilkelerini miras alır, ancak uygulama düzeyinde, merkezi olmayan ve dağıtılmış "akıllı uç noktalar, aptal borular" mimarisi oluşturarak ESB'nin yerini alma eğilimindedir ve hizmet keşfi, yönlendirme dahil tüm hizmet yönetişim mantığını entegre eder. Mesaj analizi servisin içine yerleştirilir ve birleşik ESB kaldırılır Servisler arasındaki iletişim, SOA'dan daha kapsamlı dağıtılmış ve merkezi olmayan bir mimari olan basit bir protokol kullanır.
Aynı zamanda mikro hizmet mimarisi, modern yenilikçi organizasyon yapılarının ihtiyaçlarını karşılar. Ünlü Conway Yasası, organizasyon yapısının teknik yapıyı belirlediğini belirtir. İnternet işinin hızla gelişmesiyle karşı karşıya kalan "iki pizza ilkesi" ilk olarak Amazon CEO'su Bezos tarafından önerildi ve bir proje ekibi için iki pizza yeterli değilse, ekibin çok büyük görünebileceğine inanıyordu. Çünkü küçük ekipler verimli iletişim ve işbirliğine daha elverişli, fikir birliğine varılması daha kolay ve kurum içinde yeniliği etkili bir şekilde teşvik edebilir. Böyle bir organizasyon yapısı ayrıca her ekibin modüllerinin daha net bir iş sınırına sahip olmasını gerektirir Her küçük ekip kendi modülünün tüm yaşam döngüsünden sorumludur ve modüller, modüllerin bağımsız olarak gelişebilmesi için mümkün olduğu kadar ayrıştırılmıştır.
Elbette, tek bir büyük uygulamayı birden çok mikro hizmete ayırmak, BT sistemi Ar-Ge işbirliğinin, sunumunun, işletim ve bakımının karmaşıklığını kesinlikle artıracaktır. Kapsayıcı teknolojisinin yaygın uygulamasıyla, kapsayıcılar, uygulamaları temeldeki işletim ortamından ayırabilen uygulama dağıtımı ve teslimi için standart haline geldi; Kubernetes, temel mimarideki farklılıkları koruyarak ve uygulamaların sorunsuz çalışmasına yardımcı olarak kaynak planlama ve düzenleme için standart haline geldi. Farklı altyapılar, uygulamaların veri merkezlerinden bulut gibi farklı ortamlara sorunsuz bir şekilde geçmesine yardımcı olabilir. Bu sırada mikro hizmet mimarisi, DevOps ve kapsayıcılar doğal olarak bir araya gelerek bulut yerel uygulama mimarisinin prototipini oluşturdu.
Mikro hizmet mimarisi ayrıca dağıtılmış mimarinin doğasında bulunan karmaşıklıkla da karşı karşıyadır. Lütfen "Dağıtılmış Hesaplamanın Yanlış Anlamaları" makalesine bakın. Mikro hizmet çerçevesinin, hizmet keşfi, birleştirme, mevcut sınırlama, tam bağlantı izleme ve diğer zorluklar gibi hizmet iletişimi ve hizmet yönetişiminin karmaşıklığını çözebilmesi gerekir. HSF, Dubbo veya Spring Cloud gibi mikro hizmet çerçeveleri, bu yetenekleri kod kitaplıkları biçiminde içerir. Bu kod kitaplıkları, Şekil I-4'te gösterildiği gibi uygulamanın kendisinde yerleşiktir, uygulama ile birlikte yayınlanır ve korunur.
Hizmet iletişimi ve yönetişim, esasen iş mantığına ortogonal olan yatay sistem düzeyindeki endişelerdir. Ancak mikro hizmet mimarisinde, uygulanması ve yaşam döngüsü iş mantığı ile birleştirilir. Mikro hizmet çerçevesinin yükseltilmesi, tüm hizmet uygulamasının yeniden yapılandırılmasına ve konuşlandırılmasına yol açacaktır. Ek olarak, kod tabanı genellikle belirli bir dile bağlı olduğundan, kurumsal uygulamaların çoklu dil (çok dilli) uygulamasını desteklemek zordur.
Evrim bulutu yerelinin ışığı
SOA, iş mantığını ve hizmet yönetişim mantığını ayırmak için merkezi bir hizmet veri yolu mimarisi kullanır; mikro hizmet mimarisi, iş mantığı ve hizmetlerden ödün verirken çevikliği ve ölçeklenebilirliği artıran merkezi olmayan noktadan noktaya arama yöntemine geri döner Yönetişim mantığının ayrıştırılmasının getirdiği esneklik.
Yukarıdaki zorlukları çözmek için topluluk bir hizmet ağı (hizmet ağı) mimarisi önerdi. Hizmet yönetişimi yeteneklerini altyapıya yeniden yerleştirir ve bunları hizmet tüketicilerinin ve sağlayıcıların her iki tarafında bağımsız bir süreçte dağıtır. Bu sadece ademi merkeziyetçilik amacına ulaşmak ve sistemin ölçeklenebilirliğini garanti etmekle kalmaz, aynı zamanda hizmet yönetişimi ve iş mantığının ayrıştırılmasını gerçekleştirir; bu, birbirini engellemeden bağımsız olarak gelişebilir, bu da genel mimari evriminin esnekliğini artırır; Şebeke mimarisi, Şekil I-5'te gösterildiği gibi, iş mantığına müdahaleyi azaltır ve çoklu dil desteğinin karmaşıklığını azaltır.
2017'de Google, IBM ve Lyft liderliğindeki Istio projesi, hizmet ızgarası mimarisinin tipik bir uygulaması ve aynı zamanda yeni bir fenomen düzeyinde "net ünlü" projesi haline geldi.
Istio, hizmet keşfi ve yük dengeleme, aşamalı sunum (gri sürüm), kaos ekleme ve analiz, tam bağlantı izleme ve sıfır güvene sahip ağ güvenliği gibi bir dizi üst düzey hizmet yönetişimi yeteneği sağlar. Üst düzey iş sistemi tarafından kendi BT mimarisi ve yayınlama sistemine göre düzenlenebilir. Bunun yanı sıra, makine öğrenimi için bulutta yerel platform Kubeflow ve sunucusuz için Knative gibi etki alanına yönelik bulut yerel çerçeveler de hızla ortaya çıkıyor. Böyle bir mimari katmanlama yoluyla, geliştiricilerin temeldeki uygulamanın karmaşıklığı yerine yalnızca kendi iş mantığına odaklanmaları gerekir.
2019, servis şebekesi teknolojisinin uygulanması için kritik bir yıl. Istio'nun temsil ettiği servis şebekesi teknolojisinin hızlı olgunluğa ve yaygın kullanımına tanık olduk. Ali ekonomisi içinde, Ant Financial ve e-ticaret işletmeleri, çoklu dil desteği sağlamak ve iş yerleştirme eşiğini düşürmek; teknoloji yinelemesinin hızını artırmak için birleşik bir mimari model sağlamak için büyük ölçekte hizmet ızgara teknolojisini uygulamaya başladı.
Kullanıcıların Istio'yu kullanmalarını destekleme sürecinde, yüksek bir öğrenme eşiğine sahip olduğunu da derinden anladık. Nesnel olarak konuşursak, Istio'nun karmaşıklığı zengin işlevlerinden kaynaklanır. Örneğin, birden çok protokolün akış denetimini destekler, birden çok dili destekler ve uygulamayı değiştirmeden karşılıklı TLS kimlik doğrulamasını destekler. Bir yandan, dağıtılmış mimarinin dağıtımının, işletiminin ve bakımının karmaşıklığından kaynaklanmaktadır.
Bir geliştirici olarak bir yandan kendi işine odaklanmayı umuyor; diğer yandan da temeldeki servis ızgarası teknolojisinin basit, kullanımı kolay, güvenli ve istikrarlı olmasını umuyor. Bu hedeflere ulaşmak için, barındırılan bir hizmet ağı modeli daha makul bir çözüm olabilir. Barındırma modunda, kullanıcıların kullanım karmaşıklığını azaltmak için kontrol düzleminin bileşenleri barındırılır.Kullanıcıların yalnızca veri düzlemindeki iş uygulamalarının geliştirilmesine ve konuşlandırılmasına odaklanmaları gerekir. Aynı zamanda, Istio ile uyumluluğunu sürdürür, esnek yönlendirme kurallarını tanımlamanın bildirime dayalı bir yolunu destekler ve birden çok Kubernetes kümesi için birleşik trafik yönetimini destekler.
Görünüm
"Dünyanın uzun bir süre bölünmüş genel eğilimi birleştirilmeli ve uzun süre birlikte bölünmelidir." Kurumsal dağıtılmış uygulama mimarisi de evrimsel bir ayırma ve kombinasyon yolundan geçti. Bugün, yeni teknolojilerin ortaya çıkmasıyla birlikte, sadece yeni teknolojilerin getirdiği mimari değişiklikleri benimsemekle kalmamalı, bunların arkasındaki evrim mantığına ve temel değerlere de dikkat etmeli ve karmaşıklığı sistematik olarak kontrol etmeliyiz.
Konteynerler ve hizmet ızgaraları gibi teknolojilerin hızla gelişmesiyle birlikte, bulut tabanlı bir işletim sisteminin embriyonik formunun ortaya çıkmaya başladığını görebiliriz. Bu, geliştiriciler için en iyi dönemdir. Bulut altyapısı ve bulut yerel bilgi işlem teknolojisi, iş inovasyonunun hızını büyük ölçüde artırmıştır. Aynı zamanda, bulutta yerel teknolojinin gelişimi, topluluğun büyümesi ve genişlemesinden ayrılamaz. Alibaba, bulut tabanlı teknolojiyi tam olarak benimser ve büyük ölçekli üretimdeki en iyi uygulamalarımızı topluluğa geri döndürür ve daha iyi bir bulut yerel bilgi işlem oluşturmak için toplulukla birlikte çalışır. .
10 yılı aşkın süredir "Istio Service Grid Technology Analysis and Practice" kitabının yazarı Wang Xining ile çalıştım. Eskiden SOA alanında teknik bir uzmandı.Kurumsal dağıtık mimarinin evrimini kişisel olarak deneyimledi ve ilgili alanlarda birçok küresel teknolojiye sahip. patent. Servis şebekesi alanında çok derin bir teorik temeli ve zengin pratik deneyime sahip ve Alibaba Bulut servis şebeke teknolojisinin ürünleştirme sürecinden sorumludur. Okuyucuların hizmet ağının teknik özünü daha iyi kavramalarına ve bunu kendi iş sistemlerine esnek bir şekilde uygulamalarına yardımcı olmak için bu kitabı gerçekten dört gözle bekliyorum.
Sınırlı bir süre için% 8 indirimli "Istio Service Grid Technology Analysis and Practice", hızlı bir başlangıç yapın
Bu kitap, Alibaba Cloud kıdemli teknik uzmanı Wang Xining tarafından yazılmıştır.İstio'nun temel ilkelerini ve gelişimini ayrıntılı olarak tanıtır. İndirilebilen çok sayıda seçilmiş durum ve referans kodu içerir ve Istio geliştirmeye hızlı bir şekilde başlayabilirsiniz. Gartner, hizmet şebekesinin 2020'de tüm önde gelen konteyner yönetim sistemlerinin standart teknolojisi olacağına inanıyor. Bu kitap, mikro hizmetler ve yerel bulut ile ilgilenen tüm okuyucular için uygundur.Bu kitabı derinlemesine okumanız tavsiye edilir.
Bu makalenin yazarı hakkında: Kıdemli teknik uzman Alibaba Bulut Konteyner Hizmeti başkanı Yi Li
"Milyonlarca Kişi Yapay Zekayı Öğreniyor" un önemli bir parçası olarak, 2020 AIProCon Geliştiriciler Konferansı 26 Haziran'da çevrimiçi olarak yayınlanacak ve geliştiricilerin mevcut sınır teknolojisi araştırmaları ve yapay zekanın temel teknolojileri hakkında tek noktadan bilgi edinmelerine olanak tanıyor. Uygulamalar ve kurumsal vakalardaki pratik deneyimle, heyecan verici ve çeşitli geliştirici salonlarına ve programlama projelerine çevrimiçi olarak da katılabilirsiniz. Bir dizi ileriye dönük aktiviteye ve çevrimiçi canlı yayın etkileşimlerine katılın. Yalnızca on binlerce geliştiriciyle iletişim kurmakla kalmaz, aynı zamanda özel canlı yayın hediyeleri kazanma ve teknik uzmanlarla bağlantı kurma fırsatına da sahip olursunuz.
Yorum alanında seçilirseniz, 299 yuan değerinde "2020 AI Geliştiriciler Konferansı" için çevrimiçi canlı bir bilet alacaksınız. Parmaklarınızı hareket ettirin ve söylemek istediklerinizi yazın!
Microsoft bir kişi için bir şirket mi satın alıyor? Sony programlarını kırın, hacker romanları yazın ve sağlam program hayatını izleyin!
Çin insansız hava aracı "Old Paoer" ın anıları
4 yılda 46 sürüm, Spring Cloud'un geliştirme geçmişini anlamak için bir makale
Jingdong Mall'un arkasındaki yapay zeka teknolojisinin sırrı - anahtar kelimelere dayalı otomatik özet oluşturma
İnternetin babası yeni tacı teşhis etti, bir efsane: Google'ın başkan yardımcısı ve NASA'da misafir bilim insanı olarak görev yaptı
Hiç bu kadar kolay olmamıştı: Kafka'ya karşı saldırmanız için sizi 10 dakika alacak!
Kodsuz çağın gelişiyle, programcılar işlerini nasıl sürdürebilirler?
