Not. tercüme: Bu makalenin yazarı (Luc Perkins), Linkerd, SMI (Service Mesh Interface) ve Kuma gibi Açık Kaynak projelerine ev sahipliği yapan CNCF organizasyonunda geliştirici savunucusudur (bu arada, Istio'nun neden olduğunu da merak ettiniz mi? bu listede yok mu? .). Bir kez daha DevOps topluluğunun "hizmet ağı" adı verilen modaya uygun heyecanı daha iyi anlamasını sağlamaya çalışırken, bu tür çözümlerin sağladığı 16 karakteristik yeteneği listeliyor.
bugün – yazılım mühendisliği alanındaki en sıcak konulardan biri (ve haklı olarak öyle!). Bu teknolojinin inanılmaz derecede umut verici olduğunu düşünüyorum ve geniş çapta benimsenmesini istiyorum (tabii ki mantıklı olduğunda). Ancak çoğu insan için hala bir gizem havasıyla çevrilidir. Aynı zamanda bunu yapanlar bile iyi bilinen Bununla birlikte, avantajlarını ve tam olarak ne olduğunu (sizinki de dahil olmak üzere) açıkça ifade etmek genellikle zordur. Bu yazıda çeşitli listeleyerek durumu düzeltmeye çalışacağım. kullanım durumları "hizmet ağları"*.
* Not çeviri: burada ve makalenin devamında tam olarak bu çeviri (“hizmet ağı”) hala yeni olan hizmet ağı terimi için kullanılacaktır.
Ama önce birkaç yorum yapmak istiyorum:
- Kendi eğitimim için başlattığım projeler dışında hiçbir zaman hizmet ağları ile çalışmadım veya bunları kullanmadım. Öte yandan, 2015 yılında Twitter'ın dahili hizmet ağı için bir sürü belge yazan (o zamanlar buna "hizmet ağı" bile denmiyordu) ve web sitesinin ve belgelerin geliştirilmesine katılan bendim. yani bunun bir anlamı var.
- Listem yaklaşıktır ve eksiktir. Benim bilmediğim kullanım durumları olabilir ve teknoloji geliştikçe ve popülaritesi arttıkça zaman içinde muhtemelen yeni seçenekler ortaya çıkacaktır.
- Aynı zamanda, mevcut her hizmet ağı uygulaması, listelenen kullanım durumlarının tümünü desteklemez. Bu nedenle, "hizmet ağı yapılabilir..." gibi ifadelerim "bireysel ve belki de tüm popüler hizmet ağı uygulamaları..." şeklinde okunmalıdır.
- Örneklerin sırası herhangi bir fark yaratmaz.
Kısa liste:
- hizmet keşfi;
- şifreleme;
- Kimlik doğrulama ve yetkilendirme;
- yük dengeleme;
- devre kesme;
- otomatik ölçeklendirme;
- kanarya konuşlandırmaları;
- mavi-yeşil dağıtımlar;
- sağlık kontrolü;
- yük atma;
- trafik yansıtma;
- yalıtım;
- istek hızı sınırlaması, yeniden denemeler ve zaman aşımları;
- telemetri;
- denetim;
- görselleştirme.
1. Hizmet keşfi
TL;DR: Basit adları kullanarak ağdaki diğer hizmetlere bağlanın.
Hizmetler, yeterli adları kullanarak birbirlerini otomatik olarak "bulabilmelidir" - örneğin, service.api.production, pets/staging veya cassandra. Bulut ortamları esnektir ve tek bir ad, bir hizmetin birçok örneğini gizleyebilir. Böyle bir durumda tüm IP adreslerini sabit kodlamanın fiziksel olarak imkansız olduğu açıktır.
Ayrıca, bir hizmet diğerini bulduğunda, bozuk örneğinin girişine düşeceği korkusu olmadan bu hizmete istek gönderebilmelidir. Başka bir deyişle, hizmet ağı tüm hizmet örneklerinin sağlığını izlemeli ve ana bilgisayarların listesini mümkün olduğunca güncel tutmalıdır.
Her hizmet ağı, hizmet bulma mekanizmasını farklı şekilde uygular. Şu anda en yaygın yol Kubernetes DNS gibi harici süreçlere yetki vermektir. Geçmişte Twitter'da bu amaçla bir adlandırma sistemi kullanıyorduk . Ek olarak, hizmet ağı teknolojisi, özel adlandırma mekanizmalarının ortaya çıkmasını mümkün kılmaktadır (her ne kadar henüz bu tür işlevselliğe sahip herhangi bir SM uygulaması görmemiş olsam da).
2. Şifreleme
TL;DR: Hizmetler arasındaki şifrelenmemiş trafikten kurtulun ve bu süreci otomatik ve ölçeklenebilir hale getirin.
Saldırganların dahili ağınıza giremeyeceğini bilmek güzel. Güvenlik duvarları bu konuda harika bir iş çıkarıyor. Peki bir bilgisayar korsanı içeri girerse ne olur? Hizmet içi trafikle istediğini yapabilecek mi? Umarız bundan sonra böyle bir durum yaşanmaz. Bu senaryoyu önlemek için hizmetler arasındaki tüm trafiğin şifrelendiği sıfır güven ağı uygulamanız gerekir. Çoğu modern hizmet ağı bunu karşılıklı olarak gerçekleştirir. (karşılıklı TLS, mTLS). Bazı durumlarda mTLS tüm bulutlarda ve kümelerde çalışır (gezegenler arası iletişimin bir gün benzer şekilde düzenleneceğini düşünüyorum).
Elbette mTLS hizmet ağı için isteğe bağlı. Her hizmet kendi TLS'sini halledebilir ancak bu, sertifika oluşturmanın, bunları hizmet ana bilgisayarlarına dağıtmanın ve bu sertifikaları dosyalardan yükleyecek kodu uygulamaya dahil etmenin bir yolunu bulmanız gerekeceği anlamına gelir. Evet, bu sertifikaları belirli aralıklarla yenilemeyi unutmayın. Hizmet ağları mTLS'yi aşağıdaki gibi sistemlerle otomatikleştirir bu da sertifikaların verilmesi ve döndürülmesi sürecini otomatikleştirir.
3. Kimlik doğrulama ve yetkilendirme
TL;DR: İstekte bulunanın kim olduğunu belirleyin ve istek hizmete ulaşmadan önce ne yapmasına izin verildiğini tanımlayın.
Hizmetler genellikle bilmek ister kim isteği gerçekleştirir (kimlik doğrulama) ve bu bilgiyi kullanarak karar verir o Belirli bir varlığın bunu yapmasına izin verilir (yetkilendirme). Bu durumda “kim” zamiri şunları gizleyebilir:
- Diğer servisler. Buna "kimlik doğrulama" denir akran" Örneğin, hizmet
webhizmete erişmek istiyordb. Hizmet ağları genellikle bu tür sorunları mTLS kullanarak çözer: bu durumda sertifikalar gerekli tanımlayıcı görevi görür. - Bazı insan kullanıcılar. Buna "kimlik doğrulama" denir rica etmek" Örneğin, kullanıcı
haxor69yeni bir lamba satın almak istiyor. Servis ağları çeşitli mekanizmalar sağlar; .Birçoğumuz bunu uygulama kodunda yaptık. Bir istek geliyor, masaya bakıyoruz
users, kullanıcıyı bulun ve şifreyi karşılaştırın, ardından sütunu kontrol edinpermissionsvesaire. Hizmet ağı söz konusu olduğunda bu, istek hizmete ulaşmadan önce gerçekleşir.
Talebin kimden geldiğini belirledikten sonra bu varlığın ne yapmasına izin verildiğini belirlememiz gerekir. Bazı hizmet ağları, temel ilkeleri (kimin ne yapabileceğine ilişkin) YAML dosyaları olarak veya komut satırında ayarlamanıza olanak tanırken, diğerleri gibi çerçevelerle entegrasyon sunar. . Nihai hedef, hizmetlerinizin güvenilir bir kaynaktan geldiğini varsayarak herhangi bir isteği güvenli bir şekilde kabul etmesidir. и bu eyleme izin verilir.
4. Yük dengeleme
TL;DR: Yükü hizmet örnekleri arasında belirli bir düzene göre dağıtın.
Bir hizmet bölümü içindeki bir “Hizmet” çoğunlukla birçok özdeş örnekten oluşur. Örneğin bugün hizmet cache 5 nüshadan oluşmaktadır ve yarın sayıları 11'e çıkabilir. cache, belirli bir amaca uygun olarak dağıtılmalıdır. Örneğin, gecikmeyi en aza indirin veya çalışan bir örneğe ulaşma olasılığını en üst düzeye çıkarın. En yaygın kullanılan algoritma Round-robin'dir, ancak başka birçok algoritma da vardır; örneğin ağırlıklı yöntem (ağırlıklı) sorgular (tercih edilen hedefleri seçebilirsiniz), zil sesi (yüzük) karma (yukarı akış ana bilgisayarları arasında tutarlı karma kullanarak) veya en az istek yöntemi (en az istek içeren örneğe tercih edilir).
Klasik dengeleyicilerin HTTP önbelleğe alma ve DDoS koruması gibi başka işlevleri vardır, ancak bunlar doğu-batı trafiğiyle (yani bir veri merkezi içinde akan trafik için - yaklaşık çeviri) (hizmet ağının tipik kapsamı) pek alakalı değildir. Elbette, yük dengeleme için bir hizmet ağının kullanılması gerekli değildir, ancak her hizmet için dengeleme politikalarını merkezi bir kontrol katmanından ayarlamanıza ve kontrol etmenize olanak tanır, böylece ağ yığınında ayrı yük dengeleyicileri çalıştırma ve yapılandırma ihtiyacını ortadan kaldırır. .
5. Devrenin kesilmesi
TL;DR: Sorunlu hizmete giden trafiği durdurun ve en kötü senaryolarda hasarı kontrol edin.
Hizmet herhangi bir nedenle trafikle baş edemiyorsa, hizmet ağı bu sorunu çözmek için çeşitli seçenekler sunar (diğerleri uygun bölümlerde tartışılacaktır). Devre kesme, bir hizmetin trafikle bağlantısını kesmenin en ciddi seçeneğidir. Ancak tek başına bir anlam ifade etmiyor; bir yedekleme planına ihtiyaç var. Geri basınç sağlanabilir () istekte bulunan hizmetlere (sadece bunun için hizmet ağınızı yapılandırmayı unutmayın!) veya örneğin durum sayfasını kırmızıya boyamak ve kullanıcıları “düşen balina” ile sayfanın başka bir sürümüne yönlendirmek (“Twitter aşağı").
Servis ağları yalnızca tanımlamanıza izin vermekle kalmaz zaman kapatma takip edecek ve o bu takip edecek. Bu durumda, "ne zaman" belirtilen parametrelerin herhangi bir kombinasyonunu içerebilir: belirli bir süre için toplam istek sayısı, paralel bağlantıların sayısı, bekleyen istekler, etkin yeniden denemeler vb.
Muhtemelen devre kesmeyi kötüye kullanmak istemezsiniz, ancak acil durumlarda bir yedek planınızın olduğunu bilmek güzel.
6. Otomatik ölçeklendirme
TL;DR: Belirtilen kriterlere bağlı olarak hizmet örneklerinin sayısını artırın veya azaltın.
Hizmet ağları zamanlayıcı değildir, dolayısıyla gerçekleştirmek kendinizi ölçeklendiriyorsunuz. Ancak planlamacıların kararlarını hangi temele dayandıracakları konusunda bilgi sağlayabilirler. Hizmet ağları, hizmetler arasındaki tüm trafiğe erişime sahip olduğundan, neler olup bittiğine dair kapsamlı bilgiye sahiptirler: hangi hizmetlerde sorun yaşanıyor, hangi hizmetler çok hafif yükleniyor (bunlara ayrılan kapasite boşa gidiyor), vb.
Örneğin Kubernetes, hizmetleri bölmelerin CPU ve bellek kullanımına göre ölçeklendirir (raporumuza bakın "" - yakl. çeviri.), ancak başka herhangi bir metriğe (bizim durumumuzda trafikle ilgili) dayalı olarak ölçeklendirme yapmaya karar verirseniz, özel bir metriğe ihtiyacınız olacaktır. Yönetmek bunun nasıl yapılacağını gösterir , и , ancak sürecin kendisi oldukça karmaşıktır. Hizmet ağının, "hizmet örneklerinin sayısını artırın" gibi koşulları basitçe ayarlamamıza izin vererek bunu basitleştirmesini istiyoruz. authBekleyen isteklerin sayısı bir dakika içinde eşiği aşarsa."
7. Kanarya konuşlandırmaları
TL;DR: Yeni özellikleri veya hizmet sürümlerini bir kullanıcı alt kümesinde test edin.
Diyelim ki bir SaaS ürünü geliştiriyorsunuz ve bunun yeni ve harika bir sürümünü piyasaya sürmeyi planlıyorsunuz. Aşamalandırmada test ettiniz ve harika çalıştı. Ancak gerçek koşullardaki davranışlarıyla ilgili hala bazı endişeler var. Yani kullanıcı güvenini riske atmadan yeni sürümü gerçek sorunlar üzerinde test etmeniz gerekiyor. Kanarya dağıtımları bunun için mükemmeldir. Bir kullanıcı alt kümesine yeni bir özellik göstermenize olanak tanır. Bu alt küme, en sadık kullanıcılardan veya ürünün ücretsiz sürümüyle çalışanlardan veya "kobay" olma arzusunu dile getiren kullanıcılardan oluşabilir.
Hizmet ağları, uygulamanın hangi sürümünü kimin göreceğini belirleyen kriterleri belirtmenize ve trafiği buna göre yönlendirmenize olanak tanıyarak bunu gerçekleştirir. Ancak hizmetlerin kendisinde hiçbir şey değişmiyor. Hizmetin 1.0 sürümü, tüm isteklerin onu görmesi gereken kullanıcılardan geldiğine inanırken, 1.1 sürümü de kullanıcıları için aynı olduğuna inanıyor. Bu arada, eski ve yeni sürümler arasındaki trafik yüzdesini değiştirebilir, istikrarlı bir şekilde çalışıyorsa ve "kobaylarınız" onay verirse artan sayıda kullanıcıyı yeni sürüme yönlendirebilirsiniz.
8. Mavi-yeşil dağıtımlar
TL;DR: Harika yeni bir özelliği kullanıma sunuyoruz, ancak her şeyi anında geri almaya hazır olun.
Anlam eski "yeşil" hizmete paralel olarak yeni bir "mavi" hizmet başlatacak. Her şey yolunda giderse ve yeni hizmet iyi performans gösterirse eski hizmet yavaş yavaş devre dışı bırakılabilir. (Ne yazık ki, bir gün bu yeni "mavi" hizmet, "yeşil" hizmetin kaderini tekrarlayacak ve ortadan kaybolacak...) Mavi-yeşil dağıtımlar, yeni işlevin aşağıdakileri kapsaması bakımından kanarya dağıtımlarından farklıdır: hepsi birden kullanıcılar (parça değil); Burada önemli olan bir şeylerin ters gitmesi ihtimaline karşı bir “güvenli liman”ın hazır olması.
Servis ağları, "mavi" bir hizmeti test etmek ve sorun olması durumunda anında çalışan "yeşil" bir hizmete geçmek için çok uygun bir yol sunar. Yol boyunca "mavi" nin çalışması hakkında pek çok bilgi sağladıklarından (aşağıdaki "Telemetri" bölümüne bakın) ve bu da onun tam çalışmaya hazır olup olmadığının anlaşılmasına yardımcı olduğundan bahsetmiyorum bile.
Not. tercüme: Kubernetes'teki farklı dağıtım stratejileri hakkında daha fazla bilgiyi (bahsedilen kanarya, mavi/yeşil ve diğerleri dahil) şurada bulabilirsiniz: .
9. Sağlık kontrolü
TL;DR: Hangi hizmet örneklerinin işlevsel olduğunu takip edin ve artık işlevsel olmayanlara yanıt verin.
Sağlık kontrolü (sağlık kontrolü) hizmet örneklerinin trafiği kabul etmeye ve işlemeye hazır olup olmadığına karar vermeye yardımcı olur. Örneğin, HTTP hizmetleri söz konusu olduğunda, bir durum denetimi, uç noktaya gönderilen bir GET isteği gibi görünebilir. /health... Cevap 200 OK örneğin sağlıklı olduğu anlamına gelir, diğerleri ise trafik almaya hazır olmadığı anlamına gelir. Servis ağları, hem işlevselliğin kontrol edilme şeklini hem de bu kontrolün gerçekleştirilme sıklığını belirtmenize olanak tanır. Bu bilgiler daha sonra başka amaçlarla (örneğin, yük dengeleme ve devre kesme) kullanılabilir.
Bu nedenle, durum kontrolü tek başına bir kullanım durumu değildir, genellikle başka hedeflere ulaşmak için kullanılır. Ayrıca durum kontrollerinin sonuçlarına bağlı olarak diğer hizmet ağ hedeflerinin dışında eylemler de gerekli olabilir: örneğin durum sayfasını güncellemek, GitHub'da sorun oluşturmak veya bir JIRA bileti doldurmak. Ve servis ağı tüm bunları otomatikleştirmek için kullanışlı bir mekanizma sunuyor.
10. Yük atma
TL;DR: Kullanımdaki geçici artışa yanıt olarak trafiği yeniden yönlendirin.
Belirli bir hizmetin trafiği aşırı yüklüyse, bu trafiğin bir kısmını geçici olarak başka bir konuma yönlendirebilirsiniz (yani "döküm", "aktarma") (baraka) o orada). Örneğin bir yedekleme hizmetine veya veri merkezine ya da kalıcı bir başlık. Sonuç olarak hizmet, çökmek ve her şeyin işlenmesini tamamen durdurmak yerine bazı istekleri işlemeye devam edecek. Devreyi kırmak yerine yükün azaltılması tercih edilir, ancak yine de kötüye kullanılması tavsiye edilmez. Aşağı akış hizmetlerinin çökmesine neden olan basamaklı arızaların önlenmesine yardımcı olur.
11. Trafik paralelleştirme/yansıtma
TL;DR: Bir isteği aynı anda birden fazla yere gönderin.
Bazen bir isteğin (veya belirli bir istek seçiminin) birden fazla hizmete aynı anda gönderilmesi gerekebilir. Tipik bir örnek, üretim trafiğinin bir kısmının bir hazırlama hizmetine gönderilmesidir. Ana üretim web sunucusu, alt hizmete bir istek gönderir products.production ve sadece ona. Ve hizmet ağı bu isteği akıllı bir şekilde kopyalar ve products.stagingWeb sunucusunun farkında bile olmadığı bir şey.
Trafik paralelleştirmesinin yanı sıra uygulanabilecek bir başka ilgili hizmet ağı kullanım durumu da şudur: . Aynı isteklerin hizmetin farklı sürümlerine gönderilmesini ve tüm sürümlerin aynı şekilde davranıp davranmadığını kontrol etmeyi içerir. Henüz entegre bir regresyon test sistemine sahip bir hizmet ağı uygulamasına rastlamadım. , ancak fikrin kendisi umut verici görünüyor.
12. Yalıtım
TL;DR: Hizmet ağınızı mini ağlara bölün.
Ayrıca şöyle bilinir segmentasyonYalıtım, bir hizmet ağını birbirleri hakkında hiçbir şey bilmeyen, mantıksal olarak farklı bölümlere ayırma sanatıdır. İzolasyon biraz sanal özel ağlar oluşturmaya benzer. Temel fark, bir hizmet ağının (hizmet keşfi gibi) tüm avantajlarından ek güvenlikle yararlanmaya devam edebilmenizdir. Örneğin, bir saldırgan bir alt ağdaki bir hizmete girmeyi başarırsa, diğer alt ağlarda hangi hizmetlerin çalıştığını göremez veya trafiğine müdahale edemez.
Ayrıca faydalar organizasyonel de olabilir. Hizmetlerinizi şirket yapınıza göre alt ağlara ayırmak ve geliştiricileri tüm hizmet ağını akılda tutma zorunluluğunun bilişsel yükünden kurtarmak isteyebilirsiniz.
13. İstek hızı sınırlaması, yeniden denemeler ve zaman aşımları
TL;DR: Artık kod tabanınıza ayrıntılı istek yönetimi görevlerini eklemenize gerek yok.
Bunların hepsi ayrı kullanım durumları olarak düşünülebilir, ancak ortak bir özellik nedeniyle bunları birleştirmeye karar verdim: genellikle uygulama kitaplıkları tarafından gerçekleştirilen istek yaşam döngüsü yönetimi görevlerini üstleniyorlar. Ruby on Rails'de (hizmet ağıyla entegre olmayan) arka uç hizmetlerine istekte bulunan bir web sunucusu geliştiriyorsanız N isteğin başarısız olması durumunda uygulamanın ne yapacağına karar vermesi gerekecektir. Ayrıca, bu hizmetlerin ne kadar trafiği işleyebileceğini ve özel bir kütüphane kullanarak bu parametreleri kodlayabileceğini de öğrenmeniz gerekecektir. Ayrıca uygulamanın ne zaman pes etme zamanının geldiğine karar vermesi ve isteğin (zaman aşımına bağlı olarak) sonuçsuz kalmasına izin vermesi gerekecektir. Yukarıdaki parametrelerden herhangi birini değiştirmek için web sunucusunun durdurulması, yeniden yapılandırılması ve yeniden başlatılması gerekecektir.
Bu görevleri bir hizmet ağına aktarmak, yalnızca hizmet geliştiricilerinin bunlar hakkında düşünmek zorunda kalmayacağı anlamına gelmez, aynı zamanda bunların daha küresel bir şekilde görüntülenebileceği anlamına da gelir. A -> B -> C -> D -> E gibi karmaşık bir hizmet zinciri kullanılıyorsa, isteğin tüm yaşam döngüsü dikkate alınmalıdır. Görev, C hizmetindeki zaman aşımlarını uzatmaksa, bunu parçalar halinde değil, tek seferde yapmak mantıklıdır: hizmet kodunu güncelleyerek ve çekme isteği kabul edilene ve CI sistemi güncellenen hizmeti dağıtana kadar bekleyerek.
14. Telemetri
TL;DR: Hizmetlerden gerekli (ve tam olarak değil) tüm bilgileri toplayın.
Telemetri, ölçümleri, dağıtılmış izlemeyi ve günlükleri içeren genel bir terimdir. Hizmet ağları, her üç veri türünün de toplanması ve işlenmesi için mekanizmalar sunar. Olası seçeneklerin sayısı çok fazla olduğundan işlerin biraz bulanıklaştığı yer burasıdır. Metrikleri toplamak için ve günlükleri toplamak için kullanılabilecek diğer araçlar , , vb (örneğin ClickHouse ile K8'ler için - yakl. çeviri.)dağıtılmış izleme için ve benzeri. Her hizmet ağı bazı araçları destekleyebilir, bazılarını desteklemeyebilir. Projenin başarılı olup olmayacağını görmek ilginç olacak bir miktar yakınlaşma sağlar.
Bu durumda servis ağı teknolojisinin avantajı, sepet konteynerlerinin prensipte yukarıdaki tüm verileri hizmetlerinden toplayabilmesidir. Başka bir deyişle, emrinizde tek bir telemetri toplama sistemi vardır ve hizmet ağı tüm bu bilgileri çeşitli şekillerde işleyebilir. Örneğin:
- CLI'deki belirli bir hizmetin kuyruk günlükleri;
- hizmet ağı kontrol panelinden isteklerin hacmini izlemek;
- Dağıtılmış izleri toplayın ve bunları Jaeger gibi bir sisteme iletin.
Dikkat, öznel yargı: Genel olarak konuşursak, telemetri, servis ağından gelen güçlü müdahalenin istenmediği bir alandır. Temel bilgileri toplamak ve istek başarı oranı ve gecikme gibi bazı altın ölçümleri anında izlemek iyidir, ancak umarız, bazıları zaten kendini kanıtlamış ve iyi çalışılmış özel sistemlerin yerini almaya çalışan Frankenstein yığınlarının ortaya çıktığını görmeyiz. .
15. Denetim
TL;DR: Tarihin derslerini unutanlar, onları tekrar etmeye mahkumdur.
Denetim, bir sistemdeki önemli olayları gözlemleme sanatıdır. Hizmet ağı söz konusu olduğunda bu, belirli hizmetler için belirli uç noktalara kimin istekte bulunduğunu veya geçen ay güvenlikle ilgili bazı olayların kaç kez meydana geldiğini takip etmek anlamına gelebilir.
Denetimin telemetri ile çok yakından ilişkili olduğu açıktır. Aradaki fark, telemetrinin genellikle üretkenlik ve teknik bütünlük gibi şeylerle ilişkilendirilmesi, denetimin ise tam anlamıyla teknik alanın ötesine geçen hukuki ve diğer konularla (örneğin, GDPR - veri korumaya ilişkin AB Genel Yönetmeliği) uyumlulukla ilgili olabilmesidir.
16. Görselleştirme
TL;DR: Yaşasın React.js - tükenmez bir şık arayüz kaynağı.
Daha iyi bir terim olabilir ama bilmiyorum. Sadece bir hizmet ağının veya bazı bileşenlerinin grafiksel temsilini kastediyorum. Bu görselleştirmeler ortalama gecikmeler, sepet yapılandırma bilgileri, durum kontrolü sonuçları ve uyarılar gibi göstergeleri içerebilir.
Hizmet odaklı bir ortamda çalışmak Majesteleri Monolith'e kıyasla çok daha yüksek bir bilişsel yük gerektirir. Bu nedenle bilişsel baskı ne pahasına olursa olsun azaltılmalıdır. Bir düğmeye tıklama ve istenen sonucu alma becerisine sahip bir hizmet ağı için basit bir grafik arayüz, bu teknolojinin popülaritesinin artmasında belirleyici olabilir.
Listeye dahil edilmedi
Başlangıçta listeye birkaç kullanım örneği daha eklemeyi düşünüyordum ama sonra yapmamaya karar verdim. İşte kararımın nedenleri ile birlikte:
- Çoklu veri merkezi. Bana göre bu, hizmet ağlarının veya hizmet keşfi gibi bazı işlevlerin dar ve spesifik bir uygulama alanı olarak pek de bir kullanım durumu değildir.
- Giriş ve çıkış. Bu ilgili bir alandır, ancak kendimi (belki de yapay olarak) "doğu-batı trafiği" kullanım durumuyla sınırladım. Giriş ve çıkış ayrı bir makaleyi hak ediyor.
Sonuç
Şimdilik bu kadar! Tekrar ediyorum, bu liste oldukça keyfidir ve büyük olasılıkla eksiktir. Bir şeyi kaçırdığımı veya yanlış anladığımı düşünüyorsanız lütfen benimle Twitter'dan iletişime geçin (). Lütfen nezaket kurallarına saygı gösterin.
çevirmenden PS
Makalenin başlık illüstrasyonu makaledeki bir görsele dayanmaktadır:"(Gregory MacKinnon tarafından). Uygulamalardaki bazı işlevlerin (yeşil), aralarındaki bağlantıları sağlayan bir hizmet ağına (mavi) nasıl taşındığını gösterir.
Blogumuzda da okuyun:
- «";
- «";
- «'.
Kaynak: habr.com
