微服务架构是从单体架构演化而来的。所谓单体架构，指的是整个互联网系统所有代码打包在一个程序中，部署在一个集群上，一个单体应用构成整个系统。
而微服务架构则是将这个大的应用里面的一些模块拆分出来，这些模块独立部署在一些相对较小的服务器集群上，应用通过远程调用的方式依赖这些独立部署的模块完成业务处理。这些被独立部署的模块被称为微服务，而这样的应用架构也被称为微服务架构。
应该说，模块化、低耦合一直以来都是软件设计追求的目标，独立部署的微服务使模块之间的依赖关系更加清晰，隔离得也更好，让系统更易于开发、维护，代表了正确的技术方向。但是在实践中，有时使用了微服务系统反而变得更加难以开发、维护，技术团队痛苦不堪，觉得是微服务的“锅”，于是主张放弃微服务，退回到单体架构。
那么，究竟该不该使用微服务？微服务是“灵丹”还是“毒药”？
单体架构的困难和挑战
阿里巴巴大约是国内最早尝试微服务的企业之一。让我们先回顾一下这段历史，看看当年阿里巴巴为什么要使用微服务架构？微服务架构能解决什么问题？用好微服务需要做哪些准备？
阿里巴巴开始尝试微服务架构大约是在2008年。在此之前，一个网站就是一个大应用，一个用Java开发的war包就包含了整个应用。系统更新时，即使只是更新其中极小的一部分，也要重新打包整个war包，发布整个系统。
随着业务的不断发展，这样的单体巨无霸系统遇到了越来越多的困难。
1. 编译、部署困难
一个应用系统一个war包，这个war包的大小可能是几个GB。对于开发工程师来说，开发编译和部署这个war包都是非常困难的，当时我用自己的电脑编译，大约花了半个多小时。工程师在开发的过程中，即使只改了庞大系统中的一行代码，也必须重新打包完整的系统才能做开发测试。对这样的单体系统进行开发部署和测试都是非常困难的，有时甚至一天都写不了几行代码。
2. 代码分支管理困难
因为单体应用非常庞大，所以代码模块也是由多个团队共同维护的，但最后还是要编译成一个单体应用，统一发布。这就要求把各个团队的代码合并在一起，这个过程很容易发生代码冲突。而合并的时候又是应用要发布的时候，发布本就是复杂的过程，再加上代码合并带来的风险，各种情况纠缠在一起，极易出错。所以，在单体应用时代，每一次应用发布都需要搞到深更半夜。
3. 数据库连接耗尽
对于一个巨型的应用而言，因为有大量的用户进行访问，所以必须部署到大规模的服务器集群上，且每个应用都需要与数据库建立连接。大量的应用服务器连接到数据库，会对数据库的连接产生巨大的压力，某些情况下甚至会耗尽数据库的连接。
4. 新增业务困难
因为所有的业务都耦合在一个单一的大系统里，随着时间的推移，这个系统会变得非常复杂，想要维护这样一个系统是非常困难的。很多新入职的工程师不熟悉业务，于是熟悉系统的老员工要加班加点地干活，不熟悉系统的新员工虽然一帮忙就出乱，但也免不了要跟着加班。整个公司热火朝天地干活，但最后还是常常出故障，新的功能迟迟不能上线。
5. 发布困难
单体系统一个war包就包含了所有的代码，新版本发布的时候，即使跟自己开发的代码一点关系都没有，但就因为包含了自己的代码，所以也不得不跟着发布值班，真正更新代码功能的只有几个人，他们汗流浃背地处理代码冲突和修复发布Bug，没有代码更新的同事则陪着聊天、打瞌睡、打游戏。
这些单体架构带来的问题很多工程师都是有切身体会的。所以，在开始重构微服务架构时，虽然也遇到了很多挑战和困难，但是大家为了自身的利益，还是团结一致，成功完成了微服务架构重构。
微服务框架原理
当时，阿里自己开发了一个微服务框架重构微服务架构，这个微服务框架就是著名的Dubbo。Dubbo借鉴了此前更早的SOA架构方案，即面向服务的体系架构。SOA架构如图27-1所示。
在面向服务的体系架构里面，服务提供者向注册中心注册自己的服务后，服务调用者要到注册中心去发现服务，发现服务以后，根据服务注册中心提供的访问接口和访问路径对服务发起请求，由服务的提供者完成请求，返回结果给调用者。后来的各种微服务框架其实都可以认为是SOA架构的一种实现。但是在早期的SOA架构实践中，WSDL、SOAP这些协议都比较重，服务的注册与发现描述协议很复杂，服务的调用效率也比较低。
Dubbo在借鉴SOA架构的基础上进行了优化，抛弃了SOA一些不必要的规范约束，使用二进制协议进行服务注册与调用，这使得执行效率和使用的简洁性都得到了极大提升。Dubbo架构如图27-2所示。
Dubbo架构和SOA架构一样，最核心的组件也是三个，分别是服务提供者、服务消费者和服务注册中心。
顾名思义，服务的提供者就是微服务的具体提供者，它通过微服务容器对外提供服务，而服务的消费者就是应用系统或是其他微服务。
具体过程是服务的提供者程序在Dubbo的服务容器中启动，通过服务管理容器向服务注册中心进行注册，声明服务提供者提供的接口参数和规范，并且注册自己所在服务器的IP地址和端口。
服务的消费者如果想要调用某个服务，只需依赖服务提供者的接口进行编程即可。而服务接口通过Dubbo框架的代理访问机制，调用Dubbo的服务框架客户端，服务框架客户端会根据服务接口声明，去注册中心查找对应的服务提供者启动在哪些服务器上，并且将这个服务器列表返回给客户端。客户端根据某种负载均衡策略，选择某一个服务器，通过远程通信模块发送具体的服务调用请求。
服务调用请求通过Dubbo底层的远程通信模块，也就是RPC调用方式，将请求发送到服务的提供者服务器，服务提供者服务器收到请求以后，将该请求发送给服务提供者程序，执行服务，并将服务执行的结果通过远程调用通信模块RPC返回给服务消费者客户端，服务消费者客户端将结果返回给服务调用程序，从而完成远程服务的调用，获得服务处理的结果。
微服务架构的落地实践
阿里当时进行微服务架构重构的目标比较明确，要解决的问题也是工程师们日常开发的痛点，大家积极参与其中，所以阿里的微服务重构过程还是比较成功的。
即使在单体时代，war包内的模块关系也是比较清晰的。所以在重构微服务时，只需要对这些模块进行较小的改动，进行微服务部署就可以了。这也是阿里微服务重构成功的另外一个重要因素。
那么，回到本章开始的问题，为什么有些企业会觉得用了微服务之后，反而问题更多了呢？
有些实施微服务的技术团队，既没有达成共识，又没有做好模块划分，模块的职责边界不清，依赖关系混乱，很多单体架构下隐藏的问题到了微服务上反而变得更加严重，于是有人觉得是微服务这个技术有问题。
微服务不同于分布式缓存、分布式消息队列或者分布式数据库这些技术。这些技术相对来说是比较“纯粹”的，和业务的耦合关系并不大，使用这些技术的场景也比较明确。而微服务本身和业务强相关，如果业务关系没梳理好，模块设计不清晰，使用微服务架构很可能得不偿失，带来各种问题。
很多技术团队在实施微服务的时候，把关注的重点放在了微服务技术框架上。事实上，微服务技术框架作为一个工具对于成功实施微服务不是最重要的，最重要的是使用微服务究竟能得到什么，也就是自己的需求是什么。
实施微服务的关注点应该是如图27-3所示的倒三角模型。
首先明确自己的需求，即我们到底想用微服务达到什么样的目的。需求清晰了，再去考虑具体要实现的价值，并根据价值构建我们的设计原则，根据设计原则寻找最佳实践，最后根据实践去选择最合适的工具。
如果先找到一个工具，然后用工具硬往上套需求，只会导致技术用不好，业务也做不好，所有人都疲惫不堪，事情变得一团糟，最后还要反过来找技术的毛病。
小结
微服务和业务的关系是非常紧密的，仅仅用好微服务技术框架是无法成功实施微服务的。成功实施微服务最重要的是做好业务的模块化设计，模块之间要低耦合、高聚合，模块之间的依赖关系要清晰简单。只有实现这样的模块化设计，才能构建出良好的微服务架构。如果系统本身就是一团糟，强行将它们拆分在不同的微服务里，只会使系统变得更加混乱。
本文摘自机械工业出版出版的《架构师的自我修炼:技术、架构和未来》一书，作者李智慧。
推荐阅读
《架构师的自我修炼：技术、架构和未来》从四个方面，全方位阐述了架构师必须具备的各项知识。本书既包含了成为一个软件架构师必须具备的各种知识技能体系，也包含了修炼成为一个架构师的学习成长思考。阅读本书，相信您从中不但可以领会各种技术的内在联系，也可以领悟到更深刻的技术和成长之道。
RECOMMEND
更多微服务相关好书推荐
01
《微服务架构设计模式》
推荐语：由世界十大软件架构师之一、微服务架构的先驱、Java开发者社区的意见领袖Chris Richardson亲笔撰写，旨在帮助架构师和程序员学会使用微服务架构成功开发应用程序。书中描述了如何解决我们将面临的众多架构设计挑战，涵盖44个架构设计模式，系统解决服务拆分、事务管理、查询和跨服务通信等难题。本书将教会你如何开发和部署生产级别的微服务架构应用，帮助你设计、实现、测试和部署基于微服务的应用程序。
02
《Go微服务实战》
推荐语：“给小白的Go语言微服务实战书籍”结合大量实战案例，全面深入介绍Go语言知识、微服务理论，以及Go语言实现微服务模式的方法。
03
《Spring Cloud微服务：入门、实战与进阶》
推荐语：本书主打的是与微服务相关的实战体系。本书的读者对象主要是 Java 开发人员，特别是工作 1～3 年的开发人员，这个阶段的开发人员资历尚浅，需要一些实用的技术和经验来提升自己，Spring Cloud 正是一门符合提升要求的技术。因为它现在正处于快速发展的阶段，越来越多的企业也开始使用 Spring Cloud。相信在不久的将来，熟练掌握Spring Cloud 将会成为 Java 开发人员面试的门槛。
04
《OpenShift在企业中的实践: PaaS DevOps 微服务》
推荐语：本书受到多位全球知名企业IT负责人的联名推荐，涵盖银行、保险、汽车制造、航空信息等行业，体现了本书巨大的含金量。本书的内容均来自作者一线的售前和实施经验，具有极强的技术指导性。本书系统性地阐述了PaaS、DevOps、微服务治理和微服务高级管理。本书不是简单地介绍基本概念或实验步骤，而是从企业客户实战角度出发，为客户通过OpenShift实现IT转型给出具体的建议和参考架构。
本书内容兼顾运维和开发，是秉承全栈理念的一本书籍。
扫码关注【华章计算机】视频号
每天来听华章哥讲书
书讯 | 5月书讯（下）| 5天小长假，一起读新书
书讯 | 5月书讯（上）| 5天小长假，一起读新书
资讯 | DB-Engines 4月数据库排名：Redis有望甩掉“千年老七”？
书单 | 8本书助你零基础转行数据分析岗
收藏 | 终于有人把Scrapy爬虫框架讲明白了
上新 | 【新书速递】架构师是怎样炼成的
3105
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
