论微服务拆分

微服务拆分的起点

使用微服务架构模式的思想对目标系统进行拆分之前,我们需要先明白服务拆分起点和终点,以及需要考虑的因素与坚持的原则。所谓起点就是需要清楚拆分的是已有的项目还是新的项目,如果是已有的项目,那么这个项目处于什么样的架构阶段。而终点则是服务拆分后所需达到的架构阶段,以及后续扩展性的考虑,毕竟好的架构不是一次性设计出来的,而是不断进化来的。

不适合使用微服务的业务场景:

  • 系统中包含很多很强事务场景的,分布式事务比较难处理,而且由于CAP定律的原因,也无法保证数据的强一致性
  • 业务相对稳定,迭代周期长,大半年不需要更新一次版本的,使用微服务意义不大
  • 访问压力不大,可用性要求不高,例如一些简单的内部使用的系统

所以说微服务并不是放之四海而皆准的,而且在一些不适合的场景上使用微服务架构只会适得其反,所以我们在考虑架构的时候一定要根据实际的业务场景来设计,否则抛开需求谈架构,不就是在耍流氓吗


康威定律与微服务

微服务可以说是近两年来非常火的新概念,大家都在追,也都觉得很对,但是似乎没有很充足的理论基础说明这是正确的,给人的感觉更多是不明觉厉 。但实际上微服务很多核心理念其实在半个世纪前的一篇文章中就被阐述过了,而且这篇文章中的很多论点在软件开发飞速发展的这半个世纪中竟然一再被验证,这就是康威定律(Conway's Law)

据说这篇文章最初投的哈佛商业评论,结果程序员屌丝的文章不入商业人士的法眼,无情被拒,康威就投到了一个编程相关的杂志,所以被误解为是针对软件开发的。最初这篇文章显然不敢自称定律(law),只是描述了作者自己的发现和总结。后来,在Brooks Law著名的人月神话中,引用这个论点,并将其“吹捧”成了现在我们熟知“康威定律”。

谈到康威定律,最经常被人摆出来的一句就是:

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)

中文大意:

任何组织在设计一套系统(广义概念上的系统)时,所交付的设计方案在结构上都与该组织的沟通结构保持一致。

说白了就是,团队在沟通时项目结构是怎么样的,那么项目最终的结构就会是怎么样的,所以项目的结构与团队的沟通是会相互影响的。

我们通过两张图片简单的看一下两种模式下的团队结构:

  1. 传统架构模式下的团队结构:

2. 微服务架构模式下的团队结构:


服务拆分分析

如果一个系统拥有买家端和卖家端,我们可以根据这一点拆分成两个服务。也可以根据业务功能进行拆分,例如可以拆分为商品服务、订单服务、用户服务等,这样拆分的粒度就更细一些。但是代入实际的开发中,如果目标项目比较小,或者团队人数不多,项目迭代也很慢的话,那么这种项目是不需要进行拆分的。

我们在拆分服务的时候,需要满足几个基本点:服务的高可用、可水平扩展以及功能解耦等等。那么如何拆 “功能” 呢,可以参考以下几点:

  • 遵循单一职责、松耦合、高内聚原则
  • 关注点分离
    • 按职责
    • 按通用性
    • 按粒度级别

如何拆 “数据” :

  • 每个微服务都有单独的数据存储
  • 依据服务特点选择不同结构的数据库类型
  • 难点在确定边界
  • 针对边界设计API
  • 依据边界权衡数据冗余

可以参考扩展立方模型去进行拆分:

在微服务架构中,每个服务一般都会拥有各自的数据源,服务和数据的关系如下:

  • 先考虑拆分业务功能,在考虑拆分业务对应的数据
  • 无状态服务,所谓状态就是只一个数据需要被多个服务共享才能完成一个请求,那么这个数据就可以被称为状态。而依赖这个状态数据的服务被称为有状态服务,反之称为无状态服务

我们来通过一张图片,直观的看一下,服务拆分的前后对比:

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • Spring Cloud Zuul 快速入门

    我们已经知道,在微服务架构中,不同的微服务可以有不同的网络地址,各个微服务之间通过互相调用完成用户请求,客户端可能通过调用N个微服务的接口完成一个用户请求。比如...

    端碗吹水
  • 同一浏览器下sessionid互相覆盖的问题

    在一台机器上安装多个Tomcat,端口不一样,这里姑且分别称为tomcat1 和 tomcat2,在两个不同的Tomcat上部署了A和B两个项目,两个项目的代码...

    端碗吹水
  • 笔记内容:df命令,du命令,磁盘分区

    df命令可以汇报文件系统的磁盘空间使用情况,直接回车就可以查看文件系统的使用情况:

    端碗吹水
  • 微服务架构三十六计

    用户1682855
  • 微服务架构深度解析与最佳实践

    微服务架构的概念,现在对于大家应该都不陌生,无论使用 Apache Dubbo、还是 Spring Cloud,都可以去尝试微服务,把复杂而庞大的业务系统拆分成...

    用户1737318
  • 一位阿里架构师的分享——谈谈微服务架构

    微服务架构有两个关键特征,其一是原单体应用必须拆分为纵向完全独立的微服务模块,其二是微服务模块间通过轻量的Http Rest接口进行交互。对于是否进行了容器化部...

    美的让人心动
  • 『高级篇』docker之课程管理dubbo入门操练(14)

    PS:dubbo的入门也就到这里,从spring 和springboot 对dubbo的整合。

    IT故事会
  • 宜信微服务架构落地及其演进|分享实录

    应用服务架构一直处于不断演进的过程中,上图通过对比5种比较主流的架构模式,展示应用架构的演进历程和变化。

    宜信技术学院
  • [微服务感悟] 服务发现与常见架构

    微服务架构中,服务都运行在许许多多的机器中,调用其他服务时首先需要找到这个服务在哪里呢,找服务对应的机器的过程就是服务发现。

    逝兮诚
  • 服务拆分与架构演进|洞见

    本文首发于InfoQ: http://www.infoq.com/cn/articles/service-split-and-architecture-evol...

    ThoughtWorks

扫码关注云+社区

领取腾讯云代金券