我所了解的微服务

开始装逼之旅以前，请容许我和你们一块儿再温习一句话：

这句话适合一切高大上的概念，好比：SOA，DevOps，DDD，Agile，Cloud等等，包括我如今想要讲述的「微服务」。
为何会这样？
“专家”太多了，俗话说的好：「一千个专家眼里，有一千个哈姆雷特」。
概念听的多了，还觉得本身见多识广，最后大多都是迷茫了：「卧槽！我到底应该信谁？」
依老夫看：信谁都不如信本身！
如此纷繁复杂的概念，真是让人捉摸不透，却又不得不去了解，毕竟互联网的圈子里有太多洪水猛兽，稍有懈怠，就会被拍在沙滩上了。
其实，意识到本身身处如此险境，也算是个人后知后觉，或许早有感知，但是迟迟没有行动。直至现现在，我才十分强烈地感觉到这个时代对咱们这些素人深深的恶意。
是的，我得挣扎一下，给将来的本身留下点痕迹。
纵观我不算很长的从业经验，能够总结出六字箴言：

据说过，没用过

这将是IT界的技术人员在知识的广度和深度之间纠结的一个缩影。
多么痛的领悟，有木有！~~
个人生活很多阅历，却极度匮乏提炼和升华。虽然以前也在社交媒体上零零散散地「矫情」过几回，但那都是生活成长之感悟，对于本身的专业技术层面，仍是少之又少。
所以，为了不迷失于这一波又一波的互联网大潮中，我决定梳理一下「毕生所学」，恰好最近对微服务有一些实践经验，那就谈谈我所了解的微服务。

---

一、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的开发模式何尝不可。

---

二、浅谈SOA

犹豫了好久，要不要顺带介绍一下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两大核心要素：服务和治理。

---

三、再谈微服务

写到最后，最重要的压轴戏终于出现了！我不由要把Martin大神拿出来拜上两拜。

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

回到上述的ALL in ONE，这种模式下开发出来的应用，不管是可扩展性，仍是可维护性，都是很是差劲的，这与微服务的理念是相违背的。
微服务的目的是有效的拆分应用，实现敏捷开发和快速部署 。

以上的这个小方块，在互联网圈子里，被众多巨巨们所津津乐道。这是一个三维模型，三个方向分别表明了三种可扩展的维度：

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

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

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

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

咱们能够试着感觉一下：
X-axis表明运行多个应用实例，外加Load Balance，提高了应用的总体抗压性；
Y-axis表明将应用进一步分解为微服务，并部署多个实例，也就意味着针对应用内的某几个服务，提高其性能，使其不易触碰到瓶颈；
当数据量大时，还能够用Z-axis将服务按数据分区（分表）。
从这个角度看，这是应用性能提高的几个手段。

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

Martin本身也说了，每一个人对微服务均可以不尽相同，不过大概的标准仍是有一些的。
一、分布式服务组成的系统
二、按照业务而不是技术来划分组织
三、作有生命的产品而不是项目
四、Smart endpoints and dumb pipes（个人理解是强服务个体和弱通讯）
五、自动化运维（DevOps）
六、容错
七、快速演化

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

对于前面三个标准，一样适用于SOA，然后面的几点，则有所分别了。
第4个标准对前面说起的ESB的理念是有所冲击的。SOA侧重于对服务的治理，服务的治理者天然就成为了系统强势的一方，以ESB为中心，若是接入的服务多了，ESB将会变得愈来愈重。因此微服务主张的是去ESB，去中心化，消息的解析放在服务内进行。
对于5~7个标准，在SOA中并无过多强调，由于已经不在其标准范畴内。而在微服务中，倒是必须的。

不难看出，微服务彻底具有了这个时代鲜明的特点，这些特点，在以往是不具有的，由于不那么被人们所重视。
在如今看来，有了Docker，DevOps等关键技术的加持，整个微服务生态仍是比较完整的，也就不难理解微服务为何这么火了。

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

---

总结

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

但愿对你有所帮助。

THANKS！

附：

参考文献：

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

二、SCA 专题——来自IBM

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

四、Microservices: Decomposing Applications for Deployability and Scalability