什么是微服务架构

一、微服务简介

微服务（Microservice）这个概念是2012年出现的，作为加快Web和移动应用程序开发进程的一种方法，2014年开始受到各方的关注，而2015年，可以说是微服务的元年。

微服务架构是将一个应用程序拆分成一组小型服务的方法，每个服务是独立的进程或者项目，服务间通信采用轻量级通信机制（通常用HTTP资源API）。

微服务项目由若干服务模块组成，然后由一些中间件来管理这些微服务。

二、微服务的优势

很多第一次接触微服务架构的同学很不理解，为什么要把一个完整的项目化整为零，而且还拆分的这么零碎。咱们就先来看看传统单体项目存在的问题。

例如一个单体项目包含了这么多业务模块，即便修改一个BUG，也要重新编译项目然后打包发布，非常麻烦。我们再往大了想，京东这种规模的电商项目，上千个业务模块，如果采用了单体项目架构，那么打包出来的项目在普通硬件服务器上根本运行不起来。这时候要是修改一处BUG，项目编译还不得耗时大半天时间啊。所以越是大项目，就越应该拆分，维护起来更方便。
在微服务架构中，服务之间通过网络调用，所以代码层面基本是解耦的。A服务可以用Java开发，B服务可以用Python实现，这是允许的。

也许有的同学想问，为什么本课程微服务之间用Feign调用（HTTP协议），而不用Dubbo呢？这个吧，还是从全局上考虑，HTTP协议的通用性更好，如果用了Dubbo，那么所有的服务就都得用Java实现了。作为一个大项目，混合多种语言开发是很常见的，没必要把项目绑定到Java一种语言上面。

三、微服务和RPC有什么区别？

严格来说微服务属于RPC的一种，但是广义上的RPC指的是项目之间的调用。例如校园网系统中的各个系统就是用RPC调用的，所以RPC指的是项目之间的调用。RPC是把单体项目做了粗颗粒度的拆分，而微服务把单体项目拆分的更零碎。

因为RPC是独立系统之间的调用，所以不太注重事务的一致性。毕竟独立系统各自使用的数据库也不同，没办法组成全局的分布式事务。而微服务更注重分布式事务，微服务原本是一个系统，拆分出来的各个模块，所以模块之间应该有分布式事务。比如支付模块和代金券模块就应该被纳入到全局事物中，否则我们支付失败，但是代金券使用成功了。按理说应该一起回滚，对吧。

四、使用什么版本SpringCloud？

因为SpringCloud架构的很多中间件产品都停止维护了，所以现在开发微服务项目，SpringCloud并不是最佳选择。所以本课程的项目使用了Alibaba SpringCloud架构。而且现在国内有很多公司要求项目必须采用Alibaba SpringCloud架构，因为这些创业公司的老板等着盼着，希望阿里来收购自己。为了实现这个目标，技术栈就得跟阿里对接。

五、服务之间的调用

1. 注册微服务

微服务之间能相互调用，首先需要相互发现，所以我们必须把微服务注册到Nacos上面。这样服务A想调用服务B，就可以从Nacos上面拿到服务B的IP地址和端口号了。

即便某个服务B宕机了，也没有问题，因为心跳检测机制，Nacos很快就发现了宕机。所以服务A再调用服务B的时候，Nacos会从现有可用的服务B里面挑出一个给服务A。于是服务A和服务B之间调用，并不会因为一个服务B宕机而失败。

2. 远程调用微服务

在Alibaba SpringCloud架构中，服务之间调用可以采用Feign技术。Feign是Netflix开发的声明式、模板化的HTTP客户端， 它可以帮助我们快捷优雅地调用HTTP API接口。

比如说A服务想要调用B服务，需要我们在B服务中正常声明Controller中的Web方法。然后在A项目中定义Feign接口，然后业务层调用这个Feign接口就可以实现对B服务的Web方法调用，而且代码上写几个注解就可以了，挺简单的。