土味微服务

前段时间有大佬邀请,参加了一个微服务方面的交流,期间大放厥词,回味起来意犹未尽,整理一稿出来,博诸君一哂。

扯一扯定义

单体应用(monolithic application)这个名词,是经常被拿出来和微服务做比较(吊打)的。知己知彼百战不殆,在说微服务之前,似乎蛮有必要了解一下这个老对手的情况。

按照 Google 程序员的常用抄袭手段,我在 Google 搜索 monolithic application,选一点结果摘录如下:

In software engineering, a monolithic application describes a single-tiered software application in which the user interface and data access code are combined into a single program from a single platform.

Monolith means composed all in one piece. The Monolithic application describes a single-tiered software application in which different components combined into a single program from a single platform.

根据上面的陈述,会发现很难对单体应用做出一个精准的判断,single programsingle-tiered 放到真实世界中,除了单服务器、单进程的小网站之外,这种情况似乎很难看到。在面对几十几百台服务器的时候,我想大概没有架构师会有兴趣让几百台服务器都跑同一个 WAR 吧。

对手身份不太明确,那么会不会是个兔死狗烹呢?微服务的定义又是什么样的呢?下面是 Martin Folwer 给出的定义:

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

小有多小,轻有多轻,全自动的范围有多大,去中心化到底有怎样的自治,似乎也都让人摸不到头脑。

虽说概念没有一清二楚,然而从上述的定义来看,微服务是对一些既有的观点进行了强调的:

  • 以业务为中心
  • 多技术栈共存
  • 轻量协议互访
  • 去中心化

据此,我对微服务这个风向的理解,是在传统软件的设计开发体系基础之上的一种变化,相对于翻天覆地的变革,我更愿称之为一种改良。

是谁坑了瀑布流程

人人喊打的瀑布流程,在我看来,面对的是一种类似读书时候经常提到的理想状况

perfect.png

在理想状况中:

  • 需求是清晰而持久的
  • 基础设施都是稳定的
  • 依赖服务都是靠得住的

过往的开发过程在这种理想状况中,是具备非常多的好处的:

  • 单一的技术栈有利于人才招聘、培养以及技术积累。
  • 少量的业务进程对发布、运维都有较小的压力,并且内部调用效率更高。
  • 集中数据的好处更是车载斗量,安全、事务等方面有极大的优势。

然而世界发生了变化,廉价服务器包打天下,IT 人满坑满谷,业务日新月异,新技术层出不穷,用户漫山遍野,这一切因素叠加起来,都让以前重如千钧的需求变得相当轻浮。

结果现在越来越多的开发过程,变成了这样:

real.png

所有的环节,都随时面临变化的冲击:

  • 既有需求尚未完成,已经产生变更。
  • 设计开发过程受到新技术新方法的冲击。
  • 测试标准、交付标准的变化。
  • 运行环境升级和故障响应要求。

种种变化归结起来:

硬件和人力都变得廉价,变更频繁并且范围更大。

快速的变化除了产生需求之外,还让黏连在一起的大进程难于适应:

  • 不同业务之间的信任关系会发生变化。
  • 共享数据容易污染。
  • 多小的代码变更,都可能引发大量的测试和上线动作。
  • 特定业务场景无法使用最优技术栈进行实现。
  • 必须同步进行缩放。

除了上述的外部因素之外,开发团队和交付物自身其实也同样的不理想:

  • 牵一发而动全身的共享代码库。
  • 不严格的组件边界,可能导致不同业务互相干扰。

应对思路也顺理成章:

  • 越长的流程越容易被变化击中,换句话说,越短的流程越容易完成。
  • 缩短的流程,决定了交付物体积缩小,但是并行开发的需求大增。
  • 并行开发的过程,要求有多团队协同工作。
  • 多团队的结果就会导致扩展技术栈、去中心化的要求。

更小的交付物,和更便宜的服务器勾搭起来,产生了大量运行小进程的廉价服务器,自然也就催生了“民用”的分布式计算。

如此一来,各种集群、各层协议、各种分布式框架就成了刚需,产生了空前发展。

从“集中力量干大事”,到“各村有各村的高招”,这种变化自然是为了满足客户需要

没有 Silver Bullshit

按照前面提到的思路,我们:

  • 把进程内的组件拆成独立服务。
  • 独立的服务运行各自的进程。
  • 原有的进程内调用变成了网络调用。
  • 各个服务可能采用不同的技术栈来实现。
  • 每个服务独占存储自己的存储。

大的有点不好,小的就一定好么?各自放飞的微服务,有了各自的实现、发布、伸缩的弹性,是不是就一定好了?

  • 更多的服务器,和相关设施,代表着更多的故障。所以微服务经常强调的是面向故障进行设计。
  • 分离的数据,相对于原有的单一数据库来说,事务保障变得复杂无比。
  • 大量的进程会给运维工作带来很大压力,急需监控和自动化的大力支持。
  • 单一业务的调用序列大幅延长,调试优化难度也一定是大大增加了。
  • 散乱的技术栈,会大幅提高技术管理的难度,降低知识的复用性。
  • 独立的代码库,很明显会降低代码复用的可能性。

由此看来,这种拆分并非只赚不赔的好买卖。是一个需要权衡的事情。不论微服务的数量有多大,个头有多小,作为一个独立的交付物,都还是需要遵循既有的软件开发技能和规律的。那么问题来了——对于给定的系统,到底应该有多少个微服务,每个服务有多大呢?

前文说道,我更愿意称微服务为一种改良,他是一种应对变化的手段,而非特征。在如今的情况下,不管是对新业务实现的设计,还是对既有系统的重构,任何架构师都不会把明明应该拆分的东西硬性的合并到一起。所以这个分离的标准就比较重要了。

拆还是不拆,这是个问题

很明显的,微服务的设计不是一个靠数量取胜的事情,所以重点不是能拆成多少块,而是什么东西需要拆,下面列出我所知的几个影响因素。

组织机构

利益人的识别,在各种软件开发过程中都是很重要的一个环节,在微服务中也是如此,而且尤其重要。当一份交付物存在多个利益人,并且互相之间不存在管辖关系的时候,就表明当前交付物的边界出现了问题,面临着令出多头、需求干扰的风险。

伸缩需求

同一个进程之内的不同业务功能,有时在业务量方面会出现较大的差异,具体要求的进程数量会有较大差别,这样的模块锁定在同一进程之内,势必会造成资源的浪费。

部署频率

这个很容易理解,同一个交付物内不同的组件有着不同的上线频率,会大大的提高上线流程的发生频率,会造成较大的人员浪费。

修改的相关性

如果同一交付物内的不同组件,经常会被同步修改,这可能说明,如果发生拆分,这两个模块应该是”在一起“的。

技术栈

新技术的爆发,让很多不同的场景有了更好的实现方式,如果有业务急需使用新的技术栈来(重新)实现。这种新技术除了新的语言、新的数据库之外,可能还包括容器、Service Mesh、API 网关等新晋 PaaS 能力。毫无疑问,这种业务也同样有拆分的需要。

结论

微服务虽说不是一个全新的东西,但也绝非是简单的新瓶装旧酒。总体说来,我认为这是在尊重现实,适当妥协的基础上,一种应对变化的好办法。

参考

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 217,509评论 6 504
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,806评论 3 394
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 163,875评论 0 354
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,441评论 1 293
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,488评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,365评论 1 302
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,190评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,062评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,500评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,706评论 3 335
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,834评论 1 347
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,559评论 5 345
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,167评论 3 328
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,779评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,912评论 1 269
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,958评论 2 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,779评论 2 354

推荐阅读更多精彩内容

  • 资料来源:有架构给我的一些资料,以及自己百度和论坛、社区找来的一些资料,权当做一个总结式的简介。。。 目录如下: ...
    AlbenXie阅读 52,447评论 4 57
  • 关于“什么是微服务”的问题,其实并没有一个统一的认识。这些年在不同的场合里和不同背景的朋友都在探讨微服务。但聊得越...
    顾宇阅读 3,433评论 0 18
  • 目录如下: 一、微服务架构介绍 二、出现和发展 三、传统开发模式和微服务的区别 四、微服务的具体特征 五、SOA和...
    昨天今天下雨天1阅读 392评论 0 2
  • 在美国广袤的大地上(东海岸到西海岸是6个小时的航程),美景众多,在读博期间就被称为爱玩之人的我,到了美国也...
    bluecafe阅读 818评论 1 2
  • 剧情里的人物陈俊生表面老实,骨子里自私自利,虚伪无情!觉得跟自己当初经历的人生相同,然而不同的是我没有陈太太的好命...
    王好好_0f28阅读 157评论 0 0