关于生命周期:网易七鱼服务治理实践

家喻户晓，业务架构是逐步演进的。随着业务和组织的倒退，架构在继续变动，而这种变动往往会体现在业务域的划分上。动静调整是一个过程，个别是先拆开再治理。简略的拆分会引入依赖和耦合的问题，本文将着重探讨业务架构演进过程中呈现的服务和模块边界问题以及解决这些问题的实际。

1. 业务架构演进

因为七鱼自身复杂度较大，因而在零碎设计之初就是微服务架构，这个架构随着组织和业务的倒退呈现了比拟重大的变动。

这些变动从根本上说，是零碎拆分从“依照性能拆分”，逐步演进到“依照业务畛域”进行拆分的过程。

• 依照性能拆分

晚期，因为大家都是一个团队，每个人负责的内容是依照性能来划定的。这种做法简略、直观而且且合乎“繁多职则”准则。

同时，因为采纳面向数据和过程编程的形式（即须要什么数据本人负责组装，公共逻辑采纳 Jar 包共享的形式进行提取和复用），因而服务和服务之间耦合度不高。

繁多职责、高内聚低耦合，在业务倒退初期撑持了七鱼以极高的速度进行版本和性能迭代。

• 依照业务拆分

随着业务的一直倒退，七鱼逐步形成了几个大的独立售卖业务线，以及一些绝对小但独立性也很强的撑持性业务。

到了这个阶段，能够显著的感觉到晚期依照性能划分的服务不再能适应组织倒退的须要了。最典型的状况就是各个业务组在开发性能的时候都会去改根底服务域的服务。

此时，“繁多职责”准则尽管失去了保留，然而“高内聚、低耦合”准则被毁坏掉了。这导致大量的代码耦合、不合理的服务依赖、公布依赖。这些问题会影响线上零碎稳定性、维护性，拖慢研发效力。

为了解决上述问题，咱们开始了七鱼服务治理我的项目。

2. 服务分级

在辨认耦合和依赖的合理性之前，咱们须要对服务进行分级。没有分级，就没有服务优先级、依赖倒置等技术优化的切入点，也不会有资源和进度的安顿根据。

外围模块非核心模块的这种说法是由来已久的。依照这个思路能够对服务的重要水平度进行分级。

在七鱼中咱们对服务的层级做了如下定义：（留神，这里不包含中间件和数据库等基础设施）

• P0: 零碎级根底服务，如果宕机则导致大面积可感知的服务异样，通常数量很少（底层共用数据的治理和查问等）
• P1: 外围业务根底服务和外围性能，如果呈现了宕机则某个外围业务呈现主流程不可用
• P2: 非核心业务利用和外围业务非核心性能（数据报表、零碎告诉等）
• P3: 外部撑持业务（经营后盾、运维后盾等）

在定义了服务分级之后，咱们有如下的一些根本准则：

• 上层服务不能间接调用下层服务
• 上层服务稳定性可用性不能受限于下层服务
• 同层级服务之间尽可能放弃逻辑隔离
• 底层服务只提供根底能力，并放弃模型稳固

3. 边界问题和解法

在服务分级以及模块划分的根底上，咱们在日常开发中辨认了如下问题：

代码耦合 ：因为咱们经验了从性能拆分到业务拆分的过程。在两头阶段，某些服务承载了多个业务域的业务。尽管拆分之后这些服务被划到了某个业务组，然而代码的耦合仍然存在，Owner 须要依照其余组的需要批改代码。代码耦合会导致如下问题：

1. Owner 无奈齐全掌控本人的代码和打算，响应其余组的需要可能打乱本人的工夫安顿；
2. Owner 无奈排期时，为了赶时间而让非 Owner 来进行开发，因为相熟水平不够，从而引起问题；
3. 上线存在依赖，这又会引入公布权限和公布程序的问题。

不合理依赖 ：又分成了反向依赖、环状依赖、强弱依赖三个方面

1. 反向依赖：底层服务依赖下层服务。调用倒置，造成上层服务稳定性受下层服务影响。
2. 环状依赖：A 依赖 B，B 依赖 A，当然可能是有两头服务的 A->B->C->A 这样的依赖关系。会导致公布程序失控。
3. 不合理的强弱依赖：业务上弱依赖的然而服务调用上是强依赖的。即业务上，某个服务宕机应该不影响外围性能，然而理论后果是该服务宕机之后外围性能不可用。

在七鱼的根底服务边界治理过程中，采纳了如下的一些技术手段来优化服务。为了优化某个场景，可能会联结采纳多个伎俩来共同完成指标。

上面咱们就从场景登程，对这些技术手段做简略的介绍。

4. 边界治理实际

拆分

拆分分为上面几种状况：

• 无共用代码的，个别是各业务方比拟独立的性能，间接拆走即可；

• 有共用代码的，又分成两种状况：共用局部属于根底能力、共用局部属于业务逻辑的一部分：

  • 共用的根底能力能够单出抽取成 Jar 包或者抽取成独立的服务
  • 而如果业务逻辑耦合
• 如果底层模型无奈拆开，这里就走漏出了业务畛域划分存在问题；
• 而如果为了展现的须要，则能够作为聚合服务存在，自身不影响业务畛域划分；

晚期，所有的页面接口承载在同一个服务中，导致该利用不得不被归类为 P0 级。其中大部分接口都是业务外部设置和数据查看，因而属于无共用代码的状况，能够间接拆走。

此外，所有页面都依赖于一系列根底数据，如企业信息、客服信息、权限信息等。这属于为了展现的需要而全局依赖某种根底能力的状况，因而咱们将页面根底数据查问性能独立为一个独自服务。因为所有页面仍然依赖这些数据，所以这个服务还是 P0。

这样的拆分操作，将原来大杂烩的 P0 拆成了一个性能繁多、逻辑简略、代码稳固的 P0，以及一系列 P1 和 P2 服务。

按需加载 + 弱依赖降级

对于依赖多业务方的场景，通常这些依赖有强弱之分。

• 弱依赖：A 场景依赖 B 服务，然而 A 跟 B 并非强相干。即如果 B 不可用，A 的主流程还能够运行。
• 强依赖：A 依赖 B，且 A 场景跟 B 强相干。即如果 B 不可用，A 的主流程走不通。

对于强依赖，必须要保障可用性，同时要做到按需加载以尽可能减少不必要的危险。弱依赖是容许呈现不可用，然而为了避免弱依赖不可用之后呈现不敌对的提醒，须要提供降级计划。

上个例子中页面依赖的所有根底数据，在拆分前是一起加载的。一项数据加载失败就可能导致所有数据返回失败。尽管业务上各个根底数据不肯定都能用到，然而事实上就是强依赖了所有根底数据。

然而因为大量的数据是共用的，因而为每个页面独自写一个数据封装接口又是十分不划算的。所以咱们在新数据加载服务中，引入 GraphQL 来解决这个问题。

GraphQL 要求将数据拆分成根底的单元，通过组装 query 语句来向 Server 查问，query 语句既蕴含了原子数据项，又蕴含了最终想要的数据格式。

相较于为每个页面写一个独自的数据接口，以满足按需加载的须要，这样做的益处很多：

• 原子数据的查问复用
• 按需加载
• 数据格式灵便可调
• 扩大容易
• 提供了丰盛的数据运算和拼装能能力
• 跨前端技术栈

这里不对 GraphQL 做过多开展，感兴趣能够参考 https://graphql.org/。

降级则通常有 Hystrix 或者 Sentinel 来实现。这里也不做过多的开展。

边界变更

业务畛域往往有多种划分形式，然而有时候最合乎业务畛域的划分形式不肯定是最事实牢靠的划分形式。

从代码维护性和线上稳固角度思考，有时候必须要对边界做从新划分。这里有几个参考准则：

• 缩小 P0 利用数量
• 模型稳固、调用量大、有全局影响的业务逻辑能够放在一起
• 调整之后模型边界须要有明确的业务含意以便于了解和保护，不能硬凑。

七鱼的“企业信息管理”和“订单与服务包”开始分处于两个服务。然而日常工作中发现：企业治理调用量大且模型稳固；订单逻辑简单变更多，但大部分调用量很小，只有“服务包查问”调用量很大且模型稳固。

咱们将“服务包查问”的性能迁徙到“企业信息管理”中，从概念上将“企业信息管理”模块变更成了“企业运行时治理”。通过边界变更，咱们将两个 P0 级服务拆成一个 P0 一个 P1，同时也保障了复杂多变的业务不影响稳固的底层服务。

畛域模型优化

畛域模型如果呈现了对其余畛域数据的耦合，那么代码也肯定是强耦合的。然而只有能确定业务域划分没问题，则能够通过畛域模型优化的形式来解除耦合。

通常的做法是用 KV 表存储其余畛域的关联数据、用事件驱动异步更新这个 KV 表，这样以后的畛域模型就能够不关注数据的业务含意。

不关怀业务含意只是存储数据，则底层模型就能够做到通用化并保持稳定，将反向依赖和代码耦合彻底清除掉。

七鱼的 User 表中除了根底的用户信息，还保留了“最近和最初分割工夫”等业务方的数据。显然，这种层面的耦合会导致 User 模型被净化。然而，业务性能上这些信息是展现 User 信息必须的。

思考到当初 User 须要展现的是“最新分割工夫”，那么后续就有可能要展现“最新工单工夫”、“最新短信工夫”等等。如果继续去适配需要改变代码，则就造成了代码耦合。

从模型层面上做调整，减少 UserInfoExt 表，用键值对的模式提供扩大信息的存储，业务零碎通过被动更新 K - V 值的形式来更新数据。这样就保障了 User 模型层的稳固、调用关系的优化、代码层的齐全解耦。

能力上推

接畛域模型优化。

畛域模型的优化老本很高，理论中不肯定有资源来实现这种重构。特地是波及到 P0 级利用的底层模型变更，危险往往很大。

在须要底层数据和下层数据关联展现的场景中。关联展现的逻辑能够不承载在底层模型上，而是将这部分组装的过程上推到下层业务零碎中去，从而解除底层模型的数据耦合。

接下面的例子，因为 User 是全局最外围的服务之一，革新的危险很大，最初咱们并没有采纳畛域模型优化的计划。而是在这里做能力上推，将 P0 级别的能力推到 P1 级别去。

User 外围模型删除“最近最初分割工夫”，获取信息的过程上推到 User-Gateway 服务中来实现。User-Gateway 尽管是属于根底业务域，但仅负责提供页面须要的用户数据，宕机也不影响底层会话、工单等数据流，因而属于 P1 级别的服务。

事件驱动

当业务流程耦合了其余业务域的流程时。有两个可能性存在：

• 强依赖下层业务流程的后果；
• 不依赖下层业务的后果。

如果不依赖下层业务的后果，那么能够通过生命周期事件的形式，将流程和外围节点播送进来，让下层业务独立实现后续的流程。

为了保障生命周期事件可能被顺利生产并触发业务逻辑。须要在中间件层保障音讯的触达和幂等性，同时假如在极其状况下呈现了执行失败，则须要提供音讯弥补执行的机制。

最后，七鱼的企业注册的流程简略的串行过程，两头任何一个设置没做完，企业都没法初始化实现从而导致企业注册失败。

这种失败其实是很不划算的，即使某个业务没有初始化好，也能够试用其余业务，不至于齐全失落一个潜在客户。

咱们通过对企业注册生命周期进行建模，将“企业创立”事件播送进去，用事件驱动来实现整个注册过程。这样做的益处在于：

• 新增业务的初始化不会影响现有的官网代码，从而解除代码耦合；
• 局部业务的初始化失败不会影响整体的注册流程，解除对繁多业务的强依赖；
• 官网作为 P1 级别服务，间接调用的只有 P0 的企业和客服治理服务，因而不存在反向依赖。

异步调用

接事件驱动。

当业务流程中底层流程依赖下层业务的后果时，解决这种依赖的形式有两种：

• 革新畛域模型以解除强依赖。尽管比拟彻底，然而往往老本很大。
• 间接调用并依赖后果；这样就造成了调用的反向依赖。

异步调用是为了解决间接调用产生的代码耦合和反向依赖的问题。通过事件驱动的形式获取下层业务的后果，而不是间接调用并获取后果。跟一般音讯驱动不同，异步调用依赖返回的后果；跟间接调用不同，不依赖被调用方的接口。

在七鱼，删除客服须要校验：是否有未实现的电话、会话、工单等。因为删除客服是属于根本的客服治理，所以在 P0 级服务中。而为了校验业务信息，则必须调用 P1 级服务。

如果采纳畛域模型重构的形式，让业务层将“是否删除”告知给“客服治理”并随着业务流程实时更新，则能够解除该反向依赖。然而这种形式须要侵入各个业务方的外围流程中，且须要批改以后业务逻辑，老本过高。

在七鱼，咱们设计实现了一个异步调用的组件。假如删除客服关注 A、B、C 三个服务的后果，则 ABC 则向注册核心注册关注删除事件。每次删除过程都会拿到关注列表，而后播送删除音讯，业务方收到音讯之后将后果返回到注册核心。删除客服依赖注册核心的告诉机制获取到后果并决定是否实现删除。

因为该过程是异步驱动的，所以会有一个 Timeout 期待过程。这里有两个模式，一个是强依赖模式，Timeout 则操作失败；另外一种是弱依赖模式，Timeout 仍然能够操作胜利。

这样做的益处在于：

• 能够解除掉代码层的耦合，假如新增须要校验的业务方 D，在 D 服务上注册关注删除事件即可。
• 这个革新对现有业务逻辑和外围流程没有影响，变更范畴很无限。
• 不是间接调用，因而不会呈现反向依赖。

防腐层

接事件驱动和异步调用。

最现实的状况下，业务方可能响应外围零碎的驱动事件，从而实现残缺的业务流程。

然而实际上，第三方因为不受本团队的管制，开发排期不可控、开发能源不强。为了能继续推动本团队的优化更新，须要依赖业务方的代码全副封装在一起并从 P0 级服务中剥离进来，避免对外围模型和外围流程造成净化。

咱们在做注册解耦的时候，须要业务方响应企业注册的生命周期事件。在做客服删除的解耦时，则须要业务方集成异步调用组件。

这就导致咱们的开发依赖了其余业务团队。为此咱们独自减少一个防腐层利用，将响应生命周期事件和集成异步掉调用组件的逻辑迁徙过来，最初实现了革新。

这样做，咱们的开发才可能按时顺利完成，同时跟业务零碎的耦合被限度在一个独自的利用中限度了腐化的范畴，前期业务方迁徙也变得非常容易。

5. 总结

拆分、按需加载、弱依赖降级、边界变更、事件驱动这些伎俩是最开始做治理时的切入点。随着治理的深刻，很多问题不是简略的拆分和变更能解决的。只有通过畛域模型革新，能力找到一种办法将服务残缺解开来。

然而，模型革新的老本往往是很高的，事实操作中咱们不得不采纳防腐层、能力上推、异步调用等伎俩来确保革新能理论进行上来，而不是陷入到无穷无尽的排期、测试中。

在梳理好了边界关系之后，下层服务还是可能影响底层服务稳定性的。次要的场景在不受控的调用产生的零碎压力。这属于熔断限流降级的领域，这里就不开展做具体探讨了。

更多技术干货，欢送关注【网易智企技术 +】微信公众号