Mikro hizmetler tasarlama: Sürekli tümleştirmeDesigning microservices: Continuous integration

Sürekli tümleştirme ve sürekli teslim (CI/CD), mikro hizmetler ile başarı elde etmek için önemli bir gereksinim olan.Continuous integration and continuous delivery (CI/CD) are a key requirement for achieving success with microservices. İyi bir CI/CD işlem, taahhüt mikro hizmet çevikliği elde etmez.Without a good CI/CD process, you will not achieve the agility that microservices promise. Mikro hizmetler için CI/CD sorunlarından bazıları, birden çok kod tabanları ve heterojen yapı ortamları için çeşitli Hizmetleri kalmamasını ortaya çıkar.Some of the CI/CD challenges for microservices arise from having multiple code bases and heterogenous build environments for the various services. Bu bölümde sorunlarını açıklar ve sorun için aşağıdaki yaklaşımlardan önerir.This chapter describes the challenges and recommends some approaches to the problem.

Mikro hizmetler için CI/CD diyagramı

Yayın döngüleri daha hızlı mikro hizmet mimarisi benimsemek için büyük nedenleri biridir.Faster release cycles are one of the biggest reasons to adopt a microservices architecture.

Yalnızca tek parçalı bir uygulamada uygulama yürütülebilir çıktısı olan bir tek bir derleme işlem hattı yok.In a purely monolithic application, there is a single build pipeline whose output is the application executable. Bu ardışık düzen halinde, tüm geliştirme iş akışları.All development work feeds into this pipeline. Yüksek öncelikli hata bulunursa, bir düzeltme gerekir tümleşik test ve yayımlanan hangi yeni özellikler sürümü erteleyebilirsiniz.If a high-priority bug is found, a fix must be integrated, tested, and published, which can delay the release of new features. Katsayıları iyi belirlenmiş modüllerine sahip olmak ve kod değişikliklerinin etkisini en aza indirmek için özellik dalları kullanarak bu sorunları azaltabilirsiniz geçerlidir.It's true that you can mitigate these problems by having well-factored modules and using feature branches to minimize the impact of code changes. Ancak uygulama daha karmaşık büyür ve daha fazla özellik eklenir monoliti sürüm sürecini daha kırılır ve ayırmak büyük olasılıkla eğilimindedir.But as the application grows more complex, and more features are added, the release process for a monolith tends to become more brittle and likely to break.

Mikro hizmet felsefesi hiçbir zaman olmalıdır satır almak için her takım sahip olduğu bir uzun yayın eğitimi.Following the microservices philosophy, there should never be a long release train where every team has to get in line. Birleştirilecek, "B" hizmetindeki değişiklikler için beklemenize gerek kalmadan herhangi bir zamanda bir güncelleştirme "A" serbest bırakabilirsiniz service'ı oluşturan ekip, test ve dağıtılabilir.The team that builds service "A" can release an update at any time, without waiting for changes in service "B" to be merged, tested, and deployed. CI/CD işlem, bunu mümkün kılmak için önemlidir.The CI/CD process is critical to making this possible. Güncelleştirmeleri dağıtmak riskleri simge durumuna küçültülmüş böylece yayın işlem hattınızı otomatik ve yüksek oranda güvenilir olması gerekir.Your release pipeline must be automated and highly reliable, so that the risks of deploying updates are minimized. Üretim için günlük veya günde birden çok kez yayınlıyorsanız gerilemeleri ya da hizmet kesintilerine nadiren olmalıdır.If you are releasing to production daily or multiple times a day, regressions or service disruptions must be very rare. Aynı zamanda, hatalı bir güncelleştirme dağıtılsın, hızlı bir şekilde geri veya ileri bir hizmetin bir önceki sürüme geri alma için güvenilir bir yol olmalıdır.At the same time, if a bad update does get deployed, you must have a reliable way to quickly roll back or roll forward to a previous version of a service.

CI/CD monoliti diyagramı

Biz CI/CD hakkında konuşurken, biz aslında ilgili çeşitli işlemleri hakkında varsayılır: Sürekli tümleştirme, sürekli teslim ve sürekli dağıtım.When we talk about CI/CD, we are really talking about several related processes: Continuous integration, continuous delivery, and continuous deployment.

  • Sürekli tümleştirme, kod değişikliklerini sık otomatik yapı kullanarak ana dalla birleştirilir ve ana dalda kod her zaman üretim kalitesinde olduğunu sağlamak için süreçleri test anlamına gelir.Continuous integration means that code changes are frequently merged into the main branch, using automated build and test processes to ensure that code in the main branch is always production-quality.

  • Sürekli teslim, CI işlem geçen kod değişiklikleri, bir üretim ortamına benzer otomatik olarak yayımlanır anlamına gelir.Continuous delivery means that code changes that pass the CI process are automatically published to a production-like environment. Canlı üretim ortamına dağıtım el ile onayı gerektirir, ancak aksi otomatik.Deployment into the live production environment may require manual approval, but is otherwise automated. Kodunuzun her zaman olmalıdır amaçtır hazır üretime dağıtmak için.The goal is that your code should always be ready to deploy into production.

  • Sürekli dağıtım, CI/CD işlem geçen kod değişiklikleri otomatik olarak üretime dağıtılır anlamına gelir.Continuous deployment means that code changes that pass the CI/CD process are automatically deployed into production.

Kubernetes ve mikro hizmetler bağlamında CI aşama bu görüntüleri bir kapsayıcı kayıt defterine gönderme oluşturmayı ve kapsayıcı görüntüleri test ile ilgilidir.In the context of Kubernetes and microservices, the CI stage is concerned with building and testing container images, and pushing those images to a container registry. Dağıtım aşamasında, en son üretim görüntüyü çekmek için pod özellikleri güncelleştirilir.In the deployment stage, pod specs are updated to pick up the latest production image.

ZorluklarChallenges

  • Birçok küçük bağımsız kod tabanları.Many small independent code bases. Her takımın kendi hizmetiyle, kendi derleme işlem hattı oluşturmak için sorumludur.Each team is responsible for building its own service, with its own build pipeline. Bazı Kurumlarda, takımlar ayrı kod depoları kullanabilir.In some organizations, teams may use separate code repositories. Bu, burada sistem oluşturma konusunda bilgi takımlar arasında yayılır ve kimse kuruluş içindeki tüm uygulama dağıtmak bildiği bir durum neden olabilir.This could lead to a situation where the knowledge of how to build the system is spread across teams, and nobody in the organization knows how to deploy the entire application. Örneğin, hızlı bir şekilde yeni bir kümeye dağıtmak ihtiyacınız varsa ne bir olağanüstü durum kurtarma senaryosunda olur?For example, what happens in a disaster recovery scenario, if you need to quickly deploy to a new cluster?

  • Birden çok dil ve çerçeveleri.Multiple languages and frameworks. Her takıma kendi teknoloji harmanı kullanarak, kuruluş genelinde çalışır bir tek bir yapı işlemi oluşturmak zor olabilir.With each team using its own mix of technologies, it can be difficult to create a single build process that works across the organization. Derleme işlemi, tüm takımlar, kendi seçtikleri dil veya çerçeve için uyum kadar esnek olması gerekir.The build process must be flexible enough that every team can adapt it for their choice of language or framework.

  • Tümleştirme ve yük testi.Integration and load testing. Kendi belirlediğiniz hızda güncelleştirmeler takımlarla sağlam-test etme, özellikle Hizmetleri bağımlılıkları diğer hizmetlere sahip olduğunda uca tasarlamak için zor olabilir.With teams releasing updates at their own pace, it can be challenging to design robust end-to-end testing, especially when services have dependencies on other services. Her takım testi için üretim ölçekler, kendi tam kümesini çalıştırın mümkün olacağını tahmin edilemez, bu nedenle Ayrıca, bir tam üretim kümesini çalıştırmak pahalı olabilir.Moreover, running a full production cluster can be expensive, so it's unlikely that every team will be able to run its own full cluster at production scales, just for testing.

  • Sürüm Yönetimi.Release management. Her takım bir güncelleştirme üretime dağıtma özelliği olmalıdır.Every team should have the ability to deploy an update to production. Bu, her ekip üyesi, bunu yapmak için izinlere sahip olduğundan gelmez.That doesn't mean that every team member has permissions to do so. Ancak bir merkezi sürüm Yöneticisi rolüne sahip dağıtımları hızını azaltabilir.But having a centralized Release Manager role can reduce the velocity of deployments. Daha fazla, CI/CD işlem otomatik ve güvenilir, az orada olması gereken bir yönetim yetkilisi gereksinimini.The more that your CI/CD process is automated and reliable, the less there should be a need for a central authority. Küçük hata düzeltmeleri ile karşılaştırması büyük özellik güncelleştirmeleri serbest bırakmak için farklı ilkeler olabilir. Bununla birlikte.That said, you might have different policies for releasing major feature updates versus minor bug fixes. Merkeze bağlı sıfır idare olmalıdır anlamına gelmez.Being decentralized does not mean there should be zero governance.

  • Kapsayıcı görüntü sürüm.Container image versioning. Geliştirme ve test döngüsü sırasında çok sayıda kapsayıcı görüntülerini CI/CD işlem oluşturacaksınız.During the development and test cycle, the CI/CD process will build many container images. Bazıları, sürüm için aday niteliği yalnızca ve yalnızca bazı bu sürüm adayları, üretime gönderilen.Only some of those are candidates for release, and then only some of those release candidates will get pushed into production. Hangi görüntüleri şu anda üretim ortamına dağıtılır ve gerekiyorsa, önceki bir sürüme geri dönebilirsiniz öğrenmek için bir açık sürüm oluşturma stratejisi olmalıdır.You should have a clear versioning strategy, so that you know which images are currently deployed to production, and can roll back to a previous version if necessary.

  • Hizmet güncelleştirmeleri.Service updates. Bir hizmetin yeni bir sürüme güncelleştirdiğinizde, bağımlı diğer hizmetleri sonu olmamalıdır.When you update a service to a new version, it shouldn't break other services that depend on it. Sıralı bir güncelleştirme Bunu yaparsanız, bir süre boyunca bir karışımını sürümleri çalışırken olacaktır.If you do a rolling update, there will be a period of time when a mix of versions is running.

Bu zorluklar bir temel gerilimi yansıtır.These challenges reflect a fundamental tension. Bir yandan takımların mümkün olduğunca bağımsız olarak çalışması gerekir.On the one hand, teams need to work as independently as possible. Öte yandan, böylece tek bir kişi bir tümleştirme testi çalıştıran yeni bir küme için tüm çözümü yeniden dağıtmak ya da hatalı bir güncelleştirme geri alma gibi görevleri yapmak için bazı koordinasyon gereklidir.On the other hand, some coordination is needed so that a single person can do tasks like running an integration test, redeploying the entire solution to a new cluster, or rolling back a bad update.

Mikro hizmetler için CI/CD yaklaşımlarıCI/CD approaches for microservices

Yapı ortamlarının kapsayıcılı hale getirme tüm hizmet takımlar için iyi bir uygulamadır.It's a good practice for every service team to containerize their build environment. Bu kapsayıcıdaki tüm hizmet için kod yapıları oluşturmak için gereken derleme araçları olması gerekir.This container should have all of the build tools necessary to build the code artifacts for their service. Genellikle, dil ve çerçeve için resmi bir Docker görüntüsü bulabilirsiniz.Often you can find an official Docker image for your language and framework. Kullanabileceğiniz sonra docker run ya da yapıyı çalıştırmak için Docker Compose.Then you can use docker run or Docker Compose to run the build.

Bu yaklaşımda, yeni bir yapı ortamı ayarlamak için basit.With this approach, it's trivial to set up a new build environment. Kodunuzu derlemek için isteyen bir geliştirici, bir dizi derleme araçları yüklemeniz gerekmez, ancak yalnızca kapsayıcı görüntüsünü çalıştırır.A developer who wants to build your code doesn't need to install a set of build tools, but simply runs the container image. Belki de daha da önemlisi, yapı sunucusunu aynı şeyi yapmak için yapılandırılabilir.Perhaps more importantly, your build server can be configured to do the same thing. Bu şekilde, bu araçların yapı sunucusuna yükleyin veya Araçlar çakışan sürümlerini yönetmek gerekmez.That way, you don't need to install those tools onto the build server, or manage conflicting versions of tools.

Yerel geliştirme ve test için bir kapsayıcı içinde hizmeti çalıştırmak için Docker'ı kullanın.For local development and testing, use Docker to run the service inside a container. Bu işlemin bir parçası olarak sahte Hizmetleri veya test veritabanları yerel olarak test etmek için gerekli olan diğer kapsayıcıları çalıştırmanız gerekebilir.As part of this process, you may need to run other containers that have mock services or test databases needed for local testing. Bu kapsayıcıların koordine etmek için Docker Compose kullanın veya Minikube Kubernetes yerel kullanmak.You could use Docker Compose to coordinate these containers, or use Minikube to run Kubernetes locally.

Kod hazır olduğunda, ana dala bir çekme isteği ve birleştirme açın.When the code is ready, open a pull request and merge into master. Bu yapı sunucusunda bir iş başlatır:This will start a job on the build server:

  1. Kod varlıklarına oluşturun.Build the code assets.
  2. Kodu karşı birim testleri çalıştırın.Run unit tests against the code.
  3. Kapsayıcı görüntüsünü oluşturun.Build the container image.
  4. Kapsayıcı görüntüsü üzerinde çalışan bir kapsayıcı işlevsel testleri çalıştırarak test edin.Test the container image by running functional tests on a running container. Bu adım, bir hatalı giriş noktası gibi Docker dosyasının hataları yakalayabilir.This step can catch errors in the Docker file, such as a bad entry point.
  5. Görüntüyü bir kapsayıcı kayıt defterine gönderin.Push the image to a container registry.
  6. Test kümesi tümleştirme testleri çalıştırmak için yeni görüntüyü ile güncelleştirin.Update the test cluster with the new image to run integration tests.

Görüntü üretime geçmeye hazır olduğunda, dağıtım dosyaları herhangi bir Kubernetes yapılandırma dosyaları dahil olan en yeni görüntüyü belirtmek için gerektiği gibi güncelleştirin.When the image is ready to go into production, update the deployment files as needed to specify the latest image, including any Kubernetes configuration files. Ardından güncelleştirmeyi üretim kümesi için geçerlidir.Then apply the update to the production cluster.

Dağıtımları daha güvenilir hale getirme için bazı öneriler şunlardır:Here are some recommendations for making deployments more reliable:

  • Kapsayıcı etiketleri, sürüm ve (pod'ları, hizmetleri ve benzeri) kümeye dağıtılan kaynakları için adlandırma kuralları için kuruluş genelinde kuralları tanımlayın.Define organization-wide conventions for container tags, versioning, and naming conventions for resources deployed to the cluster (pods, services, and so on). Bu, dağıtım sorunlarını tanılamak kolaylaştırabilir.That can make it easier to diagnose deployment issues.

  • İki ayrı bir kapsayıcı kayıt defterleri, bir geliştirme/test ve üretim için bir tane oluşturun.Create two separate container registries, one for development/testing and one for production. Üretime dağıtmaya hazır oluncaya kadar görüntü üretim kayıt defterine gönderin yok.Don't push an image to the production registry until you're ready to deploy it into production. Bu uygulama ile kapsayıcı görüntüleri anlamsal sürüm birleştirirseniz, yanlışlıkla sürüm için onaylanmış değildi bir sürümü dağıtma olasılığını azaltabilirsiniz.If you combine this practice with semantic versioning of container images, it can reduce the chance of accidentally deploying a version that wasn't approved for release.

Güncelleştirme HizmetleriUpdating services

Üretimde olan bir hizmeti güncelleştirmek için çeşitli stratejileri vardır.There are various strategies for updating a service that's already in production. Burada üç yaygın seçenekleri ele alır: Güncelleştirme ve mavi-yeşil dağıtım vamp alınıyor.Here we discuss three common options: Rolling update, blue-green deployment, and canary release.

Sıralı güncelleştirmeRolling update

Sıralı bir güncelleştirmede yeni bir hizmetin örneklerine dağıtmak ve yeni örnekleri isteklerini hemen almak başlatın.In a rolling update, you deploy new instances of a service, and the new instances start receiving requests right away. Yeni örnekleri oluştukça önceki örneği kaldırılır.As the new instances come up, the previous instances are removed.

Bir dağıtım için pod spec güncelleştirdiğinizde çalışırken Kubernetes varsayılan davranışı güncelleştirmelerdir.Rolling updates are the default behavior in Kubernetes when you update the pod spec for a Deployment. Güncelleştirilmiş pod'ları için yeni bir REPLICASET dağıtım denetleyiciyi oluşturur.The Deployment controller creates a new ReplicaSet for the updated pods. Ardından, istenen çoğaltma sayısını korumak için eski bir ölçeklendirme sırasında yeni REPLICASET ölçeklendirir.Then it scales up the new ReplicaSet while scaling down the old one, to maintain the desired replica count. Yeni bir tane hazır olana kadar bu eski pod'ları silinmez.It doesn't delete old pods until the new ones are ready. Bir güncelleştirme gerekirse geri almak için kubectl kullanabilmeniz için Kubernetes güncelleştirme bir geçmişini tutar.Kubernetes keeps a history of the update, so you can use kubectl to roll back an update if needed.

Hizmetinizi uzun başlangıç görevi gerçekleştirir, hazır olma durumu araştırması tanımlayabilirsiniz.If your service performs a long startup task, you can define a readiness probe. Kapsayıcı trafiğini almaya başlamak için hazır olduğunda hazırlık araştırma bildirir.The readiness probe reports when the container is ready to start receiving traffic. Araştırma başarılı sonuç raporlar kadar Kubernetes pod'u trafiği göndermez.Kubernetes won't send traffic to the pod until the probe reports success.

Güncelleştirmeleri çalışırken, bir güncelleştirme işlemi sırasında bir karışımı eski ve yeni sürümleri çalıştıran ve trafik almasını, zorluktur.One challenge of rolling updates is that during the update process, a mix of old and new versions are running and receiving traffic. Bu süre boyunca herhangi bir istek iki sürüm birini yönlendirilir.During this period, any request could get routed to either of the two versions. Olabilir veya iki sürümü arasındaki değişiklikleri kapsamına bağlı olarak sorunlara neden olmaz.That may or may not cause problems, depending on the scope of the changes between the two versions.

Mavi-yeşil dağıtımBlue-green deployment

Mavi-yeşil dağıtım içinde yeni sürümü önceki sürümün yanına dağıtın.In a blue-green deployment, you deploy the new version alongside the previous version. Yeni sürüm doğruladıktan sonra önceki sürümden tek seferde tüm trafiği yeni sürüme geçin.After you validate the new version, you switch all traffic at once from the previous version to the new version. Anahtarından sonra herhangi bir sorun için uygulamayı izleyin.After the switch, you monitor the application for any problems. Bir sorun yaşanırsa eski sürüme takas edebilirsiniz.If something goes wrong, you can swap back to the old version. Herhangi bir sorun yok varsayıldığında, eski sürümü silebilirsiniz.Assuming there are no problems, you can delete the old version.

İki özdeş ortamları sağlama ile daha geleneksel bir tek parçalı veya N katmanlı uygulama, mavi-yeşil dağıtım genellikle geliyordu.With a more traditional monolithic or N-tier application, blue-green deployment generally meant provisioning two identical environments. Yeni sürüm bir hazırlama ortamına dağıtma sonra hazırlama ortamına istemci trafiği yeniden yönlendirmeniz — tarafından VIP takas gibi adresleri.You would deploy the new version to a staging environment, then redirect client traffic to the staging environment — for example, by swapping VIP addresses.

Kubernetes'te, mavi-yeşil dağıtımlarına yapmak için ayrı bir küme sağlamanız gerekmez.In Kubernetes, you don't need to provision a separate cluster to do blue-green deployments. Bunun yerine, seçici yararlanabilir.Instead, you can take advantage of selectors. Yeni bir pod spec ve farklı bir etiket kümesi ile yeni bir dağıtım kaynağı oluşturun.Create a new Deployment resource with a new pod spec and a different set of labels. Önceki dağıtım noktaları için hizmet silmesini veya olmadan bu dağıtımı oluşturun.Create this deployment, without deleting the previous deployment or modifying the service that points to it. Yeni pod'ların çalışan sonra hizmetin Seçici yeni dağıtım eşleşecek şekilde güncelleştirebilirsiniz.Once the new pods are running, you can update the service's selector to match the new deployment.

Mavi-yeşil dağıtım hizmeti aynı anda tüm pod'ların geçer avantajlıdır.An advantage of blue-green deployments is that the service switches all the pods at the same time. Hizmeti güncelleştirdikten sonra tüm yeni isteklerin en yeni sürüme yönlendirilir.After the service is updated, all new requests get routed to the new version. Bir dezavantajı (güncelleştirme sırasında iki kez olarak birçok pod'ları hizmeti için geçerli ve sonraki) çalıştığını ' dir.One drawback is that during the update, you are running twice as many pods for the service (current and next). Pod'ların miktarda CPU veya bellek kaynağı gerekiyorsa, kaynak tüketimini geçici olarak işlemek için kümeyi ölçeklendirme gerekebilir.If the pods require a lot of CPU or memory resources, you may need to scale out the cluster temporarily to handle the resource consumption.

VampCanary release

Kanarya sürümde, az sayıda istemciyi güncelleştirilmiş bir sürümü alma.In a canary release, you roll out an updated version to a small number of clients. Ardından tüm istemcilere sunulmadan önce yeni bir hizmet davranışını izleyin.Then you monitor the behavior of the new service before rolling it out to all clients. Bu, denetimli bir biçimde yavaş bir sunum yapmak için tüm müşteri etkilenmeden önce gerçek veriler ve sorunları inceleyin sağlar.This lets you do a slow rollout in a controlled fashion, observe real data, and spot problems before all customers are affected.

Dinamik olarak hizmet farklı sürümlerini istekleri yönlendirmeyi gerekir çünkü bir vamp mavi-yeşil veya çalışırken güncelleştirme yönetmek için daha karmaşıktır.A canary release is more complex to manage than either blue-green or rolling update, because you must dynamically route requests to different versions of the service. Kubernetes, bir hizmeti iki çoğaltma kümesi (her sürümü için bir tane) span ve yineleme sayısını el ile ayarlamak için yapılandırabilirsiniz.In Kubernetes, you can configure a Service to span two replica sets (one for each version) and adjust the replica counts manually. Ancak, bu yaklaşım çok parçalı, Kubernetes yük şekli nedeniyle pod'ları arasında dengeler.However, this approach is rather coarse-grained, because of the way Kubernetes load balances across pods. Örneğin, toplam on çoğaltmalar varsa, yalnızca % 10 halinde trafik kaydırabilirsiniz.For example, if you have a total of ten replicas, you can only shift traffic in 10% increments. Ağ hizmeti kullanıyorsanız, daha karmaşık bir vamp stratejisi uygulamak için hizmet kafes yönlendirme kurallarını kullanabilirsiniz.If you are using a service mesh, you can use the service mesh routing rules to implement a more sophisticated canary release strategy. Yardımcı olabilecek bazı kaynaklar aşağıda verilmiştir:Here are some resources that may be helpful:

SonuçConclusion

Son yıllarda olmuştur Deniz değişiklik, bir taşıma yapı gelen sektörde sistemleri kaydının yapı için engagement sistemlerinin.In recent years, there has been a sea change in the industry, a movement from building systems of record to building systems of engagement.

Kaydın sistemleri, geleneksel arka ofis veri yönetimi uygulamalardır.Systems of record are traditional back-office data management applications. Bu sistemler yaklaşımının temelindeki var. genellikle yer alan tek gerçeklik kaynağı olan bir RDBMS'de.At the heart of these systems there often sits an RDBMS that is the single source of truth. "Sistem engagement'ın" terimi Geoffrey Moore için kendi 2011 kağıt'in alacaklı olduğu sistemleri, katılım ve kurumsal BT gelecekteki.The term "system of engagement" is credited to Geoffrey Moore, in his 2011 paper Systems of Engagement and the Future of Enterprise IT. Engagement'ın sistemleri, iletişim ve işbirliği odaklanan uygulamalardır.Systems of engagement are applications focused on communication and collaboration. Gerçek zamanlı kişilerin bağlandıklarında.They connect people in real time. Kullanılabilir 24 x 7 olmaları gerekir.They must be available 24/7. Yeni özellikler, uygulamayı çevrimdışı duruma getirmeden düzenli olarak sunulmuştur.New features are introduced regularly without taking the application offline. Kullanıcılar, daha fazla beklediğiniz ve beklenmeyen gecikme veya kapalı kalma süresi, daha az hasta olur.Users expect more and are less patient of unexpected delays or downtime.

Tüketici alanında daha iyi bir kullanıcı deneyimi, ölçülebilir iş değerine sahip olabilir.In the consumer space, a better user experience can have measurable business value. Bir kullanıcı bir uygulama ile ilgilenir. süreyi gelir'ya doğrudan çevir.The amount of time that a user engages with an application may translate directly into revenue. Ve iş sistemleri yayınladık kullanıcı beklentilerini değiştirilmiştir.And in the realm of business systems, users' expectations have changed. İletişim ve işbirliği yapmaları için bu sistemler hedeflenir, tüketiciye yönelik uygulamalardan kendi işaret gerçekleştirmeniz gerekir.If these systems aim to foster communication and collaboration, they must take their cue from consumer-facing applications.

Mikro hizmetler bu değişen yatay yanıt var.Microservices are a response to this changing landscape. Bir dizi gevşek bağlantılı Hizmetleri tek parça bir uygulamayı parçalama tarafından size her hizmetin sürüm döngüsü denetlemek ve sık sık güncelleştirme kapalı kalma süresi veya önemli değişiklikler olmadan etkinleştirin.By decomposing a monolithic application into a group of loosely coupled services, we can control the release cycle of each service, and enable frequent updates without downtime or breaking changes. Mikro hizmetler, ölçeklenebilirlik, hata Yalıtımı ve dayanıklılık ile de yardımcı.Microservices also help with scalability, failure isolation, and resiliency. Bu arada, bulut platformları derleme ve çalıştırma mikro hizmetler, işlem kaynaklarını otomatik sağlama, kapsayıcı düzenleyicileri hizmet ve olay odaklı, sunucusuz ortamları daha kolay getirirsiniz.Meanwhile, cloud platforms are making it easier to build and run microservices, with automated provisioning of compute resources, container orchestrators as a service, and event-driven serverless environments.

Ancak mikro hizmet mimarileri anlatıldığı gibi ayrıca çok güçlük olan.But as we've seen, microservices architectures also being a lot of challenges. Başarılı olması için bir düz tasarımdan başlatmanız gerekir.To succeed, you must start from a solid design. Etki çözümleme, teknolojilerini seçerken veri modelleme API'leri tasarlama ve olgun bir DevOps kültürü oluşturma içine dikkatli düşünce yerleştirmeniz gerekir.You must put careful thought into analyzing the domain, choosing technologies, modeling data, designing APIs, and building a mature DevOps culture. Umuyoruz bu kılavuzu ve eşlik eden uygulama başvuru, Yolculuğunuzun karanl yardımcı olmuştur.We hope that this guide, and the accompanying reference implementation, has helped to illuminate the journey.