27 | 微服务架构：微服务究竟是灵丹还是毒药？

Jan 24, 2020

27 | 微服务架构：微服务究竟是灵丹还是毒药？-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

27 | 微服务架构：微服务究竟是灵丹还是毒药？

2020-01-24 李智慧来自北京

《后端技术面试 38 讲》

课程介绍



讲述：李智慧

时长10:33大小8.46M



微服务架构是从单体架构演化而来的。所谓单体架构，指的就是整个互联网系统所有代码打包在一个程序中，部署在一个集群上，一个单体应用构成整个系统。
而微服务架构则是将这个大的应用里面的一些模块拆分出来，这些模块独立部署在一些相对较小的服务器集群上，而应用通过远程调用的方式依赖这些独立部署的模块，完成业务处理。这些被独立部署的模块就被称为微服务，而这样的应用架构也被称为微服务架构。
应该说，模块化、低耦合一直以来都是软件设计追求的目标，独立部署的微服务使模块之间的依赖关系更加清晰，也更加隔离，使系统易于开发、维护，代表了正确的技术方向。但是在实践中，有时候却会出现这样的情况：用了微服务，系统反而变得更加难以开发、维护。技术团队痛苦不堪，觉得是微服务的锅，主张放弃微服务，退回到单体架构。
那么，究竟该不该上微服务？微服务是灵丹还是毒药？
单体架构的困难和挑战阿里巴巴大约是国内最早尝试微服务的企业之一。让我们先回顾一下这段历史，看看当年阿里巴巴为什么要上微服务架构？微服务架构能解决什么问题？用好微服务需要做哪些准备？
阿里巴巴开始尝试微服务架构大约是在 08 年，在此之前，一个网站就是一个大应用，一个用 Java 开发的 war 包就包含了整个应用。系统更新的时候，即使只是更新其中极小的一部分，也要重新打包整个 war 包，发布整个系统。
随着业务的不断发展，这样的单体巨无霸系统遇到了越来越多的困难。
编译、部署困难一个应用系统一个 war 包，这个 war 包可能有几个 G 大。对于开发工程师来说，开发编译和部署都是非常困难的，当时我用自己的电脑编译这个 war 包，大约需要半个多小时。工程师在开发的过程中，即使只改了庞大系统中的一行代码，也必须重新打包完整的系统，才能做开发测试。这样的单体系统对于开发部署和测试都是非常困难的，有时候甚至一天都写不了几行代码。
代码分支管理困难因为单体应用非常庞大，所以代码模块也是由多个团队共同维护的。但最后还是要编译成一个单体应用，统一发布。这就要求把各个团队的代码 merge 在一起，这个过程很容易发生代码冲突。而 merge 的时候又是应用要发布的时候，发布过程本来就复杂，再加上代码 merge 带来的问题，各种情况纠缠在一起，极易出错。所以，在单体应用时代每一次应用发布，都需要搞到深更半夜。
数据库连接耗尽对于一个巨型的应用而言，因为有大量的用户进行访问，所以必须把应用部署到大规模的服务器集群上。然后每个应用都需要与数据库建立连接，大量的应用服务器连接到数据库，会对数据库的连接产生巨大的压力，某些情况下甚至会耗尽数据库的连接。
新增业务困难因为所有的业务都耦合在一个单一的大系统里，随着时间的发展，这个系统会变得非常的复杂，想要维护这样一个系统是非常困难和复杂的。很多工程师入职公司半年，都还不能熟悉业务，于是熟悉系统的老员工们忙得要死，加班加点干活，不熟悉系统的新员工们一帮忙就出乱，跟着加班加点地干活。整个公司热火朝天地干活，但最后还是常常出故障，新的功能迟迟不能上线。
发布困难因为单体系统一个 war 包就包含了所有的代码，新版本发布的时候，即使跟自己开发的代码一点关系没有，但就因为包含了自己的代码，以防万一，所有开发工程师都不得不跟着发布值班，结果真正更新代码功能的只有几个人，而整个部门都要跟着加班。有代码更新的同事汗流浃背进行代码冲突处理和修复发布 bug，没有代码更新的同事陪着聊天、打瞌睡、打游戏。
这些单体架构带来的困难，很多工程师自身都是有切身体会的。所以，在开始进行微服务架构重构的时候，虽然也遇到了很多挑战和困难，但是大家为了自身的利益，还是团结一致，成功实施了微服务架构重构。
微服务框架原理当时，阿里自己开发了一个微服务框架实施微服务架构重构，这个微服务框架就是后来很著名的 Dubbo。Dubbo 应该说是借鉴了此前更早的 SOA 架构方案，即面向服务的体系架构。
在面向服务的体系架构里面，服务提供者向注册中心注册自己的服务，而服务调用者到注册中心去发现服务，发现服务以后，根据服务注册中心提供的访问接口和访问路径对服务发起请求，由服务的提供者完成请求，返回结果给调用者。后来的各种微服务框架，其实都可以认为是 SOA 架构的一种实现。但是在早期的 SOA 架构实践中，WSDL、SOAP 这些协议都比较重，服务的注册与发现描述协议很复杂，服务的调用效率也比较低。
Dubbo 在借鉴 SOA 架构的基础上进行了优化，抛弃了 SOA 一些不必要的规范约束，使用二进制协议进行服务注册与调用，执行效率和使用的简洁性都得到了极大提升。
Dubbo 架构和 SOA 架构一样，最核心的组件也是 3 个，分别是服务提供者、服务消费者和服务注册中心。
服务的提供者顾名思义就是微服务的具体提供者，通过微服务容器对外提供服务，而服务的消费者就是应用系统或是其他的微服务。
具体过程是服务的提供者程序在 Dubbo 的服务容器中启动，通过服务管理容器向服务注册中心进行注册，声明服务提供者提供的接口参数和规范，并且注册自己所在服务器的 IP 地址和端口。
服务的消费者如果想要调用某个服务，只需依赖服务提供者的接口进行编程即可。而服务接口通过 Dubbo 框架的代理访问机制，调用 Dubbo 的服务框架客户端，服务框架客户端会根据服务接口声明，去注册中心查找对应的服务提供者启动在哪些服务器上，并且将这个服务器列表返回给客户端。客户端根据某种负载均衡策略，选择某一个服务器，通过远程通讯模块发送具体的服务调用请求。
服务调用请求通过 Dubbo 底层自己的远程通讯模块，也就是 RPC 调用方式，将请求发送到服务的提供者服务器，服务提供者服务器收到请求以后，将该请求发送给服务提供者程序，完成服务的执行，并将服务执行处理结果通过远程调用通讯模块 RPC 返回给服务消费者客户端，服务消费者客户端将结果返回给服务调用程序，从而完成远程服务的调用，获得服务处理的结果。
微服务架构的落地实践阿里当时进行微服务架构重构的目标比较明确，要解决的问题也是工程师们日常开发的痛点，大家热情参与其中，所以阿里的微服务重构过程还是比较成功的。
阿里微服务重构成功的另外一个重要因素是，即使在单体时代，war 包内的模块关系也还是比较清晰的。所以在重构微服务的时候，只需要对这些模块进行较小的改动，进行微服务部署就可以了。
那么回到我们开头的问题，为什么有些企业会觉得用了微服务之后，反而问题更多了呢？
有些实施微服务的技术团队，既没有统一共识，让大家都热情参与；又没有做好模块划分，模块的职责边界不清，依赖关系混乱，很多单体架构下被隐藏的问题，到了微服务上反而变得更加严重，于是觉得是微服务这个技术有问题。
微服务不同于分布式缓存、分布式消息队列或者分布式数据库这些技术，这些技术相对说来是比较“纯粹”的技术，和业务的耦合关系不是非常大，使用这些技术的场景也比较明确。而微服务本身和业务强相关，如果业务关系没梳理好，模块设计不清晰，使用微服务架构很可能得不偿失，带来各种挫折。
很多技术团队在实施微服务的时候，把关注的重点放在了微服务技术框架上。事实上，微服务技术框架作为一个工具对于成功实施微服务是最不重要的，最重要的是使用微服务究竟能得到什么，也就是自己的需求是什么。
实施微服务的关注点应该遵循以下一个倒三角模型：
首先明确自己的需求：我们到底想用微服务达到什么样的目的？需求清晰了，再去考虑具体要实现的价值，再根据价值构建我们的设计原则，根据原则寻找最佳实践，最后根据实践去选择最合适的工具。
如果相反，先找到一个工具，然后用工具硬往上套需求，只会导致技术也没用好，业务也没做好，所有人都疲惫不堪，事情变得一团糟，最后反过来怪技术没用。
总结微服务和业务的关系是非常紧密的，仅仅用好微服务技术框架是无法成功实施微服务的。成功实施微服务最重要的是做好业务的模块化设计，模块之间要低耦合，高聚合，模块之间的依赖关系要清晰简单。只有这样的模块化设计，才能够构建出良好的微服务架构。如果系统本身就是一团遭，强行将它们拆分在不同的微服务里，只会使系统变得更加混乱。
关于模块的设计，可参考第 19 篇文章，组件设计原则。
思考题最后留一个问题吧。现在中台的概念比较火，中台和微服务的关系也比较密切，你理解的中台是什么样的，有什么样的价值，满足什么样的需求，和微服务的关系是什么呢？
欢迎你在评论区写下你的思考，也欢迎把这篇文章分享给你的朋友或者同事，一起交流进步一下。

分享给需要的人，Ta购买本课程，你将得18元

生成海报并分享

赞 9

提建议

26 | 搜索引擎架构：如何瞬间完成海量数据检索？

28 | 高性能架构：除了代码，你还可以在哪些地方优化性能？

 写留言

精选留言(14)

_funyoo_
2020-01-28
初次了解中台这个概念的时候，觉得他与微服务没有什么不同……但深入对比了解后还是发现了区别王健老师总结说：中台是企业级能力复用平台首先中台是对于企业来说的，在我理解是面向企业的设计，并不是服务于仅仅一天业务线而言的能力指其功能模式，承载手段的多样，比如数据中台等等复用是指中台对前台复杂多变需求的抽象，在稳定的后台和多变的前台中磨合的齿轮，是树根和枝叶间沟通反哺的树干而平台是他的存在形式区别在于微服务更多的是面向技术，为了代码复用，而没有解决前台的多变的需求而中台则是面向用户，面向需求，满足用户多变的需求提供稳定的解决方案微服务是拼凑，微服务面向后台的稳定中台是抽象，中台面向前台的多变
展开
作者回复: 👍
共 3 条评论
56
虢國技醬
2020-01-30
我想微服务是业务层面低耦合高内聚的体现！中台虽然不是很清楚，但我觉得中台第一是要业务量够大，产品或者服务形成矩阵时，抽出稳定的基础共性东西形成支撑上层灵活产品的基础。关键还是对业务的深刻理解，对软件未来的清晰认识，进行边界清晰的业务模块划分，从而形成一套稳定的微服务组成的系统
共 1 条评论
6
hex
2020-02-11
最近代码重构时提出了小前台大中台的概念,说下我的理解: 中台:公司业务方向比较多,对于业务处理逻辑相同的模块想要抽取出来做成一个中台微服务,供所有需要此业务逻辑的微服务调用,如短信模块,物流模块,账单对账等. 微服务:微服务给中台提供了便利,之前对于复用代码需要复制进去,现在有了微服务,这部分直接以微服务形式存在,就不需要去动这部分代码了.有新需求新功能只需要编写与页面交互的代码即可,其余直接远程调用中台. 老师讲的微服务就是应用按模块拆分后的独立部署的一个个模块,我的理解中台只是其中一个复用模块, 提供业务实现的,而微服务技术是实现中台的方式.
展开
共 1 条评论
5
老男孩
2020-03-06
老师这篇关于微服务的文章，写的太棒了！是否选择使用微服务不能只从技术的角度考虑，应该从架构的层面，我觉得软件架构的本质就是商业利益。正如老师在文章中讲到，单体架构发展到一定程度，业务功能越来越多，开发团队越来越庞大，带来的问题就是面对一个大而全的应用包，开发人员奔溃，集成人员迷茫，测试人员幽怨。新人很难快速上手，太多无效的通宵，牵一发动全身，然后就是各种扯皮。集成人员合并的时候看花了眼，开发人员莫名背锅，本来好好的功能，代码没动过，发一次版本就出问题了。这些问题都会造成效率低下，最终影响到公司和大家的利益。从需求和痛点出发去考虑微服务架构的改造和实践，才是正确的方向！而不能把微服务作为技术和工具来看。牛掰的技术千篇一律(第一性原理)，合适的架构才是目的。
展开
4
小时候很黑
2020-07-23
老师请教一下，微服务之间的http调用是否违反了依赖倒置原则呢？
作者回复: 本质上，依赖倒置和http没关系，高层模块可以通过高层接口调用微服务，这个高层接口通过proxy模式，使用http进行远程调用，这个高层接口属于高层模块，有高层模块定义，那么依然是符合依赖倒置原则的。如果高层模块直接http调用微服务，那就是违反了依赖倒置原则。
3
Bruce
2020-03-24
我觉得中台更偏底层和工具化一点，微服务是和业务有关联的，而中台一般不会好业务挂钩。现在很多中小企业都在做微服务和中台，完全就是盲目跟风，我觉得还是应该从实际出发，有些用户量不大的应用，没有必要做成微服务。
2
yz
2021-02-13
据说元数据驱动设计模式(metadata driven design), 可以把业务抽象成通用模型，具体使用时，再把模型实例化，从而实现业务的复用，这种元数据驱动设计模式和微服务有什么关系吗？
Lucky_Dog
2020-12-04
我们公司就是写中台的，在我的理解，微服务是实现中台的技术，通过把共用业务逻辑抽取出来成为一个微服务中心，供前台调用。
何慧成
2020-10-17
微服务是一种技术实现方式，通过分业务/技术模块分别管理和部署来减少耦合，提升能力复用程度。中台是面相业务，最极端的，通过单一架构将企业公共的能力包在一起，也是中台。
escray
2020-10-11
首先，我觉的不是所有的企业都需要微服务；其次，也不能总想着跨越式发展，弯路可以少走一些，但是该做的事情，比如领域建模、业务分析、架构设计……，一件也不能少。有点好奇，除了互联网大厂，还有哪些公司在做微服务，有没有成功案例？看过王健老师的中台专栏，也认可他总结的“中台是企业级能力复用平台”，但是对于“中台”这个国产概念，持谨慎怀疑态度，其实和之前在系统中抽象出来的服务层有点类似。 EJB、SOA、微服务、中台……概念先行大厂的人、财、物各种资源充足，搞一下“微服务”或者“中台”当然不在话下，但是中小公司也可以么？或者说有必要么？文中给出的“倒三角模型”应该是技术领域通用的，无论是微服务还是中台，或者是其他什么技术，都应该从需求、价值、原则、实践、工具的线索去梳理。推荐李运华老师《从零开始学架构》专栏中，关于微服务的几篇文章；当然王健老师的《说透中台》也值得一看。
展开
陈衎
2020-04-13
中台个人认为更倾向业务的专注性，垂直领域，高内聚，职责单一，易于重用和依赖。
亢（知行合一的路上）
2020-03-28
微服务迁移要考虑业务需求，服务拆分要合理，符合低耦合、高内聚，而不是为了使用技术而用技术。随着业务的复杂，集群化，微服务也是趋势，也就是水到渠成了。
芒果少侠
2020-03-25
中台往往是一些下沉之后的模块，相对而言是稳定的，不会因为业务变化而频繁改变。而微服务跟业务挂钩，具体依赖业务的组件化和模块化拆分。 --- 中台是一种平台公共模块能力的抽象，而微服务是一种架构实现的方法。因此，我觉得它们在严格意义上，不是一个维度上的概念。比如说，中台也可以以微服务的方式部署，供业务上层进行远程调用。
展开
奔奔奔跑
2020-02-01
最近也看了很多关于中台的文章，中台区别于微服务的很多是组织架构上的调整，而微服务不涉及组织架构。中台是为了更灵活快速的试错而提出来的

