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

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

维基百科：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 接口产生的远