架构师进阶之路 - 微服务怎么划分

这篇具有很好参考价值的文章主要介绍了架构师进阶之路 - 微服务怎么划分。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

目录

微服务划分目标

业务、技术、团队导向规划服务

领域检查

依赖DAG检查

分布式事务检查

性能分布检查

稳定(易变)性检查

调用链检查


架构师进阶之路 - 微服务怎么划分,架构,java,开发语言

 

微服务划分目标

我们常说服务的合理划分是微服务成功的重中之重,一个合理的服务划分应该符合一下几点:

  • 符合团队结构 服务的落地与维护靠人,靠的是执行团队(包含业务、产品、技术、测试与运维团队),所以服务的设定一定是与团队结构相辅相成的,同一个系统不同的执行团队往往会有不同的且都合理的服务划分方案
  • 业务边界清晰 各服务有清晰的责任及边界,一个服务对应一块业务,服务间多为单向依赖
  • 最小化地变更 新增或变更业务上有很明确的服务对应,或是新增服务或是扩展某些服务,很少出现既可以在这个服务上实现也可以在那个服务上实现这种摸棱两可的情况,在符合上述条件前提下某一业务需求地变更受影响的服务应该尽可能地少
  • 最大化地复用 服务的复用是服务化的一个重大优势,服务设定要考虑复用的场景,在符合上述条件的前提下应该尽可能最大化地实现服务复用
  • 性能稳定简洁 上述条件更多的是业务导向,从技术上服务设定的核心要关注对性能的影响、是否稳定及架构是否简洁,是否要引入额外的中间件等

业务、技术、团队导向规划服务

我们必须明确的是,服务不是越细越好,服务划分的第一要素是先以业务域拆分,再以技术视角拆分,结合团队的规模、能力确定服务间的关系与边界。服务划分完毕要做进行以下几方面的检查确保服务划分的合理性。

1、领域检查

领域检查可以为我们的服务划分提供方向性的指导,使服务划分更明确、各有规划性。

领域通用语言检查:确保在一个领域内产研描述的同一个对象就是同一个对象,比如质量验收中的巡检,北京的“鲁班行动”由于历史原因既是鲁班巡检也是验后巡检,都是同一类人在做(品质监察),西部的从验收模版就进行了区分鲁班巡检和验后巡检吗,这就是典型的同一个领域内语言描述不统一,导致的问题也很多既有线上数据记录错误也有BI侧的同学统计出错,反复确认该问题。

界限上下文检查:从业务特征上对领域进行划分形成子域,检查界限上下文是否划分合理。代码层面是否按照界限上下文进行继承关系、实体、聚合、值对象、领域服务等设计。比如我们的很多老的不同的服务都是共用一个DB这个现象不管是在微服务设计还是领域驱动设计范式里都是不提倡的。

领域防腐层检查:防腐层隔离不仅是为了保护自身领域模型免受其他领域模型的代码的侵害,还在于分离不同的域并确保它们在将来保持分离。咱们目前很多项目没有防腐层概念设计,导致大部分同学在开发的时候就是堆砌代码而不在意领域范围内结构的完整性,最终导致代码风格迥异,从系统上边界混淆。

        领域对象、领域上下文不明确导致,定则生成业务(其实是统一业务)拆分在不同的领域服务里,带来的影响也有很多不便:

  • 定则业务从技术层面没有收口出了问题排查就要拉多方逐一确认,只有很熟悉代码的同学才知道原来“主材补退货”的定则是否生成是供应链服务控制的!!!但是产品同学肯定不知道。
  • 后期技术同学维护交接容易遗漏,后期迭代开发容易遗漏影响面。
  • 产品迭代需要不同的团队支持,其实是同一个业务,这也是不太合理的情况。

架构师进阶之路 - 微服务怎么划分,架构,java,开发语言

 

2、依赖DAG检查

        DAG在数学上是有向无环图,指从任何一点出发都不会回到这个点,即不存在环路,我们服务的依赖也应如此。服务间要尽量避免双向或循环依赖,否则可能会导致灾难性的后果。质量领域中的业主线下验收就存在一个有向环图,下图中第一个就是业主发起线下申请人出现的有向有环图问题,究其原因就是系统边界划分不清晰导致质量领域事件出现在了验收单领域里,增加了系统间交互的复杂性和系统边界模糊,调用链路复杂等情况发生。经过领域界限上下文重新规划和代码优化之后的教系统交付如下图二,可以看到边界清晰了,系统交互简化了,调用链路也减少了。

架构师进阶之路 - 微服务怎么划分,架构,java,开发语言

图一

架构师进阶之路 - 微服务怎么划分,架构,java,开发语言

图二

3、分布式事务检查

        分布式事务调用的成本很高,服务拆分尽量避免产生跨服务事务,能合则合。如无法合并则优先考虑TCC或基于MQ的柔性事务,尽可能规避2PC等对性能影响很大的事务方案。TCC可完全替换2PC,但开发成本偏高,需要调用各方都同步修改以支持Try、Confirm和Cancel操作,某些场景会调用三方服务,其代码不受我们控制,此时可以考虑使用MQ实现异步消息和补偿性事务。咱们的业务比较复杂系统间的交互协作比较多,分布式事务在所难免。

        举一个比较典型的case就是,验收报告确认的时候,因为会产生延期会同步修改排期时间(排期领域)、有验收不合格项会记录整改工单(整改领域)、同步修改验收报告为代项目经理确认或待业主确认(验收单领域)、有延期赔付的话需要确认延期赔付(服务承诺领域)等等,者么多的领域服务调用都要确保成功才能算该节点验收通过,采用分布式事务显然成本很大,必然导致接口耗时增加很多影响接口性能和系统稳定。

        咱们具体看看一下这几个领域的特点。其中排期领域和整改领域是同一类领域在发生错误或者修改的时候要做到始终以最后一次提交为准,那就要领域服务内做到“幂等”。最好能从产品层面达成一致,比我们整改领域就是和产品同学达成产研层面的一致:始终以最后一次提交的整改为准。我们会记录本次验收提交的整改单,若有重复提交只记录最后一次提交的整改。当然这是在业务场景教低频的情况下的解决方案,大家按照自己的实际的情况采用最适合自己业务场景的技术方案。

        而验收单领域、延期赔付(服务承诺领域)就是同步更新操作,天然的幂等操作。在这种业务场景下即使重复提交也是更新到目标状态所以也是没有问题。

4、性能分布检查

        对于特别耗资源的操作应尽量独立。这部分咱们系统中应该没有类似场景大家知道这方面的范式即可。

5、稳定(易变)性检查

        一个服务中如存在稳定和不稳定的模块,应该将两者拆分。这部分也是暂时没有在咱们的业务场景中遇到,基本上都分别部署的,质量领域中目前验收模版配置是频繁发生的也是单独拆分成子领域迭代,验收模版配置的变更不会影响验收应用层,大家在进行领域划分系统设计的时候关注这方面的影响即可。

6、调用链检查

        服务间调用有IO消耗且不易追踪,应控制调用链路的长度。通过服务间的调用链路可以很清晰的发现历史无效代码的调用,需求迭代查产生的无效逻辑,以及潜藏的重复调用、循环依赖、以及系统可优化点等等。如下图就是一个验收提交的case,由于迭代时间太长,其中有很多废弃的逻辑没有删除,代码臃肿不说调用其他服务的接口、发送的消息、都是资源成本,若能及时梳理清楚代码整洁性提高了,维护成本降低,切服务稳定性也有了提升。文章来源地址https://www.toymoban.com/news/detail-539727.html

到了这里,关于架构师进阶之路 - 微服务怎么划分的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 微服务基础概念、架构图、划分图

    1、微服务 微服务架构风格,就像是把一个单独的应用程序,就像是把一个单独的应用程序开发为一套小服务,每个小服务运行在自己的进程中,并使用轻量级机制通信,通常是http api。这些服务围绕业务能力来构建。并且通过完全自动化部署机制来独立部署,这些服务使用不

    2024年01月23日
    浏览(32)
  • 从0开始,精通Go语言Rest微服务架构和开发

    现在 拿到offer超级难 ,甚至连面试电话,一个都搞不到。 尼恩的技术社区中(50+),很多小伙伴凭借 “左手云原生+右手大数据”的绝活,拿到了offer,并且是非常优质的offer, 据说年终奖都足足18个月 。 第二个案例就是:前段时间,一个2年小伙伴希望涨薪到18K, 尼恩把

    2024年02月11日
    浏览(53)
  • 微服务_微服务的架构演进之路

    目录 一、前言 二、单体架构 三、分布式架构 四、微服务 五、SpringCloud 六、服务拆分 5.1服务拆分原则 5.2服务拆分示例 微服务是一种软件开发架构风格,它将单个应用程序拆分成多个小型服务,每个服务都具有自己的特定功能。这些服务之间通过API进行通信,可以独立部署

    2023年04月09日
    浏览(78)
  • K8s进阶之路-命名空间级-服务发现 :

    服务发现: Service(东西流量):集群内网络通信、负载均衡(四层负载)内部跨节点,节点与节点之间的通信,以及pod与pod之间的通信,用Service暴露端口即可实现 Ingress(南北流量):将内部服务暴露外网访问的服务ingress-nginx,也就是nginx反向代理负载均衡服务(七层http负

    2024年02月20日
    浏览(46)
  • K8s进阶之路-控制器无状态服务:

    RC/RS/Deployment 控制器 deployment 无状态(最常用):    nginx和Apache statefulset 有状态: mysql和redis damonset 初始化 job 一次性任务 cronjob 任务计划 1无状态:不会对本地环境产生依赖如:nginx和Apache 3.RC、RS和 Deployment 区别 :   RC和RS : 动态更新pod副本数      管理pod,控制pod怎么

    2024年02月19日
    浏览(44)
  • Unity中级客户端开发工程师的进阶之路

    上期 UWA技能成长系统 之《Unity高级客户端开发工程师的进阶之路》得到了很多Unity开发者的肯定。通过系统的学习,可以掌握游戏性能瓶颈定位的方法和常见的CPU、GPU、内存相关的性能优化方法。 UWA技能成长系统是UWA根据学员的职业发展目标,提供技能学习的推荐路径,再将

    2024年02月12日
    浏览(50)
  • 编程语言学习笔记-架构师和工程师的区别,PHP架构师之路

    🏆作者简介,黑夜开发者,全栈领域新星创作者✌,CSDN博客专家,阿里云社区专家博主,2023年6月CSDN上海赛道top4。 🏆数年电商行业从业经验,历任核心研发工程师,项目技术负责人。 🏆本文已收录于PHP专栏:PHP进阶实战教程。 🎉欢迎 👍点赞✍评论⭐收藏 什么是架构师

    2024年02月12日
    浏览(51)
  • 微服务架构之路1,服务如何拆分?使用微服务的注意事项?

    大家好,我是哪吒。 微服务已经是Java开发的必备技能,甲方不管项目大小,都想上微服务,感觉上了就高大上了,牛逼了。 微服务确实给我们带来了一定的便利性,但是也带来了麻烦,比如学习成本高,存在很多不可预见的问题。 我是做互联网项目的,刚开始的时候,用的

    2024年02月05日
    浏览(55)
  • 软件架构之前后端分离架构&服务器端高并发演进之路

    首先,当一个项目刚起步的时候,不能预知后续的访问量和并发能达到多少,在初步开发的架构选型中,采用前后端分离的架构。关于前后端分离架构,其优势如下: 前后端分离是一种软件系统架构模式,它将应用程序的前端和后端分离开发和部署。在这种架构中,前端和后

    2024年02月10日
    浏览(56)
  • 大型医院云HIS系统:采用前后端分离架构,前端由Angular语言、JavaScript开发;后端使用Java语言开发 融合B/S版电子病历系统

    一套医院云his系统源码 采用前后端分离架构,前端由Angular语言、JavaScript开发;后端使用Java语言开发。融合B/S版电子病历系统,支持电子病历四级,HIS与电子病历系统均拥有自主知识产权。 文末卡片获取联系! 基于云计算技术的B/S架构的医院管理系统(简称云HIS),采用前后

    2024年02月03日
    浏览(50)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包