一、微服务是什么
微服务是一种架构风格，即，一个应用应该是一组小型服务，每个服务器只负责一种服务，服务之间可以通过 HTTP 的方式进行互通。每一个功能元素最终都是一个可独立替换和独立升级的软件单元。
可以说，微服务具有以下特征：
-
根据业务模块划分服务种类。
-
每个服务可以独立部署并且互相隔离。
-
通过轻量的 API 调用服务。
-
服务需要保证良好的高可用性。
二、单体应用
与微服务相对的是单体应用风格，即现在常用的开发风格，一个应用中包含所有服务。
优点
-
调试方便
-
运维简单
缺点
-
软件变更受到了很大的限制，应用系统的一个很小的部分的一处变更，也需要将整个单块应用系统进行重新构建和部署。
-
当对系统进行扩展时，不得不扩展整个应用系统，而不能仅扩展该系统中需要更多资源的那些部分。
三、微服务架构要解决的问题
微服务架构要达到三大要求
-
高可用
-
高并发
-
高性能
要达到这三大要求，就需要解决以下这四个问题：
1.客户端如何访问这么多的服务？
使用 API 网关对服务进行聚合，客户端通过访问 API 网关来获取相应的服务
2.服务之间如何通信
服务之间的通信有两种解决方案：
同步通信
HTTP：Apache HTTP Client
RPC：Dubbo、gRPC
异步通信
消息队列：kafka、Rabbit MQ、Rocket MQ
3.多个服务要怎样管理（治理）
注册中心：zk，eureka，consul，etcd，nacos
4.服务提供者宕机要如何应对
-
重试机制
-
服务熔断
-
服务降级
-
服务限流
四、总结
微服务架构需要的功能或使用场景：
-
我们把整个系统根据业务拆分成几个子系统。
-
每个子系统可以部署多个应用，多个应用之间使用负载均衡。
-
需要一个服务注册中心，所有的服务都在注册中心注册，负载均衡也是通过在注册中心注册的服务来使用一定策略来实现。
-
所有的客户端都通过同一个网关地址访问后台的服务，通过路由配置，网关来判断一个 URL 请求由哪个服务处理。请求转发到服务上的时候也使用负载均衡。
-
服务之间有时候也需要相互访问。例如有一个用户模块，其他服务在处理一些业务的时候，要获取用户服务的用户数据。
-
需要一个断路器，及时处理服务调用时的超时和错误，防止由于其中一个服务的问题而导致整体系统的瘫痪。
-
还需要一个监控功能，监控每个服务调用花费的时间等，推荐Prometheus。
-
还需要统一日志收集，推荐ELK。