database 微服务和数据库连接

Microservices and database joins

提问by Martin Bayly

For people that are splitting up monolithic applications into microservices how are you handling the connundrum of breaking apart the database. Typical applications that I've worked on do a lot of database integration for performance and simplicity reasons.

对于将单体应用程序拆分为微服务的人来说，您如何处理拆分数据库的难题。出于性能和简单性的原因，我处理过的典型应用程序进行了大量的数据库集成。

If you have two tables that are logically distinct (bounded contexts if you will) but you often do aggregate processing on a large volumes of that data then in the monolith you're more than likely to eschew object orientation and are instead using your database's standard JOIN feature to process the data on the database prior to return the aggregated view back to your app tier.

如果您有两个逻辑上不同的表（如果您愿意，则为有界上下文），但您经常对大量数据进行聚合处理，那么在单体应用中，您很可能会避开面向对象，而是使用数据库的标准JOIN 功能在将聚合视图返回到您的应用程序层之前处理数据库上的数据。

How do you justify splitting up such data into microservices where presumably you will be required to 'join' the data through an API rather than at the database.

您如何证明将此类数据拆分为微服务是合理的，其中您可能需要通过 API 而不是在数据库中“加入”数据。

I've read Sam Newman's Microservices book and in the chapter on splitting the Monolith he gives an example of "Breaking Foreign Key Relationships" where he acknowledges that doing a join across an API is going to be slower - but he goes on to say if your application is fast enough anyway, does it matter that it is slower than before?

我读过 Sam Newman 的《微服务》一书，在拆分单体的一章中，他举了一个“打破外键关系”的例子，他承认跨 API 进行连接会变慢 - 但他接着说如果无论如何，您的应用程序足够快，比以前慢有关系吗？

This seems a bit glib? What are people's experiences? What techniques did you use to make the API joins perform acceptably?

这似乎有点油嘴滑舌？人们的体验是什么？您使用了哪些技术来使 API 连接的性能令人满意？

回答by sap1ens

• When performance or latency doesn't matter too much (yes, we don't always need them) it's perfectly fine to just use simple RESTful APIs for querying additional data you need. If you need to do multiple calls to different microservices and return one result you can use API Gatewaypattern.

• It's perfectly fine to have redundancy in Polyglot persistenceenvironments. For example, you can use messaging queue for your microservices and send "update" events every time you change something. Other microservices will listen to required events and save data locally. So instead of querying you keep all required data in appropriate storage for specific microservice.

• Also, don't forget about caching :) You can use tools like Redisor Memcachedto avoid querying other databases too often.

• 当性能或延迟不太重要时（是的，我们并不总是需要它们），只使用简单的 RESTful API 来查询您需要的其他数据就完全没问题了。如果您需要对不同的微服务进行多次调用并返回一个结果，则可以使用 API 网关模式。

• 在多语言持久性环境中拥有冗余是完全没问题的。例如，您可以为微服务使用消息队列，并在每次更改某些内容时发送“更新”事件。其他微服务将侦听所需的事件并在本地保存数据。因此，您无需查询，而是将所有必需的数据保存在特定微服务的适当存储中。

• 另外，不要忘记缓存 :) 您可以使用Redis或Memcached 之类的工具来避免过于频繁地查询其他数据库。

回答by mcintyre321

It's OK for services to have read-only replicated copies of certain reference data from other services.

服务可以拥有来自其他服务的某些参考数据的只读副本。

Given that, when trying to refactor a monolithic database into microservices (as opposed to rewrite) I would

鉴于此，当尝试将单体数据库重构为微服务（而不是重写）时，我会

• create a db schema for the service
• create versioned* views** in that schema to expose data from that schema to other services
• do joins against these readonly views

• 为服务创建一个数据库架构
• 在该架构中创建版本化* 视图** 以将该架构中的数据公开给其他服务
• 对这些只读视图进行连接

This will let you independently modify table data/strucutre without breaking other applications.

这将让您独立修改表数据/结构，而不会破坏其他应用程序。

Rather than use views, I might also consider using triggers to replicate data from one schema to another.

除了使用视图，我还可以考虑使用触发器将数据从一个模式复制到另一个模式。

This would be incremental progress in the right direction, establishing the seams of your components, and a move to REST can be done later.

这将是朝着正确方向的渐进式进展，建立组件的接缝，并且可以稍后完成向 REST 的迁移。

*the views can be extended. If a breaking change is required, create a v2 of the same view and remove the old version when it is no longer required. **or Table-Valued-Functions, or Sprocs.

*视图可以扩展。如果需要进行重大更改，请创建相同视图的 v2，并在不再需要时删除旧版本。** 或表值函数，或 Sproc。

回答by Praful

CQRS---Command Query Aggregation Pattern is the answer to thi as per Chris Richardson. Let each microservice update its own data Model and generates the events which will update the materialized view having the required join data from earlier microservices.This MV could be any NoSql DB or Redis or elasticsearch which is query optimized. This techniques leads to Eventual consistency which is definitely not bad and avoids the real time application side joins. Hope this answers.

CQRS---Command Query Aggregation Pattern 是 Chris Richardson 的答案。让每个微服务更新自己的数据模型并生成事件，这些事件将更新具有来自早期微服务所需连接数据的物化视图。这个 MV 可以是任何 NoSql DB 或 Redis 或查询优化的 elasticsearch。这种技术导致最终一致性，这绝对不错，并避免了实时应用程序端连接。希望这个答案。

回答by Jaro64

I would separate the solutions for the area of use, on let's say operational and reporting.

我会将使用领域的解决方案分开，比如说操作和报告。

For the microservices that operate to provide data for single forms that need data from other microservices (this is the operational case) I think using API joins is the way to go. You will not go for big amounts of data, you can do data integration in the service.

对于为需要来自其他微服务的数据的单个表单提供数据的微服务（这是操作案例），我认为使用 API 连接是可行的方法。您不会去获取大量数据，您可以在服务中进行数据集成。

The other case is when you need to do big queries on large amount of data to do aggregations etc. (the reporting case). For this need I would think about maintaining a shared database – similar to your original scheme and updating it with events from your microservice databases. On this shared database you could continue to use your stored procedures which would save your effort and support the database optimizations.

另一种情况是当您需要对大量数据进行大查询以进行聚合等时（报告案例）。为了这个需求，我会考虑维护一个共享数据库——类似于你的原始方案，并使用来自你的微服务数据库的事件来更新它。在这个共享数据库上，您可以继续使用您的存储过程，这将节省您的精力并支持数据库优化。

回答by techagrammer

In Microservices you create diff. read models, so for eg: if you have two diff. bounded context and somebody wants to search on both the data then somebody needs to listen to events from both bounded context and create a view specific for the application.

在微服务中，您创建差异。读取模型，例如：如果您有两个差异。有界上下文，有人想要搜索这两个数据，然后有人需要监听来自两个有界上下文的事件并为应用程序创建特定的视图。

In this case there will be more space needed, but no joins will be needed and no joins.

在这种情况下，将需要更多空间，但不需要联接，也不需要联接。