1. 微服务介绍

微服务简介

1. 微服务

**微服务 （MircroService）的概念最早是在 2014 年由 Martin Fowler 和 James Lewis 共同提出，他们定义了微服务是由单一应用程序构成的小服务，拥有自己的进程与轻量化处理，服务依业务功能设计（微服务一个业务一个项目），以全自动方式部署，与其他服务使用 HTTP API 通讯（每个项目都是一个标准的web项目，不在像之前RPC项目分为provider和consumer）。同时，服务会使用最小规模的集中管理 （例如 Docker）技术，服务可以用不同的编程语言与数据库等。**
**微服务以业务为单位，每个业务可以形成一个独立项目**

微服务是架构。核心就是按照业务拆分成独立项目。如果业务之前需要通信使用任何http协议工具（HttpClient/RestTemplate）。

2. 微服务特点

微服务以业务为单位，每个业务可以形成一个独立项目
微服务架构的特点：针对特定服务发布，影响小，风险小，成本低；频繁发布版本，快速交付需求；低成本扩容，弹性伸缩，适应云环境。
我们知道一个朴素的理念，没有任何事物是完美的，任何东西都有两面性，有得必有失，那么在选择微服务在解决了快速响应和弹性伸缩的问题同时，它又给我们带来了什么问题？简单总结如下：

分布式系统的复杂性

• 部署，测试和监控的成本问题

• 分布式事务和CAP的相关问题

  分布式中微服务架构相对于单体架构还需要处理很多事情。例如：分布式事务、团队合作等问题都需要明确的提前设计好。

什么样的服务才算微服务呢？

• 单一职责的。一个微服务应该都是单一职责的，这才是“微”的体现，一个微服务解决一个业务问题（注意是一个业务问题而不是一个接口）。
• 面向服务的。将自己的业务能力封装并对外提供服务，这是继承SOA的核心思想，一个微服务本身也可能使用到其它微服务的能力。

我觉得满足以上两点就可以认为典型的微服务。

3. 微服务典型架构

微服务架构，核心是为了解决应用微服务化之后的服务治理问题。
**应用微服务化之后，首先遇到的第一个问题就是服务发现问题，一个微服务如何发现其他微服务呢？最简单的方式就是每个微服务里面配置其他微服务的地址，但是当微服务数量众多的时候，这样做明显不现实。所以需要使用到微服务架构中的一个最重要的组件：服务注册中心，所有服务都注册到服务注册中心，同时也可以从服务注册中心获取当前可用的服务清单：**

服务注册中心

**解决服务发现问题后，接着需要解决微服务分布式部署带来的第二个问题：服务配置管理的问题。当服务数量超过一定程度之后，如果需要在每个服务里面分别维护每一个服务的配置文件，运维人员估计要哭了。那么，就需要用到微服务架构里面第二个重要的组件：配置中心，微服务架构就变成下面这样了：**

配置中心

以上应用内部的服务治理，当客户端或外部应用调用服务的时候怎么处理呢？服务A可能有多个节点，服务A、服务B和服务C的服务地址都不同，服务授权验证在哪里做？这时，就需要使用到服务网关提供统一的服务入口，最终形成典型微服务架构：

典型微服务架构

上面是一个典型的微服务架构，当然微服务的服务治理还涉及很多内容，比如：

• 通过熔断、限流等机制保证高可用；
• 微服务之间调用的负载均衡；
• 分布式事务（2PC、3PC、TCC、LCN等）；
• 服务调用链跟踪等等。

4. 微服务框架