从0开始学习微服务（一）

话不多说，首先介绍微服务的相关概念

所谓微服务就是将单体应用的本地调用改变为通过HTTP或者RPC远程调用的多应用

相比于传统单体应用的优缺点

单体应用缺点：

不同模块直接逻辑耦合性高

任何一个模块代码有改动时即使是不相关的模块也要重新打包部署

部署代码时候要时刻更改依赖版本，容易出错

部署时间久

任何一块代码逻辑错误可能导致整个系统崩溃

一些并发量高的模块和一些并发量低的模块部署在一起容易导致服务器压力过大系统效率低下，吞吐量变低

不同的功能模块分属不同的项目，可以部署在各个地方，扩展性好

模块之间耦合性低，模块之间的互相调用通过HTTP或者RPC的方式进行，可以引入消息队列等中间件，当一个模块出问题时不会影响其他模块
对于一些并发量高的模块可以单独部署，通过增加机器，集群部署来提高系统吞吐量，同时不会给别的服务器带来访问压力

实现一个微服务需要的相关组件

整体来看所谓微服务就是将逻辑上功能比较分离的模块拆分成一个单独的项目，比如淘宝的个人中心，当在其他模块，比如购物车模块，需要使用用户信息的时候就可以远程调用个人中心提供的相应服务，也就是接口，来获取个人信息，这个过程有几个关键的点

1.个人信息服务的描述

试想一下，在一个模块想要远程调用另一个模块提供的服务，首先要明白这个服务即接口需要哪些参数，会返回哪些信息，这些内容就是服务的描述

常用的服务描述比如进行restful api开发的时候可以使用swagger进行服务描述，可以表明该接口需要哪几种参数分别是什么类型等

2.个人信息的注册

当一个服务写完之后必须让别人知道怎么调用到改服务，这时候就需要注册，往往需要一个注册中心，常见的spring cloud,dubbo,wso2等开源框架都提供了注册中心，在注册中心注册完毕的服务可以暴露给其他模块调用

3.服务之间的调用方式

购物车模块现在明白了个人中心模块需要什么参数，也知道在哪里调用这个模块，下一个问题就是调用的方式了，是通过http掉还是Rpc调用

4.数据传输方式

模块之间的传输方式也必须事先规定，是json还是xml等

5.服务监控

在经过以上步骤后，两个服务直接可以正常调用了，此时我们需要对服务进行监控，记录不同接口的调用情况和成功率，这些信息可以帮助我们分析服务，比如某个服务的调用频率比较大，可以适当的进行集群部署并进行负载均衡，spring cloud等框架也提供了服务的检测，同时会将检测信息在dashboard上进行展示，比较直观

6.服务追踪

当购物者模块调用个人中心模块的服务时，会在本地生成一个requestID,当进行调用时会将requestId作为参数传递，个人中心在得到requestID后悔进行处理， 此时当调用出问题时，我们可以利用requestID进行追踪，从而快速定位问题

7.服务治理

不管是服务检查还是服务追踪最终的目的都是对服务进行治理，这也是微服务对比于单体应用的优点之一，比如服务直接调用出现问题时，比如网络不通，微服务框架可以重试，当重试也不能修复时会直接返回，不会一直卡在调用这一步而导致整个应用崩溃，比如spring cloud就提供了熔断机制，这也是服务治理的一个方面