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

Bir çukur var! Geleneksel işletmeler mikro hizmetlere yöneliyor ...

1. Mikro hizmetlerin uygulanması, BT mimarisinin, uygulama mimarisinin ve organizasyon yapısının birçok yönünü içeren karmaşık bir konudur

Geleneksel endüstrilerdeki birçok şirket mikro hizmetleri ziyaret edip uyguladıktan sonra, mikro hizmetlerin uygulanmasının teknik bir sorun bile değil, çok karmaşık bir sorun olduğunu gördüler.

O zamanlar mikro hizmetlerin uygulamaları dönüştürmesi, kayıt, keşif, sigorta, akım sınırlama, düşürme gibi mikro hizmet yönetişimi yapması gerektiğinden, uygulama geliştirme grubundan çıkarılması gerektiğini düşünmüştüm.Genel olarak, monolitik mimariden başlangıçta daha mutlu olacağını düşündüm. SOA'ya ve ardından Dubbo'dan SpringCloud'a mikro hizmet mimarisine, ancak kaçınılmaz olarak mikro hizmetlerin yanı sıra DevOps ve kapsayıcı katmanının serbest bırakılması, çalıştırılması ve bakımını içerecektir. Bunlar, geliştirme ekibinin kontrolü altında değildir. İşlem ve bakıma alındıktan sonra Grup, konteynerlerin kabulü bir sorun haline geldi ve geleneksel fiziksel makineler ile sanal makineler arasındaki fark, ne gibi riskler getirecek vb., Özellikle konteyner kesinlikle hafif bir sanallaştırma meselesi değil, değil Bir süre sonra netleşecek. Dahası, açıklığa kavuşturulsa bile, çevrimiçi uygulama konteynerleri de vardır.Bir şeyler ters gittiğinde, kimin arkasında olduğu sorunu, konteyner genellikle uygulama katmanı ile altyapı katmanı arasındaki sınırın bulanıklaşmasına neden olur ve bu da her iki tarafı da tereddütlü hale getirir.

Bazı firmaların mikro hizmetleri, operasyon ve bakım departmanı tarafından başlatılmaktadır.İşletme ve bakım departmanı, çeşitli tutarsız uygulamaların neden olduğu sıkıntıları fark etmiş ve konteyneri içeren konteyner işletme ve bakım modelini kabul etmeye isteklidir. Doğrudan hizmet keşfi, operasyon ve bakımın konteyner katmanında mı yapılacağı yoksa uygulamanın kendi başına mı yapılması gerektiği ve Dockerfile'ın geliştirme için mi yoksa operasyon ve bakım için mi yazıldığı sorusudur. Konteynırlaştırma sürecine girdikten sonra, geliştirme işbirliği yapmaz ve bunu tek taraflı yapmak için operasyon ve bakım can sıkıcıdır, ancak sınırlıdır.

Aşağıdaki şekil, mikro hizmetlerin uygulanmasına dahil olan seviyeleri gösterir.Özel açıklamalar için makaleye bakın

Gelişmiş bulut mimarisi stratejisi

Bazı nispeten gelişmiş şirketlerde, mikro hizmetlerin dönüşümünü teşvik etmek için operasyon ve bakım grubu ile geliştirme grubu arasında bir ara yazılım grubu veya mimari grubu olacaktır.Mimarlık grubunun, mikro hizmetleri uygulamaya iş geliştirmeyi ikna etmekten sorumlu olması gerekir. Servis odaklı, ancak aynı zamanda operasyon ve bakım ekibini konteynerizasyonu uygulamaya ikna etmek için, mimari ekibin yetkisi yetersizse, teşvik etmek genellikle zor olacaktır.

Bu nedenle, mikro hizmetlerin, kapsayıcıların ve DevOps'un tanıtımı yalnızca teknik bir sorun değil, aynı zamanda organizasyonel bir sorundur.Mikro hizmetleri geliştirme sürecinde, Conway yasasının rolünü daha fazla hissedebilir ve daha üst düzey teknik yöneticiler veya CIO'lara ihtiyaç duyabilirsiniz. Mikro hizmetlerin inişini yalnızca dahil olmak suretiyle teşvik edebilir.

Bununla birlikte, CIO seviyesine gelince, birçok şirket teknik sıkıntı noktalarının farkında değil ve iş seviyesine daha fazla önem veriyor.İşletmeler para kazanabildiği sürece, mimari, ara katman yazılımı, işletim ve bakımın sancıları pek algılanamaz. , Mikro hizmetlerin ve konteynerleştirmenin teknik avantajlarını takdir edemiyorum. Bununla birlikte, birçok üretici, işletmeler için mikro hizmetlerin ve konteynerleştirmenin avantajlarından bahsediyor.

Bu nedenle, mikro hizmetlerin dönüşümü ve kapsayıcılık düz bir organizasyonda gerçekleşmesi daha olasıdır.Toptan teknik detayların acısını deneyimleyebilen bir CIO, bu konuyu öngörü ile tanıtacaktır. Bu aynı zamanda, mikro hizmetlerin uygulanmasının genellikle İnternet şirketlerine ilk inen olmasının nedenidir, çünkü İnternet şirketlerinin organizasyon yapısı çok platformludur, üst düzey de olsa, cepheye çok yakındır ve cephenin acısını anlar.

Bununla birlikte, geleneksel endüstrilerde, o kadar şanslı değilsiniz.Çoğu zaman daha fazla seviye vardır.Şu anda, işi etkilemek, geliri etkilemek ve rakipler tarafından geride kalmak için yeterli teknik acıya sahip olmanız gerekir. Cennete git ve dinle.

İşlemdeki acıyı çözelim.

2. Aşama 1: Tek mimari grubu, çoklu geliştirme grupları, birleşik işletim ve bakım grubu

2.1. Aşama 1'in organizasyonel durumu

Örgütsel durum nispeten basittir.

Birleştirilmiş bir operasyon ve bakım grubu, fiziksel makineler, fiziksel ağlar ve VMware sanallaştırma gibi kaynakları yönetir.Aynı zamanda, operasyon ve bakım departmanı dağıtımdan sorumludur.

Geliştirme ekibinin her işi bağımsızdır, kod yazmaktan sorumludur ve farklı işletmeler arasında çok fazla iletişim yoktur.Kendi sistemini geliştirmenin yanı sıra dış kaynak şirketi tarafından geliştirilen sistemi de sürdürmesi gerekir.Farklı dış kaynak firmaları farklı teknik seçeneklere sahip olduğundan, Bu nedenle baca mimarisi durumundadır.

Geleneksel baca mimarisi aşağıda gösterilmiştir.

2.2. Birinci aşamanın işletme ve bakım modu

Geleneksel mimari altında, altyapı katmanı genellikle fiziksel makineler veya sanallaştırma ile konuşlandırılır.Farklı uygulamalar arasında karşılıklı erişimi kolaylaştırmak için, köprüler genellikle düz iki katmanlı bilgisayar odası ağını köprülemek için kullanılır, yani tüm makinelerin IP adresleri karşılıklı olarak erişilebilir durumdadır. Birbirinizi ziyaret etmek istemiyorsanız, izolasyon için güvenlik duvarları kullanın.

İster fiziksel makineler, ister sanallaştırma kullanıyor olsun, konfigürasyon nispeten karmaşıktır.Yıllardır işletme ve bakım yapan bir kişi değilse, bağımsız olarak bir makine oluşturmak zordur ve ağ planlamasının da çok dikkatli olması gerekir. Segmentler çakışamaz. Tüm bunlar, operasyon ve bakım departmanı tarafından birleşik bir yönetim gerektirir. Genel BT personeli veya geliştiricileri ne profesyoneldir ne de onlara çalışma izni veremez. Bir makineye başvurmak istersem ne yapmalıyım? Bir iş emri alın, inceleyin ve onaylayın ve bir süre sonra Zamanla makineler oluşturulabilir.

2.3. Birinci Aşama Uygulama Mimarisi

Geleneksel mimarinin veritabanı katmanı, dış kaynak sağlayan şirketler veya farklı geliştirme departmanları tarafından bağımsız olarak geliştirilir.Farklı işletmeler Oracle, SQL Server, Mysql ve MongoDB gibi farklı veritabanları kullanır.

Geleneksel mimarinin ara katman katmanında, her ekip bağımsız olarak ara yazılımları seçer:

Dosya: NFS, FTP, Ceph, S3
Önbellek: Redis Kümesi, etkin ve beklemede, Sentinel, Memcached
Dağıtılmış çerçeve: Spring Cloud, Dubbo, Restful veya RPC farklı departmanlar tarafından seçilir
Alt veritabanı ve alt tablo: Sharding-jdbc, Mycat
Mesaj kuyruğu: RabbitMQ, Kafka
Kayıt merkezi: Zk, Euraka, konsolos

Geleneksel mimarinin hizmet katmanı olan sistem ya bir dış kaynak şirketi tarafından ya da bağımsız bir ekip tarafından geliştirilmektedir.

Geleneksel mimari ön uç, her biri kendi ön ucunu geliştirir.

2.4 Birinci aşamada herhangi bir sorun var mı?

Aslında 1. aşamada sorun yok ve bu modelin faydalarını açıklamak için 10.000 neden bile bulabiliriz.

Operasyon ve bakım departmanı ile açık departman doğal olarak ayrılmıştır ve kimse birbirini önemsemek istemez, her iki taraftaki patronlar da derecelendirilir ve huzur içindedirler.

Tabii ki, bilgisayar odasına sadece işletme ve bakım personeli dokunabilir, güvenlik sorunları, mesleki sorunlar ve çevrimiçi sistemlerde ciddi sorunlar vardır. Ortamı dağıtmak için daha az profesyonel bir geliştirme ortamına bırakırsanız, sistem arızalandığında sorumluluğu kim üstlenebilir ve çevrimiçi sistem çöktüğünde kim sorumlu? Bu soruyu sormak herhangi bir anlaşmazlığı susturabilir.

Veritabanının Oracle, DB2 veya SQL Server kullanıp kullanmadığına bakılmaksızın, herhangi bir sorun yoktur.Şirketin yeterli bütçesi olduğu ve performans gerçekten kaldırıldığı sürece, içinde depolanmış çok sayıda yordam vardır, bu da uygulama geliştirmeyi çok daha kolay hale getirir ve operasyon ve bakıma yardımcı olacak profesyonel B partisi vardır , Veritabanı çok kritiktir, eğer Mysql ile değiştirilirse, direnmezse veya açık kaynak korunmazsa, çevrimiçi olan bir şeyden kim sorumlu olacak?

Ara yazılım, hizmet katmanı ve ön uç, işveren veya Taraf B tarafından yürütülür. Uçtan uca bakım mevcuttur Her sistem, kurulumu ve çalıştırması ve bakımı kolay, eksiksiz bir settir.

Aslında sorun yok, şu anda, konteyner veya mikro hizmeti kullanırken gerçekten sorun istiyorsun.

2.5 Hangi durumlarda birinci aşamada sorun olduğunu düşünüyorsunuz?

Elbette başlangıçtaki sıkıntı noktası iş seviyesinde olmalıdır.Kullanıcıların ihtiyaçları çeşitlenmeye başladığında, iş tarafı zaman zaman yeni bir işlev eklemek zorunda kalacaktır.Yeni bir sistem kurarken, dış kaynak firmasının her şeyi tam olarak idare edemeyeceğini göreceksiniz. Bunlar şelale modelinin geliştirilmesidir ve geliştirilen sistemin değiştirilmesi zordur, en azından hızla değiştirilmesi zordur.

Yani bazı geliştiricileri kendiniz işe almak, kontrol edebileceğiniz bir sistem geliştirmek veya en azından dış kaynak şirketi tarafından geliştirilen sistemi devralmak istemeye başlıyorsunuz.Şu anda işletme departmanının ihtiyaçlarına cevap vermede daha esnek olacaksınız.

Bununla birlikte, kendi kendini geliştirme ve bakım yeni sorunları da beraberinde getirdi.Çeşitli veri tabanları ile bu kadar çeşitli DBA'ları işe almak imkansızdır.İnsanlar çok pahalıdır ve sistemlerin artmasıyla bu veri tabanlarının lisansı da çok pahalıdır. .

Çeşitli ara katman yazılımları, her takım bağımsız olarak ara yazılımı seçer, birleşik bakım yoktur, birleşik bilgi birikimi yoktur ve birleşik SLA garantisi vermek imkansızdır. Kullanılan mesaj kuyruğu, önbellek ve çerçeveyle ilgili bir sorun olduğunda, tüm ekipteki hiç kimse bununla başa çıkamaz.Herkes iş geliştirme ile meşgul olduğu için, hiç kimsenin bu ara yazılımların arkasındaki ilkeleri, ortak sorunları ve bunları nasıl ayarlayacağını çalışmak için zamanı yoktur. Mükemmel ve benzeri.

Ön uç çerçevede de aynı sorun var, teknoloji yığını tutarsız, arayüz tarzı tutarsız ve kullanıcı arabirimi testini otomatik olarak yapmak imkansız.

Birden fazla sistemi koruduktan sonra, bu sistemlerin tüm seviyelerinin birçok ortak noktası olduğunu, birçok yeteneğin yeniden kullanılabileceğini ve birçok verinin bağlanabileceğini göreceksiniz. Aynı mantık kümesi burada ve orada var Aynı tür verilerin bir kopyası burada ve bir diğeri orada, ancak bilgi izole edilmiş ve veri modeli birleşik değildir ve içinden geçmek imkansızdır.

Bu sorunlar ortaya çıktığında ikinci aşamaya geçmeyi düşünüyorsunuz.

3. 2. Aşama: Kurumsal hizmet, SOA mimarisi ve bulut altyapısı

3.1. 2. Aşamanın organizasyonel şekli

Yukarıdaki problem nasıl çözülür?

Conway teoremine göre, belirli organizasyonel ayarlamalar gereklidir ve tüm şirket operasyon ve bakım gruplarına ve geliştirme gruplarına bölünmüştür.

Sorunlu noktalar iş seviyesinden geldiğinden, geliştirme ekibi uyum sağlamaya başlamalıdır.

Bağımsız bir ön uç grubu, birleşik bir ön uç çerçevesi ve tutarlı bir arayüz oluşturulmalıdır.Herkes birleşik bir ön uç geliştirme yeteneğine sahiptir, ön uç kodu biriktirir ve yeni ihtiyaçlar olduğunda hızla gelişebilir.

Bir ara katman grubu veya bir mimar grubu kurun. Bu grubun iş geliştirmeye yakın olması gerekmez.Günlük görevleri, bu ara katman yazılımlarını nasıl kullanacaklarını, onları nasıl ayarlayacaklarını, sorunlarla karşılaştıklarında nasıl hata ayıklayacaklarını ve bilgi birikimi oluşturmayı çalışmaktır. Ara yazılım üzerine odaklanan birleşik bir grup insan varsa, araştırmaya odaklanmak için kendi durumunuza göre sınırlı sayıda ara yazılım seçebilir ve iş grubunu yalnızca bu ara yazılımı kullanacak şekilde sınırlandırabilir, bu da seçimin tutarlılığını sağlayabilir. Ara yazılım bu grup tarafından kullanılıyorsa Birleştirilmiş bakım, iş tarafında da güvenilir SLA sağlayabilir.

İş geliştirme grubunu bir parçaya ayırın, bir orta ofis grubu oluşturun ve bu gruplara yeniden kullanılabilir yetenekleri ve kodları teslim ederek iş grubu tarafından kullanılmak üzere hizmetler geliştirin, böylece veri modeli birleştirilecektir. Öncelikle, hangi hazır hizmetlerin mevcut olduğuna bir göz atalım. Hepsini sıfırdan geliştirmenize gerek yok, bu da geliştirme verimliliğini artıracaktır.

3.2. Aşama 2 uygulama mimarisi

Bir orta ofis kurmak ve onu diğer işletmeler tarafından kullanılmak üzere bir hizmete dönüştürmek için, yeniden kullanılabilir bileşenlere hizmet vermek ve bunları hizmet kayıt defterine kaydetmek için SOA mimarisini kullanmak gerekir.

Varlıklı şirketler için, ticari ESB otobüsleri satın alabilirler veya Dubbo'yu bir hizmet kaydı olarak paketlemek için kullanabilirler.

Bir sonraki adım, hangilerinin kaldırılması gerektiğini düşünmektir. Son husus, onu nasıl ayıracağımızdır?

Bu iki sorunun cevapları farklı şirketler için farklıdır.Aslında iki aşamaya ayrılırlar.İlk aşama deneme aşamasıdır, yani tüm şirketin hizmet odaklı bölünmede deneyimi yoktur.Tabii ki, ana işle başlamaya cesaret edemezler ve genellikle seçerler Bir köşe işi için önce ona bir göz atalım. Yıkımın kendisi şu anda önemlidir. Aslında yıkım, yıkım uğruna yapılıyor. Yıkım daha ideal ve alan odaklı tasarıma uyuyor. Nasıl yıkılır? Tabii ki, bir veya iki ay sürer ve çekirdek çalışanlar, kapalı kapılar ardında gelişir, deneyim biriktirmek için onları ayırır ve birleştirir. Birçok şirket şu anda bu aşamada.

Ancak aslında, bu aşamadaki sökme yöntemi yalnızca deneyim biriktirmek için kullanılabilir, çünkü başlangıçta onu iş taleplerine hızlı bir şekilde yanıt vermek için bölmek istedik ve bu köşe modülü çoğu zaman en zahmetli temel iş değildir. Başlangıçta, iş sadece bir köşeydi ve sökmeden sökmenin pek bir faydası yoktu ve yeteneği yeniden kullanmanın bir yolu yoktu. Elbette yeniden kullanım temel yetenekleri yeniden kullanmak istiyor.

Yani aslında en önemlisi ikinci aşama, işin gerçek hizmet odaklı aşaması. Elbette, en çok iş gereksinimine sahip olan temel iş mantığı, iş taleplerine hızlı bir şekilde yanıt vermek ve yetenekleri yeniden kullanmak için kullanılabilir.

Örneğin, Koala aslında Oracle'ı kullanan ve harici olarak yalnızca bir çevrimiçi işi olan tek bir uygulamaydı ve gerçek ayrım, temel sipariş iş mantığı etrafında gerçekleştirildi.

Temel iş mantığından hangisi ayrılmalıdır? Pek çok şirket bize soracak, aslında şirketin kendi gelişimi en açık olanıdır.

Bu zamanda sıklıkla yapılan hata, ilk olarak temel iş mantığını monolitik uygulamadan ayırmaktır. Örneğin, sipariş mantığı, çevrimiçi hizmetten ayrılmış bir sipariş hizmetine dönüştürülür.

Tabii ki durum böyle olmamalı, mesela iki ordu savaşırken aşçılık ekibi askerleri içiyor Çin ordusu kampı taşınmalı mı yoksa aşçı timi taşınmalı mı? Tabii ki yemek pişirme dersi.

Bir başka nokta da, yeniden kullanılabilen bileşenlerin çoğu zaman temel iş mantığı olmamasıdır. Anlaşılması kolaydır. İki farklı işletmenin farklı temel iş mantığı vardır (veya bir iş haline gelir). Temel iş mantığı genellikle kombinasyonel mantıktır. Karmaşık olmasına rağmen, bir sipariş olsa bile çoğu zaman yeniden kullanılamaz. Farklı e-ticaret şirketleri de farklıdır, bu ne tür fasulyeler sunuyor, diğerinin sunduğu kupon ve diğer teklifler ne tür faaliyetler temel iş mantığında farklıdır ve sık sık değişecektir. Yeniden kullanılabilen şey genellikle kullanıcı merkezi, ödeme merkezi, depolama merkezi, envanter merkezi ve diğer temel işlerin çevresel mantığıdır.

Bu nedenle, bölme sırasında, bu çekirdek işlerin çevresel mantığı, ana faaliyet alanından ayrılmalıdır.Sonunda, Çevrimiçi, sipariş vermek için değiştirilebilen, sipariş vermek için temel yol kalmıştır. İş tarafı aniden panik satın alma aktivitesi başlatma ihtiyacı duyduğunda, çevreleyen mantığı hemen şimdi yeniden kullanabilir. Panik satın alma başka bir uygulamanın temel mantığı haline geldi.Aslında, temel mantık faks pinidir ve çevresel mantık verileri kaydetmek ve atomik bir arayüz sağlamaktır.

Öyleyse önce hangi çevresel mantık kaldırılmalıdır? Kendi gelişiminizi sorun.Kendilerini değiştirdikten sonra titreyen ve temel mantığı kırmaktan korkan gruplar, temel mantıktan ayrılmaya motive olurlar.Bu, teknik direktör ve mimarların denetlemesini gerektirmez, kendi Orijinal motivasyon çok doğal bir süreçtir.

Buradaki asıl motivasyon, geliştirme bağımsızlığı ve çevrimiçi bağımsızlıktır.Koala'nın çevrimiçi sisteminde olduğu gibi, depo ekibi, çeşitli depolama sistemleri ve dünya çapındaki pek çok depo ile bağlantı kurmaları gerektiğinden bağımsız olarak çıkmak istiyor. , Sistem çok geleneksel, arayüz farklı, yeni yerleştirme yok, geliştirme sırasında siparişin temel mantığının bozulup çevrimiçi kazalara neden olacağından endişe ediyorlar.Aslında depolama sistemi kendi yeniden deneme ve afet tolerans mekanizmasını tanımlayabilir. Emir çok ciddi. Lojistik ekibi ayrıca bağımsız olarak çıkmak istiyor çünkü bağlantı kuracak çok fazla lojistik şirketi var ve sık sık çevrimiçi olmaları gerekiyor ve siparişi kapatmak istemiyorlar.

Ayrıca şirketinizin iş mantığını da çözebilirsiniz ve bir orta ofis hizmeti oluşturmak için bölmek isteyeceğiniz işletmeler olacaktır.

Çevreleyen mantık bölündükten sonra, temel mantığın bir kısmı, sipariş verme ve ödeme gibi karşılıklı etkilenme korkusuyla bölünebilir. Ödeme birden fazla mükellefi ile kesildiğinde, sipariş vermeyi etkilemek istemezsiniz ve bağımsız olarak çıkabilirsiniz.

O zaman nasıl bölüneceğimiz sorusuna bakarız?

Bölünmenin öncülü, zamanlaması, yöntemi, spesifikasyonu vb. İle ilgili olarak makaleye bakın

Mikro hizmetlerin hizmet bölme ve hizmet keşfi

Yapılacak ilk şey, orijinal mühendislik kodunu standartlaştırmaktır. Biz buna genellikle "Herhangi bir modülü devralan herkes tanıdık bir yüz görebilir" diyoruz.

Örneğin bir java projesi açmak için aşağıdaki paketin olması gerekir:

API arayüz paketi: Tüm arayüz tanımları burada. Dahili çağrılar için arayüz de uygulanmalıdır, böylece bölündükten sonra yerel arayüz çağrıları uzak arayüz çağrılarına dönüştürülebilir
Harici hizmet paketlerine erişim: Bu süreç diğer süreçlere erişmek isterse, harici erişim paketleri burada yer alır. Ünite testi için, modelin bu kısmı, üçüncü bir tarafa güvenmeksizin işlevsel testi mümkün kılabilir. Servis bölme için diğer servisleri aramak da buradadır.
Veritabanı DTO: Veritabanına erişmek istiyorsanız, atomik veri yapısını burada tanımlayın
Access veritabanı paketi: Veritabanına erişim mantığı tamamen bu pakette
Hizmet ve iş mantığı: Ana iş mantığı burada uygulanır ve ayrım buradan da bölünür.
Harici servis: Harici servis sağlama mantığı buradadır ve arayüzün sağlayıcısı burada uygulanmalıdır.

Diğeri test klasörüdür.Her sınıfın birim testleri olmalıdır. Birim test kapsamını gözden geçirmek için, Mock yöntemi ile modül içerisinde entegrasyon testleri uygulanmalıdır.

Sırada konfigürasyon klasörü, konfigürasyon profili, konfigürasyon birkaç kategoriye ayrılmıştır:

Dahili yapılandırma öğeleri (başlangıçtan sonra değişmedi, değişikliğin yeniden başlatılması gerekiyor)
Merkezi konfigürasyon öğeleri (konfigürasyon merkezi, dinamik olarak verilebilir)
Dış yapılandırma öğeleri (dış bağımlılıklar ve çevreyle ilgili)

Bir projenin yapısı çok standart hale getirildiğinde, o zaman orijinal hizmette, önce bağımsız fonksiyonel modüller, girdi ve çıktıyı standartlaştırır ve hizmetin ayrılmasını oluşturur. Yeni işlemi ayırmadan önce yeni sürahiyi ayırın Yeni sürahi ayrılabildiği sürece, temelde gevşek bağlantı elde edilir.

Daha sonra, yeni bir proje oluşturmalı, yeni bir işlem başlatmalı, en kısa sürede kayıt defterine kayıt olmalı ve hizmet vermeye başlamalısınız.Şu anda, yeni projedeki kod mantığı ortadan kalkabilir, sadece orijinal süreç arayüzünü çağırın.

Bağımsızlık neden mümkün olan en kısa sürede yapılmalı? Mantık henüz uygulanmamış olsa bile? Hizmet bölme süreci kademeli olduğundan, yeni işlevlerin geliştirilmesi ve yeni gereksinimlerin ortaya çıkmasıyla birlikte, şu anda orijinal arayüzü değiştirmek için yeni gereksinimler olacaktır.İş mantığını ayırmak isterseniz bağımsız hale gelecektir. Zamanın yarısı yeni ihtiyaçlar geliyor.Eski ya da yeniyi değiştirmek uygun değil.Yeni bağımsız olarak hizmet vermiyor.Eski proje değiştirilirse eski projeden yeni projeye geçişe neden olacak.Taşarken birleşmesi daha zor olacak. Mümkün olan en kısa sürede bağımsız olursanız, tüm yeni gereksinimler yeni projeye girecektir.Tüm arayanlar güncellendiğinde, yeni süreci çağırmak için değiştirilecekler.Eski sürece yapılan çağrı gittikçe azalacak ve yeni süreç sonunda tüm eski süreçleri devredecektir.

Daha sonra, eski projedeki mantık kademeli olarak yeni projeye taşınabilir.Kod geçişi mantığın doğruluğunu garanti edemediğinden, sürekli entegrasyon ve gri sürüm gereklidir.Microservice çerçevesi yeni ve eski arayüzler arasında geçiş yapabilir.

Son olarak, yeni proje istikrarlı bir şekilde çalıştığında ve çağrı izlemede eski projeye çağrı olmadığında, eski proje çevrimdışı duruma getirilebilir.

3.3. Faz 2 işletme ve bakım modu

Hizmet odaklı iş katmanı, operasyon ve bakım ekibi üzerinde de baskı oluşturur.

Başvurular kademeli olarak bölünür ve hizmetlerin sayısı artar.

Hizmet bölmenin en iyi uygulamalarından biri, bölme işleminin tutarlı işlevleri sağlamak için sürekli entegrasyon gerektirmesidir.

Sürekli entegrasyon süreci genellikle test ortamlarının sık sık konuşlandırılmasını gerektirir.

Hizmetlerin bölünmesiyle, farklı iş geliştirme grupları farklı gereksinimler alacak, paralel geliştirme işlevleri artacak ve sık sürümler, test ortamında ve üretim ortamında daha sık dağıtımlarla sonuçlanacaktır.

Sık dağıtım, sanal makinelerin sık sık oluşturulmasını ve silinmesini gerektirir.

Yukarıdaki onay modeli hala benimsenirse, operasyon ve bakım departmanı bir darboğaz haline gelecektir veya geliştirme sürecini etkileyecek veya çeşitli dağıtımlar nedeniyle tükenecektir.

Bu, işletim ve bakım modelinde bir değişiklik, yani altyapının bulutlaştırılmasını gerektirir.

Sanallaştırmadan bulutlaştırmaya kadar olan fark nedir?

Her şeyden önce, merkezi işletim ve bakım yönetiminden kiracı self servis kullanım modunun dönüştürülmesine kadar iyi bir kiracı yönetimi olmalıdır.

Yani, manüel oluşturma, manüel programlama ve manüel konfigürasyonun merkezi yönetim modu bir darboğaz haline geldi, kiracı self servis yönetimi, otomatik makine planlaması ve otomatik konfigürasyon haline gelmelidir.

İkinci olarak, Kota ve QoS'ye dayalı kaynak kontrolü uygulamalıyız.

Yani, kiracı tarafından oluşturulan kaynakların kontrolü için, her şeyi manuel olarak yönetmek için operasyon ve bakımı iyileştirmeye gerek yoktur.Kiracı müşteriye atandığı, Kota atandığı ve Qos ayarlandığı sürece, kiracı sınırlı işletme ve bakım kapsamı dahilinde özgürce yapabilir. İşlem ve bakım bildirimi olmadan sanal makineler oluşturun, kullanın ve silin, böylece yineleme hızı artacaktır.

Üçüncüsü, sanal ağlara, VPC'ye ve SDN'ye dayalı ağ planlaması gerçekleştirilmelidir.

Orijinal ağ fiziksel bir ağ kullanıyordu. Sorun, fiziksel ağın tüm departmanlar tarafından paylaşılması ve bir işletme departmanı tarafından serbestçe yapılandırılamaması ve kullanılamamasıdır. Bu nedenle, VPC sanal ağı kavramı olmalıdır.Her kiracı kendi alt ağını, yönlendirme tablosunu ve harici ağa bağlantısını dilediği zaman yapılandırabilir.Farklı kiracıların ağ bölümleri çakışabilir ve birbirlerini etkilemez.Kiracılar kendi ihtiyaçlarına göre, Arayüzde ağ planlaması yapmak için yazılımı kullanın.

Bulut altyapısına ek olarak, işletim ve bakım departmanı da uygulamaların dağıtımını otomatikleştirmelidir.

Çünkü bulut bilişim uygulama ile ilgilenmiyorsa, genişletme veya otomatik dağıtım ihtiyacı olduğunda, bulut platformu tarafından oluşturulan sanal makine hala boştur ve çok meşgul olan işletim ve bakım ile manuel olarak dağıtılması gerekir. Bu nedenle, bulut platformunun da uygulamaları yönetmesi gerekir.

Bulut bilişim uygulamaları nasıl yönetir? Uygulamaları iki türe ayırırız, bunlardan biri genel amaçlı uygulamalar olarak adlandırılır ve genellikle veritabanları gibi herkes tarafından kullanılan bazı karmaşık uygulamalara atıfta bulunur. Hemen hemen tüm uygulamalar bir veritabanı kullanır, ancak veritabanı yazılımı standarttır.Kurulum ve bakım daha karmaşık olsa da, onu kimin yüklediği önemli değildir. Bu tür uygulamalar, bulut platformunun arayüzünde standart PaaS katman uygulamalarına dönüştürülebilir. Bir kullanıcı bir veritabanına ihtiyaç duyduğunda, bir noktada ortaya çıkar ve kullanıcı onu doğrudan kullanabilir.

Bu nedenle, işletim ve bakım modelindeki ikinci değişiklik, evrensel yazılımın PaaSization'udur.

Daha önce de belirtildiği gibi, geliştirme departmanında bu genel uygulamalardan sorumlu bir ara katman grubu vardır ve işletim ve bakım da bu uygulamaları otomatik olarak dağıtır.İki grup arasındaki sınır nedir?

Genel uygulama, bulut platformunun PaaS'sinin oluşturulan ara yazılımın kararlılığından sorumlu olmasıdır, SLA'yı garanti eder ve bir sorun olduğunda otomatik olarak onarır.

Geliştirme departmanının ara katman grubu, temel olarak bu PaaS'nin nasıl doğru şekilde kullanılacağını, hangi parametrelerin yapılandırılacağını, doğru duruşun kullanılacağını vb. İnceler. Bu işle ilgilidir.

Genel uygulamalara ek olarak, Puppet, Chef, Ansible, SaltStack vb. Araçlar gibi komut dosyaları aracılığıyla dağıtılması gereken kişiselleştirilmiş uygulamalar da vardır.

Burada, çıplak metal dağıtımının kullanılmasının önerilmediği bir uygulama vardır, çünkü bu dağıtım çok yavaştır ve sanal makine görüntülerine dayalı otomatik dağıtım önerilir. Bulut platformunda, herhangi bir sanal makinenin oluşturulması görüntüye dayanır.Görüntüde dağıtılacak ortamın çoğunu dağıtabiliriz ve yalnızca dağıtım aracı tarafından tamamlanan küçük bir özelleştirme yapmamız gerekir.

Aşağıdaki şekil OpenStack'in Isı tabanlı sanal makine düzenlemesini göstermektedir.Görüntüye dayalı bir sanal makine oluşturmak için OpenStack API'yi çağırmanın yanı sıra, sanal makinedeki aracıya özelleştirilmiş talimatlar yayınlaması için SaltStack yöneticisini de çağırır.

Sanal makine görüntüsü ve komut dosyası dağıtımına dayalı olarak, otomatikleştirilmiş bir dağıtım platformu NDP oluşturulabilir

Bu şekilde, orkestrasyon adı verilen sanal makine görüntüsüne dayalı olarak eksiksiz bir uygulama konuşlandırılabilir ve başlatılabilir. Düzenlemeye bağlı olarak, iyi sürekli entegrasyon gerçekleştirilebilir Örneğin, her gece bir ortam seti otomatik olarak dağıtılır ve değişikliğin doğruluğunu sağlamak için regresyon testi yapılır.

İkinci aşamadan sonra, tüm durum yukarıdaki şekilde gösterildiği gibidir.

Operasyon ve bakım departmanının fonksiyonları belli bir ölçüde değişmiştir.En temel kaynak yaratımına ek olarak self servis operasyon platformu, PaaS tabanlı ara katman yazılımı, görüntülere ve betiklere dayalı otomatik dağıtım da sağlanmaktadır.

Geliştirme departmanının işlevleri de bir dereceye kadar değişmiştir.Bölüm, ön uç grubu, iş geliştirme grubu, orta aşama grubu ve ara katman grubu olarak adlandırılır.Bunların arasında, ara katman birleşimi operasyon ve bakım departmanı en yakın olanıdır.

3.4. 2. Aşama ile ilgili herhangi bir sorun var mı?

Aslında, çoğu şirket problemlerinin çoğunu bu aşamada zaten çözebilir.

SOA tabanlı mimari ve bulut tabanlı altyapıya ulaşabilen şirketler, geleneksel endüstrilerde bilgi teknolojisi alanında zaten liderdir.

Orta istasyon geliştirme ekibi temelde orta istasyonun yeteneklerini yeniden kullanma sorununu çözebilir ve sürekli entegrasyon temelde çalışır, bu da iş geliştirme grubunun yineleme hızını önemli ölçüde hızlandırır.

Merkezi ara yazılım grubu veya mimari grubu, ileti kuyruklarını, önbellekleri ve diğer ara yazılımları merkezi olarak seçebilir, koruyabilir ve araştırabilir.

Bu aşamada, iş istikrarı gereksinimleri nedeniyle birçok şirket Oracle ticari veritabanlarını sorunsuz bir şekilde kullanmaya devam edecektir.

İkinci aşamada, sektörde zaten belirli bir rekabet avantajına sahibiz.

3.5 Hangi koşullar altında 2. Aşamada sorun olduğunu düşünüyorsunuz?

Geleneksel endüstriler artık bu sektördeki lider konumdan memnun olmadığında ve İnternet işine bağlanmayı umduğunda, yukarıdaki modelin yeni sorunlu noktaları olduğunu gördük.

İnternetin karşı karşıya olduğu en büyük sorun, çok sayıda kullanıcının getirdiği istek ve veri miktarının orijinalinin N katı olacağıdır, desteklenip desteklenemeyeceği konusunda herkes belirsizdir.

Örneğin, bazı müşteriler İnternet finans yönetimi flaş satın alımlarını başlattı ve orijinal mimari anlık trafiğin neredeyse yüz katını taşıyamadı.

Bazı müşteriler İnternet ödemesiyle veya hatta en büyük yurtiçi paket servisiyle bağlantı kurdular Orijinal ESB otobüsü en büyük ölçeğe (13 düğüm) genişletilse bile, bunu sürdüremeyebilir.

Bazı müşteriler hizmet sağlamak için Dubbo kullanmış olsalar da, füzyon, akım sınırlama ve küçültme hizmet yönetimi stratejisine sahip değillerdir.Bir talebin yavaş olması, yoğun dönemde geniş bir alana yayılması veya tüm taleplerin alınması ve sonuç olarak sürdürülememesi mümkündür. Bir parça asın.

Bazı müşteriler endüstriyel bir internet platformu uygulamak ister, ancak erişim verilerinin miktarı genellikle PB düzeyindedir ve taşınabilirse bu büyük bir sorundur.

Bazı müşteriler başlangıçta açık kaynak önbellekleri, mesaj kuyrukları ve dağıtılmış veritabanları kullandılar, ancak okuma ve yazma sıklığı belirli bir seviyeye ulaştığında, çeşitli garip ve tuhaf sorunlar ortaya çıkacak ve bunları nasıl ayarlayacaklarını bilmiyorlardı.

Bazı müşteriler, İnternet promosyon seviyesine ulaştıklarında, Oracle veritabanının kesinlikle bununla başa çıkamayacağını fark ederler.Oracle'dan DDB dağıtılmış veritabanına geçmeleri gerekir, ancak geçiş yöntemi ve geçişin nasıl kolaylaştırılacağı hakkında hiçbir fikirleri yoktur.

Bazı müşteri hizmetleri bölündükten sonra, orijinal atomik operasyon iki servis çağrısına bölünür.Atomikliğin nasıl korunacağı, hepsi başarılı olsun veya olmasın, dağıtılmış işlemler gerektirir.Sektörde çok sayıda dağıtılmış çözüm olmasına rağmen, Ancak yüksek eşzamanlı ödemeler taşıyabilecek bir çerçeve yoktur.

Bu sorunlar ortaya çıktığında, üçüncü aşamaya, yani mikro hizmetlere girmeyi düşünmeliyiz.

4. Aşama 3: DevOps organizasyonu, mikro hizmet mimarisi, kapsayıcıya alınmış altyapı

4.1. Aşama üç uygulama mimarisi

SOA'dan mikro hizmetlere geçiş çok kritiktir ve karmaşıklık nispeten yüksektir, bu nedenle başlarken dikkatli olmanız gerekir.

İnternetin yüksek eşzamanlılığını taşıyabilmek için, işin genellikle çok ince bir ayrıntıyla bölünmesi gerekir. Ne kadar iyi? Aşağıdaki resme bakalım.

Mikro hizmetleri kullanan bu tanınmış İnternet şirketlerinde, mikro hizmetler arasındaki karşılıklı aramalar birbiriyle yakından bir ağa bağlanmıştır ve neredeyse hiç organizasyon yoktur.

Neden bu ayrıntı düzeyine ayrılalım? Temelde yüksek eşzamanlılık talebi.

Ancak yüksek eşzamanlılık maliyetsiz değildir. Bu ayrıntı düzeyindeki sorun nedir? Sökme işlemi tamamlandığında, aşağıdaki önlemlerin hiçbirinin ihmal edilemeyeceğini göreceksiniz.

İşlevin aynı kalmasını sağlamak için nasıl bölünür ve hata oluşmaz - sürekli entegrasyon, referans
Mikro hizmetlerin temel taşı - sürekli entegrasyon
Statik kaynaklar, erişim katmanında veya CDN'de bölünmeli ve önbelleğe alınmalıdır ve trafiğin çoğu, kullanıcıya yakın kenar düğümünde veya erişim katmanı önbelleğinde kesilecektir.
Mikro hizmet erişim katmanı tasarımı ve dinamik ve statik kaynakların yalıtımı
Uygulamanın durumu iş mantığından ayrı tutulmalıdır, böylece iş durumsuzdur ve kapsayıcıya göre yatay olarak ölçeklenebilir.
Mikro hizmetlerin durum bilgisi ve kapsayıcılığı
Çekirdek iş ve çekirdek olmayan iş, çekirdek işin genişlemesini ve çekirdek olmayan işin düşürülmesini kolaylaştırmak için ayrılmalıdır, bkz.
Mikro hizmetlerin hizmet bölme ve hizmet keşfi
Veri tabanı ayrı olarak okunmalı ve yazılmalıdır ve veri tabanı tablolara bölünmelidir, böylece veri tabanı yatay olarak genişleyebilir ve büyük miktarda veri olması durumunda bir darboğaz haline gelmez.
Mikro hizmet odaklı veritabanı tasarımı ve okuma ve yazmanın ayrılması
Katman katman önbelleğe almak için, Çin askeri kamp veritabanına yalnızca küçük bir miktar trafik ulaşır.
Mikro hizmet önbelleğe alma tasarımı
Bir mesaj kuyruğu kullanmak için, daha önce sürekli olarak çağrılan birden çok hizmeti eşzamansız olarak bir dinleme mesajı kuyruğuna dönüştürün, böylece temel mantığı kısaltın
Servisler arasında sigorta, mevcut limit ve downgrade stratejileri ayarlanmalıdır.Çağrı engellendiğinde hızlı bir şekilde başarısız olmalı ve orada takılıp kalmamalıdır.Sağlık altı durumundaki hizmetler zincirleme reaksiyon olmadan zamanında sigortalanmalıdır. Çekirdek olmayan işlerin derecesinin düşürülmesi, artık çağrılmaması ve kaynakların çekirdek iş için ayrılması gerekiyor. Çağrı akışını basınçla ölçülen kapasite aralığı içinde sınırlamak için, hepsini bir kerede yerleştirip tüm sistemi yok etmektense yavaş işlemek daha iyidir.
Bölünmüş çok fazla hizmet var ve bunları tek tek yapılandırmanın bir yolu yok. Yapılandırmayı sağlamak için birleşik bir yapılandırma merkezine ihtiyaç var
Bölünmüş çok fazla hizmet var ve günlükleri tek tek görüntülemenin bir yolu yok. Günlükleri özetlemek için birleşik bir günlük merkezine ihtiyaç var
Çok fazla hizmet bölünmüştür ve performans darboğazını bulmak zordur.Performans darboğazını bulmak ve zamanında değiştirmek için APM tam bağlantı uygulamasını izlemek gerekir
Bölünmüş çok fazla hizmet var ve hiç kimse stres testi olmadan ne kadar dayanabileceğini bilemeyecek, bu nedenle tam bağlantılı bir stres testi sistemine ihtiyaç var.

Uygulama katmanının bu on iki sorunu ele alması gerekiyor. Sonuncusu göz ardı edilemez Mikro hizmetleri uygulamaya hazır mısınız? Springcloud'u kurtararak tüm bunları yapabileceğinizi gerçekten düşünüyor musunuz?

4.2. Üçüncü aşamanın işletme ve bakım modu

İşletmenin mikro hizmet dönüşümünden sonra işletme ve bakım modeline etkisi olacaktır.

İşletme böylesine ince bir ağa bölünürse, hizmetlerin sayısı çok büyük olacak ve her hizmet bağımsız olarak piyasaya sürülecek ve piyasaya sürülecek, bu nedenle çok sayıda sürüm olacak.

Bu ortam çok fazla olacak, manuel dağıtım artık mümkün değil, otomatik dağıtım uygulanmalıdır. Neyse ki, son aşamada, komut dosyası tabanlı veya ayna tabanlı otomatik dağıtım uyguladık, ancak mikro hizmet aşamasında sorunlar var.

Dağıtım komut dosyalarına dayanıyorsa, komut dosyaları başlangıçta işletim ve bakım tarafından yazılmıştır.Çok fazla hizmet ve değişiklik olduğu için komut dosyaları sürekli güncellenmelidir.Ve her şirketin operasyon ve bakım personelinden çok daha fazla geliştiricisi vardır ve işletim ve bakım için çok geçtir. Otomatik dağıtım için komut dosyalarını koruyun. Komut dosyası geliştiriciler tarafından yazılabilir mi? Genellikle uygulanabilir değildir.Geliştirme, işletim ortamına ilişkin sınırlı anlayışa sahiptir ve komut dosyaları için bir standart yoktur.İşletme ve bakım, geliştirme tarafından yazılan komut dosyalarının kalitesini kontrol edemez.

Sanal makine aynalama çok daha iyi olacaktır çünkü komut dosyalarıyla yapılacak daha az şey vardır ve uygulamanın yapılandırmasının çoğu aynaya yerleştirilir. Teslimat, sanal makine görüntüsüne dayanıyorsa, standart teslimatın etkisini de elde edebilir. Ve çevrimiçi olma konusunda bir sorun olduğunda, sanal makine görüntüsünün sürümüne bağlı olarak da geri alınabilir.

Ama sanal makine imajı çok büyük, her dönüşte yüzlerce gigabayt.Toplam yüz hizmet varsa ve her hizmetin günlük bir sürümü varsa, günde 10.000 gigabayt olacaktır. Bu depolama kapasitesi kimse tarafından karşılanamaz.

Şu anda konteyner işlevseldir. Yansıtma, konteynerlerin temel bir buluşu ve paketleme ve çalıştırma için bir standarttır.Diğer ad alanları ve gruplar uzun süredir mevcuttur.

İşletme ve bakıma yönelik orijinal geliştirme ve teslimat, bir savaş paketi, bir dizi yapılandırma dosyası ve bir dağıtım belgesidir, ancak dağıtım belgesi zaman içinde güncellenmediği için, genellikle işletim ve bakım dağıtımında hatalar meydana gelir. Bir konteyner imajı ile geliştirme ve teslimat bir konteyner imajıdır Konteyner içindeki işletim ortamı Dockerfile'a yansıtılmalıdır.Bu dosya geliştirilmeli ve yazılmalıdır.

Bu aşamada süreç açısından bakıldığında ortam konfigürasyonu ileri itilir ve geliştirmeye itilir.Geliştirme tamamlandıktan sonra mağaza sahibi olmak değil ortam yayılımı konusunu düşünmek gerekir. Konteyner imajı standart olduğu için betiklerin standartlaştırılamaması problemi yoktur.Tek konteyner çalışamazsa Dockerfile problemi olmalıdır.

Operasyon ve bakım ekibinin yalnızca konteyner platformunun bakımını yapması gerekir ve tek bir konteynerdeki ortam, bakım için geliştirmeye bırakılır. Bunun avantajı, belirli bir modülün geliştirme ekibi için birçok süreç, birçok konfigürasyon değişikliği ve sık güncelleme olmasına rağmen, bu miktarın çok az olmasıdır, çünkü 5-10 kişi bu modülün konfigürasyonunu sürdürme ve güncelleme konusunda uzmanlaşmıştır. hata yapmak kolay. Neyi değiştirdiğini biliyorsun.

Tüm bu iş yükleri az sayıda işletme ve bakım ekibine teslim edilirse, yalnızca bilgi aktarımı ortam yapılandırmasını tutarsız hale getirmekle kalmaz, dağıtım miktarı da çok büyük olur.

Konteynırın işlevlerinden biri, ortamı planlanandan önce sunmaktır, böylece her geliştirme yalnızca% 5 daha fazla iş yapabilir, bu da işletme ve bakım çalışmalarında% 200 tasarruf sağlayabilir ve hatalara meyilli değildir.

Konteynerin bir diğer işlevi de altyapının değiştirilememesidir.

Kapsayıcı aynalamasının bir özelliği, SSH tarafından üzerinde yapılan herhangi bir değişikliğin yeniden başlatıldıktan sonra kaybolması ve aynanın orijinal durumuna geri yüklenmesidir, bu da orijinal dağıtım ortamımızdaki kötü sorunları, bu değişikliği ve nihai dağıtım başarısını ortadan kaldırır.

Çünkü makine sayısı nispeten küçükse, bir şeyleri değiştirmek için her makineye giriş yapabilirsiniz.Bir hata oluştuğunda, sorunu gidermek daha kolaydır, ancak mikro hizmetler durumunda, ortam çok karmaşıktır ve ölçek çok büyüktür.Bir düğüm olduğunda, manuel değişiklik nedeniyledir.

DockerfileGittrack

4.3.

DevOpsDevOps