微服务概念
什么是微服务
“微服务”一词来源于 Martin Fowler 的《Microservices》一文。微服务是一种架构风格,即将单体应用划分为小型的服务单元,微服务之间使用 HTTP 的 API (RESTFUL风格)进行资源访问与操作。如下图
-
左:all in one,单体架构下,应用紧耦合,所有的变更必须一起上线
-
中:传统SOA架构允许单独的变更,但是每一个部分必须很谨慎地修改以免破坏整体架构设计。
-
右:在微服务架构下,开发可以独立地创建、维护和改进服务。服务之间通过RESTFUL API连接。
下面来看看一个比较简单的微服务结构图:
在这里插入图片描述
从这幅图可以看出,每一个微服务单体应用(Microservice)都有自己一个单独的数据库进行连接(分库),这是要保证事物的一致性和避免脏数据以及减小响应的速度就非常有必要。以及如何保证每个服务之间的安全和持续通信,以及模块关联模块时,如何解决一整条模块链不会因为一个模块的宕机而引起服务雪崩。
微服务优点
整体架构一分再分,降低了每个模块的耦合性,每个服务单独进行专门的维护和开发,使分工更加明确,职责更加专一
-
服务的独立部署
- 每个服务都是一个独立的项目,可以独立部署,不依赖于其他服务,耦合性低。
-
服务的快速启动
- 拆分之后服务启动的速度必然要比拆分之前快很多,因为依赖的库少了,代码量也少了。
-
更加适合敏捷开发
- 敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行。服务拆分可以快速发布新版本,修改哪个服务只需要发布对应的服务即可,不用整体重新发布。
-
职责专一,由专门的团队负责专门的服务
- 业务发展迅速时,研发人员也会越来越多,每个团队可以负责对应的业务线,服务的拆分有利于团队之间的分工。
-
服务可以动态按需扩容
- 当某个服务的访问量较大时,我们只需要将这个服务扩容即可。
-
代码的复用