“微服务”技术另一个可能更合适的名字

引言

这两天~~夜观天象~~准备分享，重新对服务化、微服务等技术的来龙去脉做了一些思考和总结，当然网上早有一百篇或者一万篇不同的文章来解释和描述服务化是什么微服务是什么，微服务和服务化的区别是什么，我也看过其中一二。我从来不打算说重复的东西，说的也没有大师好。但微服务这个东西既不像【我不想提及的网络热词】技术那样基本上啥都不是就是骗骗外行，又不像【另一个热点技术词汇】那样“大家都理解关于那个东西大家的理解不一致”，冷静下来思考，一种可能性就是这个名字起的不好没有直击本质，导致一些误解，这两天突然想通一些东西，这里和各位探讨一下。

服务和微

首先我们来扣一下字眼，服务(service)是什么？搜中文大概是这的【履行职务，为他人做事，并使他人从中受益的活动】，英文的含义1大概是【the action of helping or doing work for someone.】，意思其实是一样的，serve的名词，从技术角度看有点似是而非。英文含义2比较贴近我们技术角度说的服务【a system supplying a public need such as transport, communications, or utilities such as electricity and water.】虽然对应中文比较明显是”公共事业“，但还是基本命中”服务化“这件事情的核心点：1、独立系统；2、公共需求。

然后看一下“微”(micro-)，这个词字面意思没有什么误解，但放到微服务里要解读它就有点困难了，不如说有很多正确答案，可能有：

单一职责（指责小，内聚）
单进程，容器化等（体量轻）

等等，问题在于，这些特性、方向、指导原则，其实和巨石架构到服务化的方向是一模一样的。一个东西如果只是比原来的一个东西程度更甚，只是量变，那它是没有资格被单独讨论的：高铁也是铁路，高铁再快，就算是比飞机还快的磁浮，也还是铁路，也还是火车站，也还是轨道交通系统。飞机，就算是原始飞机飞得再慢，问题再多，和火车也是不一样的东西，因为那是质变。

我不太同意微服务只是原来服务化方向上的量变，所以不太认可微服务这个名字，就好像把飞机叫超快火车那样，快是飞机比火车的优点，但飞机的本质是飞，不是快。

微服务的本质

我们来回想一下谈到“微服务”的时候我们一般谈论什么？服务治理、服务网格(service mesh)、容器编排等等，这些东西其实并不和“微”直接相关，但微服务这个名字却一直被大家用下来，我也并没有发现有人对这个名字有不满（一定有，可是我不知道），可能是因为这些技术解决的是服务化落地以后，单个服务进一步肿胀，试图进一步拆分（微）的时候，遇到的实际困难。

解决火车提速的实际困难有两条路：发明更快的火车或者发明飞机，那么是什么东西让我们认为“微服务”这个东西并不是高铁，而是飞机，对比服务化火车是具备革命性的变化的呢？这个问题的答案(能飞)最终能够成为微服务技术的更好的名字(飞机)。

微服务技术的掌上明珠Istio一直在迅猛发展，最近的一条消息是Istio重构了它的控制平面，将原本控制平面内部的“微服务”架构重构为单体架构，原本control plane的多个组件Pilot, Galley, Citadel等被合并为一个istiod程序。这条消息引起了一些关于微服务vs巨石的讨论，但无论如何，不会有人认为istio成为一个单体服务后，istio架构就不是一个微服务架构了，这也应证了我的思考，微服务的本质不是微。那么让istio得以呈现它微服务本质的特点是什么？

元服务 meta-service

Istio本身原本是微服务，即使它变成了巨石架构，它仍然是一个服务，这个服务和非微服务架构里的各种服务还是有本质区别：它服务的“公共需求”，既不是业务需求（业务服务），也不是技术实现的需求（基础服务如DB、队列），而是“服务化”本身，istio是为服务化服务的服务。写服务解决服务化过程中遇到的瓶颈和挑战，这才是”微服务架构“区别于服务化架构的本质，这并不因istio内部组件融合成巨石架构而动摇，这才是”微服务“技术的本质，所以它的名字应当是元服务。(这里开始我把微服务统一叫元服务)

元(meta-)这个前缀的含义是自引用、关于X的X：关于数据的数据叫元数据，写程序操作程序叫元编程，那么，解决服务化问题的服务，自然应当被称为元服务，我们讨论元服务时，几乎不讨论某个业务服务是否micro或者如何把它做micro，而是讨论为了把服务拆分好，需要实现某某特性，因此引进或者研发某某服务解决这个问题。

服务化架构为什么遇到困境？因为服务化架构在解决自身问题的时候，并没有用到服务化的思想。元服务更全面地应用了服务化思想，从而使得它和服务化架构有了本质的区别，插上翅膀成为飞机，从而被大家讨论、实践和学习。