“微服务”一词来源于 Martin Fowler 的《Microservices》一文。微服务是一种架构风格,即将单体应用划分为小型的服务单元,微服务之间使用 HTTP 的 API 进行资源访问与操作。

在笔者看来,微服务架构的演变更像是一个公司的发展过程,从最开始的小公司,到后来的大集团。大集团可拆分出多个子公司,每个子公司的都有自己独立的业务、员工,各自发展,互不影响,合起来则是威力无穷。

臃肿的系统、重复的代码、超长的启动时间带给开发人员的只有无限的埋怨,丝毫没有那种很舒服的、很流畅的写代码的感觉。他们把大部分时间都花在解决问题和项目启动上面了。

微服务架构的优势

使用微服务架构能够为我们带来如下好处:

1)服务的独立部署

每个服务都是一个独立的项目,可以独立部署,不依赖于其他服务,耦合性低。

2)服务的快速启动

拆分之后服务启动的速度必然要比拆分之前快很多,因为依赖的库少了,代码量也少了。

3)更加适合敏捷开发

敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行。服务拆分可以快速发布新版本,修改哪个服务只需要发布对应的服务即可,不用整体重新发布。

4)职责专一,由专门的团队负责专门的服务

业务发展迅速时,研发人员也会越来越多,每个团队可以负责对应的业务线,服务的拆分有利于团队之间的分工。

5)服务可以按需动态扩容

当某个服务的访问量较大时,我们只需要将这个服务扩容即可。

6)代码的复用

每个服务都提供 REST API,所有的基础服务都必须抽出来,很多的底层实现都可以以接口方式提供。

微服务架构的劣势

微服务其实是一把双刃剑,有利有弊。下面我们来谈谈微服务有哪些弊端,以及能采取什么办法避免。

1)分布式部署,调用的复杂性高

单体应用的时候,所有模块之前的调用都是在本地进行的,在微服务中,每个模块都是独立部署的,通过 HTTP 来进行通信,这当中会产生很多问题,比如网络问题、容错问题、调用关系等。

2)独立的数据库,分布式事务的挑战

每个微服务都有自己的数据库,这就是所谓的去中心化的数据管理。这种模式的优点在于不同的服务,可以选择适合自身业务的数据,比如订单服务可以用 MySQL、评论服务可以用 MongoDB、商品搜索服务可以用 ElasticSearch。

缺点就是事务的问题了,目前最理想的解决方案就是柔性事务中的最终一致性,后面的章节会给大家做具体介绍。

3)测试的难度提升

服务和服务之间通过接口来交互,当接口有改变的时候,对所有的调用方都是有影响的,这时自动化测试就显得非常重要了,如果要靠人工一个个接口去测试,那工作量就太大了。这里要强调一点,就是 API 文档的管理尤为重要。

4)运维难度的提升

在采用传统的单体应用时,我们可能只需要关注一个 Tomcat 的集群、一个 MySQL 的集群就可以了,但这在微服务架构下是行不通的。当业务增加时,服务也将越来越多,服务的部署、监控将变得非常复杂,这个时候对于运维的要求就高了。

参考

微服务的概念和优缺点

评论