什么是微服务?

详解:

微服务分为单体应用和集群

单体应用:
单体应用的优点
开发简单: 方便开发
便于共享: 单个归档文件中包含所有的功能,便于在团队之间以及不同的部署环境阶段进行共享.
易于测试: 测试便捷, 部署方便

单体应用的缺点:
复杂性高: 所有功能都在一个应用中, 耦合度比较高
技术债务: 单体应用所用的技术都特别单一. 所以市场上的一些中间件,新技术无法应用到单体应用上

面向接口编程

SOA多业务架构

面向服务架构
它一种设计方法, 服务之间通过相互依赖最终异同一系列的功能,一个服务通常以独立的形式存在.

微服务架构

微服务的特点:
面向服务
松耦合
模块化
分布式计算
平台无关
集中管理

微服务的优点:
开发简单
技术栈灵活
各服务之间没有任何依赖关系
独立性强,可以按需拓展
可用性比较高

微服务的缺点:
维护成本高
运维难度大
复杂
数据一致性差
重复工作
性能监控不及时
通信复杂

我们什么时候需要使用微服务??

1.开发效率非常快的情况下需要:
应用进行微服务化后,规模和体积将边的非常轻量, 在编译,打包,分发,部署等环境都节约了大量的时间,开发效率明显提升

  1. 保证质量时需要:
    微服务应用面向持续集成,友好度比较高, 自动化编译,单元和集成测试用例的执行和回归,提高应用的整理质量时需要用到微服务

  2. 稳定的时候需要
    单体应用是牵一发动全身,微服务,牵一发,动一动 ,在微服务中,单一功能挂掉之后,不影响其他功能

我们什么时候不需要使用微服务
1.场景单一
应用只有几个特定的功能, 没有必要进行微服务独立开发时

  1. 逻辑简单

当单体应用的一个功能挂掉后,这个单体应用就无法使用了 ( 修改代码后重新部署 )

当微服务的一个功能挂掉后,这个功能牵连的功能无法使用外,其他的功能影响正常功能(正常生产) ( 服务检测, 重试机制,限流,熔断机制,(客户端)负载均衡, 降级)

springcloud的生态图谱

绿色部分为常用组件
Eureka:
服务注册与发现,各个服务启动时,Eureka Client都会将服务注册到Eureka
Server,并且Eureka Client还可以反过来从Eureka Server拉取注册表,从而知道
其他服务在哪里

Ribbon:
服务请求调用客户端负载均衡,服务间发起请求的时候,基于Ribbon做负载均衡,
从一个服务的多台机器中选择一台

Feign:
服务请求调用,基于Feign的动态代理机制,根据注解和选择的机器,拼接请求URL
地址,发起请求

Hystrix:
熔断器,发起请求是通过Hystrix的线程池来走的,不同的服务走不同的线程池,实
现了不同服务调用的隔离,避免了服务雪崩的问题

Zuul:
api路由网关,如果前端、移动端要调用后端系统,统一从Zuul网关进入,由Zuul网
关转发请求给对应的服务

gateWay:
zuul替代品

你可能感兴趣的:(后端,微服务架构,微服务,spring,cloud)