从0开始学架构_35_34_深入理解微服务架构银弹_or_焦油坑
你好，我是华仔。
今天我和你分享的主题是深入理解微服务。
微服务是近几年非常火热的架构设计理念，大部分人认为是马丁福勒提出了微服务概念，但事实上，微服务概念的历史要早得多，也不是马丁福勒创造出来的。
马丁只是将微服务进行了系统的阐述，不过不能否认马丁在推动微服务起到的作用，微服务能火，马丁功不可没。
微服务的定义，相信你早已耳熟能详。
参考维基百科，我就来简单梳理一下微服务的历史吧。
二零零五年，彼得罗杰博士在web services edge大会上提出了micro web services的概念。
二零一一年，一个软件架构工作组使用了micro service一词来描述一种架构模式。
二零一二年，同样是这个架构工作组正式确定用microo service来代表这种架构。
二零二年，thoutwworks的詹姆斯刘易斯针对微服务概念在q ko on旧金山二零一二发表了演讲。
二零一四年，詹姆斯刘易斯和马丁福勒和写了关于微服务的一篇学术性的文章，详细阐述了微服务。
由于微服务的理念中也包含了服务的概念，而SOA中也有服务的概念。
我们自然而然的会提出疑问，微服务与SOA有什么关系？有什么区别？为何有了SOA还要提微服务？这几个问题是理解微服务的关键。
否则，如果只是跟风拿来用，既不会用也用不好用了，不但没有效果，反而还可能有副作用。
我们先来看看微服务与SOV的关系。
对于了解过SOA的人来说，第一次看到微服务这个概念肯定会有所疑惑，为何有了SOA还要提微服务呢？等到简单看完微服务的介绍后，可能很多人更困惑了，这不就是SOA吗？关于SOA和微服务的关系和区别，大概分为下面几个典型的观点。
第一种观点，微服务是SOA的实现方式，如文稿中图所示。
这种观点认为，SOA是一种架构理念，而微服务是SOA理念的一种具体实现方法。
例如，微服务就是使用HTTP restful协议来实现ESB的SOA.使用SOA来构建单个系统，就是微服务和微服务，就是更细粒度的SOA.第二种观点，微服务是去掉ESB后的SOA,如文稿中图所示。
这种观点认为，传统SOA架构最广为人诟病的就是庞大、复杂、低效的ESB,因此将ESB去掉，改为轻量级的HTTP,实现就是微服务。
第三种观点，微服务是一种和SOV相似，但本质上不同的架构理念，如文稿中图所示。
这种观点认为，微服务和SOA只是有点类似，但本质上是不同的架构设计理念。
相似点在于图中交叉的地方，就是两者都关注服务都是通过服务的拆分来解决。
可扩展性问题本质上不同的地方在于几个核心理念的差异，是否有ESB服务的力度、架构设计的目标等。
以上观点看似都有一定的道理，但都有点差别，到底哪个才是准确的呢？单纯从概念上是难以分辨的。
我来对比一下SOV和微服务的一些具体做法，再来看看到底哪一种观点更加符合实际情况。
第一，服务力度整体上来说，SOA的服务力度要粗一些，而微服务的服务力度要细一些。
例如，对于一个大型企业来说，员工管理系统就是一个SOA架构中的服务。
而如果采用微服务架构，则员工管理系统会被拆，分为更多的服务，比如员工信息管理、员工考勤管理、员工假期管理和员工福利管理等更多服务。
第二，服务通信SOV采用了ESB作为服务间通信的关键组件，负责服务定义、服务路由消息转换消息传递，总体上是重量级的实现微服务推荐使用统一的协议和格式，例如restful协议RPC协议无需ESP这样的重量级实现。
马丁福勒将微服务架构的服务通讯理念称为聪明的终端。
愚蠢的管道之所以用愚蠢二字，其实就是与ESB对比的。
因为ESB太强大了。
既知道每个服务的协议类型，又知道每一个服务的数据类型，还知道每个数据的格式。
而微服务的愚蠢的管道仅仅做消息传递，对消息格式和内容一无所知。
第三，服务交付SOA对服务的交付并没有特殊要求，因为SOA更多考虑的是兼容已有的系统。
微服务的架构理念要求快速交付，相应的要求采取自动化测试、持续集成、自动化部署等敏捷开发相关的最佳实践。
如果没有这些基础能力支撑，微服务规模一旦变大，整体就难以达到快速交付的要求。
这也是很多企业在实行微服务时踩过的一个明显的坑。
就是系统拆分为微服务后，部署的成本呈指数上升。
第四，应用场景SOV更加适合于庞大、复杂易构的企业级系统，这也是SOV诞生的背景。
这类系统的典型特征就是很多系统已经发展多年，采用不同的企业级技术，有的是内部开发的，有的是外部购买的，无法完全推倒重来，或者进行大规模的优化和重构。
因为成本和影响太大，只能采用兼容的方式进行处理。
而承担兼容任务的就是ESB微服务更加适合于快速轻量级。
基于web的互联网系统，这类系统业务变化快，需要快速尝试，快速交付，同时基本都是基于web,虽然开发技术可能差异很大，但对外接口基本都是提供HTTP resup风格的接口，无需考虑在接口层进行类似SOA的ESB那样的处理。
综合上述分析，我将SOA和微服务对比列在一个表格里，请点击报告查看。
因此我们可以看到，SOV和微服务本质上是两种不同的架构设计理念，只是在服务这个点上有交集而已。
因此，两者的关系应该是上面第三种观点。
其实马丁福勒在他的微服务文章中已经做了很好的提炼。
原文，请查看文稿。
这段英文的三个关键词，分别是small、 light、 weight automated,基本上浓缩了微服务的精华，也是微服务与SOA的本质区别所在。
通过前面的详细分析和比较，似乎微服务本质上就是一种比SOA要优秀很多的架构模式。
那是否意味着我们都应该把架构重构为微服务呢？其实不然，SOA和微服务是两种不同理念的架构模式，并不存在孰优孰劣，只是应用场景不同而已。
我们介绍SOA的时候提到其产生历史背景，是因为企业的IT服务系统庞大而又复杂，改造成本很高，但业务上又要求其互通。
因此才会提出SOA这种解决方案。
如果我们将微服务的架构模式生搬硬套到企业级IT服务系统中，这些IT服务系统的改造成本可能远远超出实施SUV的成本。
接下来我们来看看微服务有哪些陷阱。
单纯从上面的对比来看，似乎微服务大大优于SOV.这也导致了很多团队在实践时不加思考的采用微服务，既不考虑团队的规模，也不考虑业务的发展，也没有考虑基础技术的支撑。
只是觉得微服务很牛，就赶紧来实施，以为实施了微服务后，就什么问题都解决了。
而一旦真正实施后，才发现掉到微服务的坑里面去了。
我们看一下微服务具体有哪些坑。
第一，服务划分过细，服务件关系复杂，服务划分过细，单个服务的复杂度确实下降了，但整个系统的复杂度却上升了。
因为微服务将系统内的复杂度转移为系统间的复杂度了。
从理论的角度来计算，整体系统的复杂度是随着微服务数量的增加，呈指数级增加的文稿中的图形象的，说明了整体复杂度粗力度划分服务时系统被划分为三个服务。
虽然单个服务较大，但服务间的关系很简单，细粒度划分服务时。
虽然单个服务小了些，但服务间的关系却复杂了很多。
第二，服务数量太多，团队效率急剧下降。
微服务的微字本身就是一个陷阱，很多团队看到微字后，就想到必须将服务拆分的很细。
有的团队人员规模是五到六个人，然而却拆分出三十多个微服务，平均每个人要维护五个以上的微服务，这样做给工作效率带来了明显的影响。
一个简单的需求开发就需要设计多个微服务。
光是微服务之间的接口就有六到七个。
无论是设计、开发、测试部署，都需要工程师不停的在不同的服务间切换。
开发工程师要设计多个接口打开，多个工程调试时要部署多个程序，提测时，打开多个包测试工程师。
要部署多个环境准备多个微服务的数据测试，多个接口运维工程师每次上线都要操作多个微服务，并且微服务之间可能还有依赖关系。
第三，吊用链太长，性能下降。
由于微服务之间都是通过HTTP或者RPC调用的，每次调用必须经过网络。
一般线上的业务接口之间的调用，平均响应时间大约为五十毫秒。
如果用户的一起请求需要经过六次微服务调用，则性能消耗就是三百毫秒，这在很多高性能业务场景下是难以满足需求的。
为了支撑业务请求可能需要大幅增加硬件，这就导致了硬件成本的大幅上升。
第四，调用链太长问题定位困难系统拆分为微服务后一次用户请求需要多个微服务协同处理。
任意微服务的故障都将导致整个业务失败。
然而，由于微服务数量较多且故障存在扩散现象。
快速定位到底是哪个微服务故障是一件复杂的事情，有一个典型案例，请点击问稿，查看service c的数据库出现慢查询，导致service c给service b的响应错误。
Service b给service a的响应错误。
Service a给用户的响应错误，我们在实际定位时是不会有样例图中这么清晰的。
最开始是用户报错，这时我们首先会去查service a导致service a故障的原因有很多，我们可能要花半个小时甚至一个小时才能发现是service b返回错误导致的。
于是我们又去查service b这相当于重复service a故障定位的步骤。
如此循环下去，最后可能花费了几个小时才能定位到是service c的数据库慢查询导致了错误。
如果多个微服务同时发生不同类型的故障，则定位故障更加复杂。
示意图请点击问稿，查看service c的数据库发生慢查询故障。
同时service c到service d的网络出现故障。
此时到底是哪个原因导致了service c返回error给service b需要大量的信息和人力去排查。
第五，没有自动化支撑，无法快速交付。
如果没有相应的自动化系统进行支撑，都是靠人工去操作。
那么微服务不但达不到快速交付的目的，甚至还不如一个大而全的系统效率高。
例如，没有自动化测试支撑，每次测试时需要测试大量接口。
没有自动化部署支撑，每次部署六到七个服务几十台机器，运维人员敲shell命令出台部署，手都要敲码。
没有自动化监控，每次故障定位都需要人工查几十台机器几百个微服务的各种状态和各种日志文件。
第六，没有服务。
这里微服务数量多了后管理混乱。
信奉微服务理念的设计人员总是强调微服务的litwwait特性，并举出ESB的反例来证明微服务的优越之处。
但具体实践后就会发现，随着微服务种类和数量越来越多，如果没有服务治理系统进行支撑，微服务提倡的litwwait就会变成问题。
主要问题有服务路由。
假设某个微服务有六十个节点部署在二十台机器上，那么其他依赖的微服务如何知道这个部署情况呢？服务故障处理。
假设上述例子中的六十个节点有五个节点发生故障了，依赖的微服务如何处理这种情况呢？服务注册和发现同样是上述的例子，现在我们决定从六十个节点扩容到八十个节点，或者将六十个节点缩减为四十个节点，新增或者减少的节点。
如何让依赖的服务知道呢？如果以上场景都依赖人工去管理，整个系统将陷入一片混乱。
最终的解决方案必须依赖自动化的服务管理系统。
这时就会发现，微服务所推崇的light wait,最终也发展成和ESP,几乎一样的复杂程度。
今天我为你讲了微服务与SOV的关系，以及微服务实践中的常见陷阱，希望对你有所帮助。
这就是今天的全部内容，留一道思考题给你吧。
你们的业务有采用微服务吗？谈谈具体实践过程中有什么经验和教训，欢迎你把答案写到留言区，和我一起讨论。
相信经过深度思考的回答，也会让你对知识的理解更加深刻。