Mikro hizmetler tasarlama: Verilerle ilgili dikkat edilecek konularDesigning microservices: Data considerations

Bu bölümde, mikro hizmetler mimarisinde veri yönetme konuları açıklanmaktadır.This chapter describes considerations for managing data in a microservices architecture. Her mikro hizmet kendi verilerini yönettiği için veri bütünlüğü ve veri tutarlılığı kritik sorunlardır.Because every microservice manages its own data, data integrity and data consistency are critical challenges.

Veri konuları diyagramı

Mikro hizmetlerin temel ilkelerinden biri, her hizmetin kendi verilerini yönetmesidir.A basic principle of microservices is that each service manages its own data. İki hizmet, bir veri deposu paylaşmamalıdır.Two services should not share a data store. Bunun yerine, her hizmetin diğer hizmetlere doğrudan erişemez, kendi özel veri deposu için sorumludur.Instead, each service is responsible for its own private data store, which other services cannot access directly.

Bu kural nedeni Hizmetleri aynı temel alınan veri şemaları paylaşırsanız, hangi neden olabilir, hizmetler arasında yanlışlıkla eşleştirmeye kaçınmaktır.The reason for this rule is to avoid unintentional coupling between services, which can result if services share the same underlying data schemas. Veri şemasında yapılan bir değişiklik olursa, ilgili veritabanını kullanan her bir hizmet arasında değişiklik Eşgüdümlü.If there is a change to the data schema, the change must be coordinated across every service that relies on that database. Her hizmete ait veri deposuna yalıtarak Biz değişiklik kapsamını sınırlandırmak ve tamamen bağımsız dağıtımlar çevikliğini koruyabilirsiniz.By isolating each service's data store, we can limit the scope of change, and preserve the agility of truly independent deployments. Her mikro hizmet kendi veri modelleri, sorgular veya olabilir desenleri okuma/yazma, başka bir neden olmasıdır.Another reason is that each microservice may have its own data models, queries, or read/write patterns. Paylaşılan veri deposunu kullanarak veri depolama, belirli bir hizmet için en iyi duruma getirmek için her takımın özelliğini sınırlar.Using a shared data store limits each team's ability to optimize data storage for their particular service.

Yanlış bir CQRS yaklaşımı diyagramı

Bu yaklaşım için doğal geliyor çok yönlü Kalıcılık — tek bir uygulama içinde birden çok veri depolama teknolojilerinin kullanılması.This approach naturally leads to polyglot persistence — the use of multiple data storage technologies within a single application. Bir hizmet, bir belge veritabanı şeması okuma yeteneklerini gerektirebilir.One service might require the schema-on-read capabilities of a document database. Başka bir RDBMS'de tarafından sağlanan bilgi tutarlılığını gerekebilir.Another might need the referential integrity provided by an RDBMS. Her takımın kendi hizmeti için en iyi seçimi yapabilmenizi ücretsiz olarak kullanılabilir.Each team is free to make the best choice for their service. Çok yönlü Kalıcılık Genel İlkesi hakkında daha fazla bilgi için bkz. iş için en iyi veri deposunu kullanın.For more about the general principle of polyglot persistence, see Use the best data store for the job.

Not

Hizmetler için aynı fiziksel veritabanında sunucu paylaşım uygundur.It's fine for services to share the same physical database server. Sorun Hizmetleri aynı şemaya paylaşın veya okuma ve yazma veritabanı tabloları aynı kümesine oluşur.The problem occurs when services share the same schema, or read and write to the same set of database tables.

ZorluklarChallenges

Bu dağıtılmış yaklaşımı verileri yönetmek için bazı zorluklar ortaya çıkar.Some challenges arise from this distributed approach to managing data. İlk olarak, olabilir yedeklilik ile birden fazla yerde görüntülenen verileri aynı öğenin veri depoları arasında.First, there may be redundancy across the data stores, with the same item of data appearing in multiple places. Örneğin, veri bir işlemin bir parçası depolanan ve sonra analiz, raporlama ya da arşivlemek için başka bir yerde depolanır.For example, data might be stored as part of a transaction, then stored elsewhere for analytics, reporting, or archiving. Yinelenen veya bölümlenmiş verileri veri bütünlüğü ve tutarlılık sorunlarına yol açabilir.Duplicated or partitioned data can lead to issues of data integrity and consistency. Veri ilişkileri birden çok hizmet span, ilişkiler zorlamak için geleneksel veri yönetimi teknikleri kullanamazsınız.When data relationships span multiple services, you can't use traditional data management techniques to enforce the relationships.

Geleneksel veri modelleme "bir olgu tek bir yerde" kuralını kullanır.Traditional data modeling uses the rule of "one fact in one place." Her varlık, şemada tam bir kez görüntülenir.Every entity appears exactly once in the schema. Diğer varlıkların başvuruları tutun ancak yinelenen değil.Other entities may hold references to it but not duplicate it. Geleneksel yaklaşım belirgin avantajı güncelleştirmeleri veri tutarlılığı sorunları önler tek bir yerde yapılmasıdır.The obvious advantage to the traditional approach is that updates are made in a single place, which avoids problems with data consistency. Bir mikro hizmet mimarisinde güncelleştirmeleri hizmetler arasında nasıl dağıtılır ve güçlü tutarlılık olmadan birden çok yerde veri görüntülendiğinde, nihai tutarlılık yönetme düşünmeniz gerekir.In a microservices architecture, you have to consider how updates are propagated across services, and how to manage eventual consistency when data appears in multiple places without strong consistency.

Verileri yönetme yaklaşımlarıApproaches to managing data

Her durumda doğru olduğundan ve tek bir yaklaşım yoktur, ancak mikro hizmetler mimarisinde verileri yönetmek için bazı genel yönergeler şunlardır.There is no single approach that's correct in all cases, but here are some general guidelines for managing data in a microservices architecture.

  • Mümkün olduğunda nihai tutarlılık yaklaşımını benimseyin.Embrace eventual consistency where possible. Güçlü tutarlılık veya ACID işlemlerini ve son tutarlılık kabul edilebilir olduğu yerde duyduğunuz senaryolara sistemde yerleri anlayın.Understand the places in the system where you need strong consistency or ACID transactions, and the places where eventual consistency is acceptable.

  • Güçlü tutarlılık garantilerinin gerektiğinde, bir hizmet bir API aracılığıyla kullanıma sunulan belirli bir varlığın doğru kaynağı temsil edebilir.When you need strong consistency guarantees, one service may represent the source of truth for a given entity, which is exposed through an API. Diğer hizmetleri, kendi veri kopyası ya da bir veri alt kümesini ile ana verilerin nihai olarak tutarlı, ancak gerçekte kaynağını dikkate alınmaz tutabilir.Other services might hold their own copy of the data, or a subset of the data, that is eventually consistent with the master data but not considered the source of truth. Örneğin, bir müşteri sipariş hizmeti ve önerisi hizmeti ile bir e-ticaret sistemi düşünün.For example, imagine an e-commerce system with a customer order service and a recommendation service. Öneri hizmet sırası hizmetinden olayları dinleyip ancak bir müşteri para iadesi isterse, sipariş hizmeti, tam işlem geçmişi olan önerisi hizmeti değil, değildir.The recommendation service might listen to events from the order service, but if a customer requests a refund, it is the order service, not the recommendation service, that has the complete transaction history.

  • Desenleri gibi işlemler için kullanın Zamanlayıcı Aracısı Gözetmeni ve telafi işlemi çeşitli hizmetlerdeki tutarlı verileri tutmak için.For transactions, use patterns such as Scheduler Agent Supervisor and Compensating Transaction to keep data consistent across several services. Ek bir parça birden fazla hizmet arasından kısmi hatadan kaçınmak için birden çok hizmet kapsayan iş birimi durumunu yakalayan veri depolamak gerekebilir.You may need to store an additional piece of data that captures the state of a unit of work that spans multiple services, to avoid partial failure among multiple services. Örneğin, çok adımlı bir işlem devam ederken bir iş öğesi dayanıklı bir kuyruğa tutun.For example, keep a work item on a durable queue while a multi-step transaction is in progress.

  • Bir hizmet gerektiren veri Store.Store only the data that a service needs. Bir hizmetin yalnızca bir alt etki alanı varlığı hakkındaki bilgilerin gerekebilir.A service might only need a subset of information about a domain entity. Örneğin, sevkiyat sınırlanmış bağlam içinde size hangi müşteri belirli bir dağıtım için ilişkilendirilen bilmeniz gerekir.For example, in the Shipping bounded context, we need to know which customer is associated to a particular delivery. Ancak müşterinin fatura adresini ihtiyaç duymayacağımız — hesapları sınırlanmış bağlam tarafından yönetilir.But we don't need the customer's billing address — that's managed by the Accounts bounded context. Dikkatli bir şekilde etki alanınız hakkında düşünmek ve DDD bir yaklaşım kullanarak burada yardımcı olabilir.Thinking carefully about the domain, and using a DDD approach, can help here.

  • Hizmetlerinizi tutarlı ve gevşek bir şekilde olup olmadığını göz önünde bulundurun.Consider whether your services are coherent and loosely coupled. Sık iletişim kuran API'lerden içinde elde edilen iki hizmetin sürekli olarak birbiriyle bilgi değişimi, iki hizmet birleştirme veya işlevleri yeniden düzenleme, hizmet sınırları Çiz gerekebilir.If two services are continually exchanging information with each other, resulting in chatty APIs, you may need to redraw your service boundaries, by merging two services or refactoring their functionality.

  • Kullanım bir mimari stili aktivita typu EventDriven.Use an event driven architecture style. Bu mimari stilini kendi genel modelleri veya varlıklar değişiklik olduğunda bir olay hizmet yayımlar.In this architecture style, a service publishes an event when there are changes to its public models or entities. İlgili hizmetler, bu olaylara abone olabilirsiniz.Interested services can subscribe to these events. Örneğin, başka bir hizmet, olayları, sorgulama için daha uygun olan verilerin gerçekleştirilmiş görünümünü oluşturmak için kullanabilirsiniz.For example, another service could use the events to construct a materialized view of the data that is more suitable for querying.

  • Olayları sahip bir hizmet, serileştirme ve seri kaldırma olayları, Yayımcılar ve aboneler arasında sıkı eşleştirme önlemek için otomatik hale getirmek için kullanılan bir şema yayımlamanız gerekir.A service that owns events should publish a schema that can be used to automate serializing and deserializing the events, to avoid tight coupling between publishers and subscribers. JSON şema veya gibi bir çerçeve göz önünde bulundurun Microsoft Bond, Protobuf veya Avro.Consider JSON schema or a framework like Microsoft Bond, Protobuf, or Avro.

  • Olayları yüksek ölçekte sistemde performans sorunlarına, bu nedenle toplam yükü azaltmak için işlem grubu oluşturma veya toplama kullanarak göz önünde bulundurun.At high scale, events can become a bottleneck on the system, so consider using aggregation or batching to reduce the total load.

İnsansız hava aracı ile teslimat: Veri depolarını seçmeDrone Delivery: Choosing the data stores

Bile yalnızca birkaç Hizmetleri ile sevkiyat sınırlanmış bağlam Bu bölümde açıklanan noktaları bazıları gösterilmektedir.Even with only a few services, the Shipping bounded context illustrates several of the points discussed in this section.

Bir kullanıcı, yeni teslimat zamanlarken, istemci istek boyutu ve Ağırlık gibi paket ve her iki teslim, toplama ve dropoff konumları gibi hakkında bilgi içerir.When a user schedules a new delivery, the client request includes information about the both the delivery, such as the pickup and dropoff locations, and about the package, such as the size and weight. Bu bilgiler, Event Hubs'a alma hizmetidir gönderen iş birimi tanımlar.This information defines a unit of work, which the Ingestion service sends to Event Hubs. Zamanlayıcı hizmetine iş akışı yürütülürken teslim istek kayıp, böylece iş birimini kalıcı depolama alanında kalmasını önemlidir.It's important that the unit of work stays in persistent storage while the Scheduler service is executing the workflow, so that no delivery requests are lost. İş akışını daha fazla bilgi için bkz. alma ve iş akışı.For more discussion of the workflow, see Ingestion and workflow.

Çeşitli arka uç Hizmetleri istekteki bilgiler farklı bölümlerini önem verdiğiniz ve ayrıca farklı okuma ve yazma profilleri.The various backend services care about different portions of the information in the request, and also have different read and write profiles.

Teslim hizmetiDelivery service

Teslim hizmeti, devam eden veya şu anda zamanlanmış her teslim hakkında bilgi depolar.The Delivery service stores information about every delivery that is currently scheduled or in progress. Dronlarla hayat kurtarma gelen olayları dinler ve devam eden teslimler durumunu izler.It listens for events from the drones, and tracks the status of deliveries that are in progress. Ayrıca, etki alanı olayları teslim durum güncelleştirmeleri ile gönderir.It also sends domain events with delivery status updates.

Paket için beklerken kullanıcıların sık bir teslim durumunu kontrol beklenmektedir.It's expected that users will frequently check the status of a delivery while they are waiting for their package. Bu nedenle teslim hizmeti uzun vadeli depolama (okuma ve yazma) aktarım hızı vurgular bir veri deposu gerektirir.Therefore, the Delivery service requires a data store that emphasizes throughput (read and write) over long-term storage. Ayrıca, herhangi bir karmaşık sorgular veya Analiz teslim hizmeti gerçekleştirmez, yalnızca belirli bir dağıtım için en son durumu getirir.Also, the Delivery service does not perform any complex queries or analysis, it simply fetches the latest status for a given delivery. Teslim hizmeti ekibi, Azure Redis Cache yüksek okuma-yazma performansını etti.The Delivery service team chose Azure Redis Cache for its high read-write performance. Redis içinde depolanan görece kısa süreli bilgilerdir.The information stored in Redis is relatively short-lived. Bir teslim tamamlandıktan sonra teslim geçmişi kayıt sistemi hizmetidir.Once a delivery is complete, the Delivery History service is the system of record.

Teslim geçmişi hizmetiDelivery History service

Teslim geçmişi hizmet teslim hizmeti teslim durumu olayları dinler.The Delivery History service listens for delivery status events from the Delivery service. Bu verileri uzun vadeli depolama alanında depolar.It stores this data in long-term storage. İki farklı kullanım farklı veri depolama gereksinimleri olan örnekleri için bu geçmiş verileri vardır.There are two different use-cases for this historical data, which have different data storage requirements.

İlk senaryo, veri analizi, iş en iyi duruma getirmek için hizmet kalitesini artırmak amacıyla verileri yeniden hesaplanır.The first scenario is aggregating the data for the purpose of data analytics, in order to optimize the business or improve the quality of the service. Teslim geçmiş hizmeti verilerin gerçek çözümleme gerçekleştirmez unutmayın.Note that the Delivery History service doesn't perform the actual analysis of the data. Yalnızca depolama ve alma için sorumlu değildir.It's only responsible for the ingestion and storage. Bu senaryo için depolama üzerinde çeşitli veri kaynaklarından uyum sağlamak için bir şema okuma yaklaşımını kullanarak verileri, çok sayıda veri analizi için iyileştirilmelidir.For this scenario, the storage must be optimized for data analysis over a large set of data, using a schema-on-read approach to accommodate a variety of data sources. Azure Data Lake Store bu senaryo için iyi bir uygun.Azure Data Lake Store is a good fit for this scenario. Data Lake Store, Hadoop dağıtılmış dosya sistemi (HDFS) ile uyumlu bir Apache Hadoop dosya sistemidir ve veri analizi senaryoları için performans için ayarlanmıştır.Data Lake Store is an Apache Hadoop file system compatible with Hadoop Distributed File System (HDFS), and is tuned for performance for data analytics scenarios.

Diğer senaryo, bir teslimat geçmişi teslim tamamlandıktan sonra kullanıcılar etkileştirir.The other scenario is enabling users to look up the history of a delivery after the delivery is completed. Azure Data Lake, bu senaryo için özellikle getirilmemiştir.Azure Data Lake is not particularly optimized for this scenario. En iyi performans için tarihe göre bölümlenmiş klasörlerdeki veri Gölü'nde zaman serisi verilerinin depolanması Microsoft önerir.For optimal performance, Microsoft recommends storing time-series data in Data Lake in folders partitioned by date. (Bkz ayarlama Azure Data Lake Store için performans).(See Tuning Azure Data Lake Store for performance). Ancak, bu yapıyı kimliğine göre kayıtları tek tek bakmak en uygun değilHowever, that structure is not optimal for looking up individual records by ID. Zaman damgası da duymadıkça, Kimliğine göre arama, tüm koleksiyon tarama gerektirir.Unless you also know the timestamp, a lookup by ID requires scanning the entire collection. Bu nedenle, teslim geçmiş Hizmeti ayrıca geçmiş verilerin bir alt kümesini Cosmos DB için hızlı arama depolar.Therefore, the Delivery History service also stores a subset of the historical data in Cosmos DB for quicker lookup. Kayıtları Cosmos DB'de süresiz olarak kalmasını gerek yoktur.The records don't need to stay in Cosmos DB indefinitely. Eski teslim arşivlenen — , bir ay sonra varsayalım.Older deliveries can be archived — say, after a month. Bu, bir arada sırada toplu işlem'i çalıştırarak yapılabilir.This could be done by running an occasional batch process.

Paket hizmetiPackage service

Paket hizmeti tüm paketler hakkında bilgi depolar.The Package service stores information about all of the packages. Paket için depolama gereksinimleri şunlardır:The storage requirements for the Package are:

  • Uzun vadeli depolama.Long-term storage.
  • Aktarım hızı yüksek gerektiren paketleri, yüksek hacimli yazma işlemek kullanabilirsiniz.Able to handle a high volume of packages, requiring high write throughput.
  • Paket kimliğine göre basit sorgu desteğiSupport simple queries by package ID. Karmaşık birleştirmeler veya başvurusal bütünlük gereksinimlerini yok.No complex joins or requirements for referential integrity.

Paket veriler ilişkisel olmadığından, belge yönelimli veritabanı uygundur ve parçalı koleksiyonlar kullanarak, Cosmos DB çok yüksek aktarım hızı elde edebilirsiniz.Because the package data is not relational, a document oriented database is appropriate, and Cosmos DB can achieve very high throughput by using sharded collections. Seçmeleri için paket hizmeti üzerinde çalışan takım MEAN yığını (MongoDB, Express.js, AngularJS ve Node.js) ile ilgili bilgi sahibi mi MongoDB API'si Cosmos DB için.The team that works on the Package service is familiar with the MEAN stack (MongoDB, Express.js, AngularJS, and Node.js), so they select the MongoDB API for Cosmos DB. Bunları yönetilen bir Azure hizmeti olan Cosmos DB avantajlarını alınırken, MongoDB ile kendi mevcut deneyiminden yararlanmaya olanak tanır.That lets them leverage their existing experience with MongoDB, while getting the benefits of Cosmos DB, which is a managed Azure service.