微服务是近些年流行起来的热门概念,与传统的单体架构相比,它有许多的优势。那么到底什么是微服务呢?本文将对微服务优缺点进行分析,让大家全面的了解微服务。
一、什么是微服务
通常而言,微服务架构是一种架构模式或者说是一种架构风格。
它提倡将单一应用划分成一组小的服务,每个服务运行独立的自己的进程中,服务之间互相协调、互相配合,为用户提供最终价值。
服务之间采用轻量级的通信机制互相沟通(通常是基于 HTTP 的 RESTful API) 。每个服务都围绕着具体业务进行构建,并且能够被独立地部署到生产环境、类生产环境等。
二、微服务的优劣势
1)优势
- 开发起来简单:一个服务可能就是专一的只干一件事情,开发人员开发时只需要关注自己的微服务即可。
- 易于扩展:当某个服务的访问量较大时,我们只需要将这个服务扩容即可。
2)劣势
- 维护起来麻烦:运维人员需要维护多个系统(每个微服务看样看做是一个系统),单体应用架构只需要维护一套系统。
- 技术复杂性较高:典型的分布式事务问题。微服务架构下会有多个数据库,这些数据库间的事务一致性是一个急需解决的问题。
三、微服务适合什么样的项目
看一个项目适不适合用微服务,主要参考两方面:业务复杂度和性能要求。
1)业务复杂度![在这里插入图片描述](https://i-blog.csdnimg.cn/blog_migrate/e4ed730fda934c5dc83ee73c5065bb8b.png)
上面的图来自 Martin Fowler 的文章,揭示了生产率(Productivity)和业务复杂度(Base Complexity)的一个关系:
- 在业务复杂度较小时采用单体应用(Monolith)的生产率更高。
- 当业务复杂度到了一定规模时,单体应用的生产率开始急剧下降,这时对其进行微服务化(Microservice)的拆分才是合理的。
2)性能
- 当并发量比较小的时候,使用微服务并不能体现它的优势。这时用单体结构就可以满足系统的性能要求。
- 当并发量较大时,尤其集中在一个或者少量几个业务场景下,使用微服务便可有效的节省资源。
综上所述,当系统的业务复杂度较小、并发量不高时,使用单体架构较为划算。当业务复杂度较大、并发量较高时则使用微服务架构。