领域驱动设计下的服务高可用设计

我们知道领域驱动设计已经逐步应用落地,系统架构设计在后微服务时代,更快速的向DDD演进,微服务架构的设计面向系统维度的拆分,实现快速的独立部署,解决DevOps的效能问题,进入后微服务时代,领域模型的理解逐步深入,简单的设计微服务架构会使得系统过于松散,尤其在服务的高可用设计上,领域驱动设计的边界如何考量和把控,成为我们后微服务架构设计必须考虑的要素。

今天的话题是讨论领域驱动设计下的服务高可用设计,首先举个例子,A调用B,B的服务高可用如何设计?

方案一,A与B实现1:1的服务保障能力,RPC调用的SLA保障;

方案二,A与B通过共享资源,降低RPC损耗,基于共享资源实现SLA保障;

方案三,B提供二方包,封装RPC调用和存储资源,提供A本地调用的SLA保障。

领域驱动设计下的服务高可用设计

如何进行三种方案的技术选型?

方案一,优点是架构简单,功能松耦合,领域定义清晰;缺点是1:1流量的服务保障,B服务的容器资源、调用性能、稳定性等衍生的稳定性风险,会有较大的高可用设计成本,尤其是若B提供的是一些配置数据,这个架构设计的性价比较低。

方案二,优点是架构不复杂,功能清晰,领域定义明确,解决了静态数据1:1流量调度的弊端;缺点是A服务依赖了B服务的存储资源,在一定程度上形成了耦合,这体现在变更后的整体发布。这个架构设计降低了高可用设计的成本,但是随着时间推移A和B会演进成大泥潭。

方案三,优点是功能清晰,领域定义明确,解决了A依赖B的耦合问题;缺点是架构复杂,B提供的Jar包变更仍需要A发布,存在一定的耦合。若A提供SPI的服务能力,成本会降低,但是A的高可用设计成本会加大。这个架构设计在选型时需慎重。

微服务的九个核心特征:围绕业务能力构建,分散治理,通过服务来实现独立自治的组件,产品化思维,数据去中心化,强终端弱管道,容错性设计,演进式设计,基础设施自动化。

其中,通过服务来实现独立自治的组件,微服务之所以强调通过服务Service而不是类库Library来构建组建,是因为类库在编译期静态连接到程序里,通过本地调用来提供功能,而服务时通过进程外调度,通过远程调度来提供服务。尽管远程服务有更高昂的调用成本,但这是为组件带来自治与隔离能力的必要代价。—— 摘自《凤凰架构》

那么,基于微服务的设计理论基础,以及通过实践得出效果来看,绝大多数的业务架构都应该基于通过服务Service的模式进行设计,那么这就涉及到高可用的设计归属域的边界问题?就我个人而言,A服务已经完成领域的建模,那么高可用的设计则归属A服务,并与B确认服务的SLA。

其中,数据去中心化,微服务明确提倡数据应该按领域分散管理、更新、维护、存储,那么通过共享资源的架构设计,这是否违背了微服务的设计原则?共享资源使得领域都必须修改和映射到同一个实体之中,这很可能使不同服务之间相互影响而丧失独立性。除此之外,共享资源带来的潜在隐患,B若是Ops系统,其发生问题可能影响到核心链路上的系统,比如A。

那么,回到最开始的话题,A调用B,B的高可用设计就有了设计的变化。

领域驱动设计下的服务高可用设计

如何进行三个方案的调整?

方案二,共享缓存的架构设计,会造成A与B之间相互影响,进而调成独立缓存的架构设计。A与B共享缓存的设计,常见在系统已拆分,但组织架构未拆分的情况,这隐藏的约束是共享缓存专门服务于该业务,而非为领域服务。

方案三,B提供二方包嵌入A,会造成A与B之间的相互影响,进而调整对B服务进行架构拆分的设计。这其实是领域设计已经逐步演进成需要对B服务进行垂直拆分的诉求,这也是B Jar出现的原罪,由此更应对B进行领域内的系统拆分。

综述,今天讨论的内容就结束了,主要讨论了在分布式架构设计中服务间调用的高可用设计,以上不同的方案都有过实践,虽说代码写在哪里都可以,但领域驱动设计的愿景就是降低软件架构的设计复杂度,否则,终将是行走的恐龙巨兽。

上一篇:Mac配置Tomcat及Servlet虚拟目录设置


下一篇:架构风格与协同之间设计考量