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替代品