1.2 什么是微服务

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

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

1.2.1 使用微服务架构的优势和劣势

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

1．优势

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

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

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

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

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

❑ 服务可以动态按需扩容：当某个服务的访问量较大时，我们只需要将这个服务扩容即可。

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

2．劣势

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

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

❑ 独立的数据库，分布式事务的挑战：每个微服务都有自己的数据库，这就是所谓的去中心化的数据管理。这种模式的优点在于不同的服务，可以选择适合自身业务的数据，比如订单服务可以用MySQL、评论服务可以用Mongodb、商品搜索服务可以用Elasticsearch。缺点就是事务的问题了，目前最理想的解决方案就是柔性事务中的最终一致性，后面的章节会给大家做具体介绍。

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

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

1.2.2 重构前的准备工作

对于上不上微服务，关键在于公司的发展程度。系统是否真的到了必须做分解的地步？在上微服务之前一定要做好技术选型。用什么框架来构建微服务？公司是否支持重构？这些问题都很重要，没有公司的支持一切都是空谈。你要告诉你的上级为什么要重构，为什么要上微服务，上了之后能解决哪些问题，比如能否提高系统稳定性、能否节约机器资源等。有了明确的目标及计划，我相信这件事必成。

在重构之前，架构师一定要对公司所有的产品做一遍梳理，出一个重构方案，画一个架构图。还要对团队成员进行一次培训，讲讲重构的过程中会遇到哪些技术问题，可采用什么方式解决，在这个过程中大家能学到什么。我相信，对于有成长、有意义的事情，就算加班，大家也会开心的。这些你都不准备好，别人会觉得你没事找事，天天让他加班。

重构时最好采用循序渐进的模式，首先对一个产品进行重构规划，抽出业务服务，再抽出这个产品所依赖的基础服务，基础服务是最为重要的。等一个产品稳定之后，再重构其他产品，把核心业务放到最后面。不要想着一步登天，重构就像堆积木，堆着堆着就高了，一周抽一个微服务，慢慢就都变成微服务了。