通俗易懂的方式带你了解微服务

前言

  其实微服务没有一个相对官方的定义，来声明这个具体是一个什么东西，在我个人看来微服务更符合一种思想或者说是一种以业务功能为主的服务概念，每一个功能都具有自主运行的业务功能并且不受语言限制。

什么是微服务，为什么要用微服务

  在百度百科介绍中：微服务可以称为“微服务架构”，其中心思想就是单个应用程序有许多松散耦合且可独立的较小的组件或服务组成。
  在维基百科介绍中：微服务是一种架构风格，专注于模块化(单一责任与功能的小型功能模块)为基础，利用模块化组合出复杂的大型应用程序，各功能模块与语言无关的 API 集相互通信。
  与微服务架构理念相反的就是单体应用架构，如果说微服务是由 N 个业务功能模块组成的应用程序，那么单体应用架构就是一个应用程序包含所有的业务功能。

微服务的优点

1. 易开发，每个模块都有独立数据库（可模块化开发）
2. 可独立部署（不同模块部署不同的服务器）
3. 伸缩性强（可根据需求进行需求更改）
4. 低耦合，高内聚
5. 技术栈不受限

微服务的缺点

1. 服务部署较困难（运维同志比较辛苦）
2. 难以保证一致性（微服务通讯通过 REST，RPC 等形式进行交互，通讯时延迟会受到比较大的影响）
3. 服务调用跨网络，增加网络IO，降低性能
4. 服务依赖性，A 依赖 B，B 依赖 C，那就只能按顺序部署 C > B > A

微服务比较单体应用架构的优劣

  在单体应用架构中，每一个业务功能都是不可分割的一步，一个挂掉都会影响整个程序的使用。包括升级也不例外，改一小块地方，整个程序都要重新启动。而微服务每个模块都是独立的存在，即使升级或者模块服务器宏机都不会影响其他模块的使用（关于具体的比较请看另一篇文章，本文主要是介绍微服务“单体架构、分布式架构、SOA 架构之间的爱恨情仇”），补充一点，分布式架构和微服务架构的区别，微服务的应用可能会在同一个服务器上，也可以是不同服务器

总结

  没有一个框架是十全十美的，有优点就会有缺点，还是要按照需求场景来进行开发任务，别为了微服务而微服务得不偿失