1.微服务

一、微服务是什么

微服务是一种架构风格，即，一个应用应该是一组小型服务，每个服务器只负责一种服务，服务之间可以通过 HTTP 的方式进行互通。每一个功能元素最终都是一个可独立替换和独立升级的软件单元。

可以说，微服务具有以下特征：

• 根据业务模块划分服务种类。

• 每个服务可以独立部署并且互相隔离。

• 通过轻量的 API 调用服务。

• 服务需要保证良好的高可用性。

二、单体应用

与微服务相对的是单体应用风格，即现在常用的开发风格，一个应用中包含所有服务。

优点

1. 调试方便

2. 运维简单

缺点

1. 软件变更受到了很大的限制，应用系统的一个很小的部分的一处变更，也需要将整个单块应用系统进行重新构建和部署。

2. 当对系统进行扩展时，不得不扩展整个应用系统，而不能仅扩展该系统中需要更多资源的那些部分。

三、微服务架构要解决的问题

微服务架构要达到三大要求

• 高可用

• 高并发

• 高性能

要达到这三大要求，就需要解决以下这四个问题：

1.客户端如何访问这么多的服务？

使用 API 网关对服务进行聚合，客户端通过访问 API 网关来获取相应的服务

2.服务之间如何通信

服务之间的通信有两种解决方案：

同步通信

1. HTTP：Apache HTTP Client

2. RPC：Dubbo、gRPC

异步通信

消息队列：kafka、Rabbit MQ、Rocket MQ

3.多个服务要怎样管理（治理）

注册中心：zk，eureka，consul，etcd，nacos

4.服务提供者宕机要如何应对

• 重试机制

• 服务熔断

• 服务降级

• 服务限流

四、总结

微服务架构需要的功能或使用场景：

1. 我们把整个系统根据业务拆分成几个子系统。

2. 每个子系统可以部署多个应用，多个应用之间使用负载均衡。

3. 需要一个服务注册中心，所有的服务都在注册中心注册，负载均衡也是通过在注册中心注册的服务来使用一定策略来实现。

4. 所有的客户端都通过同一个网关地址访问后台的服务，通过路由配置，网关来判断一个 URL 请求由哪个服务处理。请求转发到服务上的时候也使用负载均衡。

5. 服务之间有时候也需要相互访问。例如有一个用户模块，其他服务在处理一些业务的时候，要获取用户服务的用户数据。

6. 需要一个断路器，及时处理服务调用时的超时和错误，防止由于其中一个服务的问题而导致整体系统的瘫痪。

7. 还需要一个监控功能，监控每个服务调用花费的时间等，推荐Prometheus。

8. 还需要统一日志收集，推荐ELK。