springcloud-微服务架构

springcloud

单体应用

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

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

SOA多业务架构

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

微服务架构

微服务的特点

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

微服务的优点

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

微服务的缺点

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

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

1.开发效率非常快的情况下需要:
    应用进行微服务化后,规模和体积将边的非常轻量, 在编译,打包,分发,部署等环境都节约了大量的时间,开发效率明显提升
    
2. 保证质量时需要:
    微服务应用面向持续集成,友好度比较高, 自动化编译,单元和集成测试用例的执行和回归,提高应用的整理质量时需要用到微服务
    
3. 稳定的时候需要
    单体应用是牵一发动全身,微服务,牵一发,动一动 ,在微服务中,单一功能挂掉之后,不影响其他功能

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

1.场景单一
    应用只有几个特定的功能, 没有必要进行微服务独立开发时

2. 逻辑简单
    ...

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

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

springcloud的生态图谱

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

Ribbon:
    服务请求调用客户端负载均衡，服务间发起请求的时候，基于Ribbon做负载均衡，
    从一个服务的多台机器中选择一台
    
Feign:
    服务请求调用，基于Feign的动态代理机制，根据注解和选择的机器，拼接请求URL
    地址，发起请求

Hystrix:
    熔断器，发起请求是通过Hystrix的线程池来走的，不同的服务走不同的线程池，实
    现了不同服务调用的隔离，避免了服务雪崩的问题
    
Zuul:
    api路由网关，如果前端、移动端要调用后端系统，统一从Zuul网关进入，由Zuul网
    关转发请求给对应的服务
    
gateWay:
    zuul替代品