什么是分布式微服务架构？三分钟彻底弄懂什么是分布式和微服务 _微服务架构

一、微服务简介1. 微服务的诞生
微服务是基于分而治之的思想演化出来的。过去传统的一个大型而又全面的系统，随着互联网的发展已经很难满足市场对技术的需求，于是我们从单独架构发展到分布式架构，又从分布式架构发展到 SOA 架构，服务不断的被拆分和分解，粒度也越来越小，直到微服务架构的诞生。
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。
每个服务运行在其独立的进程中，服务和服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。
2. 微服务架构与SOA架构的区别
微服务是真正的分布式的、去中心化的。把所有的“思考”逻辑包括路由、消息解析等放在服务内部，去掉一个大一统的 ESB，服务间轻通信，是比 SOA 更彻底的拆分。
微服务架构强调的重点是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用，这些小应用之间通过服务完成交互和集成。
3. 微服务架构引发的问题
随着整个业务数据被分散在各个子服务之后，也带来了两个最明显的问题。

业务管理系统对数据完整性查询，比如分页查询、多条件查询等，数据被割裂后如何来整合?
数据分析挖掘，这些需求可能需要分析全量的数据，并且在分析时不能影响到当前业务

从技术方案来讲，我们一般有两种选择来处理这些问题，第一种是在线处理数据，第二种是离线处理数据。

在线处理数据的方案：通过微服务提供的接口来获取数据，然后进行数据整合，不过这种方式有着明显的弊端，就是调用者需要编写大量的代码进行数据处理。其次在对各个微服务进行调取数据时会影响微服务的正常业务处理性能
离线处理数据方案：将业务数据准实时的同步到另外一个数据库中，在同步的过程中进行数据整合处理，以满足业务方对数据的需求，数据同步过来后，再提供另外一个服务接口专业负责对外输出数据信息，这种方案有两个特点：①数据同步方案是关键，技术选型有很多，如何选择切合公司业务的技术方案；②离线数据处理对微服务正常业务处理没有影响。

推荐使用第二种，利用 Spring Boot 和 MongoDB 可以轻松的解决这个问题，通过技术手段将分裂到 N 个微服务的数据同步到 MongoDB 集群中，在同步的过程中进行数据清洗，来满足公司的各项业务需求
在微服务架构中，有大难题，那就是服务故障的传播性、服务的划分和分布式事务。
二、CAP 理论

Consistency ：指数据的强一致性。如果写入某个数据成功，之后读取，读到的都是新写入的数据：如果写入失败，之后读取的都不是写入失败的数据。
Availability ：指服务的可用性
Partition-tolerance ：指分区容错

在分布式系统中 P是基本要求，而单体服务是 CA 系统，微服务系统通常是 AP 系统，即同时满足了可用性和分区容错。
这就有了个难题：在分布式系统中如何保证数据的一致性？这就是大家经常讨论的分布式事务
三、分布式事务在微服务架构中，分布式事务般的解决办法就是两阶段提交或者三阶段提交，不管使用哪都存在事务失败，导致数据不致的情况，关键时刻还得人工去恢复数据。

第一阶段：发起一个分布式事务，交给事务协调器TC处理，TC向多有的参与事务的节点发送处理事务操作的准备操作。所有的参与节点执行准备操作，将Undo和Redo 信息写进日志，并向事务管理器返回准备操作是否成功
第二阶段：事务管理器收集所有节点的准备操作是否成功，如果都成功，则通知所有的节点执行提交操作；如果有个失败，则执行回滚操作

文章插图

两阶段提交，将事务分成两部分能够大大提高分布式事务成功的概率。如果在第阶段都成功了，而执行第阶段的某个节点失败，仍然导致数据的不准确，这时一般需要人工去处理，这就是当初在第一步记录日志的原因。另外，如果分布式事务涉及的节点很多，某个节点的网络出现异常会导致整个事务处于阻塞状态，大大降低数据库的性能。所以一般情况下，尽量少用分布式事务。