一、单体架构和微服务
1、单体架构
将所有功能模块使用同一个数据库,同时,它还提供API或者UI访问的Web模块等,最终会打包并部署为单体式应用,这种将所有功能都部署在一个Web容器中运行的系统叫做单体架构
优点 | |
1 | 开发效率高 |
2 | 容易测试 |
3 | 容易部署 |
缺点 | |
1 | 复杂性逐渐变高,可维护性巨剑变差 |
2 | 版本跌倒速度逐渐变慢 |
3 | 阻碍技术创新 |
4 | 无法按需伸缩 |
2、微服务
每一个业务模块都使用独立的服务完成,这种微服务架构模式也影响了应用和数据库之间的关系,不像传统多个业务模块共享一个数据库,微服务架构每个服务都有自己的数据库。
好处 | |
1 | 分而治之,职责单一;易于开发、理解和维护、方便团队的拆分和管理; |
2 | 可伸缩;能够单独的对指定的服务进行伸缩; |
3 | 局部所以修改,容易替换,容易部署,有利于持续集成和快速迭代 |
4 | 不会受限于任何技术栈 |
二、服务发现
在微服务中,各服务之间协作来实现业务目标。微服务中也需要进行服务间的远程调用,那么就需要知道服务的网络位置【IP和端口号】,那么就要实现以下内容。
①、在每个服务启动时需要向服务发现中心上报自己的网络位置。
②、服务发现客户端会定期从服务发现中心同步服务注册表,并缓存在客户端
③、当需要对某服务进行请求时,服务实例通过该注册表,定位目标服务网络地址。若目标服务存在多个网络地址,则使用负载均衡算法从多个服务实例中选择出一个,然后发出请求。
总结:微服务中,由于服务运行实例的网络地址是不断变化的,服务实例数量的动态变化,因此无法使用固定的配置文件来记录提供方的网络地址,必须使用动态的服务发现机制用于实现微服务之间的相互感知。各服务实例会上报自己的网络地址,这样服务中心就形成了一个完整的服务注册表,各服务实例会通过服务发现中心来获取访问目标服务的网络地址,从而实现服务发现的机制。
三、主流服务发现与配置中心对比
对比项目 | Nacos | Eureka | Consul | Zookeeper |
一致性协议 | 支持AP和CP模型 | AP模型 | CP模型 | CP模型 |
健康检查 | TCP/HTTP/MYSQL/Client Beat | Client Beat | TCP/HTTP/gRPC/Cmd | Keep Alive |
负载均衡策略 | 权重/metadata/Selector | Ribbon | Fabil | - |
雪崩保护 | 有 | 有 | 无 | 无 |
自动注销实例 | 支持 | 支持 | 不支持 | 支持 |
访问协议 | HTTP/DNS | HTTP | HTTP/DNS | TCP |
监听支持 | 支持 | 支持 | 支持 | 支持 |
多数据中心 | 支持 | 支持 | 支持 | 不支持 |
跨注册中心同步 | 支持 | 不支持 | 支持 | 不支持 |
SpringCloud集成 | 支持 | 支持 | 支持 | 不支持 |
Dubbo集成 | 支持 | 不支持 | 不支持 | 支持 |
k8s集成 | 支持 | 不支持 | 支持 | 不支持 |
四、Spring Cloud服务协作流程