什么是微服务？

什么是微服务？为什么会有微服务？让我们带着这些疑问开始我们的探索。

我们先看下*和百度百科给出的定义：

*：2014年，martin fowler 与 james lewis 共同提出了微服务的概念，定义了微服务是由以单一应用程序构成的小服务，自己拥有自己的行程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用 http api 通信。同时服务会使用最小的规模的集中管理 (例如 docker) 能力，服务可以用不同的编程语言与数据库等组件实现。

百度百科：所谓的微服务是soa架构下的最终产物，该架构的设计目标是为了肢解业务，使得服务能够独立运行。微服务设计原则：1、各司其职 2、服务高可用和可扩展性

概念还是比较抽象的，接下来，我将从单体应用开始，讲解为什么会有微服务以及什么是微服务。

单体应用

在初期，互联网公司的应用技术栈大致分为 lamp（linux + apache + mysql + php）和 mvc（spring + ibatis/hibernate + tomcat）两大流派。两者都是为单体应用架构设计的，其优点是学习成本低，开发上手快，测试、部署、运维也比较方便。

以 mvc 架构为例，业务通常是通过部署一个 war 包到 tomcat 中，然后启动 tomcat，监听某个端口即可对外提供服务。早期在业务规模不大、开发团队人员规模较小的时候，采用单体应用架构，团队的开发和运维成本都可控。

然而随着业务规模的不断扩大，团队开发人员的不断扩张，单体应用架构就会开始出现问题，大概会有以下几个方面的问题。

• 部署效率低：当单体应用的代码越来越多，依赖的资源越来越多时，应用编译打包、部署测试一次，甚至需要 10 分钟以上。
• 团队协作开发成本高：当团队人员扩张，多人修改代码，然后一起打包部署，测试阶段只要有一块功能有问题，就得重新编译打包部署，然后重新预览测试，所有相关的开发人员又都得参与其中，效率低下，开发成本极高。
• 系统高可用性差：因为所有的功能开发最后都部署到同一个 war 包里，运行在同一个 tomcat 进程之中，一旦某一功能涉及的代码或者资源有问题，那就会影响整个 war 包中部署的功能。
• 线上发布变慢：一旦代码膨胀，服务启动的时间就会变长。因此，急需一种方法能够将应用的不同模块的解耦，降低开发和部署成本。

想要解决上面这些问题，服务化的思想也就应运而生。

服务化

服务化就是把传统的单机应用中通过 jar 包依赖产生的本地方法调用，改造成通过 rpc 接口产生的远程方法调用。在编写业务代码时，对于通用的业务逻辑，把它抽象并独立成为专门的模块，对于代码复用和业务理解有很大的好处。

以微博系统为例，微博既包含了内容模块，也包含了消息模块和用户模块等。其中消息模块依赖内容模块，消息模块和内容模块又都依赖用户模块。当这三个模块的代码耦合在一起，应用启动时，需要同时去加载每个模块的代码并连接对应的资源。一旦任何模块的代码出现 bug，或者依赖的资源出现问题，整个单体应用都会受到影响。

为此，首先可以把用户模块从单体应用中拆分出来，独立成一个服务部署，以 rpc 接口的形式对外提供服务。微博和消息模块调用用户接口，就从进程内的调用变成远程 rpc 调用。这样，用户模块就可以独立开发、测试、上线和运维，可以交由专门的团队来做，与主模块不耦合。进一步的可以再把消息模块也拆分出来作为独立的模块，交由专门的团队来开发和维护。

可见通过服务化，可以解决单体应用膨胀、团队开发耦合度高、协作效率低下的问题。

微服务

从 2014 年开始，容器化技术的成熟以及 devops 文化的兴起，服务化的思想进一步演变为微服务。

微服务相比于服务化的不同可总结为以下四点：

• 服务拆分粒度更细：微服务可以说是更细维度的服务化，小到一个子模块，只要该模块依赖的资源与其他模块都没有关系，那么就可以拆分为一个微服务。
• 服务独立部署：每个微服务都严格遵循独立打包部署的准则，互不影响。比如一台物理机上可以部署多个 docker 实例，每个 docker 实例可以部署一个微服务的代码。
• 服务独立维护：每个微服务都可以交由一个小团队甚至个人来开发、测试、发布和运维，并对整个生命周期负责。
• 服务治理能力要求高：因为拆分为微服务之后，服务的数量变多，因此需要有统一的服务治理平台，来对各个服务进行管理。

以微博系统为例，可以进一步对内容模块的功能进行拆分，比如内容模块又包含了 feed 模块、评论模块和个人页模块。通过微服务化，将这三个模块变成三个独立的服务，每个服务依赖各自的资源，并独立部署在不同的服务池中，可以由不同的开发人员进行维护。当评论服务需求变更时，只需要修改评论业务相关的代码，并独立上线发布；而 feed 服务和个人页服务不需要变更，也不会受到发布可能带来的变更影响。

由此可见，微服务化给服务的发布和部署，以及服务的保障带来了诸多好处。

单体应用和微服务应用的区别

	单体式应用	微服务应用
进程数	将所有功能放到同一个进程中	将功能的每个元素放置到分离的多个服务进程中
拓展方式	通过复制整个应用到多台服务器实现拓展	通过将不同的服务分布于不同的服务器，并按需复制服务的方式实现拓展
快速响应变更	部分更新，都需要重新部署整个应用	部署和升级都是独立的，有助于大大提高系统变更的敏捷性
团队结构	团队结构呈现垂直化，每个团队专门负责专门的一块	团队结构呈现扁平化，每个团队服务一整个业务能力
可用性	一个服务的不稳定可能导致整个应用出现问题	一个服务不稳定，影响范围比较小
创新性	很难引入新的技术和框架，所有功能都使用的同一种框架	每个微服务可以使用不同的语言和框架，引入新技术方便

总结

由单体应用进化到服务化拆分部署，随着移动互联网规模的不断扩大，敏捷开发、持续交付、devops 理论的发展和实践，以及容器化技术的成熟，微服务架构开始流行。

微服务的核心在于服务治理，微服务架构是将复杂臃肿的单体应用进行细粒度的服务化拆分，每个拆分出来的服务各自独立打包部署，并交由小团队进行开发和运维，从而极大地提高了应用交付的效率。

参考

https://zh.wikipedia.org/zh-cn/microservices

https://dwz.cn/ybnkzedt