1.什么是微服务
微服务其实就是一种架构风格，他提倡我们在开发的时候，一个应用应该是一组小型服务而组成的，每一个服务都运行在自己的进程中，每一个小服务都通过HTTP的方式进行互通。他更加强调服务的彻底拆分。他并不是仅局限于用java来实现，可以由不同的编程用语言进行实现，当然也可以用不同的数据库。
它的优点显而易见，
1.服务原子化拆分，独立打包，部署和升级，保证每个微服务清晰的任务划分，利于扩展。
2.微服务之间采用Restful架构风格规范接口设计，基于HTTP协议进行相互调用，发挥HTTP协议在网络传输中的轻量优势。
下面补充一下什么叫做Restful架构风格
它是基于http协议，核心概念围绕资源，表现层，状态转移。
其中资源用url标识，这里的资源就是网上一切可被操作的事务，如一篇文章，一个用户信息都可被抽象为资源。
表现层就是资源可具有多种表现形式，如xml，json等。
状态转移就是客户端借助HTTP协议的标准方法(GET,POST,PUT,DELETE等)对服务端资源进行操作，实现资源状态改变。像GET获取资源状态，POST创建新资源改变状态等。
2.微服务架构遇到的问题
一旦采用微服务系统架构，就势必会遇到这样几个问题：
1.这么多小服务，如何管理它们？（服务治理 注册中心[服务注册 发现 剔除]）
2.这么多小服务，它们之间如何通讯？（restful rpc）
3.这么多小服务，客户端怎么访问他们？（网关）
4.这么多小服务，一旦出现问题了，应该如何自处理？（容错）
5.这么多小服务，一旦出现问题了，应该如何排错？（链路追踪）
所以后面对于微服务的学习，大部分就是学习各个组件来解决各种问题。
3.微服务架构的常见概念
3.1服务治理
服务治理就是进行服务的自动化管理，其核心是服务的自动注册于发现。
服务注册：服务实例将自身服务信息注册到注册中心
服务发现：服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求他们提供的服务。
服务剔除：服务注册中心将出问题的服务自动剔除到可用列表之外，使其不会被调用到
3.2服务调用
在微服务架构中，通常存在多个服务之间的远程调用的需求。目前主流的远程调用技术有基于HTTP的 RESTfu接口以及基于TCP的RPC协议。
RPC是 一种进程间通信方式。允许像调用本地服务一样调用远程服务。RPC框架的主要目标就是让远程服务调 用更简单、透明。RPC框架负责屏蔽底层的传输方式、序列化方式和通信细节。开发人员在使用的时候 只需要了解谁在什么位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程。
Restful前面讲了，这里就不重复了。
3.3服务网关
随着微服务的不断增多，不同的微服务一般会有不同的网络地址，而外部客户端可能需要调用多个服务的 接口才能完成一个业务需求，如果让客户端直接与各个微服务通信可能出现：
1.客户端需要调用不同的ur地址，增加难度
2.在一定的场景下，存在跨域请求的问题
3.每个微服务都需要进行单独的身份认证
针对这些问题，API网关顺势而生。
API网关字面意思是将所有API调用统一接入到API网关层，由网关层统一接入和输出。一个网关的 基本 功能有：统一接入、安全防护、协议适配、流量管控、长短链接支持、容错能力。有了网关之后，各个 API服务提供团队可以专注于自己的的业务逻辑处理，而API网关更专注于安全、流量、路由等问题
3.4服务容错
在微服务当中，一个请求经常会涉及到调用几个服务，如果其中某个服务不可用，没有做服务容错的话， 极有可能会造成一连串的服务不可用，这就是雪崩效应。我们没法预防雪崩效应的发生，只能尽可能去做 好容错。服务容错的三个核心思想是：
1.不被外界环境影响
2.不被上游请求压垮
3.不被下游响应拖垮
