这类微服务本身没有自己独立的Owner数据库，也就是这类微服务不直接进行数据库DB层的数据访问和交互，而是直接复用已有的接口服务能力进行组合和组装。

在DDD领域驱动设计的架构分层里面，在领域层上有一个独立的应用层，这个应用层即和这类谈到的领域组合微服务对应。而下层的领域层则由多个微服务提供粗粒度的API接口服务能力。

微服务网关和API网关

===========

在前面我曾经专门写过微服务网关。API网关一般具备独立的服务注册接入，负载均衡和路由能力，而微服务网关一般则是通过和服务注册中心的集成来实现服务注册发现，负载均衡和路由。

简单来说如果当前微服务A模块有100个接口服务。

在有服务注册发现中心的情况下，微服务A模块部署后会被注册中心自动发现，并加入到可用集群列表中。因此在微服务网关和注册中心集成后，所有的接口服务也自动的注册和接入到了微服务网关中。

当用户访问网关提供的服务地址时候整体过程如下图：

微服务架构设计实践总结和思考

在这种场景下可以看到实际并不用一个个的API接口在网关上面注册。但是也无法控制一个微服务哪些具体的接口要接入网关，哪些不接入。同时这里的微服务网关实际上本身也是整体微服务架构体系里面的一个微服务模块，充当了服务消费方的角色。

也就是说APP应用无法受整体微服务框架管辖，那么对应的依赖包，代理SDK等无法下放到外部应用中，那么这部分内容实际是转移到微服务网关上来帮助外部APP应用完成。而对于相对独立的API网关来说，整体的注册和接入过程是在API网关上面独立完成的，而是是控制到API接口服务粒度进行。

当然，你也可以不采用微服务网关，直接采用类似Nginx来进行代理和路由转发，但是这个时候需要手工进行微服务节点的配置和心跳检测实现等。

一个完整的微服务架构你可以看到。比如有三个独立开发团队进行自己的微服务开发，每个团队本身又采用前后端分离的开发模式。那么这个时候实际上每个团队都可以启用自己的注册中心和微服务网关，但是多个团队之间的接口协同则必须控制到API接口这个粒度，即多个团队之间的接口协同采用API网关进行。

这个时候的API网关不属于单个开发团队管理，而属于整个平台层的集成能力。

共性基础JAR包依赖

==========

微服务架构设计实践总结和思考

在微服务架构拆分后，各个微服务仍然会使用或依赖一些共性基础组件，这些组件本身是独立工程项目，可以独立编译构建。

同时各个微服务本身以黑盒Jar包的方式对基础组件包进行依赖。

这类似于在各个微服务里面本身有一个基础的内置SDK包，这个SDK包实现了一些基础共性可复用的方法，或者对一些技术能力进行了统一封装。

在这种场景下如果微服务B对Common包提出新需求，Common包分析后仍然是共性需求需要实现，那么Common包会重新编译构建，并进行了版本升级。

在这种场景下，实际上微服务A和C两个模块的代码没有做任何修改，那么这个时候A和C是否需要重新进行编译构建？

可以很明确的看到这个时候A和C不用进行编译构建，而仅仅需要对微服务B进行编译构建，B在构建的时候会自动获取到最新的Common Jar包。

那么在这个场景下，实际的部署架构下是Common包多个版本共存。

为何要如此处理？

简单来说微服务拆分后，需要做到的就是进行最小化的编译构建和部署，来满足业务需求的变化，能够不重新构建的就不构建，不重新部署的就不部署。只有这样才能够更好的控制住变更范围，也更加容易分析在版本部署后出现问题。

比如上图，如果Common包升级后，微服务A也重新进行了部署构建，那么这个时候问题究竟出在哪里是很难马上做出判断的。

当然也存在其它的一些场景：

比如对于Common包的版本升级，虽然接口没有变化，但是一个共性方法的实现逻辑出现了变化，这个时候必须触发三个微服务部署目录下的JAR包进行升级。而这个场景下本身也有两种方式来做这个事情。

其一是三个微服务重新构建来获取新版本Jar包

其二是将新的JAR包自动分发到三个微服务部署环境或容器中

就当前来说第一种方法很难做，往往都需要对微服务重新进行编译构建，或者重新进行部署。也正是这个原因可以看到，当采用JAR包或SDK代理包这种方式，最大的一个问题就是版本变化的情况下的升级问题。

面向解耦而设计

=======

微服务架构设计实践总结和思考

前面已经谈到，不是你用了Http API接口就是松耦合，如果两个微服务模块之间有大量的API接口交互，那么仍然是一种紧耦合的关系。

谈微服务的时候你会发现，一个微服务要成功正常运行，有大量的底层技术组件或微服务依赖，也有大量的同层的其它微服务模块API接口依赖。如果任何一个依赖的微服务出现问题，或者数据库出现问题都会导致微服务无法正常运行。

不论现在谈缓存，还是谈消息中间件和事件驱动架构，你可以看到都是希望对微服务间进行解耦，对微服务和数据库之间进行解耦。

对于核心的解耦思路实际在前面已经谈到过，即：

对于查询，采用缓存方式进行解耦

对于导入或CUD接口，采用消息中间件解耦

微服务架构设计实践总结和思考

实际上面的思路和经常谈到的CQRS命令查询职责分离思路类似，通过CQRS一开始是为了更好的配合读写分离的数据库使用。但是真正CQRS实现解耦的重点仍然是两个。

其一是将命令作为事件推送到消息中间件处理，以避免出现长周期分布式事务。其次就是启用单独的R读库，可以是数据库，也可以是缓存库，来实现查询功能独立解耦和性能提升。

在实际的实践中，不同开发团队之间交互接口最好能够通过消息中间件或缓存进行彻底解耦，以降低相互之间的依赖和影响。

比如对于微服务A需要推送数据到微服务B，同时需要从微服务C查询数据。那么推送数据库到B的接口可以实现为消息接口，先推送数据到消息中间件；而对于数据的查询则可以在获取数据后进行缓存等。

变更影响分析

======

微服务架构设计实践总结和思考

在微服务架构实践过程中，由于很多接口是采用Http API接口方式进行调用，很多接口修改实际并不会引起编译构建期的错误。因此导致某个微服务接口修改后导致其它微服务模块功能出现异常的情况。当出现问题后，我们才在事后进行修复。

对于服务链监控和链路跟踪是一个事后的行为，重点是发现性能问题而不是帮你去分析服务之间的依赖关系。

小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Java工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频

如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Java）

最后

针对最近很多人都在面试，我这边也整理了相当多的面试专题资料，也有其他大厂的面经。希望可以帮助到大家。

最新整理面试题

上述的面试题答案都整理成文档笔记。也还整理了一些面试资料&最新2021收集的一些大厂的面试真题

最新整理电子书

最新整理大厂面试文档

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持。

大家。

最新整理面试题
[外链图片转存中…(img-wdxrtj0j-1711109389814)]

上述的面试题答案都整理成文档笔记。也还整理了一些面试资料&最新2021收集的一些大厂的面试真题

最新整理电子书

[外链图片转存中…(img-c5IOeyjF-1711109389814)]

最新整理大厂面试文档

[外链图片转存中…(img-PtqfSkr2-1711109389814)]

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持。

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录