我所了解的微服务

整篇文章内容适中，建议7分钟读完。
如果对文中提到的概念比较陌生，建议12分钟读完，顺便看一下我在文末附上的参考文献。
本文纯属个人原创，转载请注明出处。

开始装逼之旅之前，请允许我和大家一起再温习一句话：

这句话适合一切高大上的概念，比如：SOA，DevOps，DDD，Agile，Cloud等等，包括我现在想要讲述的「微服务」。

为什么会这样？

“专家”太多了，俗话说的好：「一千个专家眼里，有一千个哈姆雷特」。

概念听的多了，还以为自己见多识广，最后大多都是迷茫了：「卧槽！我到底应该信谁？」

依老夫看：信谁都不如信自己！

如此纷繁复杂的概念，真是让人捉摸不透，却又不得不去了解，毕竟互联网的圈子里有太多洪水猛兽，稍有懈怠，就会被拍在沙滩上了。

其实，意识到自己身处如此险境，也算是我的后知后觉，或许早有感知，可是迟迟没有行动。直至现如今，我才十分强烈地感受到这个时代对我们这些素人深深的恶意。

是的，我得挣扎一下，给未来的自己留下点痕迹。

纵观我不算很长的从业经验，可以总结出六字箴言：

听说过，没用过

这将是IT界的技术人员在知识的广度和深度之间纠结的一个缩影。

多么痛的领悟，有木有！~~

我的生活不少阅历，却极度匮乏提炼和升华。虽然之前也在社交媒体上零零散散地「矫情」过几次，但那都是生活成长之感悟，对于自己的专业技术层面，还是少之又少。

因此，为了避免迷失于这一波又一波的互联网大潮中，我决定梳理一下「毕生所学」，刚好最近对微服务有一些实践经验，那就谈谈我所了解的微服务。

---

1、ALL in ONE

谈微服务之前，我习惯先谈谈曾经折磨我三年的开发模式：ALL in ONE。

也会有人称之为：「单体应用」

此处用到了「折磨」一词，憎恨之情可谓是溢于言表。

其实这种感受并不是一开始就有，而是我在微服务圈子里混了一段时间后发掘的：

我特么以前是怎么过来的！

ALL in ONE的开发模式应该算是我这代互联网人认识软件开发过程的第一个阶段。

打开Eclipse，new一个Dynamic Web Project，Java代码放在src下，JSP放在WebContent目录下，在WEB-INF/lib目录下还有各种jar包的加持，多么熟悉的工程目录结构。

再后来，有了maven，一个项目分多个module，看起来清爽了不少，jar包也一下子少了很多，从SVN上Checkout一个工程明显更快了，编译，打包什么的，明显更方便了。

想当初，自己引以为傲的Linux命令，给服务器安装JDK，Tomcat，MySQL什么的，都是信手拈来。

当我熟练的将WAR包打出来，往webapps目录下一放，部署算是完成了。

即便如此，这种开发模式还是比较“稳”的：

从开发者的角度来说，至少从技术上了解一个项目， 没有太高的学习成本，除非你很不幸地遇到了一位爱装逼的同事。其次，每次的部署也变得出奇的简单，几乎不需要操心现在DevOps所面临的问题。

从写代码的层面看，所有依赖都集中在一个项目中，根本就不需要远程调用，拿来即用。

最后，老板要你给一张系统架构图，很尴尬的发现，原来是这样的：

既然是单体应用，也就跟集群没有半毛钱关系了，当然，想改造成集群并非不可。

以这么单薄的系统架构，很难相信其能抗住多大的流量，性能方面可圈可点。

代码结构上，到最后会很尴尬地发现功能模块间的耦合性越来越高，正所谓「剪不断，理还乱」，到头来很绝望地问自己：还要不要重构？

如果要写单元测试，跑一个Case就要重启工程5分钟，能不抓狂吗？

对于那些小型站点，以快速交付为目的的项目，用ALL in ONE的开发模式未尝不可。

---

2、浅谈SOA（Service-Oriented Architecture）

犹豫了很久，要不要顺带介绍一下SOA？讲真，并不是篇幅所限，而是知识所限。以我现有的浅薄知识，区分SOA和微服务似乎是一件很吃力的事情，但我还是试着去了解。万一哪个瞬间我的任督二脉通了呢？

还有一个原因，仔细想想，我们在谈微服务的时候，我们在谈什么？SOA大概是一个绕不过的鸿沟吧！

论资历，SOA绝对算的上老大哥了，于1996年被Gartner大神所提出，2000年才慢慢流行起来。所以我们一提到微服务这个「后起之秀」，都习惯给SOA加上一个形容词：「传统的」。

SOA可以认为是一种架构风格，甚至是一种设计模式。字面上理解，我们在做系统设计的时候，是以一个服务作为一种组件来设计。

那什么是服务（Service）？服务就是一组动作（业务活动）的抽象。

SOA主张的是粗粒度，所以在划分服务的时候，还是需要有所斟酌的。粗粒度性的一个最大好处就是向外提供的服务接口不会太多，以便降低服务之间往复调用的性能损耗。但是同时还要考虑服务的可复用性，服务划分过于简单粗暴也不是件好事。在这两者之间，需要根据实际的业务场景找到一个合适的制衡点。

当我们把订单、支付、账户等抽象成一个个模块，这个过程我们就可以看成是在做服务提取，但并不是这样做就可以完成面向服务的架构，SOA真正的价值是把所有的服务整合起来，使之相对独立而又能有条不紊的相互协作，完成一系列的业务操作。

因此，我眼中的SOA有两个核心要素：服务和治理。

那么，若干个服务之间是如何取得联系的？

这里面的水似乎很深了，涉及到了SOA领域的好几个概念，我尝试着去解释一番。

其中，最著名的当属SCA和ESB了。

SCA（Service Component Architecture），是为实现 SOA 而产生的一种规范。该规范被IBM、Oracle、SAP、BEA等大厂所认同，因此在民间也广为流传。

SCA独立于任何具体的技术，从编程模型上决定了SOA的实现方式。你可以用不同的编程语言构建功能单元或组件，然后将他们通过SOAP、JMS、RMI、REST或其它协议暴露为服务。

SCA的基础构成单元是Component，可以将它认为是一组接口的implementation的集合，或者是已存在的外部系统。SCA致力于将开发人员从繁杂的底层协议处理中解脱出来，屏蔽一切技术细节，聚焦于业务功能的实现。基于SCA开发的一套著名的框架是Apache Tuscany，关于Tuscany，已不属于本文讨论的范畴了，就不在此赘述了。附上一张SCA典型的体系结构图，感受一下：

服务组件体系结构

相比较SUN公司提出的JBI（Java Business Integration），就没那么幸运了，尤其是SUN被收购后，JBI已经陷入了名存实亡的窘境，前景自然就不容乐观。

JBI一开始的定位就是对已有的Java EE容器的扩展，并不打算兼容其他平台的组件。基于JBI规范构造出来的结果，本质上还是一种运行容器，其内部有消息的分发引擎，协议的转换引擎，所以支持的协议更多了，融合了HTTP，RMS，JMI。

这对于整个JAVA生态来说，是非常值得推行的，而对现行的SOA体系来说，就显得捉襟见肘了，所以也难以得到重用。

总的来说，SCA已成为SOA事实上的标准，提到SOA，基本上都会扯上SCA。

ESB（Enterprise Service Bus），业内通常翻译为「企业服务总线」。我尝试着百度了一下「ESB」，前面几条是有企业做广告的，大致就是为企业提供ESB服务，而百度SCA则不会有任何广告出现。这从某种意义上证明我的设想，ESB就是基于SCA规范的一种具体实现。

既然是企业服务的总线，其承载的流量是巨大的，各式各样的服务以不同的姿势接入到总线中，所以ESB首当其冲要解决的是不同协议的支撑和适配问题，其次，还需要对每个服务进行集成、编排和监控。ESB的出现，可以有效的打破企业内部「信息孤岛」的局面，让数据也能成为企业的“流动资金”。

如果你能顺利阅读到此处，其实也就不难理解我在上述提到的SOA两大核心要素：服务和治理。

---

3、再谈微服务（Microservice）

写到最后，最重要的压轴戏终于出现了！

我不禁要把Martin大神拿出来拜上两拜。

Martin大神在凡间一个蜜汁微笑，Agile诞生了；捋捋胡须，Microservice火了。

回到上述的ALL in ONE，这种模式下开发出来的应用，无论是可扩展性，还是可维护性，都是非常差劲的，这与微服务的理念是相违背的。

微服务的目的是有效的拆分应用，实现敏捷开发和快速部署 。

《The art of scalability》中提到的scale cube。

以上的这个小方块，在互联网圈子里，被众多巨巨们所津津乐道。

这是一个三维模型，三个方向分别代表了三种可扩展的维度：

X-axis：Application级别的横向扩展。当然，它们都是躲在Load Balance后面，等待钦点；

X-axis：Horizontal Duplication

Y-axis：可以看做是应用内的扩展，即一个应用内的每个服务可以部署多个实例；

Y-axis- Functional Decomposition

Z-axis：和X-axis有些相似，都是应用级别的扩展，不同的是，每个副本只访问部分数据，即多了“分库分表”的工作。

Z-axis- data partitioning

虽然三个维度是相互垂直的，但是并不代表没有任何关系，也不是非要三选一不可。

我们可以试着感受一下：

X-axis代表运行多个应用实例，外加Load Balance，提升了应用的整体抗压性；

Y-axis代表将应用进一步分解为微服务，并部署多个实例，也就意味着针对应用内的某几个服务，提升其性能，使其不易触碰到瓶颈；

当数据量大时，还可以用Z-axis将服务按数据分区（分表）。

从这个角度看，这是应用性能提升的几个手段。

再说回微服务。下面引用一段总结性的文字：

Martin自己也说了，每个人对微服务都可以不尽相同，不过大概的标准还是有一些的。
1、分布式服务组成的系统
2、按照业务而不是技术来划分组织
3、做有生命的产品而不是项目
4、Smart endpoints and dumb pipes（我的理解是强服务个体和弱通信）
5、自动化运维（DevOps）
6、容错
7、快速演化

而在我看来，微服务这种思想其实对SOA的一种传承和延伸，微服务吸纳了SOA所有的优势之处，并且也具备了SOA没有的功能。

对于前面三个标准，同样适用于SOA，而后面的几点，则有所分别了。

第4个标准对前面提及的ESB的理念是有所冲击的。SOA侧重于对服务的治理，服务的治理者自然就成为了系统强势的一方，以ESB为中心，如果接入的服务多了，ESB将会变得越来越重。所以微服务主张的是去ESB，去中心化，消息的解析放在服务内进行。

对于5~7个标准，在SOA中并没有过多强调，因为已经不在其标准范畴内。而在微服务中，却是必须的。

不难看出，微服务完全具备了这个时代鲜明的特色，这些特色，在以往是不具备的，因为不那么被人们所重视。

在现在看来，有了Docker，DevOps等关键技术的加持，整个微服务生态还是比较完整的，也就不难理解微服务为什么这么火了。

关于微服务的治理，就不在此赘述了，打算另起新篇。

总结

本篇从ALL in ONE 讲到 Microservice，算是我这些年来开发模式的转变过程。也许今后还会有新的概念不断涌现，但我还是始终告诫自己不要在滚滚浪潮中迷失自己。

希望对你有所帮助。

THANKS！

---

附：

参考文献：

1、SOA标准之----SCA架构思想

2、SCA 专题——来自IBM

3、转载：微服务（Microservice）那点事

4、Microservices: Decomposing Applications for Deployability and Scalability