一、什么是微服务

单体应用架构

聊微服务之前，先说下什么是单体应用。通过对比，可以更好的发现微服务的价值。

常见的单体应用架构有两种：

• LAMP（Linux + Apache + MySQL + PHP）
• MVC（Spring + iBatis/Hibernate + Tomcat）

在业务规模小的时候，单体应用架构具有以下优点：

• 学习成本低
• 开发上手快
• 测试、部署、运维也比较方便

随着业务规模的扩大，单体应用框架的缺点就会慢慢暴露出来：

• 部署效率低：依赖多，编译时间长，启动时间长
• 团队协作开发成本高：主要体现在merge代码上
• 系统高可用性差：重要服务和非重要服务混部，如果非重要服务出现问题，就会影响重要服务

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

什么是服务化？

服务化就是把传统的单机应用中通过本地包依赖产生的本地方法调用，改造成通过 RPC 接口产生的远程方法调用。

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

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

什么是微服务？

服务化的思想进一步演化，就演变为今天我们所熟知的微服务。

微服务相比于服务化的不同点：

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

总结来说，微服务架构是将复杂臃肿的单体应用进行细粒度的服务化拆分，每个拆分出来的服务各自独立打包部署，并交由小团队进行开发和运维，从而极大地提高了应用交付的效率，并被各大互联网公司所普遍采用。