小心掉进微服务的“坑”_被微服务平台骗了怎么样-CSDN博客

本文链接：https://blog.csdn.net/csdn_wyl2016/article/details/131868422

文章目录

引言

天下大势，分久必合，合久必分，这是历史上无数次战争和政治斗争所证明的真理。而今，这一理论同样适用于当今的技术发展，尤其是在微服务的架构设计中。

随着企业的不断发展和壮大，原来单一的系统架构逐渐无法满足日益增长的需求。为了更好地应对这些变化，越来越多的企业开始采用微服务架构。微服务架构的核心思想是将整个系统分解成多个独立的服务，每个服务都可以独立部署、扩展和维护。

这种架构设计的优势在于可以更好地满足业务需求的变化，提高了系统的灵活性和可维护性。然而，随着企业不断扩大规模和增加服务数量，系统的复杂度也随之增加。因此，微服务的架构设计也需要随之进行分分合合，以适应系统不断变化的需求。

在微服务架构设计中，分是指将整个系统分解成多个独立的服务，每个服务都可以独立部署、扩展和维护。这种设计方式可以提高系统的灵活性和可维护性，降低了整个系统的复杂度。而合则是指将多个独立的服务组合成一个更大的系统，形成一个更完整的功能。

总的来说，微服务架构的设计需要在分分合合之间取得平衡。只有在合适的时机进行分解和组合，才能够实现系统的灵活性和可维护性。而对于设计者来说，需要充分考虑服务之间的通信、复用和依赖关系等因素，以确保系统的高可用性和可扩展性。

背景介绍

根据微服务的定义，微服务建议将单个应用程序划分为一组小型服务。然而，对于“小”的定义是由使用者决定的，因此这个服务是否应该拆分，拆分成什么样，在某些情况下可能存在分歧。

因此，在这样一个背景之下，如果拆分不当可能会出现以下问题：

沟通和协调问题：各个服务之间的沟通和协调可能会变得更加复杂，需要确保各个服务之间的交互能够顺利进行。
服务依赖关系问题：服务之间的依赖关系可能会变得更加复杂，需要确保各个服务之间的依赖关系清晰明确，避免出现冲突和不一致的情况。
系统性能问题：由于微服务之间通信需要通过网络，因此可能存在较长的调用链路，这会影响服务的响应速度和吞吐量。
部署和维护问题：部署和维护可能会变得更加复杂，需要确保各个服务能够顺利部署和维护。
集成问题：微服务之间的集成问题可能会导致集成测试和部署困难，从而增加了开发和维护的成本。
故障传播问题：当一个微服务发生故障时，可能会导致整个应用程序的不可用，这会影响用户的体验和业务的稳定性。

调用链路分析

接下来，我们将调用链路作为一个问题，探讨不当的服务划分所带来的具体影响。

调用链路增长趋势：理论上如果你有N个微服务，那么你的调用链路就有N*(N-1)条。

比如，当有3个微服务，可能会存在6条链路。

当有5个微服务，存在的链路将增长至20条。

影响一：重复调用

C和D都被多次调用，流量被额外放大，末尾服务压力巨大。

影响二：循环依赖

关系理不清，问题定位困难，互相消耗，最终也不知道究竟是谁影响了谁？

影响三：链路混乱

链路又长又臭，关系理不清，问题定位困难，迭代效率低。

治理思路

重复调用

在需求迭代过程中，重复调用可能并非一开始就存在，而是因为多个开发人员在代码逻辑和上下文理解上存在不足，导致出现了重复调用的情况。针对这一问题，我们可以采取链路追踪的方法来发现重复调用，并结合业务代码的上下文逻辑，将重复调用的逻辑下沉并内聚，以避免重复的调用造成的性能问题。另外，为了避免重复调用造成的问题，可以在编写代码时尽量避免出现多次调用同一个方法或函数的情况。可以采用缓存技术或者封装好的类库等方式来解决这一问题，避免因为调用不同实现而产生的重复调用。此外，还可以通过设计良好的模块化架构来减少重复调用的发生。例如，将相关的方法和函数封装到同一个模块中，可以有效避免重复调用的问题。

在实际的开发过程中，重复调用的问题可能并不总是显而易见的，需要我们有耐心地去查找和分析。如果在发现问题后能够及时进行修复，可以避免不必要的性能问题和代码混乱的情况，提高代码的可维护性和可读性。

循环依赖

在解决循环依赖问题时，我们需要重新审视应用的分层结构以及依赖关系划分。因为循环依赖通常源于业务场景中的问题，我们需要仔细定义各应用之间的职责范围和依赖关系，以便重新划分应用之间的层级结构，消除循环依赖问题。

链路混乱

为了解决链路混乱的问题，我们需要进行应用架构设计的优化。在设计应用架构时，我们需要考虑多个团队之间的合作和沟通，以及各自领域内的业务职责定义。如果团队过大，那么就有可能导致应用的架构设计出现混乱。

我们可以借鉴“两个披萨原则”来衡量团队大小。如果两个披萨不足以喂饱一个项目团队，那么这个团队可能就显得太大了。因此，在应用架构设计过程中，我们需要充分理解与识别业务的核心问题，根据这些问题划分出相关领域，并确认领域职责以及边界。在领域与领域之间的依赖关系上，我们需要遵循“上层应用可以依赖任意一层下层应用，但下层应用不能依赖上层应用”的原则。

应用领域划分清楚后，我们还需要实现各应用领域内的垂直域，按照应用领域的划分思想来实现，避免层级太多之后，同样容易出现链路混乱，依赖过多的现象。这样就能够有效地提高应用的架构设计质量，减少链路混乱的问题。

服务的拆分与合并

永恒不变的是变化，这个真理同样适用于业务的发展与变化。由于环境的不断变化，组织结构、研发团队等方面也可能随之发生改变。因此，有时候我们不能只是将服务的划分看作是一个是非问题，而应该在现在的环境以及未来的规划中，重新审视服务的划分。我们需要思考：在当前环境下，是否需要对服务进行重新划分，划分是否过于细致，或者是否需要合并或拆分。只有这样，我们才能更好地适应业务的发展和变化。