什么是微服务、微服务解决的问题是什么

1、微服务解决的问题

传统的单体应用按照业务边界划分为小型的、可以独立部署的服务单元，然后通过遵循轻量级的交互协议进行集成，成为这一理念下事实上的标准开发模式和最佳实践。

• 服务实例太多怎么办：当系统中存在大量独立服务时，如何有效识别和管理这些服务的实例？这将成为一大挑战！分布式系统，一定要能够实时对这些服务实例进行治理。— 服务治理

• 服务调用关系太杂乱怎么办：服务数量所衍生的另一个问题，是服务调用之间的关系会变得混乱，客户端与各个服务之间也会存在较高的耦合度，分布式系统需要提供简洁而明确的入口供客户端访问。— api网关

• 服务访问出错了怎么办：分布式环境下的调用，与单体系统中的方法级调用不同。服务间的跨进程调用可能出现各种意想不到的问题，这就需要在服务访问出错时进行合理的容错处理。— 服务容错

• 配置信息散落在各个服务中怎么办：一旦系统被拆分成多个独立服务，分布式系统就需要确保分散在每个服务中的配置信息，以及所有服务在开发、测试和生产等环境中的配置信息得到统一管理。— 配置中心

• 服务调用链路太长怎么办：服务远程调用的另一个问题是调用链路可能会很长，需要对整个调用链路进行监控和跟踪，从而高效发现服务调用过程中的异常场景和性能问题。— 链路跟踪
  

• 服务治理：为了有效管理分布式系统中存在的大量服务实例，微服务架构引入了服务发现和服务注册机制，使得服务实例的管理变得自动化、透明化。

  • Eureka、nacos等

• API 网关：为了降低服务客户端与服务提供者之间的耦合度，更好地简化调用过程，微服务架构专门提供了一个 API 网关，用来优化面向客户端的 API 设计。

  • OpenResty、Kong、Zuul2、SpringCloudGateway 等

• 服务容错：为了解决服务访问出错问题，微服务架构中提供了服务隔离、服务熔断和服务回退等面向服务调用端的有效容错机制。

  • Hystrix、Resilience4J、Sentinel等

• 配置中心：为了更好地组织和管理散落在各个服务中的配置信息，微服务架构提供了一个配置中心来集中化管理。

  • apollo、nacos等

• 链路跟踪：为了高效监控服务调用的健康状态以及全链路的数据流转，微服务架构提供了链路跟踪机制，来对各个服务之间的调用过程进行统一管理。

  • ZipKin Sleuth等

2、微服务架构特点

服务组件化、去中心化、基础设施自动化

3、架构模式

基础服务、通用服务、定制服务和其他服务

4、技术体系

服务通信、服务治理、服务路由、服务容错、服务网关、服务配置、服务安全和服务监控

4.1、服务通信

4.1.1、网络连接模式

当一台计算机想要与另一台计算机通讯时，两台计算机之间的通信需要畅通且可靠，这样才能保证正确收发数据。例如，当你想查看网页或查看电子邮件时，希望完整且按顺序查看网页，而不丢失任何内容。当你下载文件时，希望获得的是完整的文件，而不仅仅是文件的一部分，因为如果数据丢失或乱序，都不是你希望得到的结果，于是就用到了TCP。

TCP协议全称是传输控制协议是一种面向连接的、可靠的、基于字节流的传输层通信协议，由 IETF 的RFC 793定义。TCP 是面向连接的、可靠的流协议。流就是指不间断的数据结构，你可以把它想象成排水管中的水流。

TCP 协议的网络连接两种基本方式

长连接和短连接的产生在于客户端和服务器端采取的关闭策略，具体的应用场景采用具体的策略。

• 长连接：指在一个连接上可以连续发送多个数据包，在连接保持期间，如果没有数据包发送，需要双方发链路检测包。
  • 长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是短连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，下次处理时直接发送数据包就OK了，不用建立TCP连接。例如：数据库的连接用长连接，如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。
• 短连接：短连接是指通讯双方有数据交互时，就建立一个连接，数据发送完成后，则断开此连接，即每次连接只完成一项业务的发送。
  • 而像WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连好。

4.1.3、I/O 模型（服务之间通信）

可以简单理解为需要做一件事能不能立即得到返回应答，如果不能立即获得返回，需要等待，那就阻塞了(进程或线程就阻塞在那了，不能做其它事情)，否则就可以理解为非阻塞(在等待的过程中可以做其它事情)。

• 阻塞式 I/O：实现简单
• 非阻塞式 I/O：性能更好

以服务网关而言，像Netflix 的 Zuul就是阻塞式 I/O，而Spring Cloud Gateway则采用的是非阻塞式 I/O。

4.1.4、服务调用方式

同步调用、异步调用

• 通常都会采用异步转同步的实现机制，也就是说开发人员使用同步的方式进行方法调用，而框架本身会基于 Future 等机制实现异步的远程处理。

4.2、服务治理

如果系统中服务数量不是很多，那么我们有很多办法可以获取这些服务的 IP 地址、端口等信息，管理起来也不是很复杂。但当服务数量达到一定量级时，可能连开发人员自己都不知道系统中到底存在多少个服务，也不知道系统中当前到底哪些服务已经变得不可用。这时候，我们就需要引入独立的媒介来管理服务的实例，这个媒介一般被称为服务注册中心。Eureka、nacos等

4.3、服务路由

我们现在已经通过注册中心构建了一个多服务的集群化环境中，当客户端请求到达集群，如何确定由哪一台服务器进行请求响应呢？这就是服务路由问题。可以认为负载均衡是最常见的一种路由方案，常见的客户端/服务器端负载均衡技术都可以完成服务路由。

负载均衡的出发点更多的是提供服务分发而不是解决路由问题，常见的静态、动态负载均衡算法也无法实现精细化的路由管理。这时候我们就可以采用路由规则。路由规则常见的实现方案是白名单或黑名单，即把需要路由的服务地址信息（如服务 IP）放入可以控制是否可见的路由池中进行路由。同样，路由规则也是微服务开发框架的一项常见功能。----Netflix Zuul

4.4、服务容错

分布式环境中的服务而言，服务在自身失败引发生错误的同时，还会因为依赖其他服务而导致失败。除了比较容易想到和实现的超时、重试和异步解耦等手段之外，我们需要考虑针对各种场景的容错机制。----Spring Cloud Hystrix等

4.5、服务网关

服务网关也叫 API 网关，封装了系统内部架构，为每个客户端提供一个定制的 API。在微服务架构中，服务网关的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。

在功能设计上，服务网关在完成客户端与服务器端报文格式转换的同时，它可能还具有身份验证、监控、缓存、请求管理、静态响应处理等功能。另一方面，也可以在网关层制定灵活的路由策略。针对一些特定的 API，我们需要设置白名单、路由规则等各类限制

4.6、服务配置

微服务架构中，考虑到服务数量和配置信息的分散性，一般都需要引入配置中心的设计思想和相关工具。与注册中心一样，配置中心也是微服务架构中的基础组件，其目的也是对服务进行统一管理，区别在于配置中心管理的对象是配置信息而不是服务的实例信息。----Spring Cloud Config、Zookeeper 、apollo、nacos等

4.7、服务安全

在对微服务架构的学习过程中，服务安全是一块非常重要但又容易被忽视的内容。一般意义上的访问安全性，都是围绕认证和授权这两个核心概念来展开的。也就是说我们首先需要确定用户身份，然后再确定这个用户是否有访问指定资源的权限。站在单个微服务的角度讲，我们系统每次服务访问都能与授权服务器进行集成以便获取访问 Token。站在多个服务交互的角度讲，我们需要确保 Token 在各个微服务之间的有效传播。另一方面，服务内部，我们可以使用不同的访问策略限制服务资源的访问。

在实现微服务安全访问上，我们通常使用 OAuth2 协议来实现对服务访问的授权机制，使用 JWT 技术来构建轻量级的认证体系。Spring 家族也提供了 Spring Security 和 Spring Cloud Security 框架来完整这些组件的构建。

4.8、服务监控

在微服务架构中，当服务数量达到一定量级时，我们难免会遇到两个核心问题。一个是如何管理服务之间的调用关系？另一个是如何跟踪业务流的处理过程和结果？这就需要构建分布式服务跟踪机制。

分布式服务跟踪机制的建立需要完成调用链数据的生成、采集、存储及查询，同时也需要对这些调用链数据进行运算和可视化管理。这些工作不是简单一个工具和框架能全部完成，因此，在开发微服务系统时，我们通常会整合多个开发框架进行链路跟踪。例如，在 Spring Cloud 中，就提供了 Spring Cloud Sleuth 与 Zipkin 的集成方案。