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

用户提供最终价值。

每个服务运行在其独立的进程中，服务和服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

2. 微服务架构与SOA架构的区别

微服务是真正的分布式的、去中心化的。把所有的“思考”逻辑包括路由、消息解析等放在服务内部，去掉一个大一统的 ESB，服务间轻通信，是比 SOA 更彻底的拆分。

微服务架构强调的重点是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用，这些小应用之间通过服务完成交互和集成。

3. 微服务架构引发的问题

随着整个业务数据被分散在各个子服务之后，也带来了两个最明显的问题。

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

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

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

推荐使用第二种，利用 Spring Boot 和 MongoDB 可以轻松的解决

（编辑：盐城站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!