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