单体架构
单体架构是早期的架构模式。单体架构将所有业务场景的表示层,业务逻辑层和数据访问层放在同一个工程中,最终经过编译,打包,并部署在服务器上。
比如,经典的 J2EE 工程,它就是将表示层的 JSP、业务逻辑层的 Service、Controller 和数据访问层的 DAO(Data Access Objects),打包成 war 文件,然后部署在 Tomcat、Jetty 或者其他 Servlet 容器中运行。
互联网产品的普及,承载流量越来越大,单体架构缺点:
灵活性差: 无论多小的改动,都要打包整个应用
可扩展性差: 高并发场景下,无法一模块为单位扩容
稳定性差: 任何一个模块有问题,都可能整个应用不可用
可维护性差: 业务复杂性提升,项目整体维护性差
微服务架构诞生
基于单体架构的局限性,微服务架构诞生。
一个复杂的系统由一系列独立的微服务组成,各个微服务运行在自己独立的容器中,开发和部署都没有依赖。
微服务架构特点:
- 每个服务运行在其独立的进程中,开发采用的技术栈也是独立的;
- 服务间采用轻量级通信机制进行沟通,通常是基于 HTTP 协议的 RESTful API;
- 每个服务都围绕着具体的业务进行构建,并且能够被独立开发、独立部署、独立发布;
- 对运维提出了非常高的要求,促进了 CI/CD 的发展与落地。
微服务架构实践
客户端如何访问这些服务
每个服务之间如何通信
如此多的服务如何实现
服务挂了,如何解决
客户端如何访问这些服务
一般在后台N个服务和UI之间一般会一个代理或者叫API 网关,其作用有下:
①提供统一服务入口,让微服务对前台透明
② 聚合后台的服务,节省流量,提升性能
③ 提供安全,过滤,流控等API管理功能
gateway为前台(通常是移动应用)提供后台服务的聚合,提供一个统一的服务出口,解除他们之间的耦合,不过API Gateway也有可能成为单点故障点或者性能的瓶颈。
微服务架构需要考虑:
1、API Gateway
2、服务间调用
3、服务发现
4、服务容错
5、服务部署
6、数据调用
如图:
每个服务之间如何通信
同步调用:
①REST(JAX-RS,Spring Boot)
②RPC(Thrift, Dubbo)
一般同步调用比较简单,一致性强,但是容易出调用问题,性能体验上也会差些,特别是调用层次多的时候
异步消息调用(Kafka, Notify, MetaQ)
而异步消息的方式在分布式系统中有特别广泛的应用,他既能减低调用服务之间的耦合,又能成为调用之间的缓冲,确保消息积压不会冲垮被调用方,同时能保证调用方的
服务体验,继续干自己该干的活,不至于被后台性能拖慢。不过需要付出的代价是一致性的减弱,需要接受数据最终一致性;还有就是后台服务一般要 实现幂等性,因为消息
发送出于性能的考虑一般会有重复(保证消息的被收到且仅收到一次对性能是很大的考验)
服务挂了,如何解决
①重试机制
②限流
③熔断机制
④负载均衡
⑤降级(本地缓存)