你要是设置成多数据源，未来系统故障时查找数据方面的问题多麻烦啊。
对于业务需要，真的是有比如两个数据源的，假设是主数据源A和辅数据源B，那么可以基于辅数据源B搭建一个微服务，暴露API，由主数据源服务在需要时调用辅数据源的服务的API就好。
不过如果辅数据源可能只有一个最简单的查询，没有更多 *** 作了，你在主数据源服务中直接配置多数据源也没问题。
我仔细想了一下，似乎还是各个数据源单独起一个自己的服务这样更有“分布式微服务”的样子呢。
什么是微服务
微服务架构的系统是一个分布式的系统，按业务进行划分为独立的服务单元，解决单体系统的不足，同时也满足越来越复杂的业务需求。
一.单体架构
1.1什么是单体架构
在软件设计的时候经常提到和使用经典的3层模型，即表现层，业务逻辑层，数据访问层。虽然在软件设计中划分了3层模型，但是对业务场景没有划分，一个典型的单体架构就是将所有的业务场景的表现层，业务逻辑层，数据访问层放在一个工程中最终经过编译，打包，部署在一台服务器上。此时服务架构如图：
1.2单体架构存在的不足
在小型应用的初期，访问量小的时候这种架构的性价比还是比较高的，开发速度快，成本低，但是随着业务的发展，逻辑越来越复杂，代码量越来越大，代码得可读性和可维护性越来越低。用户的增加，访问量越来越多单体架构的应用并发能力十分有限。可能会有人想到将单体应用进行集群部署，并增加负载均衡服务器，再来个缓存服务器和文件服务器，数据库再搞个读写分离。这种架构如图：
这种架构虽然有一定的并发能力，及应对一定复杂业务，但是依然没有改变系统为单体架构的事实。大量的业务必然会有大量的代码，代码得可读性和可维护性依然很差。如果面对海量的用户，它的并发能力依然不够。基于以上单体架构系统的不足，提出了微服务架构。
二.微服务
2.1什么是微服务
说了这么多现在来看看到底什么是微服务。微服务最初是由Martin Fowler提出来的他的理解如下：
微服务架构就是将单一程序开发成一个微服务，每个微服务运行在自己的进程中，并使用轻量级的机制通信，通常是HTTP RESTFUL API。这些服务围绕业务能力来划分，并通过自动化部署机制来独立部署。这些服务可以使用不同的编程语言，不同数据库，以保证最低限度的集中式管理。
1
总结起来微服务就是将一个单体架构的应用按业务划分为一个个的独立运行的程序即服务，它们之间通过HTTP协议进行通信（也可以采用消息队列来通信，如RoocketMQ，Kafaka等），可以采用不同的编程语言，使用不同的存储技术，自动化部署（如Jenkins）减少人为控制，降低出错概率。服务数量越多，管理起来越复杂，因此采用集中化管理。例如Eureka，Zookeeper等都是比较常见的服务集中化管理框架。
2.2微服务的优势
1）将复杂的业务拆分成多个小的业务，每个业务拆分成一个服务，将复杂的问题简单化。利于分工，降低新人的学习成本。
2）微服务系统是分布式系统，业务与业务之间完全解耦，随着业务的增加可以根据业务再拆分，具有极强的横向扩展能力。面对搞并发的场景可以将服务集群化部署，加强系统负载能力。
3）服务间采用HTTP协议通信，服务与服务之间完全独立。每个服务可以根据业务场景选取合适的编程语言和数据库。
4）微服务每个服务都是独立部署的，每个服务的修改和部署对其他服务没有影响。
2.3微服务和SOA的关系
SOA即面向服务的架构，SOA是根据企业服务总线（ESB）模式来整合集成大量单一庞大的系统，微服务可以说是SOA的一种实现，将复杂的业务组件化。但它比ESB实现的SOA更加的轻便敏捷和简单。
在微服务中，一个逻辑上原子 *** 作可以经常跨越多个微服务。即使是单片系统也可能使用多个数据库或消息传递解决方案。使用多个独立的数据存储解决方案，如果其中一个分布式流程参与者出现故障，我们就会面临数据不一致的风险 - 例如在未下订单的情况下向客户收费或未通知客户订单成功。在本文中，我想分享一些我为使微服务之间的数据最终保持一致而学到的技术。
为什么实现这一目标如此具有挑战性？只要我们有多个存储数据的地方（不在单个数据库中），就不能自动解决一致性问题，工程师在设计系统时需要注意一致性。 目前，在我看来，业界还没有一个广为人知的解决方案，可以在多个不同的数据源中自动更新数据 - 我们可能不应该等待很快就能获得一个。
以自动且无障碍的方式解决该问题的一种尝试是实现两阶段提交（2PC）模式的XA协议。但在现代高规模应用中（特别是在云环境中），2PC似乎表现不佳。为了消除2PC的缺点，我们必须交易ACID for BASE并根据要求以不同方式覆盖一致性问题。
在多个微服务中处理一致性问题的最着名的方法是Saga模式。 您可以将Sagas视为多个事务的应用程序级分布式协调 。 根据用例和要求，您可以优化自己的Saga实施。 相反，XA协议试图涵盖所有场景。 Saga模式也不是新的。 它在过去已知并用于ESB和SOA体系结构中。 最后，它成功地转变为微服务世界。 跨越多个服务的每个原子业务 *** 作可能包含技术级别的多个事务。 Saga Pattern的关键思想是 能够回滚其中一个单独的交易 。 众所周知，开箱即用的已经提交的单个事务无法进行回滚。 但这是通过引入 补偿 *** 作来 实现的 - 通过引入“取消” *** 作。
除了 取消 之外，您还应该考虑使您的服务具有 幂等性 ，以便在出现故障时重试或重新启动某些 *** 作。 应监控故障，并应积极主动地应对故障。
如果在进程的中间 负责调用补偿 *** 作的系统崩溃或重新启动 ，该怎么办？ 在这种情况下，用户可能会收到错误消息，并且应该触发补偿逻辑，或者 - 当处理异步用户请求时，应该恢复执行逻辑。
要查找崩溃的事务并恢复 *** 作或应用补偿，我们需要协调来自多个服务的数据。 对账
是在金融领域工作的工程师所熟悉的技术。你有没有想过银行如何确保你的资金转移不会丢失，或者两个不同的银行之间如何汇款？快速回答是对账。
回到微服务，使用相同的原则，我们可以在一些 动作触发器 上协调来自多个服务的数据。当检测到故障时，可以按计划或由监控系统触发 *** 作。最简单的方法是运行逐记录比较。可以通过 比较聚合值来 优化该过程。在这种情况下，其中一个系统将成为每条记录的真实来源。
想象一下多步骤交易。如何在对帐期间确定哪些事务可能已失败以及哪些步骤失败？一种解决方案是 检查每个事务的状态 。在某些情况下，此功能不可用（想象一下发送电子邮件或生成其他类型消息的无状态邮件服务）。在其他一些情况下，您可能希望立即了解事务状态，尤其是在具有许多步骤的复杂方案中。例如，预订航班，酒店和转机的多步订单。
在这些情况下，事件日志可以提供帮助。 记录是一种简单但功能强大的技术 。 许多分布式系统依赖于日志 。 “ 预写日志记录 ”是数据库在内部实现事务行为或维护副本之间一致性的方式。相同的技术可以应用于微服务设计。在进行实际数据更改之前，服务会写入有关其进行更改的意图的日志条目。实际上， 事件日志可以是协调服务所拥有的数据库中的表或集合 。
事件日志不仅可用于 恢复事务处理 ，还可用于为系统用户，客户或支持团队提供 可见性 。但是，在简单方案中，服务日志可能是冗余的， 状态端点或状态字段 就足够了。
到目前为止，您可能认为sagas只是编配(orchestration )方案的一部分。但是sagas也可以用于编排(choreography )，每个微服务只知道过程的一部分。 Sagas包括处理分布式事务的正流和负流的知识。在编排(choreography )中，每个分布式事务参与者都具有这种知识。
到目前为止描述的一致性解决方案并不容易。他们确实很复杂。但有一种更简单的方法： 一次修改一个数据源 。我们可以将这两个步骤分开，而不是改变服务的状态并在一个过程中发出事件。
在主要业务 *** 作中，我们修改自己的服务状态，而单独的进程可靠地捕获更改并生成事件。这种技术称为变更数据捕获（CDC）。实现此方法的一些技术是Kafka Connect或Debezium。
但是，有时候不需要特定的框架。一些数据库提供了一种友好的方式来拖尾其 *** 作日志，例如MongoDB Oplog。如果数据库中没有此类功能，则可以通过时间戳轮询更改，或使用上次处理的不可变记录ID查询更改。避免不一致的关键是使数据更改通知成为一个单独的过程。在这种情况下，数据库记录是 单一的事实来源 。只有在首先发生变化时才会捕获更改。
更改数据捕获的最大缺点是业务逻辑的分离。更改捕获过程很可能与更改逻辑本身分开存在于您的代码库中 - 这很不方便。最知名的变更数据捕获应用程序是与域无关的变更复制，例如与数据仓库共享数据。对于域事件，最好采用不同的机制，例如明确发送事件。
让我们来看看颠倒的单一事实来源。如果不是先写入数据库，而是先触发一个事件，然后与自己和其他服务共享。在这种情况下，事件成为事实的唯一来源。这将是一种事件源的形式，其中我们自己的服务状态有效地成为读取模型，并且每个事件都是写入模型。
“事件优先”方法面临的挑战也是CQRS本身的挑战。想象一下，在下订单之前，我们想要检查商品的可用性。如果两个实例同时收到同一项目的订单怎么办？两者都将同时检查读取模型中的库存并发出订单事件。如果没有某种覆盖方案，我们可能会遇到麻烦。
处理这些情况的常用方法是乐观并发：将读取模型版本放入事件中，如果读取模型已在消费者端更新，则在消费者端忽略它。另一种解决方案是使用悲观并发控制，例如在检查项目可用性时为项目创建锁定。
“事件优先”方法的另一个挑战是任何事件驱动架构的挑战 - 事件的顺序。多个并发消费者以错误的顺序处理事件可能会给我们带来另一种一致性问题，例如处理尚未创建的客户的订单。
诸如Kafka或AWS Kinesis之类的数据流解决方案可以保证将按顺序处理与单个实体相关的事件（例如，仅在创建用户之后为客户创建订单）。例如，在Kafka中，您可以按用户ID对主题进行分区，以便与单个用户相关的所有事件将由分配给该分区的单个使用者处理，从而允许按顺序处理它们。相反，在Message Brokers中，消息队列具有一个订单，但是多个并发消费者在给定顺序中进行消息处理（如果不是不可能的话）。在这种情况下，您可能会遇到并发问题。
实际上，在需要线性化的情况下或在具有许多数据约束的情况（例如唯一性检查）中，难以实现“事件优先”方法。但它在其他情况下确实很有用。但是，由于其异步性质，仍然需要解决并发和竞争条件的挑战。
有许多方法可以将系统拆分为多个服务。我们努力将单独的微服务与单独的域匹配。但域名有多细化？有时很难将域与子域或聚合根区分开来。没有简单的规则来定义您的微服务拆分。
虽然匹配帐户余额至关重要，但有许多用例，其中一致性不那么重要。想象一下，为分析或统计目的收集数据。即使我们从系统中随机丢失了10％的数据，也很可能不会影响分析的业务价值。
数据的原子更新需要两个不同系统之间达成共识，如果单个值为0或1则达成协议。当涉及到微服务时，它归结为两个参与者之间的一致性问题，并且所有实际解决方案都遵循一条经验法则：
在给定时刻，对于每个数据记录，您需要找到系统信任的数据源
事实的来源可能是事件，数据库或其中一项服务。实现微服务系统的一致性是开发人员的责任。我的方法如下：
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）