数据中心的 “冷数据”。 对于一些不需要做实时数据的复杂查询或者报表，通常是将微服务的“热数据”作为“冷数据”导出到数据中心以供报表。这个数据中心可能是一个基于大数据的系统，比如 Hadoop，AWS的Redshit，Azure的SQL Data warehosue等。

同步的过程你可以使用事件驱动这种通讯技术，或者是一些数据库提供的基础设施中的导入/导出工具等。如果使用事件驱动的话，其过程有点类似上面的CRQS查询过程。

3、如何实现多个微服务的数据一致性。

我们知道在每个微服务都是具有高内聚的特点的，外部想访问微服务的数据只能通过API访问，那么我们在实现一个微服务到另外一个微服务这种业务流程的时候，怎么同时保持多个微服务之间的一致性呢？

我们回到 eShop 这个微软的示例项目上来，来看看怎么处理的。 首先，Catelog 这个微服务是负责维护商品相关的信息，包括库存。 Ordering 这个微服务负责订单的管理，当新创建一个订单的时候，它必须验证这个订单的商品是否具有足够的库存（如果不够可能涉及到缺货登记），所以它就必须要和Catelog微服务打交道。在以前单服务的程序中可以简单的使用ACID事务来进行检查并且直接更新可用库存。但是现在不能这样了，每个微服务都拥有自己的数据库，当前的服务不能直接去操作其他服务的数据库的，这个时候我们为了实现我们需要的功能怎么办呢？我们可以使用异步通讯，比如消息或者事件驱动这种方式，这也是 eShop使用的方式。

这里就涉及到一个理论知识，就是 CAP定理。也就是说你必须要在可用性和ACID强一致性之间做出选择。大多数基于微服务的场景都需要可用性和高可扩展，而不是强一致性。所以为了保证在关键场景下应用程序能够正常响应，我们一般会选择牺牲强一致行从而追求最终一致性。

4、如何跨微服务进行通讯。

微服务之间的通讯，是一个比较大的技术挑战。这个时候你不应该去关注你应该使用什么协议，比如是使用 Http、Rest、AMQP
、消息、或者其他东西。相反，你应该了解每种协议的优缺点，你使用该协议想达到什么样的一个目的，以及这种协议怎么样和你的微服务更好的进行耦合。根据耦合程度，当发生故障的时候，是不是对系统有非常大的影响。

像微服务这种分布式系统中，是由许多的组件在很多的服务器之间共享的。这些组件最终可能会发生故障，当这些组件故障的时候，你需要考虑的是是否会引起更大的故障，所以你需要在设计你的微服务的时候充分考虑到这些通讯过程中常见的风险。

目前一种比较流行的做法是使用基于 HTTP 协议 REST 方式的微服务，这是因为它们很简单。而且基于 HTTP 的这种方式是完全可以接受的，当然这也取决于你当前的使用场景。 假如说你是在客户端或者是API网关中使用 HTTP 进行请求和相应以及进行微服务交互，那么它足够用了。但是，假如你是跨微服务之间进行HTTP的调用长链的话，就像在使用数据库事务那样使用，那么你的应用程序最终会遇到麻烦的问题。

事实上，如果你在内部微服务之间通讯也是通过HTTP的方式，那么我可以理解为你正在使用的是一个单机的应用程序，只是他们是基于进程之间的HTTP，而不是进程内的通讯。

因此，我们在设计微服务的时候，为了其具有更好的弹性，我们应该尽量减少这种跨微服务的通讯。这种情况下，我们可以使基于消息或者事件的异步通讯方式来达到目的。

那么在 .net 中有没有什么现成的解决方案可以用呢？ 答案是肯定的，请向下看。

这一篇主要是对上一篇的一个补充，以及涵盖了微服务的部署方式以及在构建服务器的过程中会遇到的一些技术挑战。

下一节，我们将说一下 基于消息的异步通讯， 我将会给出在 .NET Core 中的具体的解决方案，敬请期待。

本文地址：
作者博客：Savorboard
欢迎转载，请在明显位置给出出处及链接

posted @