微服务演化史（1）

微服务这个词如今在IT业界已经是炙手可热了，其解释和说明也是众说纷纭。各个领域和行业的专家学者实施人员站在自己的阶层和视角提出不同的微服务概念和理解。专家学者说，这是SOA的延伸。架构师辩解道，这是一种新的软件架构设计。开发工作者说，这是一项新的技术革命，足以颠覆以前的所有架构。运维工作者说，这是运维行业最重大的突破。事实上微服务概念并不是一个新名词，其产生并不是没有预兆就横空出世。这是IT发展到一定阶段的产物。那我们先简单了解一下微服务这个概念产生的前世今生吧。

微服务，按照字面拆开分析，一个是微，一个是服务。首先来谈谈微吧，为什么叫微服务（MicroService）？也许是翻译的缘由吧。那为什么不叫小服务，迷你服务（MineService）。同时，与微服务并列的也应该有粗服务，中服务或大服务等等名词。可这些名词连概念都没有，就只有微服务这个词流传下来。这涉及到一个计算机经典的说法，所有的Unix哲学浓缩为一条铁律，即“K.I.S.S”原则：Keep It Simple, Stupid。用白话来讲就是一个程序只用做一件事，并且做好这件事。所以这个微字，就是控制在做好一件事的范围。如果我们能做好一件事情，那一件一件去做，那就能做好所有事情。可现实是残酷的，在这个行业，我们经常做不好一件事，或者说不能长久地做好一件事，我们更谈不上去做好更多的事情。我们用了很多方法，如结构化分析设计，面向对象分析和设计，重构设计、领域设计、敏捷软件开发等等。其实就是一个目的，如何高效高质量地做好一件事情。所谓IT建模，也是围绕着做好一件事来进行的。很多专家，都投入了大部分精力去研究这个如何做好一件事的内容。这方面的书籍可以推荐一二，如Robert C.Martin《敏捷软件开发-原则、模式与实践》、Craig Larman《UML与模式应用》、Martin Fowler的《UML Distilled》和《Refactoring》等。但多年以后，收效甚微。接着是引入了服务的概念。这的确是IT届一个伟大的创举，可这也有一个源远流长的历史。而且一直不能被遗忘的是一个非常著名的概念——SOA（Service OrientedArchitecture）面向服务架构。业界对于SOA可谓是又爱又恨。SOA理念可以解决我们以前IT中所面临的所有问题，同时，SOA的实践却往往只能解决部分问题，同时带来更多的、更深层的、更广阔的问题。而微服务与SOA也是一个联系紧密，但又有所区别的概念名词。

那微服务是个技术性话题吗？那又为什么又与DevOps扯上关系？那微服务是个业务概念吗？可是又有一堆技术产品和技术概念纠结在一块。在微服务中也注入了很多软件过程和研发管理的元素，微服务也要关注需求分析、设计、开发、测试、部署、运维等等。故仅仅把微服务归纳到某一个领域和范畴，实际上与微服务的最初概念的提出，还是相差甚远。

所以根据上述字面分析，我们基本上可以得出一个结论：微服务不是基因突变出来的，而是随着IT技术的发展，业务复杂度的深入，应用场景的变化，现有架构的不足，尤其是互联网应用的推广和扩展，一步一步进化出来的。

现在来讲述微服务一步步的演化过程。这里主要包含四个时代，第一个时代是单一应用的C/S客户服务器时代，第二个时代是分布式组件应用时代，第三个时代是SOA时代。最后一个时代才是所谓的微服务时代。当然，历史也会证明，每一个时代出现的架构和技术都是要适合当前业务应用的深入发展。

首先我们回溯到主机时代，那时候应用程序都在后台，即所谓的中心大型机。当时也没有所谓服务，只有计算的概念。前台终端作为输入输出工具，把命令和数据传输到后台，后台进行复杂的计算并返回计算结果给前台终端。虽然这个遥远的主机时代，与微服务有那么一点关系，比如Unix的原则等等。但这个关系与微服务概念还是相差较远，所以就先省略掉。

第一时代是单一应用程序的客户服务器时代。

主要是所谓的C/S模式和B/S模式的服务端应用。这个阶段主要还是面向功能来实现业务，一般采用的设计方法如结构化分析与设计方法，原型法等等。这时候的系统架构上都是所谓的单一架构。由于一个业务功能形成一个完整的闭环应用。在内部完成的很好。这种系统一般是叫信息化系统，系统更多体现为数据库应用系统。一般做法都是根据数据流程图，设计好数据库物理模型，然后根据数据库结构形成所谓的CRUD操作，基本上就可以把一整套系统完成。在这种架构模式下，开发团队的所有成员在同一个代码环境中采用同样的开发工具或语音来进行开发，功能实现的代码集中在一个发布包中进行集中部署和发布。实际上是数据库系统的延伸。

这阶段是PowerBuilder、Visual Basic、Delpli、ASP等开发语言大行其道的时代。开发人员用过程化思维开发出系统功能，然后编译生成应用程序并安装到电脑中，这种方式易于开发、部署和测试，存在的问题：（1）程序代码汇总在一起，无法协同开发。（2）系统高度集中，非核心问题也可能导致整个系统瘫痪。稳定性差。（3）代码功能耦合度高，后期维护复杂、功能扩展困难。（4）业务变更或整合会导致重构整个系统，迭代时间长。（4）对开发语言的依赖性强。在这种模式下，架构是单一的，应用软件都按照模块来进行归类，对于基础架构一般都是有比较强的依赖性，如对开发语言或是某一类开发框架。系统功能专业单一，主要以处理CRUD（新增、删除、修改、查询）为主。对开发人员的要求比较高，对开发基础框架依赖性强，定制化网络开发需要从底层协议。

这个时代的标签是客户服务器模式，单一架构，类库框架设计、结构化分析方法和设计，关系数据库开发、SQL语句、安装包等等。

未完待续