微服务划分的姿势

标签: 微服务 姿势 | 发表时间:2020-01-06 23:16 | 作者:JetLee
出处:http://weekly.dockone.io

【编者的话】我们知道微服务是一种理念,没有确切的定义和边界,好比设计原则,是属于抽象的概念。在定义不明确的情况下谈划分也是一种各说各话,具体问题需要具体分析,所以这篇文章谈到的划分也不是绝对标准,仅供参考。

有人说微服务不难,难的是服务的划分,虽然我持保留意见,但是从侧面也反应了划分具有一定的困难。这里的矛盾在于粒度,如果粒度太大了,分和不分似乎都差不多;如果粒度太小了,聚合、发布、调用链、调试等都是坑。

以下谈到的拆分是前人经验的总结,我罗列了三种行家的拆分姿势,每个的的经验和视野不同,各有偏颇,我在这里更多的是谈共鸣和感受,希望对你有所启发。

拆分姿势

姿势一:新浪微博微服务专家胡忠想从纵横两个维度来划分,简单粗暴。

纵向拆分

从业务维度进行拆分。标准是按照业务的关联程度来决定,关联比较密切的业务适合拆分为一个微服务,而功能相对比较独立的业务适合单独拆分为一个微服务。

横向拆分

从公共且独立功能维度拆分。标准是按照是否有公共的被多个其他服务调用,且依赖的资源独立不与其他业务耦合。

纵向以业务为基准,关系铁的在一起;横向功能独立的在一起。我想如果拆分这么简单,你有底气拆,敢拆吗?所以我们又继续比对一下其他专家的言论。

姿势二:阿里的小伙伴从综合的维度来看,部分维度和上面会有重合

服务拆分要迎合业务的需要

充分考虑业务独立性和专业性,避免以团队来定义服务边界,从而出现“土匪”抢地盘,影响团队信任。

这个维度和上面的类似,但是强调的是业务和团队成员的各自独立性,对上面是一种很好的补充。

拆分后的维护成本要低于拆分前

这里的维护成本包括:人力、物力、时间。

这里的成本对大部分中小团队来说都是必须要考虑的重要环节,如果投入和收益不能成正比,或者超出领导的预算或者市场窗口,那么先进的技术就是绊脚石,千万不要迷恋技术,所谓工程师思维千万要不得。

拆分不仅仅是架构的调整,组织结构上也要做响应的适应性优化

确保拆分后的服务由相对独立的团队负责维护。

这句话怎么理解呢?传统的团队划分是按照产品部、前端、后端横向划分,微服务化以后的团队可能就会是吃一张披萨饼的人数,产品、前端、后端被归类到服务里面,以服务为中心来分配人数。

拆分最有价值的结果是提高了系统的可扩展性

把具有不同扩展性要求的服务拆分出来,分别进行部署,降低成本,提高效率。比如全文搜索服务。

这点和上面的按功能独立性来拆分有点类似,功能独立其实就是面向可扩展性。

考虑软件发布频率

比如把20%经常变动的部分进行抽离,80%不经常变动的单独部署和管理。说白了就是按照8/2原则进行拆分。这个拆分的好处很明显,可以尽可能的减少发布产生的后遗症,比如用户体验、服务相互干扰等。

但是这里有一个问题,假如20%的服务分属于不同的业务层面,那该怎么办?所以这里的拆分应该有个优先级,在拆分相互冲突的时候应该要优先考虑权重比较高的那个。

姿势三:资深技术专家李运华在他的架构书中给出的拆分

基于业务逻辑

将系统中的业务按照职责范围进行识别,职责相同的划分为一个单独的服务。这种业务优先的方式在前面两种姿势当中都出现过,可见是最基本,最重要的划分方式(没有之一)。

基于稳定性

将系统中的业务模块按照稳定性进行排序。稳定的、不经常修改的划分一块;将不稳定的,经常修改的划分为一个独立服务。比如日志服务、监控服务都是相对稳定的服务,可以归到一起。这个很类似上面提到的2/8原则,80%的业务是稳定的。

至此你会发现服务的拆分真的没有绝对的标准,只有合理才是标准。

基于可靠性

同样,将系统中的业务模块按照可靠性进行排序。对可靠性要求比较高的核心模块归在一起,对可靠性要求不高的非核心模块归在一块。

这种拆分的高明可以很好的规避因为一颗老鼠屎坏了一锅粥的单体弊端,同时将来要做高可用方案也能很好的节省机器或带宽的成本。

基于高性能

同上,将系统中的业务模块按照对性能的要求进行优先级排序。把对性能要求较高的模块独立成一个服务,对性能要求不高的放在一起。比如全文搜索,商品查询和分类,秒杀就属于高性能的核心模块。

姿势盘点:以上不同拆分姿势各有千秋,异曲同工

  • 对业务逻辑均不约而同的放在第一位
  • 对业务模块的稳定性和可靠性,对功能的独立性、可扩展性都有相似的看法
  • 强调拆分应该是多选,而不是单选。具体情况具体分析,可以自由灵活排列组合。


题外话

如果你把上面的划分角度背下来了拿去现场套,可能还会遇到矛盾或争议。

业务矛盾

假如我们按照业务来划分,根据粒度大小,可能存在以下两种:
  • 第一种分为商品、交易、用户3个服务;
  • 第二种分为商品、订单、支付、物流、买家、卖家6个服务。


3 VS 6,这该怎么办?

如果你的团队只有9个人,那么分成3个是合理的,如果有18个人,那么6个服务是合理的。这里引入团队成员进行协助拆分。

可见拆分的姿势不是单选,而是多选的。这个时候必须要考虑团队成员数量。

在拆分遇到争议的时候,一般情况下我们增加一项拆分条件,虽然不是充要条件,但至少我们的答案会更加接近真理。

除了业务可能存在争议,其他的划分也会有争议,比如一个独立的服务到底需要多少人员的配置?

三个火枪手(人员配置)

上面提到的人员数量配置,这里为什么是9和18呢?(这里的团队配置参考李云华前辈提到的三个火枪手的观点)

换一种问法,为什么说是三个人分配一个服务(当然,成员主要是后端人员)?
  • 假设是1个人,请个假、生个病都不行。一个人会遇到单点的问题,所以不合理。
  • 假设是2个人,终于有备份了,但是抽离一个后,剩下1个压力还是很大,不合理。
  • 假设是3个人,抽离一个还有2个在。而且数字3是个稳定而神奇数字,用得好事半功倍。特别是遇到技术讨论,3个人相对周全,如果是2个可能会各持己见,带有自我的偏见和盲区。


那么这个3是不是就是稳定的数量呢?

假设你做的是边开飞机边换引擎的重写工作,那么前期3个人都可能捉襟见肘。但是到了服务后期,你可能1个就够了。

所以3在我的理解应该是一个基准线,不同的时间段会有上下波动,但是相对稳定。


原文链接: https://www.cnblogs.com/jackyfei/p/10856427.html

相关 [微服务 姿势] 推荐:

微服务划分的姿势

- - DockOne.io
【编者的话】我们知道微服务是一种理念,没有确切的定义和边界,好比设计原则,是属于抽象的概念. 在定义不明确的情况下谈划分也是一种各说各话,具体问题需要具体分析,所以这篇文章谈到的划分也不是绝对标准,仅供参考. 有人说微服务不难,难的是服务的划分,虽然我持保留意见,但是从侧面也反应了划分具有一定的困难.

初识微服务

- - ITeye博客
微服务架构越来越火,有必要学习一下. 软件开发过程中碰到什么问题. 一个简单的应用会随着时间推移逐渐变大. 在每次的sprint中,开发团队都会面对新“故事”,然后开发许多新代码. 几年后,这个小而简单的应用会变成了一个巨大的怪物. 一旦你的应用变成一个又大又复杂的怪物,那开发团队肯定很痛苦. 敏捷开发和部署举步维艰,其中最主要问题就是这个应用太复杂,以至于任何单个开发者都不可能搞懂它.

谈微服务架构

- - 人月神话的BLOG
其实在前面很多文章谈到SOA,特别是系统内的SOA和组件化的时候已经很多内容和微服务架构思想是相同的,对于微服务架构,既然出现了这个新名称,那就再谈下微服务架构本身的一些特点和特性. 从这个图可以看到微服务架构的第一个重点,即业务系统本身的组件化和服务化,原来开发一个业务系统本身虽然分了组件和模块,但是本质还是紧耦合的,这关键的一个判断标准就是如果要将原有的业务系统按照模块分开部署到不同的进程里面并完成一个完整业务系统是不可能实现的.

微服务性能模式

- - 互联网 - ITeye博客
前言:基于微服务系统越来越普遍. 下面我们就来看看五种常见的特定微服务性能的挑战,以及如何应解他们. 背景:在IT界微服务架构为基础的系统越来越多, 每一个应用系统都集成了不同的组件和服务,几乎所有的特定业务应用程序都需要集成一个或更多的应用服务. 但是一个综合性系统集成不同的服务这无疑是一个巨大的挑战.

微服务与架构师

- - 乱象,印迹
因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少. 很多候选人有多年的工作经验,常见的框架也玩得很溜. 然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力. 这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求. 软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论.

从Excel到微服务

- - 乱象,印迹
Excel很老,Excel很土,Excel一点也不sexy;微服务新,微服务很潮门,微服务很高大上. 那么,Excel和微服务有什么关系. 上个月看了篇文章,The Unbunlding of Excel. 作者认为,对于初创公司(尤其是非“纯IT”初创公司)来说,Excel几乎包办各种工作. 想做轻量级的CRM,可用Excel.

微服务框架Spring Cloud介绍 Part2: Spring Cloud与微服务

- - skaka的博客
之前介绍过 微服务的概念与Finagle框架, 这个系列介绍Spring Cloud.. Spring Cloud还是一个相对较新的框架, 今年(2016)才推出1.0的release版本. 虽然Spring Cloud时间最短, 但是相比我之前用过的Dubbo和Finagle, Spring Cloud提供的功能最齐全..

面向服务与微服务架构

- - CSDN博客推荐文章
最近阅读了 Martin Fowler 和 James Lewis 合著的一篇文章  Microservices, 文中主要描述和探讨了最近流行起来的一种服务架构模式——微服务,和我最近几年工作的实践比较相关感觉深受启发. 本文吸收了部分原文观点,结合自身实践经验来探讨下服务架构模式的演化. 面向服务架构 SOA 思想概念的提出已不是什么新鲜事,大概在10年前就有不少相关书籍介绍过.

微服务架构实践感悟

- - mindwind
从去年初开始接触微服务架构的一些理念,然后到今年开始实施系统第四个大版本的架构升级决定采用这套架构理念. 最近关于微服务架构的讨论还是多起来,因为国外一些著名互联网公司(如:Amazon、Netflix 等)从实践中摸索出了一套新的大型系统架构方法论,并取得了成功,树立了很好的示范,然后这套方法论渐渐就被一些技术理论派 人士命名为微服务架构(Microservices).

微服务架构成功之路

- - CSDN博客推荐文章
本文来源于我在InfoQ中文站翻译的文章,原文地址是:http://www.infoq.com/cn/news/2015/07/success-of-microservices. 近年来,在软件开发领域关于微服务的讨论呈现出火爆的局面,有人倾向于在系统设计与开发中采用微服务方式实现软件系统的松耦合、跨部门开发;同时,反对之声也很强烈,持反对观点的人表示微服务增加了系统维护、部署的难度,导致一些功能模块或代码无法复用,同时微服务允许使用不同的语言和框架来开发各个系统模块,这又会增加系统集成与测试的难度,而且随着系统规模的日渐增长,微服务在一定程度上也会导致系统变得越来越复杂.