一、微服务是什么
微服务是一种架构风格,即,一个应用应该是一组小型服务,每个服务器只负责一种服务,服务之间可以通过 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。